Add WildFly Operator 0.2.0

Operator for WildFly application runtime.
Minor upgrade of the Operator that use ubi7 as its base image and can
manage applications built with the upcoming S2I for WildFly 17.
Full release notes at
https://github.com/wildfly/wildfly-operator/milestone/1?closed=1

Thanks submitting your Operator. Please check below list before you create your Pull Request.
New Submissions

[x] Are you familiar with our contribution guidelines?
[x] Have you packaged and deployed your Operator for Operator Framework?

Updates to existing Operators

[x] Is your new CSV pointing to the previous version with the replaces property?
[x] Have you tested an update to your Operator when deployed via OLM?

Your submission should not

[x] Modify more than one operator
[x] Submit operators to both upstream-community-operators and community-operators at once
[x] Modify any files outside the above mentioned folders
[x] Contain more than one commit. Please squash your commits.

Operator Description must contain (in order)

[x] Description about the managed Application and where to find more information
[x] Features and capabilities of your Operator and how to use it
[x] Any manual steps about potential pre-requisites for using your Operator

Operator Metadata should contain

[x] Human readable name and 1-liner description about your Operator
[ ] Valid category name1
=> I've submitted a PR to add the Application Runtime category in #381. It is shown on operatorhub.io but not taken into account by operator-courier release yet.
[x] One of the pre-defined capability levels2
[x] Links to the maintainer, source code and documentation
[x] Example templates for all Custom Resource Definitions intended to be used
[x] A quadratic logo

Remember that you can preview your CSV here.
--
1 If you feel your Operator does not fit any of the pre-defined categories, file a PR against this repo and explain your need
2 For more information see here

@robszumski @anik120 Hi, is there anything else to do to get this PR reviewed?
I'm missing the some docs (as it is in progress in the operator project)and a valid category but this will be eventually addressed (the category is out of my hand) and it did not prevent to get the 0.1.0 operator approved.

I've added the features provided by the operator to the csv file.
The "application runtime" category now appears on operatorhub.io but is not supported by operator-courier for validation yet.

/retest


[AIRFLOW-2263] Fix 500 for null DAG

Jira
My PR addresses the following AIRFLOW-2263
Description
Remove 500-error when opening non-existent DAG in webserver UI /admin/airflow/tree?dag_id=some_garbage
Return 404 response instead
Tests
My PR do not add new unit tests

I updated the JIRA.. I need steps to reproduce.

@marklavrynenko-original This appears to be fixed in Master -- I can't reproduce this on Master and updated the Jira accordingly. If you have other steps to reproduce, feel free to reopen this or ping me.
I'm closing this for now.


Testnet faucet: responding slow

Task Description
The coinselection for testnet faucet seems to be taking a lot of time, we might want to do coin consolidation for the testnet faucet to get it up to speed.
Dependencies

#4341

@PraneethGunas Reported the following as well:
Getting this with test sats API - Failed to fetch fee via mempool.space {"err": [AxiosError: Request failed with status code 503]}

We'll also need a fallback for Testnet fee, if not already.

Working fine.


