Modularize Discovery Protocols as Pods

Is your feature request related to a way you would like Akri extended? Please describe.
Currently, protocol discovery is all implemented in the Akri Agent, which as explained in the protocol extension proposal makes the Agent bigger than needed (if someone is not using all the protocols), creates a larger attack surface, and requires discovery protocols to be written in rust.
Akri should be able to be deployed with only the desired discovery protocols, and discovery protocols should be able to be added without changing Akri's core components (the Agent, Controller, and Configuration CRD). This would make extending Akri easier.
Describe the solution you'd like
This could be done by implementing idea 3 of the protocol extension proposal, wherein protocols are implemented as pods and exposed over a gRPC interface. The DiscoveryHandler's two methods are_shared and discover could be exposed over this interface.
Additionally, the Configuration CRD would need to be modified so protocols are generic rather than explicitly defined in the CRD. Potentially as a map, as mentioned in this thread.
Also, the Agent should still be able to be compiled with DiscoveryHandlers in case users want the smaller footprint of one Agent pod rather than Agent pod + 1 pod for each DiscoveryHandler.
Describe alternatives you've considered
Other ideas listed in the protocol extension proposal, such as exposing the Agent as a library.
Additional context
The Zeroconf protocol #163  increases the Agent's size considerably and would benefit from running in its own Pod.

I'll try to add some thoughts I have on my mind. I personally don't know gRPC, I've used only old RPC in my past so I don't have anything against it. I'd like just to point some benefits of REST over gRPC:

I think it's easier for people working with REST/HTTP rather than gRPC
The agent don't even need to actually run as pod inside the cluster. As far as agent and handler are able to communicate HTTP in some way, they can talk to each other. Not sure if gRPC can also do it, maybe yes since I think it has been designed at L7 level for that purpose.

This allows to locally test the handler during development. I think it's also easier to test HTTP rather than gRPC, there are many tools to work with HTTP like curl, Postman, etc.
This allows the discovery handler to be some external service, could be helpful for use cases where devices are managed by some service not within the cluster.
A random thought: do we even need a broker? Suppose I have my own external broker which handles discovery and communication with the devices. I think that's pretty common. In that case the cluster is only interested in knowing about those devices, via the agent-externalBroker communication, right? Then provisioning a device would mean allowing a connection between a cluster-pod to the external broker, without a in-cluster-broker.
RESTful communication is being supported with non-TCP protocols like CoAP which uses UDP. We give even more freedom to implementations.

Not strictly about REST:

What do you think about reversing the relationship? Instead of having the agent polling the discovery handler, we could have discovery handlers notify the agent pushing the discovered devices. This could save be potentially much less work for the agent.

I'll try to add some thoughts I have on my mind. I personally don't know gRPC, I've used only old RPC in my past so I don't have anything against it. I'd like just to point some benefits of REST over gRPC:

I think it's easier for people working with REST/HTTP rather than gRPC
The agent don't even need to actually run as pod inside the cluster. As far as agent and handler are able to communicate HTTP in some way, they can talk to each other. Not sure if gRPC can also do it, maybe yes since I think it has been designed at L7 level for that purpose.

This allows to locally test the handler during development. I think it's also easier to test HTTP rather than gRPC, there are many tools to work with HTTP like curl, Postman, etc.
This allows the discovery handler to be some external service, could be helpful for use cases where devices are managed by some service not within the cluster.
A random thought: do we even need a broker? Suppose I have my own external broker which handles discovery and communication with the devices. I think that's pretty common. In that case the cluster is only interested in knowing about those devices, via the agent-externalBroker communication, right? Then provisioning a device would mean allowing a connection between a cluster-pod to the external broker, without a in-cluster-broker.
RESTful communication is being supported with non-TCP protocols like CoAP which uses UDP. We give even more freedom to implementations.

Not strictly about REST:

What do you think about reversing the relationship? Instead of having the agent polling the discovery handler, we could have discovery handlers notify the agent pushing the discovered devices. This could save be potentially much less work for the agent.

I happen to be in the opposite boat, more familiar with gRPC than REST; however, I can see how REST may be better, especially since discovery handlers would only need to support two endpoints: one for discover that returns all devices and the other for are_shared to specify whether the devices can be accessed/seen by more than one node.
For testing gRPC, there is a grpCURL tool that @DazWilkin blogged about using to inspect Akri's Device Plugin's with are gRPC over UDS.
For your point about brokers not always being necessary, I agree. Brokers are currently optional, and Akri can just discover (which could mean reaching out to an external broker that exposes the REST/gRPC interface) and expose those devices to the cluster as Kubernetes resources, but not deploy a broker to the device. Is this what you were thinking?
As for push vs pull, I was wondering the same. Pulling/polling makes sense with the current flow of applying a Configuration kicking off action in Akri. In a pull scenario, the Agent would see a Configuration and then reach out to some endpoint specified in the Configuration to discover devices. If it was a push scenario, what would the Agent do in response to seeing a Configuration? Would it be ready to receive information about devices from an endpoint specified in a Configuration?

I happen to be in the opposite boat, more familiar with gRPC than REST; however, I can see how REST may be better, especially since discovery handlers would only need to support two endpoints: one for discover that returns all devices and the other for are_shared to specify whether the devices can be accessed/seen by more than one node.
For testing gRPC, there is a grpCURL tool that @DazWilkin blogged about using to inspect Akri's Device Plugin's with are gRPC over UDS.
For your point about brokers not always being necessary, I agree. Brokers are currently optional, and Akri can just discover (which could mean reaching out to an external broker that exposes the REST/gRPC interface) and expose those devices to the cluster as Kubernetes resources, but not deploy a broker to the device. Is this what you were thinking?
As for push vs pull, I was wondering the same. Pulling/polling makes sense with the current flow of applying a Configuration kicking off action in Akri. In a pull scenario, the Agent would see a Configuration and then reach out to some endpoint specified in the Configuration to discover devices. If it was a push scenario, what would the Agent do in response to seeing a Configuration? Would it be ready to receive information about devices from an endpoint specified in a Configuration?

Akri can just discover (which could mean reaching out to an external broker that exposes the REST/gRPC interface) and expose those devices to the cluster as Kubernetes resources, but not deploy a broker to the device

Yes exactly

If it was a push scenario, what would the Agent do in response to seeing a Configuration? Would it be ready to receive information about devices from an endpoint specified in a Configuration?

Good question indeed. Does it need to do something though? It could maybe have only one endpoint/interface for receiving discovered devices, but a new configuration would mean that more device types are accepted. Otherwise it could reject unknown configurations.
I don't know if this is the right issue but I have an issue on my mind with CoRE. CoRE via CoAP basically works this way:

You send GET :5683:well-known/core via multicast or by knowing the device IP.
The device responds with a list of REST resources it can offer, such as /temperature and /humidity with types oic.r.temperature and oic.r.humidity as defined by IANA. (Actually I don't know if oic.r.humidy exists)
How should I register this information?

I can register the device and it has a generic name like coap-core-614135. From its metadata, I can see the applied properties like oic.r.temperature:  /sensors/temp. Now if the cluster needs a temperature sensor, it can search through the akrii list and look for an instance with oic.r.temperature. Then look for the broker associated and allow to reach its service.
This flow is reasonable but I wonder if it could be improved or what use cases cannot be solved. What if I want a broker which can aggregate all temperature measurements from the devices to give a more accurate result?
By allowing the discovery handler to push new devices instead of polling, maybe we can support a big number of devices types. Currently a Configuration means a discovery protocol AFAIK, whereas it could mean a device type instead. It would be impractical to have a discovery handler for each resource type and ask the agent to poll each one. The reverse seems to be more pratical instead. I can have a discovery handler per protocol and push new devices along with new resource types.
I hope it makes sense and can add another perspective to this issue.

Akri can just discover (which could mean reaching out to an external broker that exposes the REST/gRPC interface) and expose those devices to the cluster as Kubernetes resources, but not deploy a broker to the device

Yes exactly

If it was a push scenario, what would the Agent do in response to seeing a Configuration? Would it be ready to receive information about devices from an endpoint specified in a Configuration?

Good question indeed. Does it need to do something though? It could maybe have only one endpoint/interface for receiving discovered devices, but a new configuration would mean that more device types are accepted. Otherwise it could reject unknown configurations.
I don't know if this is the right issue but I have an issue on my mind with CoRE. CoRE via CoAP basically works this way:

You send GET :5683:well-known/core via multicast or by knowing the device IP.
The device responds with a list of REST resources it can offer, such as /temperature and /humidity with types oic.r.temperature and oic.r.humidity as defined by IANA. (Actually I don't know if oic.r.humidy exists)
How should I register this information?

I can register the device and it has a generic name like coap-core-614135. From its metadata, I can see the applied properties like oic.r.temperature:  /sensors/temp. Now if the cluster needs a temperature sensor, it can search through the akrii list and look for an instance with oic.r.temperature. Then look for the broker associated and allow to reach its service.
This flow is reasonable but I wonder if it could be improved or what use cases cannot be solved. What if I want a broker which can aggregate all temperature measurements from the devices to give a more accurate result?
By allowing the discovery handler to push new devices instead of polling, maybe we can support a big number of devices types. Currently a Configuration means a discovery protocol AFAIK, whereas it could mean a device type instead. It would be impractical to have a discovery handler for each resource type and ask the agent to poll each one. The reverse seems to be more pratical instead. I can have a discovery handler per protocol and push new devices along with new resource types.
I hope it makes sense and can add another perspective to this issue.

~~Currently a Configuration means a discovery protocol AFAIK, whereas it could mean a device type instead. ~~
Maybe you crossed out this line because you came to the same conclusion, but while a discovery protocol is specified in a Configuration, a Configuration is specific to a device type, which is why you also specify filters in a Configuration. For example, for a Configuration to discover local video devices, you specify the udev protocol and the filter (udev rule)  KERNEL=video[0-9]*.

That's a good point that, currently, we do discovery for each Configuration/device type, so the more device types/ Configurations, the more polling the Agent has to do.

This flow is reasonable but I wonder if it could be improved or what use cases cannot be solved. What if I want a broker which can aggregate all temperature measurements from the devices to give a more accurate result?
Are you wondering about whether we could have one broker for multiple instances? Currently, we only have one "broker deployment strategy" of one broker per instance. This is a limiting use case, and we'd love to support others, such as the one you mention, which we describe as "Instance Pooling" in our broker deployment strategies proposal

~~Currently a Configuration means a discovery protocol AFAIK, whereas it could mean a device type instead. ~~
Maybe you crossed out this line because you came to the same conclusion, but while a discovery protocol is specified in a Configuration, a Configuration is specific to a device type, which is why you also specify filters in a Configuration. For example, for a Configuration to discover local video devices, you specify the udev protocol and the filter (udev rule)  KERNEL=video[0-9]*.

That's a good point that, currently, we do discovery for each Configuration/device type, so the more device types/ Configurations, the more polling the Agent has to do.

This flow is reasonable but I wonder if it could be improved or what use cases cannot be solved. What if I want a broker which can aggregate all temperature measurements from the devices to give a more accurate result?
Are you wondering about whether we could have one broker for multiple instances? Currently, we only have one "broker deployment strategy" of one broker per instance. This is a limiting use case, and we'd love to support others, such as the one you mention, which we describe as "Instance Pooling" in our broker deployment strategies proposal

If we use the method of discovery handler pods pushing discovery results to the agent, how do we prevent a denial of service attack or the Agent being overloaded by too many results?

If we use the method of discovery handler pods pushing discovery results to the agent, how do we prevent a denial of service attack or the Agent being overloaded by too many results?

I'm familiar with both gRPC and REST. REST is conventionally JSON and HTTP but need not be; Constrained RESTful Environments (CoRE) is REST/UDP . gRPC is conventionally protobuf messages over HTTP/2 but need not be.
It is true that there are more developer tools available with REST but this is partly because REST is more common. Whether REST-like or RPC-like is chosen, Akri should consider providing SDKs for the popular languages (via OpenAPI or Protos) so that Akri discovery protocol developers can use a known-good SDK rather than be exposed to what should be an implementation detail.
Request-Response, polling, streaming, bidirectional etc are implementation decisions and don't affect, for example, where handlers and agents may run (both permit running handlers remotely).
gRPC is probably better if:

Consistency with a in-process Rust mechanism is desired; because gRPC is RPC it is closer to the current Rust SDK
We consider protocol implementations to be Akri microservices; peers rather than clients?
Bidirectional|Streaming is desired; gRPC clients and servers can stream events to one another
gRPC provides mechanisms that expose services as REST/HTTP for non-gRPC uses
With apologies for being circular, gRPC Is probably better if RPC better matches the interaction pattern

REST is probably better if:

It is considered important to ease the debugging of handler client-server (!) flows; if both must be servers, is this complex?
Protocol implementations are clients of Akri; if not, would we need to add e.g. WebSockets for callbacks?
OpenAPI describes sufficient typing to offset any benefits of protobufs
With apologies for being circular, REST Is probably better if the Akri discovery host is more of a set of resources with state

Kubernetes' components frequently use gRPC service-service but the API Server (clients-service) is almost exclusively REST.

I'm familiar with both gRPC and REST. REST is conventionally JSON and HTTP but need not be; Constrained RESTful Environments (CoRE) is REST/UDP . gRPC is conventionally protobuf messages over HTTP/2 but need not be.
It is true that there are more developer tools available with REST but this is partly because REST is more common. Whether REST-like or RPC-like is chosen, Akri should consider providing SDKs for the popular languages (via OpenAPI or Protos) so that Akri discovery protocol developers can use a known-good SDK rather than be exposed to what should be an implementation detail.
Request-Response, polling, streaming, bidirectional etc are implementation decisions and don't affect, for example, where handlers and agents may run (both permit running handlers remotely).
gRPC is probably better if:

Consistency with a in-process Rust mechanism is desired; because gRPC is RPC it is closer to the current Rust SDK
We consider protocol implementations to be Akri microservices; peers rather than clients?
Bidirectional|Streaming is desired; gRPC clients and servers can stream events to one another
gRPC provides mechanisms that expose services as REST/HTTP for non-gRPC uses
With apologies for being circular, gRPC Is probably better if RPC better matches the interaction pattern

REST is probably better if:

It is considered important to ease the debugging of handler client-server (!) flows; if both must be servers, is this complex?
Protocol implementations are clients of Akri; if not, would we need to add e.g. WebSockets for callbacks?
OpenAPI describes sufficient typing to offset any benefits of protobufs
With apologies for being circular, REST Is probably better if the Akri discovery host is more of a set of resources with state

Kubernetes' components frequently use gRPC service-service but the API Server (clients-service) is almost exclusively REST.

I think k8s is a good example of gRPC vs REST indeed. For internal communication between parts gRPC is more immediate because it's closer to the SDK/language itself. For more higher-level communication between heterogeneous components REST has more advantages. So I agree gRPC or REST can be decided later after choosing the agent architecture.

Maybe you crossed out this line because you came to the same conclusion, but while a discovery protocol is specified in a Configuration, a Configuration is specific to a device type, which is why you also specify filters in a Configuration.

I crossed because I couldn't think of anything better 😄 I still feel that a Configuration is a more a discovery protocol than device type and you can filter what is discovered. For instance, to support CoRE I need to add a new Configuration. But CoRE is not a device type, it's a discovery protocol indeed. Actually I don't even think there is a concept of device types in CoRE, both CoRE and CoAP talk about resource types because a device might provide different sensor data like both temperature and humidity. By talking about resources types instead of device types, the latter don't matter. A camera could provide both video and audio resources.

If we use the method of discovery handler pods pushing discovery results to the agent, how do we prevent a denial of service attack or the Agent being overloaded by too many results?

If you mean malicious DOS, I believe it's out of the scope of akri. If you allow external services to communicate in any way to your cluster it's up to you to make it safe. Overloading could instead solved by horizontal scaling maybe? In the case of many results, even the pull approach would have severe issues. Maybe it would even be harder to scale horizontally because you should decide how to distribute the polling operations between the agents.

I think k8s is a good example of gRPC vs REST indeed. For internal communication between parts gRPC is more immediate because it's closer to the SDK/language itself. For more higher-level communication between heterogeneous components REST has more advantages. So I agree gRPC or REST can be decided later after choosing the agent architecture.

Maybe you crossed out this line because you came to the same conclusion, but while a discovery protocol is specified in a Configuration, a Configuration is specific to a device type, which is why you also specify filters in a Configuration.

I crossed because I couldn't think of anything better 😄 I still feel that a Configuration is a more a discovery protocol than device type and you can filter what is discovered. For instance, to support CoRE I need to add a new Configuration. But CoRE is not a device type, it's a discovery protocol indeed. Actually I don't even think there is a concept of device types in CoRE, both CoRE and CoAP talk about resource types because a device might provide different sensor data like both temperature and humidity. By talking about resources types instead of device types, the latter don't matter. A camera could provide both video and audio resources.

If we use the method of discovery handler pods pushing discovery results to the agent, how do we prevent a denial of service attack or the Agent being overloaded by too many results?

If you mean malicious DOS, I believe it's out of the scope of akri. If you allow external services to communicate in any way to your cluster it's up to you to make it safe. Overloading could instead solved by horizontal scaling maybe? In the case of many results, even the pull approach would have severe issues. Maybe it would even be harder to scale horizontally because you should decide how to distribute the polling operations between the agents.

I put together a spec on hackmd, pulling in a lot of this discussion into a design that I am working on implementing now. Would love to hear any comments people have on HackMD.

I put together a spec on hackmd, pulling in a lot of this discussion into a design that I am working on implementing now. Would love to hear any comments people have on HackMD.

Good job!

I tried to comment from my phone but I was challenged :smile: After switching to a laptop...

I've added some preliminary feedback.
I need to better educate myself on the message flows between an Agent and disconnected DiscoveryHandler but I think, since we already have the in-process calling mechanism defined (by the Rust SDK), and, if we agree that this mechanism is correct, then the RPC implementation should closely (exactly?) model it. gRPC's tagline after all, should be something like "develop as if you were just using an infinitely large computer"!

Good job!

I tried to comment from my phone but I was challenged :smile: After switching to a laptop...

I've added some preliminary feedback.
I need to better educate myself on the message flows between an Agent and disconnected DiscoveryHandler but I think, since we already have the in-process calling mechanism defined (by the Rust SDK), and, if we agree that this mechanism is correct, then the RPC implementation should closely (exactly?) model it. gRPC's tagline after all, should be something like "develop as if you were just using an infinitely large computer"!

Thanks for the feedback @DazWilkin and @jiayihu, it has led me to pivot a bit. It makes sense for the response to an Agent's call on a DH to be a streamed response, like ListAndWatch in Device Plugin. This allows the DH to determine the rate at which to update the agent instead of vice versa, since it is likely to be protocol specific

Thanks for the feedback @DazWilkin and @jiayihu, it has led me to pivot a bit. It makes sense for the response to an Agent's call on a DH to be a streamed response, like ListAndWatch in Device Plugin. This allows the DH to determine the rate at which to update the agent instead of vice versa, since it is likely to be protocol specific


Adding variables as Kubernetes secrets airflow is adding a linebreak

What is the bug?
When a variable is added as kubernetes secrets, airflow is adding a linebreak at the end. Once helm chart is installed if I go to admin->variables, and export them, I can see the linebreak:
ej;
"source_username": "qaperformance@performance-db\n",
"target_db_name": "targetperformance\n",
"target_host": "performance-db.postgres.database.azure.com\n",
this problem not happen if I set the variables in values.yaml without using secrets.
What version of the chart are you using?:
I am using version 8.4.1
What is your Kubernetes Version?:
1.16.7
$ kubectl version
Server Version: version.Info{Major:"1", Minor:"16", GitVersion:"v1.16.7", GitCommit:"2b13e288f94dd2577d4ff7261f9eb76b1d5692a1", GitTreeState:"clean", BuildDate:"2020-06-01T21:55:34Z", GoVersion:"go1.13.6", Compiler:"gc", Platform:"linux/amd64"}

What is your Helm version?:
$ helm version
3.0

Please copy your custom Helm values file:
airflow:

  legacyCommands: false
  config:
    ## Database
    ## Security
    AIRFLOW__CORE__ENABLE_XCOM_PICKLING: 'true'

  image:
    repository: apache/airflow
    tag: 2.1.1-python3.8
    ## values: Always or IfNotPresent
    pullPolicy: IfNotPresent
    pullSecret: "jfrog-regcred"
    uid: 50000
    gid: 50000

  variables:
   - key: "source_db_name"
     value: ${source_db_name}
   - key: "source_host"
     value: ${source_host}
   - key: "source_password"
     value: ${source_password}
   - key: "source_username"
     value: ${source_username}
   - key: "target_db_name"
     value: ${target_db_name}
   - key: "target_host"
     value: ${target_host}
   - key: "target_password"
     value: ${target_password}
   - key: "target_username"
     value: ${target_username}
   - key: "target_username3"
     value: ${target_username}

  variablesTemplates:
    source_db_name:
     kind: secret
     name: db-airflow
     key: source_db_name
    source_host:
     kind: secret
     name: db-airflow
     key: source_host
    source_password:
     kind: secret
     name: db-airflow
     key: source_password
    source_username:
     kind: secret
     name: db-airflow
     key: source_username
    target_db_name:
     kind: secret
     name: db-airflow
     key: target_db_name
    target_host:
     kind: secret
     name: db-airflow
     key: target_host
    target_password:
     kind: secret
     name: db-airflow
     key: target_password
    target_username:
     kind: secret
     name: db-airflow
     key: target_username
  variablesUpdate: true

  users:
    - username: admin
      password: ${ADMIN_PASSWORD}
      firstName: admin
      lastName: admin
      role: Admin
      email<EMAIL_ADDRESS>    - username: architect
      password: ${ARCH_PASSWORD}
      role: Admin
      firstName: admin
      lastName: admin
      email<EMAIL_ADDRESS>    - username: useradmin
      password: admin
      role: Admin
      email<EMAIL_ADDRESS>      firstName: admin
      lastName: admin

  usersTemplates:
    ADMIN_PASSWORD:
      kind: secret
      name: users-airflow
      key: admin-password
    ARCH_PASSWORD:
      kind: secret
      name: users-airflow
      key: arch-password
  usersUpdate: true

postgresql:
  enabled: false

scheduler:
  initdb: true
  extraInitContainers:
    - name: analytics-db-migrations
      image: ""
      command:
        - /bin/bash
        - -c
        - |
          mkdir -p /home/airflow/.local/bin \
          && echo 'export PATH="/home/airflow/.local/bin:$PATH"' \
          && echo "*** executing Alembic upgrade..." \
          && alembic upgrade head

externalDatabase:
  type: postgres
  host: performance-db.postgres.database.azure.com
  port: 5432
  database: airflowperformance
  user: airflowperformance@performance-db
  passwordSecret: "postgress-password"
  passwordSecretKey: "postgresql-password"
  properties: ""

@roquemoyano-tc I can't see a way that newlines would be introduced (especially if it's only in variables), can you provide the YAML for your db-airflow Secret?
I have a feeling you will be using a multiline YAML string like this:
apiVersion: v1
kind: Secret
metadata:
  name: db-airflow
stringData:
  # "|" it will add a newline to the end
  source_username: |
    qaperformance@performance-db

  # "|-" has no newline
  source_username: |-
    qaperformance@performance-db

I also have a few unrelated questions about your values (which look strange):

Why are you setting scheduler.initdb (this is not a value since 8.0.0)
Why do you need to set scheduler.extraInitContainers
I am surprised that externalDatabase.user is working with an @ symbol in it (given issue https://github.com/airflow-helm/charts/issues/318 is not fixed in 8.4.1)


release-6.5 has large memory(object) allocation and deallocation

What did you do?
run two cdc servers with release-6.5@https://github.com/pingcap/tiflow/commit/d520bc9915fe1c7d2ed45dea5519bbfb14eb928d, start a changefeed with 5000 tables. Observe the memory usage.
What did you expect to see?
No response
What did you see instead?
Memory metrics

allocate_objects in heap profile

heap profile raw file:
heap.profile.with_table_stats_1.zip
Versions of the cluster
release-6.5@https://github.com/pingcap/tiflow/commit/d520bc9915fe1c7d2ed45dea5519bbfb14eb928d

One memory allocate point is table.Stats
The other one is sendResolvedTs in kv client

/label affects-6.5

refresh

Will be fixed by #8015


plyr shows thumbnails only before 60 minutes

Hi
I have a video that is about 80 minutes. I create thumbnail image and vtt files correctly. When I hover the progress bar it shows it without problem but when I hover over 60 minutes on bar it shows it very quickly and it disappears.
I use plyr 3.6.7  and test it both in Firefox and chrome.

No one have same issue?

I have this exact same issue - I'm 98% sure this is a bug - thumbnails only show up to 60 minutes - despite changing the tile size, trying different height / width's nothing seems to fix this - plus what makes it worse is there are no examples of any videos > 1 hour so how am I supposed to check if I'm doing it right?
I'm using plyr 3.7.2 (polyfilled)
I have not tested this in other browsers as of yet (I'm using Chrome)
I hope this gets fixed


Issue with High Sierra

Since merging in #10 the app has been working but today I tested on mac OS High Sierra and saw a lot of
2019-05-14 23:30:17.338 main[50763:1244727] pid(50763)/euid(501) is calling TIS/TSM in non-main thread environment, ERROR : This is NOT allowed. Please call TIS/TSM in main thread!!!
and the app never started.
It seems like the "core.Run()" is required to be called from the main thread on mac OS that is not required on Linux.
I cannot seem to get to the bottom of this so thought I would log this issue instead.
I suspect that there are some OS input handling baked into the core package that I did not find when extracting the last of the graphics code to the "driver" package.

It seems that macOS requires that the speaker run on the main thread. The proposed pull request fixes this and should resolve the issues for this gui driver. It unfortunately creates new problems for a Fyne based driver as the render thread blocks. I will try to learn how a speaker loop and a graphics loop could be interpolated...


Add np.longlong to the set of JAX array types.

Note for posterity: this was particularly tricky to figure out due to https://github.com/numpy/numpy/issues/12264 which means that numpy.longlong prints as numpy.int64


[17.06] backport (cli) If docker swarm ca is not called with the --rotate flag, warn if other flags are passed

Backport fix:

docker/cli/pull/207 If docker swarm ca is not called with the --rotate flag, warn if other flags are passed

With cherry-pick of docker/cli@32b43bc and docker/cli@4615c92:
$ git cherry-pick -s -x -Xsubtree=components/cli 32b43bc 4615c92

Conflict with components/cli/cli/command/swarm/ca_test.go in that the docker/cli@4615c92 cherry-pick wanted to modify it and it did not exist on the 17.06 branch. Resolved the conflict by not apply the diff to that file.

@cyli when you get the chance can you have a look at this backport?

@andrewhsu That definitely matches the change in the https://github.com/docker/cli/pull/207, however I noticed a comment indicating a bug in that partiuclar fix, so have openned https://github.com/docker/cli/pull/328.
The only change is to change that second flagCACert to flagCertExpiry.  I'm not sure how to cherry-pick that change, since there was a refactor between https://github.com/docker/cli/pull/207, and https://github.com/docker/cli/pull/328.

I just merged https://github.com/docker/cli/pull/328 - if it doesn't apply cleanly, perhaps just add a second commit to the PR to perform the fix

I brought in the commit from docker/cli#328:
$ git cherry-pick -s -x -Xsubtree=components/cli 4615c92f

Conflict with components/cli/cli/command/swarm/ca_test.go in that the docker/cli@4615c92 cherry-pick wanted to modify it and it did not exist on the 17.06 branch. Resolved the conflict by not apply the diff to that file.

LGTM on green, thanks @andrewhsu and @thaJeztah!


Cross-chain loan mechanism

We would like to see a cross-chain (Tezos <> EVM) mechanism for loans, with collateral on one chain, and the loan being extended on another, with automated, decentralized mechanism protecting both sides from abuse.
Rationale
Looking at the current crypto ecosystem, it is likely that users will increasingly own various holdings, both NFTs and fungible assets, across various blockchains.
We would like to allow asset holders to temporarily pool or transfer value from one chain to another, by entering loan agreements with other users who have liquid assets on the target chain they might be willing to lend out for interest income.
Requirements
Fully decentralized mechanism, without centralized bookkeeper or administrator
Enabling parties who do not know or trust each other to enter agreements easily
Built-in disincentive against using the mechanism for permanent value transfer between chains
Judging criteria
Potential impact: Envisioned impact of your project
Novelty: Innovativeness of the project
Technical: Does the code work? Is it secure?
Design and UX: How is the look and feel and how intuitive is the design?
Track requirements:
Submissions must be open source (MIT license)
Submission with a working prototype must be deployed live on the current testnet
Submissions must list the addresses of their token contracts
Prize
Prize (1 team)
$10,000 in tez (XTZ) at the time of payout
On bounty deliverables
We would like to provide guidelines on what we expect to see out of the hackathon. We are aware that the topics we're putting up for bounties are complex, and scope might have to be defined narrowly to allow delivery within the hackathon's timeframe.
The concrete deliverables we expect out of a bounty application are:

Whitepaper describing the mechanism, with analysis from economic and game theoretical perspectives

The analysis doesn't have to be in-depth at this stage, but we want to see that thought was put into the idea

Decentralized Minimum Viable Product showcasing all key components of the mechanism

Prioritize backend completeness over frontend flashiness
Write clean code following best practices
Cleanly separate various components of your architecture
Document enough to allow reviewers to fully understand what you did

Writeup on what the product backlog for reaching what you'd consider 'completion' looks like

Keep in mind that the purpose of your deliverables are to convince people almost as smart as yourselves that your idea is viable, and you are capable of delivering a reliable, working product.
Developer resources
For those who are completely new to Tezos development, the dev portal is a good place to start https://developers.tezos.com/
Tacode, a p2p learning platform for Tezos teaches you how to build a Dapp on Tezos while earning tez
https://tacode.dev
OpenTezos is an open-source wiki on all topics Tezos
https://opentezos.com/
A guide how to mint NFTs on Tezos and how to build a simple NFT platform
https://medium.com/ecad-labs-inc/how-to-mint-nfts-on-tezos-using-taquito-and-pinata-15a407078495
A react provider for Dapps to easily setup connection to Beacon/Taquito wallets
https://github.com/tz-contrib/components-library/tree/develop/packages/react-wallet-provider
Awesomelist for Tezos
https://github.com/tz-contrib/awesome-tezos
Tezos Stack Exchange is a useful resource to where you can see answers to technical questions regarding Tezos
https://tezos.stackexchange.com/
If you do not find answers to your technical questions on the Tezos Stack Exchange, join the Tezos Developers telegram channel and ask away
https://t.me/TezosDevelopers

Hello everyone,
We have a solution for this.. here's the working MVP on testnet https://ne-crosschain.staging.newearthart.tech/
The code is at https://github.com/shreedee/tezos-cross-chain-Loan.
And the whitepaper is enclosed.
Would appreciate your comments
ne cross chain loans - litepaper.pdf


Exposing MqttClientConnection in incoming message

Exposing MqttClientConnection (Certificate, Username and Password data) on receiving the message (Broker)

Thank you for your contribution. I can not merge this because it breaks some rules of that lib. The MQTT connection is an internal thing and should not be exposed to public API.
But I think I understand the idea behind that. Please try to solve your use case by using the new session items. There you can store every information you need. Also the whole connection validator context if you like.

@rudacs You can find a description of the SessionItems object here: https://github.com/chkr1011/MQTTnet/wiki/Server#storing-data-in-the-session. It is avaiable from the version 3.0.6-beta1.


change(rpc): Select getblocktemplate RPC transactions according to ZIP-317

Motivation
We want to select transactions for block production according to ZIP-317.
Close #5473.
Specifications
https://zips.z.cash/zip-0317#recommended-algorithm-for-block-template-construction
Designs
Follow the recommended algorithm in the specification.
Use f32 for efficient calculations and weight storage.
Use a minimum fee weight of 1.0 / 20.0 to simplify the implementation. (This is not in the spec, but changes are allowed because it is not consensus-critical. If the ZIP editors disagree with this, I'll open another PR to fix it.)
Use the same random weight APIs that we use in mempool transaction eviction.
Some parts of this PR are outside the getblocktemplate-rpcs feature, because we will probably use them in ticket #5336.
Solution

Add a block_production_fee_weight field to VerifiedUnminedTx
Add a custom Zebra minimum transaction weight for block production
Randomly select transactions for block production according to ZIP-317

Related Refactors:

Move getblocktemplate transaction selection into a new zip317 module
Split the conventional fee check into its own method

This PR has some testing from the existing test vectors and snapshot tests.
The rest of its tests will be implemented as part of ticket #5652.
Review
We should probably get two reviews on this.
Reviewer Checklist

[ ] Will the PR name make sense to users?

[ ] Does it need extra CHANGELOG info? (new features, breaking changes, large changes)

[ ] Are the PR labels correct?
[ ] Does the code do what the ticket and PR says?
[ ] How do you know it works? Does it have tests?

The code in this PR will have further changes after a ZIP update. I suggest we review and merge it based on the current ZIP-317, and then do the update in a separate PR based on ticket #5752.
That will make reviewing the update easier, because the diff will be smaller.

(Oops, pressed the wrong button.)

@mergifyio refresh

Note that the algorithm has changed, as discussed in ZIP sync. PR here: https://github.com/zcash/zips/pull/650

I wouldn't bother restarting the tests in this PR, I'm going to update the code tomorrow anyway,


[path] Add tests for simplified regex matching various path conventions

Is this a BUG REPORT or FEATURE REQUEST?:
feature
What happened:
Currently we use a hardcoded simple regex.
What you expected to happen:
Test many more path conventions to make sure we use the correct regex.
Anything else we need to know?:
example.com/path/routing -> _redirect.routing.path.example.com
example.com/path-routing -> _redirect.path-routing.example.com
example.com/path-routing/test -> _redirect.test.path-routing.example.com
example.com/path_routing/test -> ?
example.com/special-chars/#?%! -> ?
example.com/path2routing/nested/test/ -> _redirect.test.nested.path2routing.example.com
example.com/123/test -> _redirect.test.123.example.com
example.com/path-routing?query=string -> _redirect.path-routing.example.com
example.com/path-routing?query=string&more=strings -> _redirect.path-routing.example.com

We've fixed this issue in #52

Correct.


Syncing with upstream ipfs-service-provider

:tada: This PR is included in version 1.13.5 :tada:
Your semantic-release bot :package::rocket:

:tada: This PR is included in version 1.13.5 :tada:
Your semantic-release bot :package::rocket:


Missing file: 'sqlite3.h' file not found

I'm trying to execute simple and small project that include 4 forms, imported from iOS Xcode and then i got some problems. This is one of them:
· The import of "sqlite3.h" (#import <sqlite3.h>) can't find the file.

You'll need to install sqlite's "VSIX package for Universal App Platform development using Visual Studio 2015" from http://sqlite.org/download.html

Installed, and also NuGet package of sqlite3 but doesn't work.

As far as I know, you only need to install the UAP .vsix: http://sqlite.org/2016/sqlite-uap-3100100.vsix.  Perhaps the Nuget package references are getting in the way?

"sqlite3" library got from Nuget Package, It doesn't work.

None of the sqlite Nuget packages that I found work.  Have you tried removing all of your Nuget package references and instead relying solely on the UAP .vsix from sqlite.org?  I am unable to repro your issue when using only sqlite's UAP .vsix: http://sqlite.org/2016/sqlite-uap-3100100.vsix

I only have "sqlite3" Nuget pacakge active in my solution but don't run anyway.
Also have both packages you said installed and the error won't disappear.

Hi Raul, can you confirm that the SQLite extension is installed successfully by opening the Visual Studio menu: Tools -> Extension & Updates.
If it is successfully installed, it should be listed under "Installed -> SDKs" as "SQLite for Universal App Platform"

Thanks, Raul.  I just realized that you also need to add the Sqlite UAP extension as a reference to your project.  In Solution Explorer, expand your project's node, right click on 'References', then hit 'Add Reference...'.  Click 'Extensions' under 'Universal Windows', check the box next to 'Sqlite for Universal App Platform', then hit 'OK'.

Nice! thx mate :+1:


tuxmux: 0.1.0 -> 0.1.1

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://github.com/edeneast/tuxmux/releases.
meta.description for tuxmux is: Tmux session manager
meta.homepage for tuxmux is: https://github.com/edeneast/tuxmux
Updates performed

Rust version update

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact

Checks done (click to expand)

built on NixOS
The tests defined in passthru.tests, if any, passed
found 0.1.1 with grep in /nix/store/bayrpap11bwadlshl6aal9gzw2vn4ya6-tuxmux-0.1.1
found 0.1.1 in filename of file in /nix/store/bayrpap11bwadlshl6aal9gzw2vn4ya6-tuxmux-0.1.1

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

1 total rebuild path(s)

1 package rebuild(s)

First fifty rebuilds by attrpath
tuxmux

Instructions to test this update (click to expand)

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

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

Or:
nix build github:r-ryantm/nixpkgs/1de438bb7bf71cbcf52ec6cdb7e9d3691b6581cc#tuxmux

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

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

1 package built:

tuxmux

Maintainer pings
cc @edeneast for testing.

This version does not depend on openssl anymore and can be removed. See #264858 for package update.


Fetch plotlyJS bundle from source url

Part of https://github.com/plotly/streambed/issues/10473

@etpinard Please review.. cc: @scjody

Another way to do this would be to run the curl command in the run_server script - that's what I had in mind when I suggested curl. But as long as the solution retries with exponential backoff and a maximum delay, I'm happy.

Another way to do this would be to run the curl command in the run_server script - that's what I had in mind when I suggested curl

That sounds to me like a more robust solution :+1:

Looking at the initial comments, it seems using curl directly inrun_server and adding a --fetch CLI argument makes more sense.. I can try that approach .. !!

Can you explain what happens if plotly.js can't be retrieved within 10 retries?

As per the current code, it will throw an Error. The server would still start, but it wont be working. Therefore I think adding it in run_server makes more sense, because then container will explicitly Fail.

The image-exporter can already use a local plotly.js (retrieved by curl in this case), can't it? I don't understand the need for --fetch, unless I'm mistaken here.

--fetch is to address @etpinard 's comment:

I'd vote for adding an CLI / API option here. For example a boolean --fetch-plotly.js or more generally --fetch-ressources as some users might still want to leave it to the electron to app to fetch their custom (i.e. non-CDN) plotly.js bundles.

That comment assumes that the server is doing the fetch though, doesn't it? If the server just has to use a local plotly.js, what would the --fetch option do?

No need for a CLI / API option if we're going with the -curl directly in run_server- route.

@tarzzz your latest patches look good to me, but deployment/ is @scjody's work so he's the main reviewer here.

It fails silently. imageserver will not start, but the other onprem services go on as usual.

Please come up with a solution that lets us keep trying until startup succeeds. Failing silently is not a good option (in this case, and in most cases).
If the imageserver container exits, it will be restarted until it succeeds, so that could help. Or you could use monit, which is already in the imageserver container.

Please come up with a solution that lets us keep trying until startup succeeds. Failing silently is not a good option (in this case, and in most cases).

I checked by adding an incorrect url in replicated (ie. which gives 404). So, the imageserver container will restart on failure. I was wondering whether the replicated dashboard should show the status for On Premise sevice as 'Started' or 'Starting' when this happens.. !!

Unless there is something wrong which prevents image-server from downloading the plotly-bundle.js at all,  this current approach will ensure that image-server is started properly (even if it takes multiple retries / container restarts).. !!

@scjody Please review the updates.. !! ( I am not sure if you have already 👀 them, but wanted to confirm)

@scjody Updates made.. !!


Performance indices should use remapcon

Currently remapbil is used to perform interpolation of all variables in the performance indices regridding. This is not appropriate for upscaling and something like remapcon should be used. The problem is that the unstructured nemo gri is missing corner data and so does not allow the use of remapcon

Branch genbil is currently addressing partially this issue, see also #21

This is deprecated since now with xarray+Xesmf we can use only bilinear interpolation. Closing, we might want to reopen this in the future if we go on with the sparse matrix interpolation approach


[dns] offer choice of all log levels

We use four log levels in our code - debug, info, warn, error - yet only allow selection of "all except debug" (the default) and "all" (when -debug is supplied).

I think warn and error should never be silenced, right?. I cannot imagine a situation where you don't want to see errors. If this is the case, that would leave info and debug as optional. Maybe we could -verbose/-v for enabling info, and a second -v or -debug could enable debug...


update internals links

Q
A

Is bugfix?
✔

New feature?
❌

Breaks BC?
❌

Fixed issues
https://github.com/yiisoft/yii2/issues/19297

Do you plan more changes?

Thanks. Maybe indeed it's worth to put all that kind of updates in one PR.


CFFL

CFFL

Linter check found the following problems:
The following problems have been found:
ERROR: /tmp/abs_89gsjz5l89/clone/recipe/meta.yaml:16: pip_install_args: pip install should be run with --no-deps.
ERROR: /tmp/abs_89gsjz5l89/clone/recipe/meta.yaml:21: missing_wheel: For pypi packages, wheel should be present in the host section
ERROR: /tmp/abs_89gsjz5l89/clone/recipe/meta.yaml:28: missing_imports_or_run_test_py: Python packages require imports or a python test file in tests.
ERROR: /tmp/abs_89gsjz5l89/clone/recipe/meta.yaml:28: missing_pip_check: For pypi packages, pip check should be present in the test commands
ERROR: /tmp/abs_89gsjz5l89/clone/recipe/meta.yaml:34: missing_license_family: The recipe is missing the about/license_family key.
WARNING: /tmp/abs_89gsjz5l89/clone/recipe/meta.yaml:34: missing_description: The recipe is missing a description
ERROR: /tmp/abs_89gsjz5l89/clone/recipe/meta.yaml:34: missing_documentation: The recipe is missing a doc_url or doc_source_url
ERROR: /tmp/abs_89gsjz5l89/clone/recipe/meta.yaml:34: missing_dev_url: The recipe is missing a dev_url
Errors were found


reCAPTCHA needs to be added.

There are a handful of spam messages coming through.

Users will need to be signed in to send messages in the next release. This functionality has been implemented in the dev branch. Now the user interface needs to be edited to inform users that this is the case.


[backport] Fix __getitem__ on Ellipsis and advanced indexing dimension

Backport of #6081 by @toslunar

/test mini

Jenkins CI test (for commit 3e1413ce19ada16ea614b0160145e84b306c0be2, target branch v10) succeeded!


login error use router

Description

Markup:

// Your code

Types of changes

[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] Improvement/refactoring (non-breaking change that doesn't add any feature but make things better)

Thanks :).


Use new Events endpoints to display events in search

The events currently displayed are mock events.

Use the /events content api endpoint instead
Check pagination works
Check if any tests need amending

/events endpoint merged in https://github.com/wellcomecollection/content-api/pull/81

in prod


Deleting user gives internal server error

This bug persists, as of 26/11/2021.

Deletion apparently removes the data (submitted missions) but then gives an "internal error".


Unit test RuntimeUtilSpec of module javalite-common fails on Windows

The tests of RuntimeUtilSpec fail on Windows, because they execute the system command ls that isn't available on Windows. RuntimeUtilSpec should either be skipped on Windows or use corresponding system command on Windows.

@cschabl since this is at your finger tips, can you send a pull request?
something like:

String command  = "ls";

if(System.getProperty("os)).contains("Windows"){
    command = "dir";
}

or similar?

@ipolevoy yes, I'll send one.


Add ProgressDeadlineSeconds

Fix https://github.com/Skyscanner/applicationset-progressive-sync/issues/63

Closing this. We will pick it up again if we really need this feature.


[staging & production] figshare file downloads do not keep name

Steps

Log into staging or production
Go to a project on which you have admin access
Go to the settings page for that project
Enable figshare and configure for project by linking a folder
Go to the files tab
Click on a file to view it in the files detail page
Click on the download button on the right hand of the screen to download the file
Go back to the files tab
Click to download the same file from the files tab

Expected
I expect that downloading the file would yield the same results in both places, whether in the files tab or file detail page.
Actual
Downloading a file from the files detail page works as expected, and the file is downloaded with the correct name. Downloading a file from the files tab, however, does not keep the file name and instead downloads all files as file.extension (file.png, file.pdf, file.jpeg, etc).

@chrisseto has already fixed this in the new waterbulter.

Deployed @chennan47 and @chrisseto ? So I can close ... (?)

@lbanner talked with @chrisseto. It needs a while to be ready.

OK - thanks.

Can anyone confirm this is fixed?

@caileyfitz can you do a double check here? Thanks

@lbanner @chrisseto Yes, this is fixed!


Seems to not work in Next.js

See stackblitz running example:
https://stackblitz.com/edit/nextjs-vngw87?file=pages/index.js
Shows in dev preview page:
Server Error
ReferenceError: exports is not defined in ES module scope
This file is being treated as an ES module because it has a '.js' file extension and '/home/projects/nextjs-vngw87/node_modules/reactjs-vimeo-player/package.json' contains "type": "module". To treat it as a CommonJS script, rename it to use the '.cjs' file extension.

This error happened while generating the page. Any console logs will be displayed in the terminal window.
Call Stack
async ModuleJob.run
https://nextjs-vngw87.w.staticblitz.com/blitz.3c06ff333fff62d153837b0d0df85b8ed07b008f.js (6:987580)
async ESMLoader.import
https://nextjs-vngw87.w.staticblitz.com/blitz.3c06ff333fff62d153837b0d0df85b8ed07b008f.js (6:1209286)

and in dev console:
error - Error: exports is not defined
    at file:///home/projects/nextjs-vngw87/node_modules/reactjs-vimeo-player/dist/index.cjs.js
    at async ModuleJob.run (https://nextjs-vngw87.w.staticblitz.com/blitz.3c06ff333fff62d153837b0d0df85b8ed07b008f.js:6:987580)
    at async Promise.all (index 0)
    at async ESMLoader.import (https://nextjs-vngw87.w.staticblitz.com/blitz.3c06ff333fff62d153837b0d0df85b8ed07b008f.js:6:1209286) {
  page: '/'
}

Hello @grempe!
You need to bump the version of react and react-dom to version >= 18. I made a test and the video player render occurred with success.

I will work on adjusting to try retrocompatibility to both versions of React (17 and 18).

Altough the player renders on the frontend, I got the same error with react-dom 18.2.0.

Server error

Attempted import error: 'VimeoPlayer' is not exported from 'reactjs-vimeo-player' (imported as 'VimeoPlayer').
Import trace for requested module:
./src/app/aula/Player.js
Warning: React.jsx: type is invalid -- expected a string (for built-in components) or a class/function (for composite components) but got: undefined. You likely forgot to export your component from the file it's defined in, or you might have mixed up default and named imports.
Check your code at Player.js:7.
at Component
at Lazy
at div
at main
at InnerLayoutRouter (webpack-internal:///(sc_client)/./node_modules/next/dist/client/components/layout-router.js:226:11)
at RedirectErrorBoundary (webpack-internal:///(sc_client)/./node_modules/next/dist/client/components/redirect-boundary.js:72:9)
at RedirectBoundary (webpack-internal:///(sc_client)/./node_modules/next/dist/client/components/redirect-boundary.js:80:11)
at NotFoundBoundary (webpack-internal:///(sc_client)/./node_modules/next/dist/client/components/not-found-boundary.js:59:11)
at LoadingBoundary (webpack-internal:///(sc_client)/./node_modules/next/dist/client/components/layout-router.js:330:11)
at ErrorBoundary (webpack-internal:///(sc_client)/./node_modules/next/dist/client/components/error-boundary.js:105:11)
at InnerScrollAndFocusHandler (webpack-internal:///(sc_client)/./node_modules/next/dist/client/components/layout-router.js:139:9)
at ScrollAndFocusHandler (webpack-internal:///(sc_client)/./node_modules/next/dist/client/components/layout-router.js:213:11)
at RenderFromTemplateContext (webpack-internal:///(sc_client)/./node_modules/next/dist/client/components/render-from-template-context.js:15:44)
at Lazy
at OuterLayoutRouter (webpack-internal:///(sc_client)/./node_modules/next/dist/client/components/layout-router.js:339:11)
at Lazy
at InnerLayoutRouter (webpack-internal:///(sc_client)/./node_modules/next/dist/client/components/layout-router.js:226:11)
at RedirectErrorBoundary (webpack-internal:///(sc_client)/./node_modules/next/dist/client/components/redirect-boundary.js:72:9)
at RedirectBoundary (webpack-internal:///(sc_client)/./node_modules/next/dist/client/components/redirect-boundary.js:80:11)
at NotFoundBoundary (webpack-internal:///(sc_client)/./node_modules/next/dist/client/components/not-found-boundary.js:59:11)
at LoadingBoundary (webpack-internal:///(sc_client)/./node_modules/next/dist/client/components/layout-router.js:330:11)
at ErrorBoundary (webpack-internal:///(sc_client)/./node_modules/next/dist/client/components/error-boundary.js:105:11)
at InnerScrollAndFocusHandler (webpack-internal:///(sc_client)/./node_modules/next/dist/client/components/layout-router.js:139:9)
at ScrollAndFocusHandler (webpack-internal:///(sc_client)/./node_modules/next/dist/client/components/layout-router.js:213:11)
at RenderFromTemplateContext (webpack-internal:///(sc_client)/./node_modules/next/dist/client/components/render-from-template-context.js:15:44)
at Lazy
at OuterLayoutRouter (webpack-internal:///(sc_client)/./node_modules/next/dist/client/components/layout-router.js:339:11)
at Lazy
at body
at html
at RedirectErrorBoundary (webpack-internal:///(sc_client)/./node_modules/next/dist/client/components/redirect-boundary.js:72:9)
at RedirectBoundary (webpack-internal:///(sc_client)/./node_modules/next/dist/client/components/redirect-boundary.js:80:11)
at NotFoundErrorBoundary (webpack-internal:///(sc_client)/./node_modules/next/dist/client/components/not-found-boundary.js:51:9)
at NotFoundBoundary (webpack-internal:///(sc_client)/./node_modules/next/dist/client/components/not-found-boundary.js:59:11)
at ReactDevOverlay (webpack-internal:///(sc_client)/./node_modules/next/dist/client/components/react-dev-overlay/internal/ReactDevOverlay.js:66:9)
at HotReload (webpack-internal:///(sc_client)/./node_modules/next/dist/client/components/react-dev-overlay/hot-reloader-client.js:277:11)
at Router (webpack-internal:///(sc_client)/./node_modules/next/dist/client/components/app-router.js:86:11)
at ErrorBoundaryHandler (webpack-internal:///(sc_client)/./node_modules/next/dist/client/components/error-boundary.js:80:9)
at ErrorBoundary (webpack-internal:///(sc_client)/./node_modules/next/dist/client/components/error-boundary.js:105:11)
at AppRouter (webpack-internal:///(sc_client)/./node_modules/next/dist/client/components/app-router.js:361:13)
at Lazy
at Lazy
at ServerComponentWrapper (/Users/martins/www/cursonextjs.com/node_modules/next/dist/server/app-render/create-server-components-renderer.js:78:31)
at ServerComponentWrapper (/Users/martins/www/cursonextjs.com/node_modules/next/dist/server/app-render/create-server-components-renderer.js:78:31)
at InsertedHTML (/Users/martins/www/cursonextjs.com/node_modules/next/dist/server/app-render/app-render.js:836:33)

error Error: Element type is invalid: expected a string (for built-in components) or a class/function (for composite components) but got: undefined. You likely forgot to export your component from the file it's defined in, or you might have mixed up default and named imports.
warn ./src/app/aula/Player.js
Attempted import error: 'VimeoPlayer' is not exported from 'reactjs-vimeo-player' (imported as 'VimeoPlayer').

Code
"use client";
import {VimeoPlayer} from "reactjs-vimeo-player";
import styles from 'reactjs-vimeo-player/dist/style.css';

export default function Component() {
    return (
        <VimeoPlayer id={822998068} autoplay={true} fullWidth={true}/>
    )
}

Altough the player renders on the frontend, I got the same error with react-dom 18.2.0.

**Server error**

Attempted import error: 'VimeoPlayer' is not exported from 'reactjs-vimeo-player' (imported as 'VimeoPlayer').
Import trace for requested module:
./src/app/aula/Player.js
Warning: React.jsx: type is invalid -- expected a string (for built-in components) or a class/function (for composite components) but got: undefined. You likely forgot to export your component from the file it's defined in, or you might have mixed up default and named imports.
Check your code at Player.js:7.
at Component
at Lazy
at div
at main
at InnerLayoutRouter (webpack-internal:///(sc_client)/./node_modules/next/dist/client/components/layout-router.js:226:11)
at RedirectErrorBoundary (webpack-internal:///(sc_client)/./node_modules/next/dist/client/components/redirect-boundary.js:72:9)
at RedirectBoundary (webpack-internal:///(sc_client)/./node_modules/next/dist/client/components/redirect-boundary.js:80:11)
at NotFoundBoundary (webpack-internal:///(sc_client)/./node_modules/next/dist/client/components/not-found-boundary.js:59:11)
at LoadingBoundary (webpack-internal:///(sc_client)/./node_modules/next/dist/client/components/layout-router.js:330:11)
at ErrorBoundary (webpack-internal:///(sc_client)/./node_modules/next/dist/client/components/error-boundary.js:105:11)
at InnerScrollAndFocusHandler (webpack-internal:///(sc_client)/./node_modules/next/dist/client/components/layout-router.js:139:9)
at ScrollAndFocusHandler (webpack-internal:///(sc_client)/./node_modules/next/dist/client/components/layout-router.js:213:11)
at RenderFromTemplateContext (webpack-internal:///(sc_client)/./node_modules/next/dist/client/components/render-from-template-context.js:15:44)
at Lazy
at OuterLayoutRouter (webpack-internal:///(sc_client)/./node_modules/next/dist/client/components/layout-router.js:339:11)
at Lazy
at InnerLayoutRouter (webpack-internal:///(sc_client)/./node_modules/next/dist/client/components/layout-router.js:226:11)
at RedirectErrorBoundary (webpack-internal:///(sc_client)/./node_modules/next/dist/client/components/redirect-boundary.js:72:9)
at RedirectBoundary (webpack-internal:///(sc_client)/./node_modules/next/dist/client/components/redirect-boundary.js:80:11)
at NotFoundBoundary (webpack-internal:///(sc_client)/./node_modules/next/dist/client/components/not-found-boundary.js:59:11)
at LoadingBoundary (webpack-internal:///(sc_client)/./node_modules/next/dist/client/components/layout-router.js:330:11)
at ErrorBoundary (webpack-internal:///(sc_client)/./node_modules/next/dist/client/components/error-boundary.js:105:11)
at InnerScrollAndFocusHandler (webpack-internal:///(sc_client)/./node_modules/next/dist/client/components/layout-router.js:139:9)
at ScrollAndFocusHandler (webpack-internal:///(sc_client)/./node_modules/next/dist/client/components/layout-router.js:213:11)
at RenderFromTemplateContext (webpack-internal:///(sc_client)/./node_modules/next/dist/client/components/render-from-template-context.js:15:44)
at Lazy
at OuterLayoutRouter (webpack-internal:///(sc_client)/./node_modules/next/dist/client/components/layout-router.js:339:11)
at Lazy
at body
at html
at RedirectErrorBoundary (webpack-internal:///(sc_client)/./node_modules/next/dist/client/components/redirect-boundary.js:72:9)
at RedirectBoundary (webpack-internal:///(sc_client)/./node_modules/next/dist/client/components/redirect-boundary.js:80:11)
at NotFoundErrorBoundary (webpack-internal:///(sc_client)/./node_modules/next/dist/client/components/not-found-boundary.js:51:9)
at NotFoundBoundary (webpack-internal:///(sc_client)/./node_modules/next/dist/client/components/not-found-boundary.js:59:11)
at ReactDevOverlay (webpack-internal:///(sc_client)/./node_modules/next/dist/client/components/react-dev-overlay/internal/ReactDevOverlay.js:66:9)
at HotReload (webpack-internal:///(sc_client)/./node_modules/next/dist/client/components/react-dev-overlay/hot-reloader-client.js:277:11)
at Router (webpack-internal:///(sc_client)/./node_modules/next/dist/client/components/app-router.js:86:11)
at ErrorBoundaryHandler (webpack-internal:///(sc_client)/./node_modules/next/dist/client/components/error-boundary.js:80:9)
at ErrorBoundary (webpack-internal:///(sc_client)/./node_modules/next/dist/client/components/error-boundary.js:105:11)
at AppRouter (webpack-internal:///(sc_client)/./node_modules/next/dist/client/components/app-router.js:361:13)
at Lazy
at Lazy
at ServerComponentWrapper (/Users/martins/www/cursonextjs.com/node_modules/next/dist/server/app-render/create-server-components-renderer.js:78:31)
at ServerComponentWrapper (/Users/martins/www/cursonextjs.com/node_modules/next/dist/server/app-render/create-server-components-renderer.js:78:31)
at InsertedHTML (/Users/martins/www/cursonextjs.com/node_modules/next/dist/server/app-render/app-render.js:836:33)

error Error: Element type is invalid: expected a string (for built-in components) or a class/function (for composite components) but got: undefined. You likely forgot to export your component from the file it's defined in, or you might have mixed up default and named imports.
warn ./src/app/aula/Player.js
Attempted import error: 'VimeoPlayer' is not exported from 'reactjs-vimeo-player' (imported as 'VimeoPlayer').

Code
"use client";
import {VimeoPlayer} from "reactjs-vimeo-player";
import styles from 'reactjs-vimeo-player/dist/style.css';

export default function Component() {
    return (
        <VimeoPlayer id={822998068} autoplay={true} fullWidth={true}/>
    )
}

@r-martins can you upload your code in code sandbox (https://codesandbox.io) and shared it with me?

The problem was closed because there was no interaction.


[Feature]fix the problem of common dependcy of agent

Description
fix common dependency (common rely on agent)
Use case
No response
Are you willing to submit PR?

[X] Yes, I am willing to submit a PR!

Code of Conduct

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

this bug has not happened again, close it.

ok


[API][Eco News Comment Controller] Received status code 500 but there isn't a description in Swagger

Environment: All environment
Reproducible: always
Build found: 23.04.2022
Preconditions
1.Go to Postman
2.Sign In POST greencity-user.azurewebsites.net/ownSecurity/signIn
3.Body {
"email": "XXXX",
"password": "XXXX"
}
Steps to reproduce
1.POST greencity.azurewebsites.net/econews/comments/like?i=21
Actual result
Got a 500 Code
Expected result
The 500 Code is described in Swagger

Now if you do that request you will receive Bad Request response


head request to trusted peer failed

Celestia Node version
v0.10.0
OS
ubuntu
Install tools
No response
Others
No response
Steps to reproduce it
https://github.com/celestiaorg/optimism/issues/57
Expected result
No errors
Actual result
errors in https://github.com/celestiaorg/optimism/issues/57
Relevant log output
celestia-light-node | 2023-05-22T21:57:06.058Z  ERROR   header/p2p      p2p/exchange.go:144     head request to trusted peer failed     {"trustedPeer": "12D3KooWBtxdBzToQwnS4ySGpph9PtGmmjEyATkgX3PfhAo4xmf7", "err": "header/p2p: failed to open a new stream: context deadline exceeded"}
celestia-light-node | 2023-05-22T22:08:13.012Z  ERROR   header/p2p      p2p/exchange.go:144     head request to trusted peer failed     {"trustedPeer": "12D3KooWBtxdBzToQwnS4ySGpph9PtGmmjEyATkgX3PfhAo4xmf7", "err": "header/p2p: failed to open a new stream: context canceled"}
celestia-light-node | 2023-05-22T22:18:43.016Z  ERROR   header/p2p      p2p/exchange.go:144     head request to trusted peer failed     {"trustedPeer": "12D3KooWBtxdBzToQwnS4ySGpph9PtGmmjEyATkgX3PfhAo4xmf7", "err": "header/p2p: failed to open a new stream: context canceled"}

Notes
No response

Hey @jcstein. Which network were you running? The error suggests there is a peering problem and not a bug, so more information is needed to understand it.

hiya @Wondertan - Blockspace Race. let me know if you need anything else 🙏

Does this happen consistently or was it only one run?

It starts and runs fine, mainly opened this to track this issue in case it is what is causing errors on the op stack testing we're doing. I think it's safe to close as we've narrowed in on this likely being the culprit

Does this happen consistently or was it only one run?

it consistently happens on different runs, but is not consistent in the cadence of when it occurs

Cool closing it then

sounds good. thanks for explaining the error more 🙏

It seems that whenever this happens, requests timeout with:
context deadline exceeded (Client.Timeout exceeded while awaiting headers
Would it be possible for this to not block client requests? Due to this timeout, there's a cascade of failures eventually leading to the safe blocks not updating. Just flagging this, as it can be probably be worked around with long enough client timeouts.


Docs for env-vars are incorrect

We tried to use the documentation to run the acceptance tests locally. The documentation specifies setting the following environment variables
CF_DEPLOYMENT_NAME - name of the Cloud Foundry deployment to backup and restore
CF_API_URL - Cloud Foundry api url
CF_ADMIN_USERNAME - Cloud Foundry api admin user
CF_ADMIN_PASSWORD - Cloud Foundry api admin password
BOSH_ENVIRONMENT - URL of BOSH Director which has deployed the above Cloud Foundries
BOSH_CLIENT - BOSH Director username
BOSH_CLIENT_SECRET - BOSH Director password
BOSH_CERT_PATH - path to BOSH Director's CA cert
BBR_BUILD_PATH - path to BBR binary
DEFAULT_TIMEOUT_MINS - timeout for commands run in the test. Defaults to 15 minutes.

On running ./scripts/run_acceptance_tests_local.sh we have encountered the following errors:
./scripts/run_acceptance_tests_local.sh: line 8: BOSH_CA_CERT: parameter null or not set

and
./scripts/run_acceptance_tests_local.sh: line 9: BOSH_GW_HOST: parameter null or not set

BOSH_GW_HOST is not included in the documentation at all.

We found that all the following env vars are required and undocumented:
export BOSH_GW_HOST=<IP_ADDRESS>:25555
export BOSH_GW_USER=jumpbox
export BOSH_GW_PRIVATE_KEY_CONTENTS="REDACTED"
export SSH_DESTINATION_CIDR="<IP_ADDRESS>/8"
export NFS_SERVICE_NAME="sda "
export NFS_PLAN_NAME="sds "
export NFS_BROKER_USER="sda "
export NFS_BROKER_PASSWORD="sda "
export NFS_BROKER_URL="sda"

We have as of yet been unable to run this script successfully. We are currently getting this error:
$ ./scripts/run_acceptance_tests_local.sh
Starting SSH tunnel, you may be prompted for your OS password...
Running DRATs...
ssh: Could not resolve hostname https://<IP_ADDRESS>:25555: nodename nor servname provided, or not known
client: fatal: failed to establish ssh session (1)
./scripts/run_acceptance_tests.sh: line 23: dep: command not found
./scripts/run_acceptance_tests_local.sh: line 38: kill: (86169) - No such process

We did some more digging, and found the following issues

The BOSH_ENVIRONMENT takes a scheme and a port, but  BOSH_GW_HOST takes an IP only
BOSH_CERT_PATH has been renamed BOSH_CA_CERT
We had trouble setting BOSH_GW_PRIVATE_KEY_CONTENTS and BOSH_CERT_PATH in a script. We got past an error using export BOSH_GW_PRIVATE_KEY_CONTENTS="$(bbl ssh-key)" and export BOSH_CA_CERT="$(bbl director-ca-cert)"

Now we're getting this error:
• Failure in Spec Setup (BeforeEach) [369.189 seconds]
backing up Cloud Foundry
/Users/sanjurtupil/go/src/github.com/cloudfoundry-incubator/disaster-recovery-acceptance-tests/acceptance_test.go:13
  backups and restores a cf [BeforeEach]
  /Users/sanjurtupil/go/src/github.com/cloudfoundry-incubator/disaster-recovery-acceptance-tests/runner/runner.go:45

  Expected error:
      <*os.PathError | 0xc420081c20>: {
          Op: "mkdir",
          Path: "cf-routing-cf-home",
          Err: 0x11,
      }
      mkdir cf-routing-cf-home: file exists
  not to have occurred

Looks like the last test run left some state behind: https://github.com/cloudfoundry-incubator/disaster-recovery-acceptance-tests/blob/master/runner/runner.go#L40
This is usually cleaned up in an AfterEach(), but that doesn't seem to have run - was the test process killed before it could clean up?

Hey we've updated our README to reflect recently added/changed environment variables, if the state not being cleaned up continues to be an issue it would probably make sense to open a separate issue for it.
Cheers


Allow path lookups in un-delimited splices

Makes it easier when you want to reference structs/functions in other modules without importing them into the local context. E.g. just using html!(w, $maud::PreEscaped("value")) instead of having to use maud::PreEscaped.

Merged, cheers!


Can't open an AES-encrypted Zip archive with password set to empty string. Is this archive nonstandard?

Steps to reproduce

Create a zip file with AES-256 encryption and an empty password. I have some created in the past with DotNetZip. I don't think they can be created with SharpZipLib.
Create a ZipFile object from the zip file and set the Password field to "".
Try to extract.

Expected behavior
The zip file is opened and extracted.
Actual behavior
The code acts as if no password has been set and throws exception "No password available for AES encrypted stream".
I see the setter code doesn't differentiate between null and empty string: https://github.com/icsharpcode/SharpZipLib/blob/master/src/ICSharpCode.SharpZipLib/Zip/ZipFile.cs#L360
7zip and DotNetZip allow these files to be extracted with an empty password, but I can't work out if they are just being more lenient than they need to be.
Version of SharpZipLib
1.2.0

Not sure why you'd want to be able to create an archive like that, but the WinZip AES spec doesn't seem to say you can't, so maybe something to handle in a read only fashion?
As fas as SharpZipLib goes:
The AES decryption machinery itself seems to handle it if you can get the empty string password into it, but the ZipCrypto machinery does require a value (that's the GenerateKeys call in the setter you link to).
Passing an empty value into GenerateKeys causes it to throw (hence the way the null/empty check works I suppose), but that wouldn't matter for AES decryption as that doesn't use that key, it just uses the password string directly.
Related observation: Doesn't the way that setter works mean that if you set the password to some string value, and then set it to null, that the rawPassword_ string will get left at the previous value?
The AES encryption setup @ https://github.com/icsharpcode/SharpZipLib/blob/195b4e2275f9d4d486b44add324d574c851db2a3/src/ICSharpCode.SharpZipLib/Zip/ZipFile.cs#L3617 also checks if the 'key' has been setup but then sets up the decryption using the password string instead of that, which is also maybe not correct...
Maybe the Password setter should always set rawPassword_ to the passed value, and CreateAndInitDecryptionStream for AES entries should just check for the string being non-null ?

I think it's a bug that creates them in the first place, but I want to support archives created in the past when the bug was present.

Yeah, as @Numpsy said, PBKDF2 (which is what is used to derive the key from the password) does not specify a minimum length. Even though it seems somewhat useless, that is not something for us to decide 😁
This should now be fixed as of #472


Carbon X: Create experimental components in React

The following components have updated html for experimental and need to get updated in the React library.

[x] Tag
[x] Structured List
[x] Notification

Tag: https://github.com/IBM/carbon-components-react/pull/1523
StructuredList: https://github.com/IBM/carbon-components-react/pull/1528
Notification: https://github.com/IBM/carbon-components-react/pull/1537


feat: added revoke and simulateRevoke

What does this PR do?
Related ticket
Fixes #169
Type of change

[ ] Chore
[ ] Bug fix
[x] New feature
[ ] Documentation update

Check list

[ ] Unit tests for any smart contract change
[ ] Contracts and functions are documented

Codecov Report

Merging #274 (eb7b3af) into dev (d0b3281) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##              dev     #274   +/-   ##
=======================================
  Coverage   93.40%   93.40%
=======================================
  Files          13       13
  Lines         197      197
  Branches       46       46
=======================================
  Hits          184      184
  Misses          8        8
  Partials        5        5

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


convert verilog to aiger with Yosys

HI, I have several verilog files which I want to convert to aiger format using Yosys, I use the following commmad in yosys:
read_verilog gclk_reg.v nld_and.v my_ff_W_8_.v gated_netlist.v
synth_xilinx -flatten -top gclk_reg
aigmap
write_aiger -ascii my.aag
When I use the aigmap command, it show that cells like VCC LUT2 GND LDCE .etc cannt be replaced. Unsurprisingly, the write_aiger command fails, showing that "ERROR: Unsupported cell type: VCC (VCC)". So how can I map those cells to allowed cells of write_aiger?(I also used the abc -g AND command but it still failed)
Many Thanks!!

Well, synth_xilinx outputs LUTs, because it's meant to be a full flow. If you're dumping to AIGER you almost certainly do not want to run a full flow, so I'd suggest the generic synth -flatten; aigmap; write_aiger example.aig


why AbstractMessageListenerContainer.active is volatile

access org.springframework.amqp.rabbit.listener.AbstractMessageListenerContainer.active is synchronized by lifecycleMonitor . so every thread will get active value right. Is it necessary to make filed active volatile?

Good catch; thanks.


Undefined "includeInvisible" when using "type: hacd;"

Trying to use the hacd Ammo shape type with the Ammo Driver.
The following console error comes up:
Uncaught TypeError: Cannot read properties of undefined (reading 'includeInvisible')
at aframe-physics-system.min.js:1:214940
at Mesh.traverse (three.js:5985:1)
at aframe-physics-system.min.js:1:214852
at aframe-physics-system.min.js:1:216333
at Object.createHACDShapes (aframe-physics-system.min.js:1:205034)
at exports.createCollisionShapes (aframe-physics-system.min.js:1:199846)
at i._createCollisionShape (aframe-physics-system.min.js:1:247486)
at i. (aframe-physics-system.min.js:1:246580)
at i.beforeStep (aframe-physics-system.min.js:1:250305)
at o.tick (aframe-physics-system.min.js:1:289954)
Issue does not occur prior to version 4.1.0, but those versions have their own fun quirks

This is easily reproduced by uncommenting this entity in the ammo sandbox example:
      <a-torus-knot
        position="-2 1.5 -1"
        rotation="0 90 90"
        scale="0.5 0.5 0.5"
        color="red"
        shadow
        ammo-body
        ammo-shape="type: hacd;"
      ></a-torus-knot>

The problem appears to be that this line of code in three-to-ammo does not pass on options object to computeBounds()
const bounds = _computeBounds(root);

Fixing it like this seems to make HACD work again
const bounds = _computeBounds(root, options);

I am puzzled how this used to work at 4.1.0...
We are still using three-to-ammo 0.1.0 (plus some patches) and there are some substantial interface changes blocking us from moving to 1.0.1.  So best solution is probably to patch three-to-ammo using npm-patch-package, as we have done before...
Before I submit that PR, I'd like to dig a bit more into how this worked at 4.1.0...

So the problematic line was introduced with this checkin:
https://github.com/InfiniteLee/three-to-ammo/commit/5b0587c660080822049f1ed87e13ba15f0e74d2f
and it looks like a straightforward oversight that options was not passed as an additional parameter on the call to _computeBounds()
Only versions of aframe-physics-system I can find with HACD working predate this change to three-to-ammo (v4.0.1).
Contrary to note above, 4.1.0 seems to have the same issue.
Tracking down specific details on when we switched from one version of three-to-ammo to another is hard, as prior to this point, aframe-physics-system just built off the latest github...

master is now using three-to-ammo 1.0.1, and HACD seems to be working fine.


pandas.errors.EmptyDataError: No columns to parse from file

Hi Yoshinori
I am getting the following error when running:
python longQC.py sampleqc -x pb-hifi -o longqc ccs.bam
I made sure that ccs.bam is a 16GB file
Thank you for the help
longQC:2021-05-07 09:18:02,824:592:INFO:Filteration finished.
longQC:2021-05-07 09:18:12,834:598:INFO:Generating coverage related plots...
Traceback (most recent call last):
File "/LongQC-1.2.0b/longQC.py", line 956, in
main(args)
File "/LongQC-1.2.0b/longQC.py", line 62, in main
args.handler(args)
File "/LongQC-1.2.0b/longQC.py", line 602, in command_sample
lc = LqCoverage(cov_path, isTranscript=args.transcript, control_filtering=pb_control)
File "/LongQC-1.2.0b/lq_coverage.py", line 88, in init
self.df = pd.read_table(table_path, sep='\t', header=None)
File "/opt/conda/lib/python3.9/site-packages/pandas/io/parsers.py", line 689, in read_table
return _read(filepath_or_buffer, kwds)
File "/opt/conda/lib/python3.9/site-packages/pandas/io/parsers.py", line 462, in _read
parser = TextFileReader(filepath_or_buffer, **kwds)
File "/opt/conda/lib/python3.9/site-packages/pandas/io/parsers.py", line 819, in init
self._engine = self._make_engine(self.engine)
File "/opt/conda/lib/python3.9/site-packages/pandas/io/parsers.py", line 1050, in _make_engine
return mapping[engine](self.f, **self.options)  # type: ignore[call-arg]
File "/opt/conda/lib/python3.9/site-packages/pandas/io/parsers.py", line 1898, in init
self._reader = parsers.TextReader(self.handles.handle, **kwds)
File "pandas/_libs/parsers.pyx", line 521, in pandas._libs.parsers.TextReader.cinit
pandas.errors.EmptyDataError: No columns to parse from file

Thank you Yoshinori for all the help, the fix was to increase ram as described

Hello ! I experienced the same issue. It looks like resubmitting the job with 100 gigs of ram has fixed the problem.
Maybe the error message should be more explicit ?

Hi, I have the same problem, memory shouldn't be an issue on my 1TB machine. The coverage_err.txt contains the following error message:

[WARNING] Indexing parameters (-k, -w or -H) overridden by parameters used in the prebuilt index.
[M::mm_mapopt_update::728.53218.16] mid_occ = 3164
[M::main::728.53218.16] loaded/built the index for 239301 target sequence(s)
[M::worker_pipeline::776.181*19.72] mapped 5000 sequences. (Peak RSS: 50.844 GB)
munmap_chunk(): invalid pointer

Seems to be a minimap2 issue.
Have you seen that before?
Thanks,
Chris


DiagonalGate decomposition is incorrect

Description of the issue
cirq.decompose on cirq.DiagonalGate should produce operations that add up to an equivalent unitary.
How to reproduce the issue

@pytest.mark.parametrize('n', [1, 2, 3, 4, 5, 6, 7, 8, 9])
def test_decomposition_unitary(n):
    rs = np.random.RandomState(1234)
    diagonal_angles = rs.rand(2 ** n)
    diagonal_gate = cirq.DiagonalGate(diagonal_angles)
    decomposed_circ = cirq.Circuit(cirq.decompose(diagonal_gate(*cirq.LineQubit.range(n))))

    expected_f = [np.exp(1j * angle * 2 * np.pi) for angle in diagonal_angles]
    assert cirq.is_unitary(np.diag(expected_f))
    assert cirq.is_diagonal(np.diag(expected_f))
    actual_unitary = cirq.unitary(decomposed_circ)
    cirq.testing.assert_allclose_up_to_global_phase(actual_unitary, np.diag(expected_f), rtol=1e-4, atol=1e-4)
    decomposed_f = actual_unitary.diagonal()

    np.testing.assert_allclose(decomposed_f, expected_f)

This fails on all qubit numbers on the assert_allclose_up_to_global_phase check.
Cirq version
v0.11.0.dev
Note
The current test_decomposition_unitary tests uses randn - which produces random numbers based on the normal distribution. This produces that are larger than pi rarely.
Also, we are not using a seed in this test - making it suspect to flakiness.
The above test is more accurate in terms of specification and tests a larger range of angles.

@ybc1991 can you have a look at this?

Sure, will take a look

@balopat Ah, the problem is the input of the diagonal gate is the angles in radians instead
of the [0-1] to represent between 0 to 2*pi.
    def __init__(self, diag_angles_radians: List[value.TParamVal]) -> None:
        r"""A n-qubit gate with only diagonal elements.

        This gate's off-diagonal elements are zero and it's on diagonal
        elements are all phases.

        Args:
            diag_angles_radians: The list of angles on the diagonal in radians.
                If these values are $(x_0, x_1, \ldots , x_N)$ then the unitary
                has diagonal values $(e^{i x_0}, e^{i x_1}, \ldots, e^{i x_N})$.

In the testing code, just change expected_f into  expected_f = [np.exp(1j * angle) for angle in diagonal_angles] will be fine.

Oh, I'm silly.
It's the other way around though, I wanted the angles to "cover" [0, 2pi] instead of [0,1]:
@pytest.mark.parametrize('n', [1, 2, 3, 4, 5, 6, 7, 8, 9])
def test_decomposition_unitary(n):
    rs = np.random.RandomState(1234)
    diagonal_angles = [2 * np.pi * angle for angle in rs.rand(2 ** n)]
    diagonal_gate = cirq.DiagonalGate(diagonal_angles)
    decomposed_circ = cirq.Circuit(cirq.decompose(diagonal_gate(*cirq.LineQubit.range(n))))

    expected_f = [np.exp(1j * angle) for angle in diagonal_angles]
    assert cirq.is_unitary(np.diag(expected_f))
    assert cirq.is_diagonal(np.diag(expected_f))
    actual_unitary = cirq.unitary(decomposed_circ)
    cirq.testing.assert_allclose_up_to_global_phase(actual_unitary, np.diag(expected_f), rtol=1e-4, atol=1e-4)
    decomposed_f = actual_unitary.diagonal()

    np.testing.assert_allclose(decomposed_f, expected_f)

Works :) Thanks for the quick check. Closing.


eigenpy: 2.7.12-1 in 'noetic/distribution.yaml' [bloom]

Increasing version of package(s) in repository eigenpy to 2.7.12-1:

upstream repository: https://github.com/stack-of-tasks/eigenpy.git
release repository: https://github.com/stack-of-tasks/eigenpy-ros-release.git
distro file: noetic/distribution.yaml
bloom version: 0.11.2
previous version for package: 2.7.11-1

@sloretz This might fix the sot-core etc. regression


[ENH] Update meta classes and add unit tests

Reference Issues/PRs
Fixes #106.
What does this implement/fix? Explain your changes.
This PR will add unit tests of the meta class functionality. It will also provide an update of the provided functionality to make it generally consistent with skbase design principles.
Does your contribution introduce a new dependency? If yes, which one?
No new dependencies.
What should a reviewer concentrate their feedback on?
Updates to BaseMetaObject (renamed from BaseMetaEstimator) and whether tests cover reasonable use-cases.

Codecov Report

Merging #107 (d20d846) into main (1a0fd6f) will decrease coverage by 0.74%.
The diff coverage is 31.25%.

@@            Coverage Diff             @@
##             main     #107      +/-   ##
==========================================
- Coverage   77.93%   77.18%   -0.75%
==========================================
  Files          23       23
  Lines        1867     1885      +18
==========================================
  Hits         1455     1455
- Misses        412      430      +18

Impacted Files
Coverage Δ

skbase/base/_meta.py
14.47% <29.03%> (-0.80%)
:arrow_down:

skbase/base/__init__.py
100.00% <100.00%> (ø)

skbase/lookup/tests/test_lookup.py
99.72% <0.00%> (-0.28%)
:arrow_down:

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

maybe one thing for you to review, whether you like (or not) the implied inheritance order.

maybe one thing for you to review, whether you like (or not) the implied inheritance order.

Do you mean in downsteram usage?

class SomePipeline(BaseMetaObject, BaseObject):
    ...

@fkiraly I'm going to leave this open for a bit and add unit tests of this functionality. For ease, can you point me to related sktime unit tests. I didn't see any directly testing this where the sktime.base tests were located, but there is test coverage. Is this handled in tests of classes using _HeterogeneousMetaEstimator?

Do you mean in downsteram usage?

Yes

@fkiraly I'm going to leave this open for a bit and add unit tests of this functionality. For ease, can you point me to related sktime unit tests. I didn't see any directly testing this where the sktime.base tests were located, but there is test coverage. Is this handled in tests of classes using _HeterogeneousMetaEstimator?

Yes, correct - most of the coverage comes from integration tests which require the functionality in the mixin to work correctly in order to pass.
I also do not think there are any direct tests, but I might be mistaken.

Do you mean in downsteram usage?

Yes.
One issue that for me has recently come up is that the meta-estimator can be a BaseObject and not BaseEstimator, or it can be both.
In either case, it makes sense to implement default functionality for the parameter getters get_params, get_fitted_params, but the second one is only "present" for BaseEstimator descendants.

I'm thinking we might want want 2 mixins.

BaseMetaObject mixin that has meta get_paramsandset_params` (and other functionaly that applies to objects and estimators).
BaseMetaEstimator mixin that inherits from BaseMetaObject (does alll the same stuff), and also has estimator specific things like retrieving fitted parameters.

From a user perspective,  we'd document that the choice of the mixin to use is dependent on whether your building a meta object or meta estimator, which seems straight-forward enough. For example:
from skbase.base import BaseEstimator, BaseMetaestimator, BaseMetaObject, BaseObject

class SomeNeatMetaObject(BaseMetaObject, BaseObject):
    ...

class SomeNeatMetaEstimator(BaseMetaEstimator, BaseEstimator):
    ...

From a maintenance perspective, we'd have the same functionality and not double anything up.
I'll work up this and some integration tests today.

From a maintenance perspective, we'd have the same functionality and not double anything up.

I suppose that makes sense, assuming they are clearly presented as mixins.


compile should bind the: signature+underline+name together

such that each "complete" signature stays together on one page
This is especially important with multiple signatures (exceeding one page), the page break can happen anywhere, resulting in, for example, a signature at the bottom of a page then its name at the top of the following page.
This can be super confusing when the underline+name are on the second page as it looks unsigned

I think the solution might be to alter the pandoc template, as per https://stackoverflow.com/a/27904021/1187277

I think the solution might be to alter the pandoc template, as per https://stackoverflow.com/a/27904021/1187277

Tho a simpler fix might be to enable the "Natural Tables" extension:

Extension: ntb
In the context output format this enables the use of Natural Tables (TABLE) instead of the default Extreme Tables (xtables). Natural tables allow more fine-grained global customization but come at a performance penalty compared to extreme tables.

https://pandoc.org/MANUAL.html

Tho a simpler fix might be to enable the "Natural Tables" extension:

Extension: ntb
In the context output format this enables the use of Natural Tables (TABLE) instead of the default Extreme Tables (xtables). Natural tables allow more fine-grained global customization but come at a performance penalty compared to extreme tables.

https://pandoc.org/MANUAL.html


Investigate optimized casm compilation

Issues #2675 and #2676 and and PR #2677 created as follow up of this.


Bar Chart colors

Hi,
Thanks for the amazing Library, it looks really nice and performs well too. Just a question. Is there a way to change the colours of the individual barchats instead of rendering them uniformly in 1 color?
e.g:
let sampleData = [       {         seriesName: 'test2',         data: [140, 160],         color: [colors.lightNavy, colors.Red],       },     ];
So that both the charts have their own individual colors?. I've tried passing primaryColor, secondary and other props, but nothing seems to be working. Any help or advice would be appreciated.
Thanks

Try this
https://github.com/oksktank/react-native-pure-chart/blob/master/README.md#multi-series-simple

@ahmedu007
Thank you for using react native pure chart.
we can only one color by one series.
if you want to individual color by data, you should split data by multi series.

Thankyou for such a quick response. I've tried that, but then the width of the bars get really narrow. I only have 2 bars to render on the whole screen so I need them to be quite wide. i've set the defaultColumnWidth to 500 and it works, but is there a way to give a gap in the middle of the two bars?

@ahmedu007
can i show your applied screen?

<PureChart
            height={height(55.2)}
            defaultColumnWidth={width(50)}
            data={sampleData}
            defaultColumnMargin={40}
            type="bar"
            numberOfYAxisGuideLine={5}
            backgroundColor="rgba(0,0,0,0.5)"
            // highlightColor="yellow"
            // primaryColor="blue"
          />

So this is what I want to do. 2 different bars with different colours. I've tried using defaultColumnMargin as you suggested already, but your default right margin for the 0 index is set to 0 in the source code. Ideally if there is a prop that can be set on individual charts it would be perfect.
@kingwang09

i understand what you mean.
we'll try implement individual column gap until next release.
thanks for using our charts.

Thankyou. Ideally if you can implement a way to pass a colour prop to individual bar charts (not a multiSeries) that would be awesome

How to set different colors for all bars in single series.


Add routing functionality

FlowRouter seems the de-facto solution featured by Meteor official guides: http://guide.meteor.com/routing.html
A few resources on the subject:

http://guide.meteor.com/routing.html
https://atmospherejs.com/kadira/flow-router
https://kadira.io/academy/meteor-routing-guide

We should expose a few routes:

/settings
/dashboard
/mood/:mood/:token

I guess that the mood was retrieve when the team memeber answer to the bot not with a link

I will show you monday how i imagine this feature


Can you add README.md please :)

A readme document explaining the algorithms / heuristics in the code would be great. It can also help us to understand the format of the output, the efficiency of the system and how to improve this system, etc.
By the way, very good job 👍

Thank you, I've added the readme.md file, I hope it's descriptive enough.