MISOCP solves returning status "Unknown" (different from #100)

We also get Unknown from a large number of MISOCPs we attempt to solve. What we observe is that MOSEK gets to the time limit AND has a feasible solution, but apparently the optimality gap is not yet satisfied. Then Mosek.jl fails to handle the status properly and returns Unknown (perhaps it should be Suboptimal).
In another case where no feasible solution was found by the time limit, MOSEK finished and Mosek.jl returned (correctly) the UserLimit status. The only difference here was that no feasible solution was found, whereas in the Unknown cases, we had both upper and lower bounds.
Here is the end of a printout (the lines with ## are our printings, not MOSEK's):
1179079  1176550  335532   30       5.0076984618e+05     5.0052105644e+05     0.05        3599.5
1179105  1176576  335540   24       5.0076984618e+05     5.0052105735e+05     0.05        3599.5
1179131  1176602  335546   45       5.0076984618e+05     5.0052105779e+05     0.05        3599.6
1179157  1176628  335550   24       5.0076984618e+05     5.0052105879e+05     0.05        3599.7
1179183  1176654  335560   36       5.0076984618e+05     5.0052106168e+05     0.05        3599.8
1179209  1176680  335566   39       5.0076984618e+05     5.0052106190e+05     0.05        3599.8
1179235  1176706  335570   35       5.0076984618e+05     5.0052106307e+05     0.05        3599.9
1179261  1176732  335576   29       5.0076984618e+05     5.0052106463e+05     0.05        3600.0
Maximum amount of time 3600.00 (=dpar_optimizer_max_time) is reached.

Objective of best integer solution : 5.007698461827e+05
Best objective bound               : 5.005210646327e+05
Construct solution objective       : Not employed
Construct solution # roundings     : 0
User objective cut value           : 0
Number of cuts generated           : 0
Number of branches                 : 1179261
Number of relaxations solved       : 1176732
Number of interior point iterations: 21020134
Number of simplex iterations       : 0
Time spend presolving the root     : 0.00
Time spend in the heuristic        : 0.00
Time spend in the sub optimizers   : 0.00
  Time spend optimizing the root   : 0.00
Mixed integer optimizer terminated. Time: 3601.02

Optimizer terminated. Time: 3601.03
#STATUS# Unknown
#OBJVAL#<PHONE_NUMBER>827041
#OBJBOUND#<PHONE_NUMBER>3272555
#TIMESOLVER# 3601.032301902771

@mlubin @ulfworsoe

There is almost surely a bug in Julia interface.
Btw getting the Julia interface to print the MOSEK solution summary after each optimization as default would help debugging so much.

@ulfworsoe, looks like the fix to https://github.com/JuliaOpt/Mosek.jl/issues/89 was incomplete

The issue is at least partially fixed now. A feasible solution should now produce Suboptimal status.

@ulfworsoe, that doesn't follow the MPB convention. If the solver stops because of a time limit, it should return :UserLimit regardless of whether it has found a primal solution so far.

Fair enough. The status function is a mess since it mixes Mosek's response code, problem status and solution status into one value. Do you have a description of MPB conventions somewhere?

Basically the relevant questions:

Does UserLimit take precedence over an optimal solution or only a feasible one?
Does Stall take precedence over an optimal solution or a feasible one?

The statuses are currently documented at http://mathprogbasejl.readthedocs.io/en/latest/solverinterface.html#status. I agree that they could use a revamp, that's something I'm open to considering.

Does UserLimit take precedence over an optimal solution or only a feasible one?

I don't understand how the solver could terminate because of the time limit if it already has an optimal solution.

Does Stall take precedence over an optimal solution or a feasible one?

Stall is not a standard status. Error maybe?
You should consider the statuses, as they're currently defined, as an explanation of why the solver stopped. :Optimal is not really about the solution itself but more explaining that the solver stopped because it found a solution that it was happy with. @ccoffrin has pointed out that :Optimal should really be called :Success or something similar.

Btw getting the Julia interface to print the MOSEK solution summary after each optimization as default would help debugging so much.

Agreed. @ulfworsoe, could we do that?

Done.

@ulfworsoe, Mosek seems to be returning :Stall on some problems where it used to return :Optimal and is therefore failing JuMP's tests.

Yes. If the solver stalls and stops, but finds that the solution after post-solve happens to be optimal, it will produce an optimal solution but still return the actual reason for stopping.

Fair enough

Unless you are doing something special in the interface then this not
correct explenation. Postsolve cannot fix a broken solution.
What can happen on linear problems is that the interior-point optimizer
stalls but the subsequent basis identification succeeds.
2016-12-28 9:28 GMT+01:00 Ulf Worsøe<EMAIL_ADDRESS>
Yes. If the solver stalls and stops, but finds that the solution after
post-solve happens to be optimal, it will produce an optimal solution but
still return the actual reason for stopping.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/JuliaOpt/Mosek.jl/issues/101#issuecomment-269443805,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AJwCcSYDB14HHvUYIw4d7j2ALETn6G0Iks5rMh2rgaJpZM4LLcy8
.

The offending test is an SDP:
using JuMP, Base.Test, Mosek
m = Model(solver=MosekSolver())
@variable(m, y)
@variable(m, z)
c = @SDconstraint(m, [0 y; z 0] <= [1 0; 0 0])
@objective(m, Max, y/2+z/2)
status = solve(m)

@test status == :Optimal
@test isapprox(getobjectivevalue(m), 0, atol=1e-5)
@test isapprox(getvalue(y), 0, atol=1e-5)
@test isapprox(getvalue(z), 0, atol=1e-5)

X = getdual(c)
@test isapprox(X[1,1], 0, atol=1e-5)
@test isapprox(X[1,2], 1/2, atol=1e-5)
@test isapprox(X[2,1], 1/2, atol=1e-5)
@test isapprox(getdual(y), 0, atol=1e-5)
@test isapprox(getdual(z), 0, atol=1e-5)

Ulf is correct that MathProgBase.status() should return the solver response. It's a bit confusing that the solver can stall and still return an optimal solution though. Why is it called a stall if the optimality tolerances are satisfied?

MOSEK does things a bit differently than normal. I hope I can covince that
what we do is rational.
As far I understand Jump has one return code. It is used to signal
optimizer failures e.g. out space, infeasibility and a lot other stuff.
Well, at least that is what many codes does but MOSEK has a richer way of
reporting what is going on.
In MOSEK we distinguish
a. Optimizer status e.g. out of space, out of time.
b. Problem status.
c. Solution status.
So if the MIP optimizer runs because out of time but has a feasible
solution, then we set
Return code = E.g. ok or out of space
Optimizer status = out of time (This is not failure of the system if the
user set time limit)
Problem status = feasible
Solution status = feasible
Using that method we can report any situations that appear accurately. I do
not see how you can reduce it much without loosing info.
In my opinion you cannot just have single number representing solver
status, solution status etc.
accurately.
Now in
http://docs.mosek.com/8.0/capi/tutorial-response.html
we explain how you should deal with termination. It can be summarized as
follows using pseudo code.
if solution I am interested is has the right status e.g. optimal
do what ever you had planned to do

else
/* Something went wrong */
You can for instance use the response code of the optimizer to obtain
information about went wrong.
Do what ever is appropriate in this case.
I hope this make sense. Also given this information it should possible to
map the MOSEK info. to Jump info.
Feel free to explain when that is not case and why.
2016-12-29 16:14 GMT+01:00 Miles Lubin<EMAIL_ADDRESS>
The offending test is an SDP:
using JuMP, Base.Test, Mosek
m = Model(solver=MosekSolver())@variable(m, y)@variable(m, z)
c = @SDconstraint(m, [0 y; z 0] <= [1 0; 0 0])@objective(m, Max, y/2+z/2)
status = solve(m)
@test status == :Optimal@test isapprox(getobjectivevalue(m), 0, atol=1e-5)@test isapprox(getvalue(y), 0, atol=1e-5)@test isapprox(getvalue(z), 0, atol=1e-5)
X = getdual(c)@test isapprox(X[1,1], 0, atol=1e-5)@test isapprox(X[1,2], 1/2, atol=1e-5)@test isapprox(X[2,1], 1/2, atol=1e-5)@test isapprox(getdual(y), 0, atol=1e-5)@test isapprox(getdual(z), 0, atol=1e-5)
Ulf is correct that MathProgBase.status() should return the solver
response. It's a bit confusing that the solver can stall and still return
an optimal solution though. Why is it called a stall if the optimality
tolerances are satisfied?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/JuliaOpt/Mosek.jl/issues/101#issuecomment-269643804,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AJwCcbad1IKRfebQ3NRKLQcxFGGvAmIXks5rM84_gaJpZM4LLcy8
.

No need to convince me, I'm already convinced that the status API in MathProgBase needs to be redone.

I find the idea of having 4 values, i.e. return code, optimizer status, problem status, and solution status, quite interesting.

I not saying we have the ideal answer. Some users thinks we overdoing it
but my opinion is that solution status and optimizer status has to be
separated as a minimum.
On other hand you could have separate solution statuses for the primal and
dual solutions. Ulf does that in Fusion.
Maybe the right way to start is to think about the possible scenarios that
can occur

Out of time but a with feasible solution.
Optimal
Almost optimal but stalled. [We use that in MOSEK in the interior-point
optimizer.]
Out space
Out space but with a feasible solution
Certificates of infeasibility
Terminated on an objective cut.
User break with possible a feasible solution
......

Some other things to think about.
Is a user break or out of time an error? Is an infeasible problem an
error?  Is out of space an error?
My reply is: No, No, Yes.
2017-01-02 15:49 GMT+01:00 Carleton Coffrin<EMAIL_ADDRESS>
I find the idea of having 4 values, i.e. return code, optimizer status,
problem status, and solution status, quite interesting.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/JuliaOpt/Mosek.jl/issues/101#issuecomment-269981694,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AJwCcUG28SwwhumS5a_aCfmWErjaBhO7ks5rOQ5ngaJpZM4LLcy8
.

Btw on the problems MOSEK fails it computes a near optimal solution. Ulf
used to report them as optimal. But changed that in the interface based on
what you told him so now tests fails.
It might not be possible to resolve this unless you change the interface.
On another note when MOSEK says near optimal on a smallish problem it might
not be an ideal problem for a unit test. So the tests MOSEK starts failing
on is likely to be somewhat strange in the sense it is hard to compute an
optimal solution.
2017-01-02 19:41 GMT+01:00 Erling Andersen<EMAIL_ADDRESS>
I not saying we have the ideal answer. Some users thinks we overdoing it
but my opinion is that solution status and optimizer status has to be
separated as a minimum.
On other hand you could have separate solution statuses for the primal and
dual solutions. Ulf does that in Fusion.
Maybe the right way to start is to think about the possible scenarios that
can occur

Out of time but a with feasible solution.
Optimal
Almost optimal but stalled. [We use that in MOSEK in the interior-point
optimizer.]
Out space
Out space but with a feasible solution
Certificates of infeasibility
Terminated on an objective cut.
User break with possible a feasible solution
......

Some other things to think about.
Is a user break or out of time an error? Is an infeasible problem an
error?  Is out of space an error?
My reply is: No, No, Yes.
2017-01-02 15:49 GMT+01:00 Carleton Coffrin<EMAIL_ADDRESS>
I find the idea of having 4 values, i.e. return code, optimizer status,
problem status, and solution status, quite interesting.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/JuliaOpt/Mosek.jl/issues/101#issuecomment-269981694,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AJwCcUG28SwwhumS5a_aCfmWErjaBhO7ks5rOQ5ngaJpZM4LLcy8
.

Closing ancient issues.


Implemented codegen for CTL record fix changes

This branch contains the codegen tools needed for the CTL record fix updates (WIP)

@gnumonik please fix the build and notify us when it's done so we can review this.

@bladyjoker need your help fixing the IPC so I don't have to literally run all the tests by hand.
there's a lingering JSON issue with newtype records that we need to fix.
but the stupid manual tests pass and that means this PR is just about done

@gnumonik
Round trip tests (Purescript <-> Haskell)
  Round trip prerequisite tests
    `[test/RoundTrip/app] $ spago build` should work [✔]
    `[test/RoundTrip/app] $ spago build` should not warn of unused packages buildable [✔]
  with defaultBridge
    should have a Purescript process running [✔]
    should produce Aeson-compatible representations [✔]
      +++ OK, passed 100 tests.
  with ledger bridge
    should have a Purescript process running [✔]
    should produce PlutusData compatible representations [✔]
      +++ OK, passed 100 tests.

Finished in 2.9049 seconds
6 examples, 0 failures

TODO:

[ ] Resolve Argonaut vs PlutusTx integer conflict (Argonaut doesn't handle Integers, and PlutusTx doesn't handle Ints)

STATUS: Vladimir is trying to make CTL use Aeson solely so we can print into that?

[ ] Specify Arbitrary for PlutusTx.AssocMap
[ ] Embed plutus-ledger-api types into testing types

CI build is still broken, keeping it that way until I find a solution


tracing: fix OTLP tracer's initialization

insecure.NewCredential was simply wrong. It has to use
otlptracegrpc.WithInsecure to disable TLS.
context.WithTimeout is nice to have, in case the endpoint is not
correctly configured.
Otherwise, the plugin initialization blocks indefinitely.
grpc.WithReturnConnectionError is nice to have.
Otherwise, otlptracegrpc.New returns "context deadline exceeded"
without underlying errors.
TraceSamplingRatio should be 1.0 by default.
Otherwise, users need to configure both io.containerd.internal.v1.tracing
and io.containerd.tracing.processor.v1.otlp.

Signed-off-by: Kazuyoshi Kato<EMAIL_ADDRESS>

@cpuguy83 What do you think about TraceSamplingRatio change? I think 0.0 is counter-intuitive.

It's probably good to set to 1.0 since it (should) only have an affect if the processor is loaded anyway. It's certainly the value I want when debugging things.


torchlight problem

Hello：
I want to run the code.First, I prepare environment according to " cd torchlight, python setup.py install, cd .." while I want to train model, the error "cannot deom torchlight import  import_class" occurred. How to solve it?

I hava same problem

你可以试试

你可以试试 pip uninstall torchlightand 然后把import那里改成from torchlight.torchlight.io import 我也遇到这样的问题了

你可以试试 pip uninstall torchlight 然后把import那里改成from torchlight.torchlight.io import 我也遇到这样的问题了

install it from source as pip install . ( when you're in torchlight directory when you cloned repo).


Loot & Permissions Buttons

Players can drag items from the loot sheet without hassle, but when using the Loot, Loot All, Loot Stack buttons, they get the error "You must loot items from a token." I have tried disabling all other modules, but the issue persists. Also, all players are assigned the right actors. The same error occurs even when dragging the NPC sheet token onto the scene. Lastly, clicking the ticks next to player names just flashes the names, but doesn't change permissions.

I am currently using version 2.5.2, in Foundry version 0.7.9, DnD5e 1.2.4.
Thanks for your help!

This is not really possible I think. User can also just drag an drop items from a compendium into their inventory, or just change the amount they have, or give themselves an infinite amout of gold.
This module wont be able to prevent all of that

I'm not trying to limit the amount they can take, simply allow them to click Loot, Loot All, Loot Stack buttons to add the item to their inventory. Am I using these buttons wrong?

Well they can click those buttons? And those Buttons do exactly what they are supposed to. Those buttons do NOT work as GM and can only be clicked on a token, not on an actor .A telling error message should appear in cases this wont work


API /v1/projects//environments//?action=upgrade does not change rancher-compose file

Rancher Version:
v1.1.2
Docker Version:
1.1.2
OS and where are the hosts located? (cloud, bare metal, etc):
Ubuntu 16.04, GCE
Setup Details: (single node rancher vs. HA rancher, internal DB vs. external DB)
single node rancher, external DB
Environment Type: (Cattle/Kubernetes/Swarm/Mesos)
Cattle
Steps to Reproduce:

pre-existing stack with services
POST /v1/projects/1a381/environments/1e68/?action=upgrade with new docker-compose.yml and rancher-compose.yml
POST /v1/projects/1a381/environments/1e68/?action=finishupgrade

Results:

stack/services run through the states active => upgrading => upgraded => active
docker-compose.yml changed
rancher-compose.yml not changed

Expected:

docker-compose.yml, rancher-compose.yml are updated
if for example the scale of a service was increased in the rancher-compose.yml the service now has more instances

Am I using the upgrade wrong? I seemed to me, that was the way to go since the upgrade action accepts the compose files as params.
Cheers
Nick

What did you change in your rancher-compose.yml? If it was only scale, then you might be hitting this bug: https://github.com/rancher/rancher/issues/4897

closing this due to inactivity. Feel free to reopen with more information or create a new issue.


JSON files are not updating

There must be something wrong with the piece of code where the dictionaries are being updated.
My bet is on the popFirstElementUpdateOtherDict function

Well...here's the thing.
The updated json files would sometimes have small discrepancies.
If Chapter 286 was scraped, then the json would have changes till chapter 283 only (chapters 284-286 would be considered "un-read").
Initially it wasn't that huge, but this time the difference was 3 chapters (yes, the previous example). That's like wasting 300 seconds (sleep time after each successful scrape is 100).
This is of importance only when either the some error occurs (which is maybe less likely) or when the code is interrupted (key-board interrupt).
I guess we can add a function for the user to invoke, before they quit the program.

 It should be solved now. I'll test it later.
refer to af60d0f.

Update:
The problem still persisted after that.
Later on I realized that the code exits in more that one way.
One of those ways is a simple exit command in the interactive shell.
I made it save the json files if they're not empty.
refer to db12b06b1edbd40fd8284b9a5bb88e01c95ed4cd
The lazy is taking over.
I'm closing this. I hope the problem doesn't pop up again.


Dockstore CLI Requested URL Different

Bug Report
Expected behaviour
wget https://github.com/dockstore/dockstore/releases/download/1.8.0-beta.6/dockstore
chmod a+x dockstore
./dockstore --help

should show help message
Actual behaviour
https://github.com/dockstore/dockstore/releases/download/1.8.0-beta.1/dockstore-client-1.8.0-beta.1-shaded.jar
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
curl: (22) The requested URL returned error: 404 Not Found

Steps to reproduce the behaviour
See above
┆Issue is synchronized with this Jira Story
┆Issue Type: Story
┆Issue Number: DOCK-1145

Due to separation of cli and webservice, we can no longer assume matching cli and webservice versions.


Sometimes OSX users get an empty list of roles

When running "awscli sts get-caller-identity", sometimes OSX users get no roles to choose,
Example:
$ awscli sts get-caller-identity

Please choose the role you would like to assume:
Selection:

After running the command a couple of times (random number) the list will appear.
Is this a known issue and is there a fix?

This is not an issue with OSX. It happens for us in Docker containers as well. We debugged and tracked it down to AWS sending broken HTML. You know the page when you login to AWS using Okta where you can select your roles from multiple accounts? That's the one it's parsing and it seems like currently AWS is sending different versions - one broken and one non-broken, depending on the backend server you reach probably. See attached files.

awssignin-success.html.txt
awssignin-broken.html.txt

Notice the stray </head> in the broken file. The HTML parser (jsoup) then fails to parse the file properly.
Furthermore, it came to our attention that it would not be required to make the request to AWS using th SAML response from Okta because the SAML response already contains the information in XML - So this tool is using AWS just as a parser/renderer. However, this still requires parsing HTML from Okta, which is still less than perfect, but a possible point of failure less.
We're working on a solution that uses the SAML response directly from Okta

Thanks for the quick answer, will love to know once this is resolved.
Just another quick question: are you sure it's not related to OSX? 3 of our OSX users experienced this while the other 10 ubuntu users did not

@GavrielNsof I'm not 100% sure why it only seems to happen on OSX. We're two developers here trying out the Okta-AWS integration. One with Ubuntu, one with OSX. In fact, it does not happen on Ubuntu, but on OSX even in a Docker container, which should be Linux.
So our best guess is that Ubuntu somehow receives only the correct answer and that the underlying issue even propagates into the Docker container on OSX. We think about DNS caching. Frankly, our explanation does not convince ourselves either.
Also, I think I know now why this project is parsing AWS' response and is not unly using the SAML response: The latter does not include the human readable name of an account. Just the number.

Not sure if it helps but other SAML tools don't have this problem on OSX, (saml2aws for example)
(they do lack other features though).

@GavrielNsof I think that's because all tools I've checked so far are not using the page rendered by AWS

So, we analyzed this one further and came to conclusion that it's actually an issue with the jsoup library. I will create a merge request within the our

Thanks @sbrandtb!

@sbrandtb if I may ask, how did you update Jsoup? did you just download the jar (what path)?
Also, will this be fixed in the next okta-aws-cli version?
Thanks!

Could we get a new release with this fix?

I’ll try to do one this week, but I’m traveling in Greece, so might be tough. In the meantime, you should be able to clone the project and run “mvn package” to create your own copy with this fix.

On Jul 23, 2018, at 20:07, Richie Vos<EMAIL_ADDRESS>wrote:
Could we get a new release with this fix?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

Hi ..
Created the JAR file but it is giving a different error now. Although the issue with the empty list of roles seems to be fixed.
Attached is the error..
Exception in thread "main" java.lang.NoSuchMethodError: com.fasterxml.jackson.databind.JavaType.isReferenceType()Z
at com.fasterxml.jackson.databind.deser.BasicDeserializerFactory.findDefaultDeserializer(BasicDeserializerFactory.java:1533)
at com.fasterxml.jackson.databind.deser.BeanDeserializerFactory.findStdDeserializer(BeanDeserializerFactory.java:194)
at com.fasterxml.jackson.databind.deser.BeanDeserializerFactory.createBeanDeserializer(BeanDeserializerFactory.java:157)
at com.fasterxml.jackson.databind.deser.DeserializerCache._createDeserializer2(DeserializerCache.java:403)
at com.fasterxml.jackson.databind.deser.DeserializerCache._createDeserializer(DeserializerCache.java:352)
at com.fasterxml.jackson.databind.deser.DeserializerCache._createAndCache2(DeserializerCache.java:264)
at com.fasterxml.jackson.databind.deser.DeserializerCache._createAndCacheValueDeserializer(DeserializerCache.java:244)
at com.fasterxml.jackson.databind.deser.DeserializerCache.findValueDeserializer(DeserializerCache.java:142)
at com.fasterxml.jackson.databind.DeserializationContext.findRootValueDeserializer(DeserializationContext.java:461)
at com.fasterxml.jackson.databind.ObjectMapper._findRootDeserializer(ObjectMapper.java:3838)
at com.fasterxml.jackson.databind.ObjectMapper._readMapAndClose(ObjectMapper.java:3732)
at com.fasterxml.jackson.databind.ObjectMapper.readValue(ObjectMapper.java:2796)
at com.amazonaws.partitions.PartitionsLoader.loadPartitionFromStream(PartitionsLoader.java:92)
at com.amazonaws.partitions.PartitionsLoader.build(PartitionsLoader.java:84)
at com.amazonaws.regions.RegionMetadataFactory.create(RegionMetadataFactory.java:30)
at com.amazonaws.regions.RegionUtils.initialize(RegionUtils.java:64)
at com.amazonaws.regions.RegionUtils.getRegionMetadata(RegionUtils.java:52)
at com.amazonaws.regions.RegionUtils.getRegion(RegionUtils.java:105)
at com.amazonaws.client.builder.AwsClientBuilder.withRegion(AwsClientBuilder.java:239)
at com.amazonaws.client.builder.AwsClientBuilder.withRegion(AwsClientBuilder.java:226)
at com.okta.tools.helpers.RoleHelper.assumeChosenAwsRole(RoleHelper.java:36)
at com.okta.tools.OktaAwsCliAssumeRole.doRequest(OktaAwsCliAssumeRole.java:109)
at com.okta.tools.OktaAwsCliAssumeRole.run(OktaAwsCliAssumeRole.java:90)
at com.okta.tools.awscli.main(awscli.java:28)

@nj80750 looks like you used the jarfile from my fork where I tried to reduce the jarfile's size by removing lots of unused AWS stuff. Unfortunately, this leads to the error you posted.
Please compile the jar file on your own or use my updated one.

This is an amazing exchange. Thank you @sbrandtb! This is a huge contribution and awesome analysis work.

I too am having this issue with the automated install jar.  1.0.3

@gtaman. The install is still using 1.0.2. I’ll fix that. Have you downloaded the 1.0.3 release manually?


Feature request add command for searching latest and trending movies/tv show.

Mov-cli: (select server/provider) Solar
Mov-cli:  -T  --trending (displays the trending movie/tvshows)  or -L --latest  (displays the latest movie/tvshows)
Cause sometimes we just don't know what to watch  and we need to browse contents that might interest us.

Seems like a good feature to add

#41


Copy documentation from http://www.lemon-lang.org/documentation to doc/README.md

Hi, Thanks for your work, but the doc in source is not really mean the Lemon's tutorial or quick started.There's will be more detail tutorial in website, feel free try more Lemon's feature and add to website. I'm gonna close this pull request.Thanks again.


Api cleanup (remove List and Dictionary in favor of IList and IDictionar...

Api cleanup (remove List and Dictionary in favor of IList and IDictionary)
from the public surface copy header values on registration.
Make a copy of the mediatypeheader value in FormatterMappings so it's
really immutable.

:shipit:

Merged


(maint) Pin net-ssh to < 7.0

This pins the max version of net-ssh to < 7.0. net-ssh >= 7.0
requires Ruby >= 2.6, which we cannot ship since Bolt needs to be
compatible with Ruby >= 2.5.
!no-release-note

@donoghuc I'm not sure I agree. Most all of our gems are pinned to a version range, with the notable exceptions being puppet and net-ssh. Additionally, net-ssh 7.0 introduces some breaking changes (specifically, removing a ton of algorithms) that might adversely affect Bolt gem installs (see here and here).


fix mixpanel provider implementation

Mixpanel provider doesn't call the 'timeEvent' method on the mixpanel library properly.

Looks like the unit tests are failing on compiling this updated MixPanelProvider:
https://travis-ci.org/twobitlabs/AnalyticsKit/builds/103679277
maybe the version of MixPanel in AnalyticsKit needs to be updated?

@twobitlabs sorry for the late response! Yes indeed, it looks like the mixpanel version that the test is running against is old. The issue here though, I think is that travis does not run pod install before running tests...If it did, it should have pulled down the latest version of mixpanel.

Would you mind updating the MixPanel SDK included in the project? While we offer cocoapods as an option for analyticskit it's not required so for the tests we rely on the version in the repository.

oh well, that didn't work : ) i diidnt look carefully. looks like ill have to update the files in the project itself. ill do that tomorrow.

@brightredchilli it looks like you need to link the libicucore library in the test target

Also feel free to add yourself to the contributors at the bottom of https://github.com/twobitlabs/AnalyticsKit/blob/master/README.md

yknow, im struggling a little here - i did include it. for some reason this is not picking up. The SHA of my commit also does not match.

I think this is a travis shenanigan...I'll try adding another commit..

yeah the tests are passing for me locally too, not sure what's up with Travis. Going to merge this. Thanks!

it keeps checking out old SHAs. the SHA of the failing test does not match my latest commit. I have a feeling it is confused when I rebase. It's a bummer. Yup. Would you also be able to submit a new version to cocoapods? I can help with that if necessary

are there any changes required to the podspec, or do you just need a version bump?

I think we probably should require the version where mixpanel 'timeEvent' call was introduced. i can update the podspec but i need a couple of hours, afk right now.

Honestly, I'm thinking about dumping Cocoapods altogether. I haven't been able to push an update for a while because pod spec lint fails. Most of the dependencies fail with The 'Pods' target has transitive dependencies that include static binaries.
I've spent more time than I care to try to get the pod lint to pass, and I don't really want to invest more time, as we don't use Cocoapods ourselves, and AnalyticsKit is trivial to integrate without it.


Speed performance

Thanks for your code, after running the Speed Testing code, the fps is 8.19 for embed_mask_R101_ms_3x.pth, but in the paper the speed is 13.7 fps, what does the fps in the paper refer to ?  why is there a difference?

@Epiphqny
What kind of GPU do you use?

@Epiphqny
What kind of GPU do you use?

Tesla V100


Even if the demo is gone, the configuration document cannot be found on the document.

Why you need it?
demo源码给一份
How it could be?
Other related information

https://github.com/fescar-group/fescar-samples


add alb zone_id and alb arn to output

heya, great module!
this pr just creates two outputs -
one exposes the concourse alb's zone_id - so we can use resource.route53
the other exposes the alb's ARN in case one might set up a specific ssl termination policy or something to that effect.

Thank you for contributing!
I think the PR makes absolutely sense. :-)

Ah, missed something...
Can you just add a comment to the CHANGELOG.md for the next (unrelease) version?


Update sbt-release to 1.0.15

Updates com.github.gseitz:sbt-release from 1.0.13 to 1.0.15.
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Ignore future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "com.github.gseitz", artifactId = "sbt-release" } ]

labels: sbt-plugin-update, semver-patch

Codecov Report

Merging #124 (3a62c75) into master (05a47c8) will increase coverage by 2.35%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master     #124      +/-   ##
==========================================
+ Coverage   84.04%   86.39%   +2.35%
==========================================
  Files          19       18       -1
  Lines         282      272      -10
  Branches        6        7       +1
==========================================
- Hits          237      235       -2
+ Misses         45       37       -8

Impacted Files
Coverage Δ

.../scala/io/circe/generic/extras/ExtrasDecoder.scala

.../main/scala/io/circe/generic/extras/semiauto.scala
75.00% <0.00%> (+1.31%)
:arrow_up:

...ce/generic/extras/decoding/ConfiguredDecoder.scala
91.52% <0.00%> (+3.19%)
:arrow_up:

...generic/extras/codec/ConfiguredAsObjectCodec.scala
100.00% <0.00%> (+7.14%)
:arrow_up:

Continue to review full report at Codecov.

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


PX4 API

Signed-off-by: Alejandro Hernández Cordero<EMAIL_ADDRESS>
PX4 draft
decouple the interface from ROS, there might be API without ROS support

For now it just arm the quadcopter
TEST
ros2 launch px4_sim x500_launch.py

another terminal
ros2 run vehicle_gateway_px4 vehicle_gateway_px4_node

arm, takeoff and land


[release 4.8] Bug 2040407 list type

Making list atomic to prevent GitOps overwrite for 4.8 backport

/label cherry-pick-approve

/label cherry-pick-approved

Hello @sttts Is // +listType=atomic is wrong?
This has passed QA/merged/been reviewed on 4 PR's so far.
What are your thoughts?


Update a-fully-applied-document-open-status.md

Pull request guidance
Thank you for submitting your contribution to our support content! Our team works closely with subject matter experts in CSS and PMs in the product group to review all content requests to ensure technical accuracy and the best customer experience. This process can sometimes take one or more days, so we greatly appreciate your patience.
We also need your help in order to process your request as soon as possible:

We won't act on your pull request (PR) until you type "#sign-off" in a new comment in your pull request (PR) to indicate that your changes are complete.

After you sign off in your PR, the article will be tech reviewed by the PM or SME if it has more than minor changes. Once the article is approved, it will undergo a final editing pass before being merged.

Hi @aartig13 and @theley502, the draft is ready for your review.

Hi @aartig13 and @theley502, the draft is ready for your review.

Looks good to me.


Small bug in OrthogonalExcitations

Describe the bug
When starting OrthogonalExcitations by passing a GroundStateSearch result, the simulation does not go through because the system is unable to get the ground state energy.
The issue seems to be with this block in these lines of ground_state_search.py, in that E0 is not previously defined.
        if apply_local_op is None and switch_charge_sector is None:
            self.orthogonal_to = [self.ground_state]
            self.results['ground_state_energy'] = E0
        else:

Problem seems to be fixed by changing E0 to data["energy"]
If this is reasonable, I'm happy to submit a pull request!
Minimal example or code extract
Show how you call the code that is failing. Include it in backticks like this:
import tenpy
import tenpy.linalg.np_conserved as npc
from tenpy.algorithms import dmrg
from tenpy.networks.mps import MPS
from tenpy.models.tf_ising import TFIChain

from tenpy.models.lattice import TrivialLattice
from tenpy.models.model import MPOModel
from tenpy.networks.mpo import MPOEnvironment

tenpy.tools.misc.setup_logging(to_stdout="INFO")

from tenpy.simulations.ground_state_search import OrthogonalExcitations, GroundStateSearch

L = 10

GS = GroundStateSearch(options = {
    "model_class": "TFIChain",
    "model_params": {
    'J': 1. , 'g': 1.5,
    'L': L,
    "conserve": None,
    'bc_MPS': 'finite',
},
    "algorithm_class": "TwoSiteDMRGEngine",
    "algorithm_params":{
    'mixer': True,
    'max_E_err': 1.e-10,
    'trunc_params': {
        'chi_max': 100,
        'svd_min': 1.e-10,
    }
},
    "initial_state_params":{
        "method":"randomized",
        "randomized_from_method": "lat_product_state",
        "product_state": [['up'], ['down']]*(L//2),
        "randomize_params": { 'N_steps': 10, 'trunc_params': {'chi_max': 100}}
    }
}
                      )

GS.run()

from pathlib import Path
GS.output_filename = Path("./test_L%d.h5"%L )
GS.save_results()
print(GS.output_filename)

OE = OrthogonalExcitations(options = {"N_excitations":2, "ground_state_filename" : "test_L%d.h5"%L})
OE.run()

Error traceback
If applicable, copy-paste (the first and last part of) the error traceback
---------------------------------------------------------------------------
NameError                                 Traceback (most recent call last)
/tmp/ipykernel_26237/2021676026.py in <module>
     36
     37 OE = OrthogonalExcitations(options = {"N_excitations":2, "ground_state_filename" : "test_L%d.h5"%L})
---> 38 OE.run()

~/CSL_Prep/CSL_Preparation/TeNPy/tenpy/simulations/ground_state_search.py in run(self)
    138     def run(self):
    139         if self.orthogonal_to is None:
--> 140             self.init_orthogonal_from_groundstate()
    141         super().run()
    142

~/CSL_Prep/CSL_Preparation/TeNPy/tenpy/simulations/ground_state_search.py in init_orthogonal_from_groundstate(self)
    218         if apply_local_op is None and switch_charge_sector is None:
    219             self.orthogonal_to = [self.ground_state]
--> 220             self.results['ground_state_energy'] = E0
    221         else:
    222             # we will switch charge sector

NameError: name 'E0' is not defined

The most up-to-date orthogonal excitations code is in the excitations_science branch and not main. This code is not commented, so let me know if you have any questions or find any unexpected behavior.
Also, if you are looking for excited states of a finite chain, you can also do this by running DMRG and passing the ground state to the DMRG engine as a parameter of the init_env function; https://tenpy.readthedocs.io/en/latest/reference/tenpy.algorithms.dmrg.DMRGEngine.html#tenpy.algorithms.dmrg.DMRGEngine.init_env
The OrthogonalExcitation class does the same thing as the above method if you don't change the charges.

Given that this is being sorted out in a different branch, let me close this!
Thanks Sajant!


How to match TLS SNI with proxy_protocol?

~~I'm not sure if sharing solution in Issues is a good practice, while making a PR for adding an example that may not be common usage is improper either. ~~
Here is the scene:
(public Internet) <-> Gateway Caddy <-> proxy_protocol+HTTPS <-> Backend Caddy <-> proxy_protocol+h2c <-> Backend Apps

Example of Not working
For backend caddy, if we want to match the TLS SNI to make special handler sequences for different sites, the following config will not work:
{
  "apps": {
    "layer4": {
      "servers": {
        "outsideHTTPS": {
          "listen": [
            "<IP_ADDRESS>:8443"
          ],
          "routes": [
            {
              "match": [
                {
                  "tls": {
                    "sni": [
                      "a.foo.bar"
                    ]
                  }
                }
              ],
              "handle": [
                {
                  "handler": "proxy_protocol"
                },
                {
                  "handler": "tls"
                },
                {
                  "handler": "proxy",
                  "proxy_protocol": "v1",
                  "upstreams": [
                    {
                      "dial": [
                        "<IP_ADDRESS>:2233"
                      ]
                    }
                  ]
                }
              ]
            }
          ]
        }
      }
    }
  }
}

Here is the logs. The tls matcher fails to match the SNI, becasue the data it reads is the proxy protocol header instead of the TLS header:
layer4        prefetched        {"remote": "<IP_ADDRESS>:39790", "bytes": 563}
layer4        matching        {"remote": "<IP_ADDRESS>:39790", "matcher": "layer4.matchers.tls", "matched": false}
layer4        matching        {"remote": "<IP_ADDRESS>:39790", "matcher": "layer4.matchers.tls", "matched": false}
layer4        matching connection        {"remote": "<IP_ADDRESS>:39786", "error": "aborted matching according to timeout"}
layer4        connection stats        {"remote": "<IP_ADDRESS>:39786", "read": 563, "written": 0, "duration": 3.001154115}
layer4        matching connection        {"remote": "<IP_ADDRESS>:39790", "error": "aborted matching according to timeout"}

Even if prepending a proxy_protocol matcher before the TLS matcher, the match still fails:
{
  "apps": {
    "layer4": {
      "servers": {
        "outsideHTTPS": {
          "listen": [
            "<IP_ADDRESS>:8443"
          ],
          "routes": [
            {
              "match": [
                {
                  "proxy_protocol":{},
                  "tls": {
                    "sni": [
                      "a.foo.bar"
                    ]
                  }
                }
              ],
              "handle": [
                {
                  "handler": "proxy_protocol"
                },
                {
                  "handler": "tls"
                },
                {
                  "handler": "proxy",
                  "proxy_protocol": "v1",
                  "upstreams": [
                    {
                      "dial": [
                        "<IP_ADDRESS>:2233"
                      ]
                    }
                  ]
                }
              ]
            }
          ]
        }
      }
    }
  }
}

layer4        matching        {"remote": "<IP_ADDRESS>:48220", "matcher": "layer4.matchers.tls", "matched": false}
layer4        matching        {"remote": "<IP_ADDRESS>:48220", "matcher": "layer4.matchers.proxy_protocol", "matched": true}

Why not using the official listener_wrapper to handle the proxy_protocol header and TLS termination? In my situation, the listener_wrapper method is good for some sites , but there is one site that needs plain HTTP with proxy_protocol.

Worked out the solution again, using the subroute handler:

Capture any connection that starts with proxy_protocol header
Process (consume) the proxy_protocol, then match the TLS SNI

{
  "apps": {
    "layer4": {
      "servers": {
        "outsideHTTPS": {
          "listen": [
            "<IP_ADDRESS>:8443"
          ],
          "routes": [
            {
              "match": [
                {
                  "proxy_protocol": {}
                }
              ],
              "handle": [
                {
                  "handler": "proxy_protocol"
                },
                {
                  "handler": "subroute",
                  "routes": [
                    {
                      "match": [
                        {
                          "tls": {
                            "sni": [
                              "a.foo.bar"
                            ]
                          }
                        }
                      ],
                      "handle": [
                        {
                          "handler": "tls"
                        },
                        {
                          "handler": "proxy",
                          "proxy_protocol": "v1",
                          "upstreams": [
                            {
                              "dial": [
                                "<IP_ADDRESS>:2233"
                              ]
                            }
                          ]
                        }
                      ]
                    },
                    {
                      "match": [
                        {
                          "tls": {}
                        }
                      ],
                      "handle": [
                        {
                          "handler": "proxy",
                          "proxy_protocol": "v1",
                          "upstreams": [
                            {
                              "dial": [
                                "<IP_ADDRESS>:8444"
                              ]
                            }
                          ]
                        }
                      ]
                    }
                  ]
                }
              ]
            }
          ]
        }
      }
    }
  }
}

Thanks for sharing your solution! It'll probably help others who search for this later.


Remove version pin for jupyter_server

The old version pin is not needed anymore and was causing environment conflict issues.

I'll merge this after successful build.

Successful build and preview!
Will merge now.


Replace Transparent nodes with deserialization leftovers

Transparent nodes are quite quirky and may lead to bugs or surprising results. They also do not really fit in the configuration tree representation, especially as we move towards immutable structures.
However, knowing what serialized data got rejected from the live structure can be useful, eg. to inject it upon re-serialization.
This PR removes the former, and adds the ability to easily get the latter through deserialization leftovers.

Thanks!


Tasks that run on the host

It would be great if you could define a task that executes on the host (not in a Docker container).
This is useful because:

It means you can use batect as your task runner for all tasks, even the ones that can't/shouldn't run in Docker
It means when you're setting up task workflows using dependencies, you can include these

A prime example: I want to run a bash script that build a Docker image for my Java app. The Dockerfile includes a COPY that takes my app.zip, which was built by Gradle, and extracts it into the image.
I want to use that bash script/task as a dependency of a task that then uses the new Docker image as part of a Terraform deployment.
This means my task flow goes:

Compile the Java (done in a batect java-env)
Run shell script to build and push the Docker image
Run the Terraform (done in a terraform-env)
More steps

Right now, 2. is done in a "docker-env" which actually doesn't contain much, and mounts the Docker socket from the host. Ideally it would be run directly on the host, but I can't do that and still have my end-to-end task workflow with batect.

This is something I've been thinking a bit about lately. Is your only use case for running a command locally building and pushing an image?

I think there's other usecases. For example, installing a pre-commit hook for the repo.
The problem is that teams tend to try and use batect instead of a "go" script, but it's hard to do that when it has to run everything in Docker.

OK, makes sense. This isn't something I'm going to implement soon, but I will one day.
Out of interest, is there a reason why you can't mount the source directory into a container and set up the pre-commit hooks from there?


build-test-recipe.yml: add

This GH workflow will build and test recipes.
Issue #, if available:
Description of changes:
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Successfully created backport PR for kirkstone-next:

#10021

Successfully created backport PR for styhead-next:

#10023


Client-side form validation

Describe the solution you'd like
Currently, most of the form validation is done by backend, that is, an error prompt is shown after the request has been sent. Form validation should be done properly on the client side, field by field, onsite.
What does your solution aim to solve?
User should be helped while filling a form to mitigate the frustration of making a failed operation.

@mausworks @iannbing What is the status of this? Seems like we are already doing it in a number of places.

It's getting a lot better for sure @yannickperrenet. In the new UI design, most forms have some sort of front-end validation. But I'll let @iannbing decide if/when we should close this issue. :+1:


Missing .launch files and packages

rosrun cartographer_ros cartographer_rosbag_validate -bag_filename cartographer_paper_deutsches_museum.bag

Full output: [rospack] Error: package 'cartographer_ros' not found
2 and 3. I haven't reached the point where I can process a bag file; not getting that far.
I've followed the steps up to https://google-cartographer-ros.readthedocs.io/en/latest/demos.html, but rosrun doesn't find any packages, and there are no .launch files on my system.
It appears the demo installation was incomplete.  How does one obtain/install packages and .launch files?
Thanks!
Alan

did you source your packages?

Hi MrGitGo, I'm not sure what you mean by "source your packages".  I'm from a Windows background, and Linux is new to me.

Folder problem.  Fixed.  Closing issue.


Update stack authors guide with the latest spec

The stack author's guide (https://devfile.github.io/devfile/assembly_making-a-workspace-portable-using-a-devfile.html and the linking partial pages) was created a while ago. New fields has been added and some of the samples and descriptions needs to be updated due to the updating of the spec since it was last created.

@elsony, I look forward to working on this issue. I've gone through the devfile docs and guide for stack authors that you included, and I know I must update the samples, specifications, and descriptions. How would I know all the information and content that needs to be updated?

@jc-berger The main thing that we need to do is to go through those documents and make sure the content covers and matches the specification under the schema doc https://docs.devfile.io/devfile/api-reference.html. Unfortunately, the original stack author's guide was created a couple months back and things get out of sync. The easiest way is probably for us to get together and I can pick one section of the doc and show you an example on how to do it. The schema doc already have some info documented in there and I can fill you in the rest if you have further questions.

@elsony, thank you. Yes, I think meeting will be the most efficient way, thanks for being willing to meet. I'll schedule something for us today, and feel free to counter to a different time. Talk soon!

@elsony, after talking to the doc team, we've decided it would be best if I made a separate PR for each doc that's getting modified, according to the schema. The goal is to make the review of each doc easier.
Letting you know for your awareness and anyone else working on this issue. Thanks!

@elsony, for your awareness, I've linked 4 PRs to this issue (PRs #18-21). Each PR is for one doc that I've edited. One doc per PR hopefully makes the review easier.  Not all the assemblies linked to the guide needed updating. Hence, not every doc referenced in the guide needed a PR.
Please let me know who will be doing the technical review of the PRs, and I shall be happy to work with him or her.
Thanks for all the help you've been on this!

@jc-berger With the 4 PRs merged, is there any outstanding work that you are still planning for this item, i.e. is this item ready to be closed?

@elsony, this issue can be closed. thank you for the follow up!


[fix-12504][sql] Add unique key to t_ds_process_definition_log

After I edit the workflow, I save it.
The interface response speed is too slow.
Let me think I didn't save it，So I saved it again.
The result saved successfully both times.
But in the t_ds_process_definition_log table, the version values are the same.
Causes the list interface to report an error.

This should be addressed first at the table structure level.
#12504

Codecov Report

Merging #12503 (55863ca) into dev (b936b88) will decrease coverage by 0.03%.
The diff coverage is n/a.

@@             Coverage Diff              @@
##                dev   #12503      +/-   ##
============================================
- Coverage     39.45%   39.41%   -0.04%
  Complexity     4217     4217
============================================
  Files          1041     1041
  Lines         39160    39112      -48
  Branches       4478     4462      -16
============================================
- Hits          15449    15417      -32
+ Misses        21942    21926      -16
  Partials       1769     1769

Impacted Files
Coverage Δ

...eduler/api/dto/schedule/ScheduleCreateRequest.java
83.33% <0.00%> (-2.39%)
:arrow_down:

...e/dolphinscheduler/service/queue/TaskPriority.java
51.31% <0.00%> (-1.25%)
:arrow_down:

...r/plugin/task/sqoop/parameter/SqoopParameters.java
51.19% <0.00%> (-1.20%)
:arrow_down:

...cheduler/plugin/alert/dingtalk/DingTalkSender.java
34.13% <0.00%> (-0.78%)
:arrow_down:

...hinscheduler/service/storage/impl/HadoopUtils.java
15.94% <0.00%> (-0.73%)
:arrow_down:

...inscheduler/plugin/registry/etcd/EtcdRegistry.java
50.34% <0.00%> (-0.69%)
:arrow_down:

...he/dolphinscheduler/plugin/task/java/JavaTask.java
58.50% <0.00%> (-0.69%)
:arrow_down:

...lphinscheduler/api/dto/task/TaskCreateRequest.java
83.33% <0.00%> (-0.54%)
:arrow_down:

.../apache/dolphinscheduler/common/utils/OSUtils.java
33.93% <0.00%> (-0.40%)
:arrow_down:

...olphinscheduler/plugin/alert/email/ExcelUtils.java
81.25% <0.00%> (-0.39%)
:arrow_down:

... and 21 more

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

May I ask whether we are going to add this patch to 3.0.2?

May I ask whether we are going to add this patch to 3.0.2?

yes


[cuDNN] Add mhlo to cudnn stub pass.

A pass with a simple pattern to rewrite an mhlo op to a cudnn op, plus a test.

This PR has moved to https://github.com/openxla/openxla-nvgpu. Closing.


Update README.md with GPTDiscord

Add my project GPTDiscord to the readme
It is a good example of a community integration with the API, and quite popular

Thank you!


Using JuliaFormatter?

As I start to work on forward mode Mooncake, I realize my fingers go for Ctrl + Shift + I ("format document") regularly. But since the current code base is not formatted, this might affect the parts of files that my meaningful changes haven't touched.
Would you be open to setting up a JuliaFormatter style and test?

Ah, yes, absolutely. What's the best way to sequence this? Should I take a look at doing this asap, or wait until we've got forwards mode stuff done?

I can do it easily before we get to forward mode

Just gotta tell me which style to go for

Excellent. Blue is my preferred style!


Add parser for Pendulum/Amplitude networks

This PR adds a parser for the asset registries of the Pendulum and Amplitude networks.

@mkchungs thanks for the review. You're right, the pallet is not yet live on Pendulum (it will be with the next runtime upgrade) and is empty on Amplitude. But of course, it's hard to test that the changes in this PR work as expected without any asset data. I'll get back to you once we added assets to the registry of Pendulum and Amplitude 👍


[hotfix][docs] Fix the Intellij key nouns.

What is the purpose of the change

I think the Intellij should be changed to IntelliJ IDEA. For details, please refer to the official website https://www.jetbrains.com/idea/ and https://en.wikipedia.org/wiki/IntelliJ_IDEA.

Brief change log

Modify Intellij to IntelliJ IDEA.

Verifying this change

This change is a trivial rework / code cleanup without any test coverage.

@flinkbot run azure

@MartijnVisser , Sorry to bother you again, can you help me review this pr? Thank you.

@flinkbot run azure

@mbalassi ,Sorry to bother you again, can you help me review this pr? Thank you.

@MartijnVisser , Thank you very much for your review.


Spelling mistake on about page

The Queue is used for coordination betweent the different end points.

Thanks, fixed in 0467edda2d4b3c1abc4abd17664b09c843d6900e


[BUG] low quality compose file parsing errors

  zookeeper:
    image: confluentinc/cp-zookeeper:5.5.0
    #<<: *defaults
    #mem_limit: 500m
    hostname: zookeeper
    ports:
      - "2181:2181"
    environment:
      ZOOKEEPER_CLIENT_PORT: "2181"
      ZOOKEEPER_TICK_TIME: "2000"
      KAFKA_HEAP_OPTS: '-Xms256M -Xmx256M'
      KAFKA_OPTS: "-Dzookeeper.4lw.commands.whitelist=*"
    healthcheck:
      test: 'echo "ruok" | nc -w 2 -q 2 localhost 2181 | grep imok'
exo apply docker-compose.yml
Error: parsing: 1:13: | is not a valid word
parsing: 1:13: | is not a valid word

@BenElgar is this solved with your work on #217?

Yes, hopefully. I'll assign to myself and close when fixed.


refactor, use nowcasting_datamodel

Detailed Description
use nowcasting_datamodel read function. This will reduce the code, and allow other components to use the various read functions

Did we you do this @rachel-labri-tipton ? I think you did


geobuf does not play well with pbf => 1.3.6

I have a server -> client setup where i encode and transfer GeoJSON using geobuf. This last 24 hours a couple of new releases of pbf has been made (1.3.6 and 2.0.0). When upgrading to any of these geobuf seems to generate (or just parse) malformed GeoJSON.
This is when I encode with 1.3.6 or 2.0.0 on the server side and use a matching pbf version on the client end. If I downgrade to 1.3.5 everything looks fine again.
Not sure if this is a pbf bug or just interplay problems between pbf and geobuf.

Oh no! Can you provide a minimal test case that reproduces the bug? cc @RReverser must be something about your encoding changes.

All geobuf tests pass when updating pbf to 1.3.6, so we'll need a specific sample GeoJSON that fails (the smaller the better) to be able to figure out the issue.

It might be something specific to my deployment. I was a bit opportunistic in posting an issue hoping it might be something obvious that you would immediately catch.. Most of my GeoJSON fails, but not completely, I get weird artefacts such as (green vector line):
1.3.5:

1.3.6:

The only difference between the two is the pbf version used for the geobuf transfer.
I'll have a test case (or an excuse) ready for you later today!

@averas in addition to a test case, can you test this with pbf on commit https://github.com/mapbox/pbf/commit/3ea87dcedb32778de1d4b43b3c43ee972deef761, and the one immediately before that (https://github.com/mapbox/pbf/commit/9ed6e8630e0d829e5f0984f9d8abc0b12655b33e), and confirm whether the second doesn't have the issue whether the first one has?

Yeah, it's weird given that test passes. Can't tell anything for sure until we have a test case.

Okay guys:
$ git clone git@github.com:averas/geobuf-test.git
$ cd geobuf-test
$ npm install
$ node server.js

This will install pbf 1.3.6 and use a build of pbf 1.3.6 on the client side. Goto http://localhost:8181/ and watch the malformed geojson.
Then, kill the server and:
$ npm install<EMAIL_ADDRESS>$ node server.js

... and modify public/index.html by hand to change to the 1.3.5 client build of pbf.
Surf to http://localhost:8181/ to see correctly shaped geosjon.

@averas is there a way to reproduce this without a server setup, just a sample GeoJSON file that you convert to pbf and back and it becomes malformed?

Sure. I just wanted to make something that was as close to my own setup as possible to begin with. It seems changing the client side version has no effect though, so it's probably on the encoding side of things.
Give me a minute to create such a case...

I got, managed to reproduce with the geojson you had in server.js. It's indeed a regression in pbf @RReverser.

I've confirmed 3ea87dcedb32778de1d4b43b3c43ee972deef761 to be the breaking commit. :(

And I've confirmed you're faster than me. :-)

Cool, but can I also get a descriptor and the source to see the difference in binary? :smile:

@RReverser
https://gist.github.com/averas/48763c776e19b7a4ecdfb700b6bffd49
returns true with 1.3.5 and false with 1.3.6.. you can extract any binary rep. you want from that.

Released 1.3.7 and 2.0.1 with the fix. Thanks for catching this bug, I was scared! Thankfully we figure it out on Saturday, before more people hit it in production. :)

I just reflected over that myself.. less than an hour between provided test case and implemented fix and published releases.. on a Saturday.. Great work!


Numpad plus on windows

I don't know whether this is a bug/feature in cursive or pancurses, sorry for the noise if this is not the scope of cursive.
I am working on windows with pancurses-backend and master branch.
For my hexview I normally use the +-Numpad to increase the array, but on windows it does not map to Char('+'), instead it is an Unknown with [161, 0, 0, 0] (the same goes for the minus, times and div key as well with 160, 159, 154 as the first value)
Is there a way to fix it here or should I open a request on pancurses repo?

I'm not sure.
I think this should be handled in pancurses' windows::to_special_keycode.
In the meantime, it should be possible to parse it here anyway.

turn numlock on.

@IGBC doen't work for me ;)

Can you run the getch_example example from pancurses, and report what you see when you press this key? Thanks!

Both problems are now fixed. I can use + on Numpad and ø/Ø. I'm happy, thanks!


VirtualizedList function optimization

Fixes
Fixes #20174
Changes Made

Optimized function passing to the CellRenderer component.
Removed all components being passed in through the parentProps prop since they were not being used but causing a re-render since component props always get a new reference.
Add shouldComponentUpdate to CellRenderer and compared the old props to the new props using shallowEquals. I had to pull in shallowEquals and modify it to allow exceptions. I would like some feedback here.

I noticed the onLayout method has this comment // This is extracted by ScrollViewStickyHeader . I'm not sure if my modification effected anything in regards to that.
Test Plan:
Tested on a real device with why-did-you-update running to view when the CellRendere component re-rendered. Applied updates to the list items to make sure they still get updated.
Added a test that makes sure the initial onLayout is still called properly.
Release Notes:
[GENERAL] [ENHANCEMENT][VirtualList]  - Prevent unnecessary re-renders of the CellRenderer Component.

IMO, Ping @sahrens @shergin

@jasekiw I will be happy to help move this forward if you don’ have the time?

@jasekiw It would be so awesome if this could make it into master. If you feel that you don't have the time to respond to the change request. I would be happy to help.

@jasekiw I asked @sahrens a few questions and depending on his answer we can choose the best approach?

@jasekiw & @sahrens I made a new pull request and simplified the solutions. CellRenderer is now a PureComponent and the props are now flat utilizing PureComponents shouldComponentUpdate
#21163

Closing in favor of the new PR.


Issue with Numix icons

I have installed Numix theme numix-gtk-theme and numix icon sets numix-icon-theme and numix-icon-theme-circle. When I wanted to change xfce's appearance selecting one of those sets, gtk always displays default icon set. (restarting, clearing ~/.cache/xfce or deleting ~/.gtkrc-2.0 or settings.ini, etc. didn't help) Changing to numix gtk theme has no issues.
At first I assumed it is missing path or gtk icon cache problem. I removed both icon sets.  Put icons directly from designer's git into ~/.icons directory as I had on Gentoo and Ubuntu. Xfce alerts be about missing gtk icon cache (yellow triangle in appearance menu). I executed gtk-update-icon-cache  command on each of icon sets directory. Still not showing desired icons.
I'm blindly guessing the problem is in gtk-update-icon-cache or maybe my config simply missing some package to handle those icons. Can't figure it out. Does anyone know how to debug those kind of issues?
Using NixOS stable 15.09. Tried unstable yesterday, same result.
nixos config, other things I tried are in comments
gtk2 config
gtk3 config

cc @lethalman

I've copied icon/theme setup from @bennofs nix configuration. works fine (with Numix)

Tnx @wedens and @bennofs for his config. The problem was missing GDK_PIXBUF_MODULE_FILE.
Q: Would it be good idea to set such variable inside numix icon definition? Or somewhere else? Would it affect other packages?

@GCerar I think it's part of https://github.com/NixOS/nixpkgs/issues/247#issuecomment-41255168

Oh, I didn't know. Nice :). My issue is solved with workaround. Final solution will came with NixOS 16.xx. Closing.


Migrate to main default branch

https://github.com/marketplace/actions/default-branch-migration

Closed by #14.


Updates to uartdpi.sv

fixed bug in cycle counters where (CYCLES_PER_SYMBOL-1) should be
used as counter end value.  Only visible when running UART at max
baud rate for simulation test, i.e. CYCLES_PER_SYMBOL==2.
added initial block to set 'seen_reset' qualifier for UART receive
start bit. This prevents spurious characters being printed when the
rx_i pin toggles before reset.

@sjalloq: The failing CI is a check on the commit message. You need to add a sign-off line that certifies you're ok with our Contributor Licence Agreement. See CONTRIBUTING.md for details.
I think you'll also find this fails a lint check in CI afterwards. Our style puts spaces around binary operators (so it should be CYCLES_PER_SYMBOL - 1 rather than CYCLES_PER_SYMBOL-1.

@sjalloq: The failing CI is a check on the commit message. You need to add a sign-off line that certifies you're ok with our Contributor Licence Agreement. See CONTRIBUTING.md for details.
I think you'll also find this fails a lint check in CI afterwards. Our style puts spaces around binary operators (so it should be CYCLES_PER_SYMBOL - 1 rather than CYCLES_PER_SYMBOL-1.

@rswarbrick, thanks, now updated.  Should I be pushing pull request updates like this or somehow squashing them locally first?

@rswarbrick, thanks, now updated.  Should I be pushing pull request updates like this or somehow squashing them locally first?

Probably better to squash locally, because this makes for a cleaner commit history at the end. In this particular case, you'll definitely need to squash because the check for a signoff line runs on each commit in the PR.

Probably better to squash locally, because this makes for a cleaner commit history at the end. In this particular case, you'll definitely need to squash because the check for a signoff line runs on each commit in the PR.


HTTP CONNECT method not supported

Hi,
Running a simple code to test CONNECT seems not to be supported :
use anyhow::Result;
use http::{Method, StatusCode};
use spin_sdk::{
    http::{Request, Response},
    http_component,
};

/// A simple Spin HTTP component.
#[http_component]
fn handle_connect(req: Request) -> Result<Response> {
    println!("{:?}", req.method());
    let (status, body) = match req.method() {
        &Method::CONNECT => {
            (StatusCode::OK, None)
        }
        // No other methods are currently supported
        _ => (StatusCode::METHOD_NOT_ALLOWED, None),
    };
    Ok(http::Response::builder()
        .status(status)
        .body(body)?)
}

Indeed CONNECT is not supported. I'm not sure there is a reasonably way to implement it in Spin's application model; could you describe your use-case?

It is usually employed for establishing an initial connection to speed things up for next requests since most middlewares are capable of caching connection details.
Of course an empty GET still works, but the proper method is actually CONNECT.

Interesting; I've never seen CONNECT used that way.
If you need to prewarm a connection with an HTTP request I would recommend using HEAD or OPTIONS.

Well to be more precise it usually when HTTPS is invoked and you might require going through some proxies before final URI. (not sure I am wording that correctly in english)

CONNECT would only be applicable if spin itself was operating as an HTTP proxy. I don't think it would make sense to add that functionality to spin given its current execution model.

No problem with me, I was just testing all methods.
But on your last comment, wouldn't Spin still require to respond to CONNECT if a client request it through a proxy? (Spin being the final URI)

CONNECT is only (typically) used in a connection to a proxy server, not in the traffic tunneled through the proxy.

No specific support for CONNECT expected at this time, though a future revision of the interface will likely allow requests with any method.


[Event Hubs] Add a 20% random jitter to the EP load balancing interval.

This PR is related to #9575

/azp run python - eventhubs - tests


Cap stack/service deploy collections

Fixes #2563 . Also adds missing index to the finished_at field.

Hmm, I think I'd prefer to avoid schema changes/migrations like this for the 1.4.x release unless it's absolutely necessary.... capping the stack/service deploy collection does makes plenty of sense, can it wait for 1.5?
OTOH adding a finished_at index does sound appropriate for a 1.4.x release.

Moved index part to #3046

Hmm... I think this isn't going to work?
api_1      | E, [2017-12-11T10:09:24.259979 #8] ERROR -- StackDeployWorker: failing update: objects in a capped ns cannot grow (10003)
api_1      | E, [2017-12-11T10:09:24.261334 #8] ERROR -- StackDeployWorker: /usr/lib/ruby/gems/2.4.0/gems/mongo-2.4.3/lib/mongo/operation/result.rb:256:in `validate!'
api_1      | /usr/lib/ruby/gems/2.4.0/gems/mongo-2.4.3/lib/mongo/operation/write/write_command_enabled.rb:57:in `execute_write_command'
api_1      | /usr/lib/ruby/gems/2.4.0/gems/mongo-2.4.3/lib/mongo/operation/write/write_command_enabled.rb:41:in `execute'
api_1      | /usr/lib/ruby/gems/2.4.0/gems/mongo-2.4.3/lib/mongo/collection/view/writable.rb:244:in `block in update'
api_1      | /usr/lib/ruby/gems/2.4.0/gems/mongo-2.4.3/lib/mongo/retryable.rb:104:in `write_with_retry'
api_1      | /usr/lib/ruby/gems/2.4.0/gems/mongo-2.4.3/lib/mongo/collection/view/writable.rb:234:in `update'
api_1      | /usr/lib/ruby/gems/2.4.0/gems/mongo-2.4.3/lib/mongo/collection/view/writable.rb:209:in `update_one'
api_1      | /usr/lib/ruby/gems/2.4.0/gems/mongoid-5.2.1/lib/mongoid/query_cache.rb:182:in `update_one_with_clear_cache'
api_1      | /usr/lib/ruby/gems/2.4.0/gems/mongoid-5.2.1/lib/mongoid/persistable.rb:212:in `persist_atomic_operations'
api_1      | /usr/lib/ruby/gems/2.4.0/gems/mongoid-5.2.1/lib/mongoid/persistable.rb:195:in `persist_or_delay_atomic_operation'
api_1      | /usr/lib/ruby/gems/2.4.0/gems/mongoid-5.2.1/lib/mongoid/persistable.rb:146:in `prepare_atomic_operation'
api_1      | /usr/lib/ruby/gems/2.4.0/gems/mongoid-5.2.1/lib/mongoid/persistable/settable.rb:23:in `set'
api_1      | /app/app/jobs/stack_deploy_worker.rb:53:in `deploy_service'
api_1      | /app/app/jobs/stack_deploy_worker.rb:27:in `block in deploy_stack'
api_1      | /app/app/jobs/stack_deploy_worker.rb:25:in `each'
api_1      | /app/app/jobs/stack_deploy_worker.rb:25:in `deploy_stack'
api_1      | /app/app/jobs/stack_deploy_worker.rb:12:in `perform'
api_1      | /usr/lib/ruby/gems/2.4.0/gems/celluloid-0.17.3/lib/celluloid/calls.rb:28:in `public_send'
api_1      | /usr/lib/ruby/gems/2.4.0/gems/celluloid-0.17.3/lib/celluloid/calls.rb:28:in `dispatch'
api_1      | /usr/lib/ruby/gems/2.4.0/gems/celluloid-0.17.3/lib/celluloid/call/sync.rb:16:in `dispatch'
api_1      | /usr/lib/ruby/gems/2.4.0/gems/celluloid-0.17.3/lib/celluloid/cell.rb:50:in `block in dispatch'
api_1      | /usr/lib/ruby/gems/2.4.0/gems/celluloid-0.17.3/lib/celluloid/cell.rb:76:in `block in task'
api_1      | /usr/lib/ruby/gems/2.4.0/gems/celluloid-0.17.3/lib/celluloid/actor.rb:339:in `block in task'
api_1      | /usr/lib/ruby/gems/2.4.0/gems/celluloid-0.17.3/lib/celluloid/task.rb:44:in `block in initialize'
api_1      | /usr/lib/ruby/gems/2.4.0/gems/celluloid-0.17.3/lib/celluloid/task/fibered.rb:14:in `block in create'

It looks like grid service deploys are also failing silently... adding some logging, it looks like the fetch_deploy_item => find_one_and_update to change the queued_at is failing:
api_1      | W, [2017-12-11T10:16:27.756392 #9]  WARN -- GridServiceSchedulerWorker: exception: failing update: objects in a capped ns cannot grow (10003) (Mongo::Error::OperationFailure)
api_1      | /usr/lib/ruby/gems/2.4.0/gems/mongo-2.4.3/lib/mongo/operation/result.rb:256:in `validate!'
api_1      | /usr/lib/ruby/gems/2.4.0/gems/mongo-2.4.3/lib/mongo/operation/executable.rb:37:in `block in execute'
api_1      | /usr/lib/ruby/gems/2.4.0/gems/mongo-2.4.3/lib/mongo/server/connection_pool.rb:107:in `with_connection'
api_1      | /usr/lib/ruby/gems/2.4.0/gems/mongo-2.4.3/lib/mongo/server.rb:247:in `with_connection'
api_1      | /usr/lib/ruby/gems/2.4.0/gems/mongo-2.4.3/lib/mongo/operation/executable.rb:35:in `execute'
api_1      | /usr/lib/ruby/gems/2.4.0/gems/mongo-2.4.3/lib/mongo/collection/view/writable.rb:118:in `block in find_one_and_update'
api_1      | /usr/lib/ruby/gems/2.4.0/gems/mongo-2.4.3/lib/mongo/retryable.rb:104:in `write_with_retry'
api_1      | /usr/lib/ruby/gems/2.4.0/gems/mongo-2.4.3/lib/mongo/collection/view/writable.rb:111:in `find_one_and_update'
api_1      | /usr/lib/ruby/gems/2.4.0/gems/mongoid-5.2.1/lib/mongoid/query_cache.rb:182:in `find_one_and_update_with_clear_cache'
api_1      | /usr/lib/ruby/gems/2.4.0/gems/mongoid-5.2.1/lib/mongoid/contextual/mongo.rb:189:in `find_one_and_update'
api_1      | /usr/lib/ruby/gems/2.4.0/gems/mongoid-5.2.1/lib/mongoid/contextual.rb:20:in `find_one_and_update'
api_1      | /app/app/jobs/grid_service_scheduler_worker.rb:59:in `fetch_deploy_item'
api_1      | /app/app/jobs/grid_service_scheduler_worker.rb:23:in `check_deploy_queue'
api_1      | /app/app/jobs/grid_service_scheduler_worker.rb:12:in `block in watch'
api_1      | /app/app/jobs/grid_service_scheduler_worker.rb:11:in `loop'
api_1      | /app/app/jobs/grid_service_scheduler_worker.rb:11:in `watch'
api_1      | /usr/lib/ruby/gems/2.4.0/gems/celluloid-0.17.3/lib/celluloid/calls.rb:28:in `public_send'
api_1      | /usr/lib/ruby/gems/2.4.0/gems/celluloid-0.17.3/lib/celluloid/calls.rb:28:in `dispatch'
api_1      | /usr/lib/ruby/gems/2.4.0/gems/celluloid-0.17.3/lib/celluloid/call/async.rb:7:in `dispatch'
api_1      | /usr/lib/ruby/gems/2.4.0/gems/celluloid-0.17.3/lib/celluloid/cell.rb:50:in `block in dispatch'
api_1      | /usr/lib/ruby/gems/2.4.0/gems/celluloid-0.17.3/lib/celluloid/cell.rb:76:in `block in task'
api_1      | /usr/lib/ruby/gems/2.4.0/gems/celluloid-0.17.3/lib/celluloid/actor.rb:339:in `block in task'
api_1      | /usr/lib/ruby/gems/2.4.0/gems/celluloid-0.17.3/lib/celluloid/task.rb:44:in `block in initialize'
api_1      | /usr/lib/ruby/gems/2.4.0/gems/celluloid-0.17.3/lib/celluloid/task/fibered.rb:14:in `block in create'

Ok, this was a bad idea.


Streams

Do you know what would be cool? Hashing a large file with streams!
The spec is coming together and just thought "hey it would be cool to use it in md5 spark!"
There is two ways you can do it. Either as a WritableStream or ReadableStream
if you would give a ReadableStream to the api then it would be in control and could handle the buffer allocation with BYOB.
However the append() operator is more like a WriteStream so you would need to provide a way to create write stream that is connected in the core
Currently you can get a ReadableStream from a the fetch api in Blink. You can also construct a ReadableStream in Blink now or you could use the web-streams-polyfill
So it would make since to just hand it over to spark in some way
I have also created a way to get a ReadableStream from blob/files with Screw-FileReader
One way you could do it is
ws = spark.createWriteStream()
blob.stream().pipeTo(ws).then(() => spark.end())

or just hand over the ReadableStream to spark in some way, cuz of right now fetch ReadableStream don't have pipeTo yet since WriteableStream is not implemented
one possible way would also be to hash it and upload it at the same time
given by the example with tee()

Handling streams is a great idea. The way I see it is spark.stream() returning a transform stream that should just consume data from a readable stream via piping. Internally it would call append() for each chunk and end it with end().

Cool lib time to port ot to Web streams 😉

Closing this for now. Feel free to work on a PR adding streams support :)


Fonts are not loaded correctly

Hello:
I have an issue that fonts are not displayed. I have found that it is because the font files end up containing JS code. For example, here is what a font file (Roboto-Regular.4db8a3e8.ttf) contains:
module.exports = __webpack_public_path__ + "df7b648ce5356ea1ebce435b3459fd60.ttf";
The fonts are displayed on the project, but when I use Storybook with the same webpack.config, I have this issue. The webpack.config contains the rule required for the fonts:
{
  test: /\.(eot|ttf|woff|woff2)$/,
  loader: 'file-loader'
}

So I don't know what can be causing this issue, would appreciate any help.
Thank you

I have found a way to fix this issue. I have check the default config and it appears that there is already a loader specified for fonts, and the issue was probably because there were two loaders. In any case, by making sure that there is only one loader for fonts specified (the one in the default Storybook config) I was able to get rid of this issue.

Not sure this should have been closed without a fix. We lost a few hours on this

Do you have a fix for it @VincentCharpentier ?

@rwieruch Nothing ideal, I just ignored the issue until it is fixed.
Maybe you can try @ilya-pyatin 's solution of using only the default storybook webpack rule for fonts.
Let me know if you find something interesting, I'd be happy to fix that in my project too


As a garment project owner, I want to be able to change the state of my project

What's the difference with #10 ?

Closing in lack of enough details.
Create a new issue if this is a problem again


Add Cloudflare Turnstile to docs

Add to: https://casdoor.org/docs/provider/captcha/overview

@YiNNx


ci: fix registry auth error

Thanks!
/approve
/lgtm

@fedepaol  finally the ci is green, should we merge to see if that will enough to have green ci for frr and metallb-operator? thanks

/lgtm


re-enable akka-persistence-tck

now that we have Scalactic available

test run in progress at https://scala-ci.typesafe.com/view/scala-2.12.x/job/scala-2.12.x-integrate-community-build/514/consoleFull

failed because the Scalactic dependency wasn't available. perhaps over-aggressive caching by dbuild? let's try again with a newer Scala SHA, forcing rebuilding of everything: https://scala-ci.typesafe.com/view/scala-2.12.x/job/scala-2.12.x-integrate-community-build/515/consoleFull

try again now that #271 is merged: https://scala-ci.typesafe.com/view/scala-2.12.x/job/scala-2.12.x-integrate-community-build/524/consoleFull


[Install issue]: type object 'CreateCollection' has no attribute 'model_validate' during Create Index

What happened?
After installed ChromaDB and run chroma run, it throws an error when I try to create a new index using the NodeJS client.
The reason I find out is because the version of pydantic is too old on my machine.
Mine was 1.10.12, and upgrading the library to the latest version (2.7.1) solves this issue.
pip install pydantic --upgrade

It seems the version in the requirement.txt is pydantic>=1.9 so it doesn't upgrade the library automatically during install, should the version number gets bumped?
Reference:
https://github.com/chroma-core/chroma/blob/b34f90ce41a82d54ca4d68e43009309cd8b43f89/requirements.txt#L18
The code that throws the error (model_validate does not exist on 1.10):
https://github.com/chroma-core/chroma/blob/b34f90ce41a82d54ca4d68e43009309cd8b43f89/chromadb/server/fastapi/__init__.py#L561
Versions
Chroma v0.5.0, Python 3.9.13, MacOS 14.4.1
Relevant log output
ERROR:    [06-05-2024 22:51:40] type object 'CreateCollection' has no attribute 'model_validate'
Traceback (most recent call last):
  File "/Users/user/opt/anaconda3/lib/python3.9/site-packages/anyio/streams/memory.py", line 81, in receive
    return self.receive_nowait()
  File "/Users/user/opt/anaconda3/lib/python3.9/site-packages/anyio/streams/memory.py", line 76, in receive_nowait
    raise WouldBlock
anyio.WouldBlock

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/Users/user/opt/anaconda3/lib/python3.9/site-packages/starlette/middleware/base.py", line 159, in call_next
    message = await recv_stream.receive()
  File "/Users/user/opt/anaconda3/lib/python3.9/site-packages/anyio/streams/memory.py", line 101, in receive
    raise EndOfStream
anyio.EndOfStream

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/Users/user/opt/anaconda3/lib/python3.9/site-packages/chromadb/server/fastapi/__init__.py", line 78, in catch_exceptions_middleware
    return await call_next(request)
  File "/Users/user/opt/anaconda3/lib/python3.9/site-packages/starlette/middleware/base.py", line 165, in call_next
    raise app_exc
  File "/Users/user/opt/anaconda3/lib/python3.9/site-packages/starlette/middleware/base.py", line 151, in coro
    await self.app(scope, receive_or_disconnect, send_no_error)
  File "/Users/user/opt/anaconda3/lib/python3.9/site-packages/starlette/middleware/base.py", line 191, in __call__
    response = await self.dispatch_func(request, call_next)
  File "/Users/user/opt/anaconda3/lib/python3.9/site-packages/chromadb/server/fastapi/__init__.py", line 92, in check_http_version_middleware
    return await call_next(request)
  File "/Users/user/opt/anaconda3/lib/python3.9/site-packages/starlette/middleware/base.py", line 165, in call_next
    raise app_exc
  File "/Users/user/opt/anaconda3/lib/python3.9/site-packages/starlette/middleware/base.py", line 151, in coro
    await self.app(scope, receive_or_disconnect, send_no_error)
  File "/Users/user/opt/anaconda3/lib/python3.9/site-packages/starlette/middleware/exceptions.py", line 65, in __call__
    await wrap_app_handling_exceptions(self.app, conn)(scope, receive, send)
  File "/Users/user/opt/anaconda3/lib/python3.9/site-packages/starlette/_exception_handler.py", line 64, in wrapped_app
    raise exc
  File "/Users/user/opt/anaconda3/lib/python3.9/site-packages/starlette/_exception_handler.py", line 53, in wrapped_app
    await app(scope, receive, sender)
  File "/Users/user/opt/anaconda3/lib/python3.9/site-packages/starlette/routing.py", line 756, in __call__
    await self.middleware_stack(scope, receive, send)
  File "/Users/user/opt/anaconda3/lib/python3.9/site-packages/starlette/routing.py", line 776, in app
    await route.handle(scope, receive, send)
  File "/Users/user/opt/anaconda3/lib/python3.9/site-packages/starlette/routing.py", line 297, in handle
    await self.app(scope, receive, send)
  File "/Users/user/opt/anaconda3/lib/python3.9/site-packages/starlette/routing.py", line 77, in app
    await wrap_app_handling_exceptions(app, request)(scope, receive, send)
  File "/Users/user/opt/anaconda3/lib/python3.9/site-packages/starlette/_exception_handler.py", line 64, in wrapped_app
    raise exc
  File "/Users/user/opt/anaconda3/lib/python3.9/site-packages/starlette/_exception_handler.py", line 53, in wrapped_app
    await app(scope, receive, sender)
  File "/Users/user/opt/anaconda3/lib/python3.9/site-packages/starlette/routing.py", line 72, in app
    response = await func(request)
  File "/Users/user/opt/anaconda3/lib/python3.9/site-packages/fastapi/routing.py", line 278, in app
    raw_response = await run_endpoint_function(
  File "/Users/user/opt/anaconda3/lib/python3.9/site-packages/fastapi/routing.py", line 191, in run_endpoint_function
    return await dependant.call(**values)
  File "/Users/user/opt/anaconda3/lib/python3.9/site-packages/chromadb/telemetry/opentelemetry/__init__.py", line 130, in wrapper
    return await f(*args, **kwargs)
  File "/Users/user/opt/anaconda3/lib/python3.9/site-packages/chromadb/server/fastapi/__init__.py", line 630, in create_collection
    await to_thread.run_sync(
  File "/Users/user/opt/anaconda3/lib/python3.9/site-packages/anyio/to_thread.py", line 28, in run_sync
    return await get_asynclib().run_sync_in_worker_thread(func, *args, cancellable=cancellable,
  File "/Users/user/opt/anaconda3/lib/python3.9/site-packages/anyio/_backends/_asyncio.py", line 818, in run_sync_in_worker_thread
    return await future
  File "/Users/user/opt/anaconda3/lib/python3.9/site-packages/anyio/_backends/_asyncio.py", line 754, in run
    result = context.run(func, *args)
  File "/Users/user/opt/anaconda3/lib/python3.9/site-packages/chromadb/server/fastapi/__init__.py", line 606, in process_create_collection
    create = CreateCollection.model_validate(orjson.loads(raw_body))
AttributeError: type object 'CreateCollection' has no attribute 'model_validate'
INFO:     [06-05-2024 22:51:40] ::1:53570 - "POST /api/v1/collections?tenant=default_tenant&database=default_database HTTP/1.1" 500

This is a good point - @tazarov should we bump the version?

Pydantic 1.x also has similar function to so maybe we can implement an adapter that is version-aware function to keep backward compatibility.
We've added the orjson serialization in 0.5.0 and so far @zhou9110 is the first to notice which leads me to believe that not so many people are running pydantic <2.x. Maybe bumping the pydantic range >=2.0 and ditching 1.x as part of the 0.5.x versions can be an OK approach.
However if we go 2.x route we may want to also add pydantic-settings package and refactor the config (can be done in a separate PR).

looking at pydantic-settings package I can see that it basically requires pydantic > 2.7
https://github.com/pydantic/pydantic-settings/blob/6d25cee4bb7a6db592ca0da123c53f3d775cd1e1/pyproject.toml#L43
Using pedantic-settings as a package dependency, we're effectively forcing a pydantic>2.0 upgrade, which in @zhou9110's and other's cases might be a breaking change.
Another interesting aspect is our fastapi dep fastapi>=0.95.2, which translates:
https://github.com/tiangolo/fastapi/blob/c81e136d75f5ac4252df740b35551cf2afb4c7f1/pyproject.toml#L45
The above will cause some dependency resolution issues with older fastapi versions.
In the end, it will be a trade-off and a bit of a jerk move to force users to upgrade their deps which may come from other dependencies.
Bottom line:
pydantic>2.0 with pydantic-settings

pro: makes the code a bit cleaner as we'll remove all the pydantic 1.x compatibility logic
pro: allows us to bump fastapi
con: we add an extra dependency pydantic-settings
con: forces users to upgrade to pydantic>2.0
con: there are possible paths that lead to unreconcilable dependency conflicts and breaking changes

support for both versions

pro: we don't have to add pydantic-settings as direct dependency, but in case it is there we can use it
pro: no breaking changes for users
con: add more boilerplate code to support both versions that need to be maintained and tested
con: our tests always run on 2.x so it properly testing with older version requires additional CI with little gain, but it will help us avoid the above error

@HammadB, any strong opinion on which option to go for?

Given that Pydantic v2 was released in April of last year, I would vote for just bumping the version.

I think we should preserve backwards compat here. The history of this is we actually did support this https://github.com/chroma-core/chroma/pull/1174 but then regressed when we changed this.


Revisit Block Structure

This PR:

introduces a skeleton for verifying blocks using TritonVM
modifies the Block data structure
redefine's the block's hash in MAST terms
refactors public scripts into public announcements
prefers the block hash over its header as index by which to fetch blocks from the database

Note that (some of) these changes are not backwards-compatible, meaning that this essentially corresponds to a new alphanet release.

Note that the unsuccessful test runs (in both cases) boil down to a single failing test: the flaky one from #100.


Expected performance-2

Thank you for  your work.
After I tried some experiments,I met met some questions:
For  ciafr10,there are two search space and corresponding experiments：
----./scripts/cifar10_macro_search.sh      ./scripts/cifar10_macro_final.sh
----./scripts/cifar10_micro_search.sh        ./scripts/cifar10_micro_final.sh
1> ----I want to confirm  the difference between  the architectures produced by cifar10_macro_search.sh and
cifar10_micro_search.sh. (one is )
2> I found the architectures produced by cifar10_macro_search.sh like
[1]
[1 1]
[5 0 0]
[5 0 0 0]
[0 0 1 1 0]
[1 1 0 0 0 0]
[1 1 0 1 1 1 0]
[3 0 0 1 0 1 1 1]
[5 0 0 1 0 0 1 0 0]
[1 1 1 0 0 0 0 1 0 0]
[0 1 1 0 0 0 0 1 1 1 1]
[0 0 1 1 1 1 0 1 0 0 1 1], which has 12 cells,while in  cifar10_macro_final.sh,the architecture is
fixed_arc="0"
fixed_arc="$fixed_arc 3 0"
fixed_arc="$fixed_arc 0 1 0"
fixed_arc="$fixed_arc 2 0 0 1"
fixed_arc="$fixed_arc 2 0 0 0 0"
fixed_arc="$fixed_arc 3 1 1 0 1 0"
fixed_arc="$fixed_arc 2 0 0 0 0 0 1"
fixed_arc="$fixed_arc 2 0 1 1 0 1 1 1"
fixed_arc="$fixed_arc 1 0 1 1 1 0 1 0 1"
fixed_arc="$fixed_arc 0 0 0 0 0 0 0 0 0 0"
fixed_arc="$fixed_arc 2 0 0 0 0 0 1 0 0 0 0"
fixed_arc="$fixed_arc 0 1 0 0 1 1 0 0 0 0 1 1"
fixed_arc="$fixed_arc 2 0 1 0 0 0 0 0 1 0 1 1 0"
fixed_arc="$fixed_arc 1 0 0 1 0 0 0 1 1 1 0 1 0 1"
fixed_arc="$fixed_arc 0 1 1 0 1 0 1 0 0 0 0 0 1 0 0"
fixed_arc="$fixed_arc 2 0 0 1 0 0 0 0 0 0 0 1 0 1 0 1"
fixed_arc="$fixed_arc 2 0 1 0 0 0 1 0 0 1 1 1 1 0 0 1 0"
fixed_arc="$fixed_arc 2 0 0 0 0 1 0 1 0 1 0 0 1 0 1 0 0 1"
fixed_arc="$fixed_arc 3 0 1 1 0 1 0 0 0 0 0 1 0 1 0 1 0 0 0"
fixed_arc="$fixed_arc 3 0 1 1 0 0 0 0 0 0 0 0 0 1 1 0 0 0 0 1"
fixed_arc="$fixed_arc 0 1 0 0 1 0 1 1 0 0 0 1 0 0 0 0 0 1 1 0 0"
fixed_arc="$fixed_arc 3 0 1 0 1 1 0 0 1 0 1 1 0 1 1 0 1 0 0 1 0 0"
fixed_arc="$fixed_arc 0 1 0 1 0 1 0 0 0 0 0 0 0 0 1 0 1 0 0 1 0 0 0"
fixed_arc="$fixed_arc 0 1 1 0 0 0 1 1 1 0 1 0 0 0 1 0 1 0 0 1 1 0 0 0", which has 24 cells.
So I want to konw where to get architecture like the one in cifar10_macro_final.sh.
Thanks for you response.

And  when I take place of the architecture in cifar10_macro_final.sh.  with an architecture produced by ./scripts/cifar10_macro_search.sh
fixed_arc="3"
fixed_arc="$fixed_arc 0 0"
fixed_arc="$fixed_arc 1 0 0"
fixed_arc="$fixed_arc 3 1 0 0"
fixed_arc="$fixed_arc 1 0 0 0 0"
fixed_arc="$fixed_arc 1 1 0 0 0 0"
fixed_arc="$fixed_arc 5 0 0 1 0 0 1"
fixed_arc="$fixed_arc 4 1 1 1 1 1 1 0"
fixed_arc="$fixed_arc 3 0 0 0 1 1 0 1 0"
fixed_arc="$fixed_arc 4 1 0 0 1 0 1 1 0 0"
fixed_arc="$fixed_arc 0 0 0 0 1 1 0 0 1 0 0"
fixed_arc="$fixed_arc 5 0 0 1 0 1 0 0 0 0 0 0"
I got an error：
Traceback (most recent call last):
File "src/cifar10/main.py", line 360, in
tf.app.run()
File "/home/axi/anaconda3/envs/Efficient/lib/python2.7/site-packages/tensorflow/python/platform/app.py", line 48, in run
_sys.exit(main(_sys.argv[:1] + flags_passthrough))
File "src/cifar10/main.py", line 356, in main
train()
File "src/cifar10/main.py", line 224, in train
ops = get_ops(images, labels)
File "src/cifar10/main.py", line 191, in get_ops
child_model.connect_controller(None)
File "/home/axi/Efficient-2/enas-master/src/cifar10/general_child.py", line 705, in connect_controller
self._build_train()
File "/home/axi/Efficient-2/enas-master/src/cifar10/general_child.py", line 595, in _build_train
logits = self._model(self.x_train, is_training=True)
File "/home/axi/Efficient-2/enas-master/src/cifar10/general_child.py", line 212, in _model
x = self._fixed_layer(layer_id, layers, start_idx, out_filters, is_training)
File "/home/axi/Efficient-2/enas-master/src/cifar10/general_child.py", line 465, in _fixed_layer
prev = res_layers + [out]
UnboundLocalError: local variable 'out' referenced before assignment


Invalid AIR generation when returning unit type

The following code:
use vstd::prelude::*;

verus! {

pub fn owl_unit() -> (res: ())
    ensures res == ()
{ () }

fn main() {
    owl_unit()
}

}

panics the verifier, as follows:
thread '<unnamed>' panicked at rust_verify/src/verifier.rs:728:21:
internal error: generated ill-typed AIR code: error 'in call to ens%main!owl_unit., expected 2 arguments, found 1 arguments' in expression '(ens%main!owl_unit. 0)'
note: [run with `RUST_BACKTRACE=1` environment variable to display a backtrace](https://play.verus-lang.org/?version=stable&mode=basic&edition=2021#)
thread '<unnamed>' panicked at rust_verify/src/verifier.rs:339:17:
dropped, expected call to `into_inner` instead
stack backtrace:
...

Minimal playground link with full backtrace
On the other hand, removing the ensures res == () on owl_unit() makes the panic go away (link).
Thanks to parametricity, the ensures res == () spec is not actually needed, but noting in case it points to a bigger bug.

I'm adding other cases to this issue where using a unit return type can result in invalid AIR code.  For example (from https://github.com/verus-lang/verus/issues/1161 ):
trait T {
    spec fn f();
}

spec fn f<A: T>() {
    A::f()
}

Here's another one:
trait Tr : Sized {
    fn get() -> (r: Self)
        ensures r == r;
}

impl Tr for () {
    fn get() -> (r: Self)
    {
    }
}

With PR https://github.com/verus-lang/verus/pull/1280, all issues mentioned in this thread so far will be fixed, with the exception of:
trait T {
    spec fn f();
}

spec fn f<A: T>() {
    A::f()
}

This is a poly issue, so should be revisited after the upcoming poly refactor.