Enable Reindex in tests

Description
Reindex wasn't enabled on the CI SQL servers and this started failing tests.
Related issues
Addresses failing CI builds.
Testing
CI is running with reindex enabled.
FHIR Team Checklist

[ ] Update the title of the PR to be succinct and less than 50 characters
[ ] Add a milestone to the PR for the sprint that it is merged (i.e. add S47)
[ ] Tag the PR with the type of update: Bug, Dependencies, Enhancement, or New-Feature
[ ] Tag the PR with Azure API for FHIR if this will release to the Azure API for FHIR managed service (CosmosDB or common code related to service)
[ ] Tag the PR with Azure Healthcare APIs if this will release to the Azure Healthcare APIs managed service (Sql server or common code related to service)
[ ] CI is green before merge
Review squash-merge requirements

Semver Change (docs)
Skip (Build job related changes)

/azp run


increase available shm memory size

fixes #44

@petrosagg Awesome! I hope this fixes a performance issue I've been seeing with loading multiple images on a screen. Can you explain what this fix is doing?

@danielmahon chromium is a multi-process system and it uses shared memory to communicate between them. Shared memory on linux is implemented as files under /dev/shm and by default this mounted as a tmpfs with a max size of 64MB. This fix is unmounting the 64MB capped tmpfs and remounts an uncapped one so the limit becomes the system memory. We are thinking of adding this change deeper in resinOS so that containers don't need to mess with it
I didn't notice any change in performance after this fix in my tests

Thanks, @petrosagg, I guess I should have specified, by "performance" I meant that Electron would crash when displaying/interacting with multiple images on the screen, which I attributed to Chromium/Electron limitations. I'll let you know if this helps the issue.

Oh. Yeah it definitely solves this problem

@petrosagg So far so good! Wish I would have looked into this before... I definitely acquired some gray hairs because of it. 😉


Guys, please try a msft guidance / promptfoo integration -- good packages that we use everyday

I love the stuff you've built to make system level robustness. This will be super useful to me if it can also have quality level robustness. Check promptfoo and msft guidance. NVIDIA has published similar stuff as part of nemo, I think, guardrails?

why can't you use this with those already? we wrap the base openai endpoint, that shouldn't stop you from using testing libraries like promptfoo, etc.?
Have you faced any errors? @akshhack


Tune itemrevision retrievals

This fixes CPU utilisation issues we were having with our RDS DB. We are only running with 6 technologies and 19 rules but we have over 100 accounts being monitored and lots of changes. We had an m3.large database running at 100% CPU.
By tuning the queries/logic to only return what we need and by adding an index on the date_created field the database CPU now hovers between 2 and 4%. I think I can resize to a smaller DB instance now :)

Woa.  Just saw this.  Looks incredible.
I'm going to fork your PR to update your alembic version to build on 331ca47ce8ad instead of 1727fb4309d8, and then update the comments on @ollytheninja's #317 to have his alembic version use 6b9d673d8e30 as its down_revision.


ensuring the objective function is compiled only once

In this comment, optimistix is mentioned as improving performance by ensuring the objective function is compiled only once. Can you help shed light on what that exactly means and in which situations you're applying a trick, and perhaps point to code where I can take a look?

Absolutely! So what's going on here is that if we have a function that looks something like this:
def nonlinear_solve(fn, ...):
    ... = fn(...)
    ... = fn(...)
    ...

then JAX will trace and compile the user-provided fn twice. This approximately doubles the compilation time! To emphasize: this is about the speed of compiling, not the speed of runtime.
The thing is that a lot of scientific programs can get very large indeed. Imagine optimizing the parameters of a stiff two-point boundary value problem: this is done by performing
(a) gradient descent over a
(b) root-finding problem, whose fn is a
(c) differential equation solve, which on each step
(d) involves finding the solution to say 6 more root-finding problems!
Let's imagine that each root-finding solver did something like the above, and had two compilations where only one would suffice. Then in this example, we'd end up with compilation taking 2 * 6 = 12 times as long (2* from (b) and 6* from (d)). Indeed I've personally seen examples where compilation goes from around an hour to about five minutes. (!)
Optimistix (and all of its sibling libraries, e.g. Diffrax for differential equation solving) take care to ensure that they do a good job of this issue.

Okay, as for a concrete example of where do this kind of thing, let's look an example of a gradient descent with a line search. Algorithms of this type need to store two function evaluations at time: the start of a line search, and how far along a line search they are. They tend to iterate in an inner loop along the line search, and then when they are happy, they will accept that point, return to an outer loop, and start a new line seach. In addition, they also need a gradient evaluation for the start of a line search (to set the direction).
Let's look at where we do all of that:
https://github.com/patrick-kidger/optimistix/blob/316000f893b652a6cccee16ae953884a483ca2c6/optimistix/_solver/gradient_methods.py#L156-L214
Here, we have flattened these two loops together. (The loop-over-line-searches and the loop-within-a-line-search.) This means that we do not need to write ... = fn(...) in two different places, and as such can immediately half our compilation time!
Moreover notice that little lin_to_grad hiding out in there. We only sometimes need a gradient (when setting the direction for a new line search). Now if we wrote two separate branches:
lax.cond(need_gradient, lambda ...: fn(...), lambda ...: jax.value_and_grad(fn)(...))`

then we would also be approximately doubling compilation time, because both fn and jax.value_and_grad(fn) would need to be compiled. (And of course obviously if we just always evaluated jax.value_and_grad(fn), then we'd waste a lot of runtime computation by evaluating the gradient when we often don't need it.)
Our solution is for every function evaluation to actually linearize the function -- which both evaluates it and keeps around the extra intermediate values needed for later autodifferentiation -- and then only if required will we perform the second half of the autodifferentiation (transposing the tangent function, and propagating cotangents). In short, we've chopped backpropagation into two different pieces to ensure that we get optimal runtime and optimal compiletime performance.
As a final example of this kind of compilation stuff -- as part of the initial set-up for the solver, we need to (a) run through a function to check if it has any closed-over variables, and (b) set up some initial fn evaluations for the evolving state of the solver. We take care to do both of these in the same pass. We do (a) here:
https://github.com/patrick-kidger/optimistix/blob/4f041ec59bdd4019dad4cb06a19efc58a9bbae1f/optimistix/_minimise.py#L92-L94
and in doing so are to get (b) for free here:
https://github.com/patrick-kidger/optimistix/blob/316000f893b652a6cccee16ae953884a483ca2c6/optimistix/_solver/gradient_methods.py#L143
And all of that is just to do a simple gradient descent with line search! As you can imagine, more complicated solvers involve more work again :)

IMO, handling this kind of thing is precisely the reason that libraries like Optimistix exist! I think this is complicated stuff -- not to mention all the other stuff that went into Optimistix, like the search/descent abstraction, extensibility, problem reduction, etc. etc. -- and I'm a strong believer that good software is a key enabler of good science.

Ah I recognise where you're doing there. Flattening multi-part iterative code, plus linearising functions where grads maybe be called multiple times.

IMO, handling this kind of thing is precisely the reason that libraries like Optimistix exist!

It does take a lot of effort to write such good code. However, there is a diminishing return to the effort. I think if the library is limited to a smallish set of commonly used algorithms then it's logical to have such consistency. I'm interested in getting much more of the science community involved in sharing a diverse set of algorithms, in a more decentralised manner. My concern is that there will be considerably fewer contributions if a form factor is enforced. To manage the potential chaos I think a process of peer review and standardised regression benchmarks is essential. I also think there is a sweet spot of enabling optimistix-like rigour, by gently suggesting the usage of well-maintained tooling.

I'm interested in getting much more of the science community involved in sharing a diverse set of algorithms

Right! So now you're speaking to how we should handle extensibility. How to make it possible for someone to come up with a whole-new optimization algorithm and then for everyone to make use of that.
We've thought about this too :)
For Optimistix this is handled through the use of abstract base classes ('ABC'). The interface to a solver is defined by classes like optimistix.AbstractMinimiser. Now optimistix.minimise only requires that your solver be an instance of this class, and moreover the example I linked above is just an implementation of this ABC.
What this means, for example, is that third party A could create their own GitHub repository, which is a Python package with a class that implements this ABC:
# third-party-A/optimistix-extensions/cool_solver.py
from optimistix import AbstractMinimiser

class CoolSolver(AbstractMinimiser): ...

And third party B could then write something that uses this in their own code, flexibly and interchangeably with any other Optimistix routine:
# third-party-B/some-project/foo.py
from optimistix import minimise, GradientDescent
from optimistix_extensions import CoolSolver

if foo:
    solver = GradientDescent(...)
else:
    solver = CoolSolver(...)
minimise(solver, ...)

The decoupling here speaks to your 'distributed' point.

To manage the potential chaos I think a process of peer review and standardised regression benchmarks is essential. I also think there is a sweet spot of enabling optimistix-like rigour, by gently suggesting the usage of well-maintained tooling.

So notably, what the above design ensures is that algorithms can be implemented and tried out without requiring the high standards of rigour I described in my previous message, and they can still be consumed by everyone.
Then if such an algorithm becomes useful enough and well-implemented enough, it can contributed to some standard place (potentially Optimistix itself).

That would only make sense if the algo being contributed had a corresponding ABC :) But we've discussed this in our meeting already. I'll close this ticket.


[BugFix] Append null to nullable numeric column

Fixes  https://github.com/StarRocks/starrocks/issues/32656
The  add_nullable_numeric_column dose not set _has_null of nullable column when a null value is appended.
This PR fixes this issue.
What type of PR is this:

[x] BugFix
[ ] Feature
[ ] Enhancement
[ ] Refactor
[ ] UT
[ ] Doc
[ ] Tool

Does this PR entail a change in behavior?

[ ] Yes, this PR will result in a change in behavior.
[x] No, this PR will not result in a change in behavior.

If yes, please specify the type of change:

[ ] Interface/UI changes: syntax, type conversion, expression evaluation, display information
[ ] Parameter changes: default values, similar parameters but with different default values
[ ] Policy changes: use new policy to replace old one, functionality automatically enabled
[ ] Feature removed
[ ] Miscellaneous: upgrade & downgrade compatibility, etc.

Checklist:

[ ] I have added test cases for my bug fix or my new feature
[ ] This pr needs user documentation (for new or modified features or behaviors)

[ ] I have added documentation for my new feature or new function

Bugfix cherry-pick branch check:

[x] I have checked the version labels which the pr will be auto-backported to the target branch

[x] 3.2
[x] 3.1
[x] 3.0
[x] 2.5

[FE Incremental Coverage Report]
:heart_eyes: pass : 0 / 0 (0%)

[BE Incremental Coverage Report]
:heart_eyes: pass : 3 / 3 (100.00%)
file detail

path
covered_line
new_line
coverage
not_covered_line_detail

:large_blue_circle:
src/formats/json/nullable_column.cpp
3
3
100.00%
[]

[FE Incremental Coverage Report]
:heart_eyes: pass : 0 / 0 (0%)

@Mergifyio backport branch-3.2

@Mergifyio backport branch-3.1

@Mergifyio backport branch-3.0

@Mergifyio backport branch-2.5


Update bio info for Andrea Cardona

Bio info was taken from #98

Andrea Cardona, Software Engineer @ Chipper.app
I am currently a full stack software engineer with a passion for bringing diversity to the programming community. After spending a few years in tech on the marking and sales side of San Francisco based startups, and working in media at VICE in NY - while focusing on LatinX and Latin America growth initiatives - I realized my passion really lied to make an impact within the Tech community. I wanted to help bridge the gap between the tech and LatinX worlds.
After attending the NYC Flatiron Full-stack Immersive program, I am now proud to say I am a full stack engineer at an Austin based startup, called Chipper. I am also an organizer for the Techqueria Austin Chapter and always looking to make tech more accessible to the LatinX community. I love helping others find a passion for programming and finding inspiration in others!

✅ By submitting this issue, I have verified the following

[x] Checked to see if the issue has already been discussed before 🤔
[x] Made sure enough details were provided if proposing a new feature 🔍

working on this


[loc][Query][LibraryManager] Localizability of string: Checked {0} {1}

Hi,
please help localization team to answer question from translator.
In case translator is not sure about context/meaning/localizability of string we raise a question to Core team.
Could you help please? Thanks!**
Source:
Checked {0} {1}
File Name:
LibraryManager.Vsix\MultilingualResources\Microsoft.Web.LibraryManager.Vsix.xlf
Resource ID:
0; "MICROSOFT.WEB.LIBRARYMANAGER.VSIX/RESOURCES/TEXT.RESX.Checked"
0; "MICROSOFT.WEB.LIBRARYMANAGER.VSIX/RESOURCES/TEXT.RESX.UnChecked"
Query:
Could you kindly provide resulting sample strings to check if our translation of the below strings work, please? Screenshot or examples of use could be good.
0; "MICROSOFT.WEB.LIBRARYMANAGER.VSIX/RESOURCES/TEXT.RESX.Checked"
0; "MICROSOFT.WEB.LIBRARYMANAGER.VSIX/RESOURCES/TEXT.RESX.Indeterminate"
0; "MICROSOFT.WEB.LIBRARYMANAGER.VSIX/RESOURCES/TEXT.RESX.UnChecked"
0; "GroupByColumnDescriptorFormat"

There's a comment in the .resx file explaining this: https://github.com/aspnet/LibraryManager/blob/aa3f5782edf8c828d6803db8539b054d7feb1901/src/LibraryManager.Vsix/Resources/Text.resx#L240
Is there a better way we can put comments in the resource files so that the localization team can find them?

In most cases comments are enough to know the context. Otherwise we would ask for better clarification.
Could you please provide real use of this strings? screenshots..etc ?

These 3 strings (Checked/Unchecked/Indeterminate) are for screen readers to indicate the state of the checkboxes in the file picker.  We've added more data to the string to indicate whether the item represented by the checkbox is a file or a folder.

Thanks, that should be enough to know I think.


daemon: service is deleted in cache when deleting endpoints

Please ensure your pull request adheres to the following guidelines:

[x] For first time contributors, read Submitting a pull request
[ ] All code is covered by unit and/or runtime tests where feasible.
[ ] All commits contain a well written commit description including a title,
description and a Fixes: #XXX line if the commit addresses a particular
GitHub issue.
[ ] If your commit description contains a Fixes: <commit-id> tag, then
please add the commit author[s] as reviewer[s] to this issue.
[x] All commits are signed off. See the section Developer’s Certificate of Origin
[ ] Provide a title or release-note blurb suitable for the release notes.
[ ] Are you a user of Cilium? Please add yourself to the Users doc
[ ] Thanks for contributing!

Fixes: #29580
fix service is deleted in cache when deleting endpints

/test

@xyz-li What is the effect of removing the service entry? Given there are no backends to respond, is this a problem?

@xyz-li What is the effect of removing the service entry? Given there are no backends to respond, is this a problem?

Deleting the service entry will not affect the data-path. But it is very confusing when using cilium cli.

/test

I think it might actually be useful to keep the service frontend in the datapath, so that when the LB decision is made, the datapath can emit drop notifications with DROP_NO_SERVICE ("Service backend not found").

kubectl  get svc

NAME         TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
kubernetes   ClusterIP   <IP_ADDRESS>       <none>        443/TCP   36d
nginx        ClusterIP   <IP_ADDRESS>   <none>        80/TCP    12d

cilium map get cilium_lb4_services_v2

<IP_ADDRESS>:443   0 1 (8) [0x0 0x10]   sync
<IP_ADDRESS>:53      0 2 (2) [0x0 0x0]    sync
<IP_ADDRESS>:443      0 1 (3) [0x0 0x0]    sync
<IP_ADDRESS>:80   0 2 (4) [0x0 0x0]    sync // <IP_ADDRESS> is here now.
<IP_ADDRESS>:9153    0 2 (1) [0x0 0x0]    sync

kubectl  scale deploy nginx --replicas=1 # now service has one endpoint
kubectl describe svc nginx

Name:              nginx
Namespace:         default
Labels:            app=nginx
Annotations:       <none>
Selector:          app=nginx
Type:              ClusterIP
IP Family Policy:  SingleStack
IP Families:       IPv4
IP:                <IP_ADDRESS>
IPs:               <IP_ADDRESS>
Port:              80-80  80/TCP
TargetPort:        80/TCP
Endpoints:         <IP_ADDRESS>:80
Session Affinity:  None
Events:            <none>

cilium map get cilium_lb4_services_v2

Key                Value                State   Error
<IP_ADDRESS>:443   0 1 (8) [0x0 0x10]   sync
<IP_ADDRESS>:53      0 2 (2) [0x0 0x0]    sync
<IP_ADDRESS>:443      0 1 (3) [0x0 0x0]    sync
<IP_ADDRESS>:9153    0 2 (1) [0x0 0x0]    sync

When scale down some workload,  the endpoint will be deleted. At Last the func deleteCacheEntry is delete.
https://github.com/cilium/cilium/blob/main/pkg/maps/lbmap/ipv4.go#L250-L257

kubectl  get svc

NAME         TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
kubernetes   ClusterIP   <IP_ADDRESS>       <none>        443/TCP   36d
nginx        ClusterIP   <IP_ADDRESS>   <none>        80/TCP    12d

2. cilium map get cilium_lb4_services_v2

<IP_ADDRESS>:443   0 1 (8) [0x0 0x10]   sync
<IP_ADDRESS>:53      0 2 (2) [0x0 0x0]    sync
<IP_ADDRESS>:443      0 1 (3) [0x0 0x0]    sync
<IP_ADDRESS>:80   0 2 (4) [0x0 0x0]    sync // <IP_ADDRESS> is here now.
<IP_ADDRESS>:9153    0 2 (1) [0x0 0x0]    sync

3. kubectl  scale deploy nginx --replicas=1 # now service has one endpoint

4. kubectl describe svc nginx

Name:              nginx
Namespace:         default
Labels:            app=nginx
Annotations:       <none>
Selector:          app=nginx
Type:              ClusterIP
IP Family Policy:  SingleStack
IP Families:       IPv4
IP:                <IP_ADDRESS>
IPs:               <IP_ADDRESS>
Port:              80-80  80/TCP
TargetPort:        80/TCP
Endpoints:         <IP_ADDRESS>:80
Session Affinity:  None
Events:            <none>

5. cilium map get cilium_lb4_services_v2  # the item in cache not exists.

Key                Value                State   Error
<IP_ADDRESS>:443   0 1 (8) [0x0 0x10]   sync
<IP_ADDRESS>:53      0 2 (2) [0x0 0x0]    sync
<IP_ADDRESS>:443      0 1 (3) [0x0 0x0]    sync
<IP_ADDRESS>:9153    0 2 (1) [0x0 0x0]    sync

6. cilium bpf lb list

SERVICE ADDRESS    BACKEND ADDRESS (REVNAT_ID) (SLOT)
<IP_ADDRESS>:9153    <IP_ADDRESS>:0 (1) (0) [ClusterIP, non-routable]
                   <IP_ADDRESS>:9153 (1) (1)
                   <IP_ADDRESS>:9153 (1) (2)
<IP_ADDRESS>:53      <IP_ADDRESS>:53 (2) (1)
                   <IP_ADDRESS>:0 (2) (0) [ClusterIP, non-routable]
                   <IP_ADDRESS>:53 (2) (2)
<IP_ADDRESS>:443   <IP_ADDRESS>:0 (8) (0) [ClusterIP, InternalLocal, non-routable]
                   <IP_ADDRESS>:4244 (8) (1)
<IP_ADDRESS>:443      <IP_ADDRESS>:0 (3) (0) [ClusterIP, non-routable]
                   <IP_ADDRESS>:6443 (3) (1)
<IP_ADDRESS>:80   <IP_ADDRESS>:80 (4) (1)     # <IP_ADDRESS> exists
                   <IP_ADDRESS>:0 (4) (0) [ClusterIP, non-routable]

After scale down my nginx workload, one endpoint will be deleted. At last the func deleteCacheEntry is called.
https://github.com/cilium/cilium/blob/fa0037638534635471c8e45583d78f87ad78b3e1/pkg/bpf/map_linux.go#L883-L890
And then the String function.
https://github.com/cilium/cilium/blob/fa0037638534635471c8e45583d78f87ad78b3e1/pkg/maps/lbmap/ipv4.go#L250-L257

Ah the String function is incorrect! It's not taking into account the BackendSlot which causes multiple service entries to have the same key, hence we delete the "master" service when we're deleting the "backend slot" entries. What's worse here is that the "cache" is used to retry failed operations in resolveErrors and thus we may fail to retry some BPF updates since we've overwritten the entry in the cache.
A short term fix to this issue is to make sure Service4Key.String() fully reflects the Service4Key value, e.g. by having say (N) at the end where N is the BackendSlot. Could you try this and verify if that results in the correct behavior?

kubectl  scale deploy nginx --replicas=4
cilium map get cilium_lb4_services_v2 |grep 224

<IP_ADDRESS>:80 (0)   0 3 (4) [0x0 0x0]    sync
<IP_ADDRESS>:80 (1)   36 0 (4) [0x0 0x0]   sync
<IP_ADDRESS>:80 (2)   38 0 (4) [0x0 0x0]   sync
<IP_ADDRESS>:80 (3)   39 0 (4) [0x0 0x0]   sync

kubectl  scale deploy nginx --replicas=2
cilium map get cilium_lb4_services_v2 |grep 224

<IP_ADDRESS>:80 (1)   36 0 (4) [0x0 0x0]   sync
<IP_ADDRESS>:80 (2)   38 0 (4) [0x0 0x0]   sync
<IP_ADDRESS>:80 (0)   0 2 (4) [0x0 0x0]    sync

kubectl  scale deploy nginx --replicas=5
cilium map get cilium_lb4_services_v2 |grep 224

<IP_ADDRESS>:80 (1)   36 0 (4) [0x0 0x0]   sync
<IP_ADDRESS>:80 (2)   38 0 (4) [0x0 0x0]   sync
<IP_ADDRESS>:80 (3)   41 0 (4) [0x0 0x0]   sync
<IP_ADDRESS>:80 (4)   42 0 (4) [0x0 0x0]   sync
<IP_ADDRESS>:80 (0)   0 5 (4) [0x0 0x0]    sync
<IP_ADDRESS>:80 (5)   43 0 (4) [0x0 0x0]   sync

cilium bpf lb list

SERVICE ADDRESS        BACKEND ADDRESS (REVNAT_ID) (SLOT)
<IP_ADDRESS>:9153 (1)    <IP_ADDRESS>:9153 (1) (1)
<IP_ADDRESS>:443 (0)   <IP_ADDRESS>:0 (8) (0) [ClusterIP, InternalLocal, non-routable]
<IP_ADDRESS>:9153 (2)    <IP_ADDRESS>:9153 (1) (2)
<IP_ADDRESS>:53 (0)      <IP_ADDRESS>:0 (2) (0) [ClusterIP, non-routable]
<IP_ADDRESS>:443 (1)      <IP_ADDRESS>:6443 (3) (1)
<IP_ADDRESS>:53 (2)      <IP_ADDRESS>:53 (2) (2)
<IP_ADDRESS>:80 (1)   <IP_ADDRESS>:80 (4) (1)
<IP_ADDRESS>:80 (5)   <IP_ADDRESS>:80 (4) (5)
<IP_ADDRESS>:443 (0)      <IP_ADDRESS>:0 (3) (0) [ClusterIP, non-routable]
<IP_ADDRESS>:80 (0)   <IP_ADDRESS>:0 (4) (0) [ClusterIP, non-routable]
<IP_ADDRESS>:443 (1)   <IP_ADDRESS>:4244 (8) (1)
<IP_ADDRESS>:53 (1)      <IP_ADDRESS>:53 (2) (1)
<IP_ADDRESS>:80 (3)   <IP_ADDRESS>:80 (4) (3)
<IP_ADDRESS>:80 (2)   <IP_ADDRESS>:80 (4) (2)
<IP_ADDRESS>:80 (4)   <IP_ADDRESS>:80 (4) (4)
<IP_ADDRESS>:9153 (0)    <IP_ADDRESS>:0 (1) (0) [ClusterIP, non-routable]

The service will not be deleted. But the output is not very intuitive.

This is the change.
func (k *Service4Key) String() string {
	kHost := k.ToHost().(*Service4Key)
	addr := net.JoinHostPort(kHost.Address.String(), fmt.Sprintf("%d", kHost.Port))
	addr = fmt.Sprintf("%s (%d)", addr, kHost.BackendSlot)
	if kHost.Scope == loadbalancer.ScopeInternal {
		addr += "/i"
	}
	return addr
}

What's unintuitive? The output now matches with the bpf map dump as it always should have. I suppose we could be more informative than just (1), e.g. (slot: 1), and avoid repeating the slot twice in bpf lb list.

What's unintuitive? The output now matches with the bpf map dump as it always should have. I suppose we could be more informative than just (1), e.g. (slot: 1), and avoid repeating the slot twice in bpf lb list.

Got it.

cilium bpf lb list

SERVICE ADDRESS        BACKEND ADDRESS (REVNAT_ID) (SLOT)
<IP_ADDRESS>:50814          <IP_ADDRESS>:0 (15) (0) [NodePort, non-routable]
                       <IP_ADDRESS>:8012 (15) (1)
<IP_ADDRESS>:47873     <IP_ADDRESS>:0 (8) (0) [ClusterIP, InternalLocal, non-routable]
                       <IP_ADDRESS>:4244 (8) (1)
<IP_ADDRESS>:13568       <IP_ADDRESS>:53 (2) (1)
                       <IP_ADDRESS>:0 (2) (0) [ClusterIP, non-routable]
                       <IP_ADDRESS>:53 (2) (2)
<IP_ADDRESS>:50814       <IP_ADDRESS>:0 (16) (0) [NodePort]
                       <IP_ADDRESS>:8012 (16) (1)
<IP_ADDRESS>:47873        <IP_ADDRESS>:0 (3) (0) [ClusterIP, non-routable]
                       <IP_ADDRESS>:6443 (3) (1)
<IP_ADDRESS>:20480    <IP_ADDRESS>:80 (4) (3)
                       <IP_ADDRESS>:80 (4) (2)
                       <IP_ADDRESS>:80 (4) (1)
                       <IP_ADDRESS>:0 (4) (0) [ClusterIP, non-routable]
<IP_ADDRESS>:19487    <IP_ADDRESS>:8012 (13) (1)
                       <IP_ADDRESS>:0 (13) (0) [ClusterIP, non-routable]
<IP_ADDRESS>:50814       <IP_ADDRESS>:8012 (14) (1)
                       <IP_ADDRESS>:0 (14) (0) [NodePort]
<IP_ADDRESS>:49535          <IP_ADDRESS>:0 (12) (0) [NodePort, non-routable]
                       <IP_ADDRESS>:5432 (12) (1)
<IP_ADDRESS>:14357    <IP_ADDRESS>:5432 (9) (1)
                       <IP_ADDRESS>:0 (9) (0) [ClusterIP, non-routable]
<IP_ADDRESS>:49535       <IP_ADDRESS>:0 (10) (0) [NodePort]
                       <IP_ADDRESS>:5432 (10) (1)
<IP_ADDRESS>:49535       <IP_ADDRESS>:0 (11) (0) [NodePort]
                       <IP_ADDRESS>:5432 (11) (1)
<IP_ADDRESS>:49443       <IP_ADDRESS>:0 (1) (0) [ClusterIP, non-routable]
                       <IP_ADDRESS>:9153 (1) (1)
                       <IP_ADDRESS>:9153 (1) (2)

cilium map get cilium_lb4_services_v2

Key                      Value                 State   Error
<IP_ADDRESS>:80 (1)     50 0 (4) [0x0 0x0]    sync
<IP_ADDRESS>:32705 (0)     0 1 (10) [0x42 0x0]   sync
<IP_ADDRESS>:32705 (0)        0 1 (12) [0x2 0x0]    sync
<IP_ADDRESS>:32454 (0)        0 1 (15) [0x2 0x0]    sync
<IP_ADDRESS>:32705 (1)        68 0 (12) [0x0 0x0]   sync
<IP_ADDRESS>:80 (3)     52 0 (4) [0x0 0x0]    sync
<IP_ADDRESS>:32705 (0)     0 1 (11) [0x42 0x0]   sync
<IP_ADDRESS>:443 (1)     88 0 (8) [0x0 0x0]    sync
<IP_ADDRESS>:8012 (1)   87 0 (13) [0x0 0x0]   sync
<IP_ADDRESS>:32454 (1)     87 0 (14) [0x0 0x0]   sync
<IP_ADDRESS>:443 (0)        0 1 (3) [0x0 0x0]     sync
<IP_ADDRESS>:32454 (1)     87 0 (16) [0x0 0x0]   sync
<IP_ADDRESS>:9153 (1)      60 0 (1) [0x0 0x0]    sync
<IP_ADDRESS>:80 (0)     0 3 (4) [0x0 0x0]     sync
<IP_ADDRESS>:5432 (1)   68 0 (9) [0x0 0x0]    sync
<IP_ADDRESS>:443 (0)     0 1 (8) [0x0 0x10]    sync
<IP_ADDRESS>:9153 (2)      63 0 (1) [0x0 0x0]    sync
<IP_ADDRESS>:9153 (0)      0 2 (1) [0x0 0x0]     sync
<IP_ADDRESS>:32454 (0)     0 1 (16) [0x42 0x0]   sync
<IP_ADDRESS>:32454 (1)        87 0 (15) [0x0 0x0]   sync
<IP_ADDRESS>:80 (2)     51 0 (4) [0x0 0x0]    sync
<IP_ADDRESS>:32705 (1)     68 0 (10) [0x0 0x0]   sync
<IP_ADDRESS>:53 (2)        62 0 (2) [0x0 0x0]    sync
<IP_ADDRESS>:53 (0)        0 2 (2) [0x0 0x0]     sync
<IP_ADDRESS>:8012 (0)   0 1 (13) [0x0 0x0]    sync
<IP_ADDRESS>:443 (1)        1 0 (3) [0x0 0x0]     sync
<IP_ADDRESS>:5432 (0)   0 1 (9) [0x0 0x0]     sync
<IP_ADDRESS>:32454 (0)     0 1 (14) [0x42 0x0]   sync
<IP_ADDRESS>:32705 (1)     68 0 (11) [0x0 0x0]   sync
<IP_ADDRESS>:53 (1)        61 0 (2) [0x0 0x0]    sync

@asauber

/test

/test

What's unintuitive? The output now matches with the bpf map dump as it always should have. I suppose we could be more informative than just (1), e.g. (slot: 1), and avoid repeating the slot twice in bpf lb list.

Now the output of  the command cilium bpf lb list -ojson is this.
{
  "<IP_ADDRESS>:32705 (0)": [
    "<IP_ADDRESS>:0 (2) (0) [NodePort]"
  ],
  "<IP_ADDRESS>:32705 (1)": [
    "<IP_ADDRESS>:5432 (2) (1)"
  ]
}

So a lot of tests can not pass.
Shall we add a command option like "--merged", translate the output like this
{
  "<IP_ADDRESS>:32705": [
    "<IP_ADDRESS>:0 (10) (0) [NodePort]",
    "<IP_ADDRESS>:5432 (10) (1)"
  ]
}
```.
Or, I just change the unit-tests.

/test

What's unintuitive? The output now matches with the bpf map dump as it always should have. I suppose we could be more informative than just (1), e.g. (slot: 1), and avoid repeating the slot twice in bpf lb list.

Now the output of the command cilium bpf lb list -ojson is this.
{
  "<IP_ADDRESS>:32705 (0)": [
    "<IP_ADDRESS>:0 (2) (0) [NodePort]"
  ],
  "<IP_ADDRESS>:32705 (1)": [
    "<IP_ADDRESS>:5432 (2) (1)"
  ]
}

So a lot of tests can not pass. Shall we add a command option like "--merged", translate the output like this
{
  "<IP_ADDRESS>:32705": [
    "<IP_ADDRESS>:0 (10) (0) [NodePort]",
    "<IP_ADDRESS>:5432 (10) (1)"
  ]
}
```.
Or, I just change the unit-tests.

Let's change the tests as this is the correct output.

/test

/test

/test

/test

@xyz-li Could you write a user-facing release note that describes the impact of the fix? For example,
Fix bug where <symptom/problem> ...

@christarazi I think it's not a fix per se, it's just improving the introspection into certain datastructures when using the in-Pod CLI.

@christarazi @xyz-li I updated the release-note, hopefully that's more accurate.

@joestringer this fixes a bug as WithCache() uses String() as the key. It fixes the overlapping keys that could have caused a failed BPF map update to never be retried.

@joamaki I didn't realize it had user-facing impact. If a user hit this issue, what would they experience? How might they know whether this fix addresses the problem they are facing? Whatever the answer to this question is what we would expect the release note in the PR description to be.

@joestringer How about not changing the output on the client side?

How about this?

Fix bug where a Service would be removed from the datapath if the backends are scaled down to zero.

@xyz-li I don't understand how that relates to my feedback, sorry. All I'm asking is that we describe the change clearly in the user-facing changelogs so that users can understand what bug this fixes and whether they are likely to be affected so they know to upgrade. The release note is derived from the ```release-note ... ``` field at the bottom of the PR description.
If you think we should revisit what the client-side output looks like, then I'd suggest describing the alternatives and then others in the PR can provide feedback about which format is best. Without seeing the output, I don't have a strong opinion about this.

How about this commit.
https://github.com/cilium/cilium/pull/31408

/test


Support @jsx pragma

It's awesome that standard supports jsx now.
In addition to supporting React, babel supports generic JSX transforms, using a pragma like this:
/** @jsx mypackage.doSomething */

demo
Of course, when using them, standard is peppered with 'React' must be in scope when using JSX. Would it be possible to respect this pragma. It's not a Babel invention, React itself required it until recently.

standard just uses eslint-plugin-react to support jsx. We could just disable the "react-in-jsx-scope" rule - but it seems useful for most users.
I would suggest opening an issue on eslint-plugin-react and ask them to support the pragmas you want.

Will do, thanks.

Yep :)


Fix Spelling using VSC Spell Checker Extension

Mb that this is an issue in the first place, I'll fix it as as I create new
documentation since I didn't have the extension when I first wrote it.
The Extension I'm refering to can be found here: https://marketplace.visualstudio.com/items?itemName=streetsidesoftware.code-spell-checker
Extension ID: streetsidesoftware.code-spell-checker

Also, try to add any words that it doesn't recognize like autons to workspace settings so it recognizes them in the future.


JSON(B) datatype uses "text" in most databases which causes issues

This could be considered a bug or enhancement depending on the direction development goes.
Environment
Knex version: 0.12.9
Database + version: mssql, mysql, maria, and others
OS: any
Feature discussion / request
We have a mandate to use an SQL database and cannot use a document store but we still want to primarily work with JSON data to minimize table conversions. We primarily support MSSQL and MySQL/MariaDB as that is what our customers are most comfortable with. These databases have support for the JSON(B) data type (some only within the last year) but Knex continues to use TEXT for these implementations. This leads to issues: some of our JSON documents exceed the maximum size of the TEXT data type in some of these implementations (maximum sizes differ) and we get exceptions when inserting these documents.
As I see it, Knex could handle this in a few ways:
A) Knex makes a runtime determination of whether or not the database supports the JSON(B) datatype.
B) Knex gives the developer the ability to specify the datatype to use instead of the JSON(B) data type when not supported.
C) Combine both of the options above
D) Bring MySQL and MariaDB in line with MSSQL by using LONGTEXT instead of TEXT
The API for (B) might look something like this:
var knex = require('knex')({
  client: 'mysql',
  jsonDatatype: (knex, callback) => {
    // ... use knex to get version somehow
    if (compareVersions(version,'5.7.8') < 0) {
        // tell the driver to use the LONGTEXT data type
        callback('LONGTEXT');
    } else {
        // tell the driver to use the JSON data type
        callback('JSON');
    }
  }
});

The proposed API could be implemented directly in the driver (ie. option (A)) allowing dynamic detection of JSON support. I still like the idea of being able to specify the type to use if JSON is not support, which might make the API for (C) look like this:
var knex = require('knex')({
  client: 'mysql',
  jsonDatatype: (knex, supported) => supported ? 'JSON' : 'LONGTEXT'
});

Option (D) would obviously be the easiest to implement.

A) not worth it to do runtime check, we trust that people will use enough modern mysql if one likes to use json datatype (there is PR to fix it for mysql, waiting for travis to get 5.7 easily available)
B) with .specificType + simple helper which decides type by dialect you can do this already very easily
C) No need for this, option B) should be enough automatic detection makes things unnecessary complicated
D) I think option B) should work for this one too (and at some point when we change mysql json type to use real json type we can set mariadb to use longtext with big warnings in changelog)
I would suggest to not use .json type at all unless you are really running the program with platform where you are doing some json queries too. Otherwise using json to store something instead of blob or just a string is not really beneficial.
I would rather just throw an error if application code is trying to create json column on a DB which doesn't really support it. That would be also safer choice in compared to just changing type from text -> json and text -> longtext...

Hi Elhigu,
Thanks for the input. I disagree that checking for supported datatypes at connection time would be difficult, complicated, or introduce significant performance drain. Doing so would elevate Knex by increasing the number of things the drivers could abstract.
As far as a solution for our problem, we can evaluate altering the columns to use the appropriate TEXT datatype in the four primary database we support. Are there instructions/documentation on how to extend the Knex implementation (through monkey-patching) such that I could expose a new API? That way, in our schema builders, we could reference our function as if it were provided by Knex?

I disagree that checking for supported datatypes at connection time would be difficult, complicated, or introduce significant performance drain.

Looks like you haven't tried to do that with all the time growing set of mysql compatible DB engines. It is complicated to maintain because there are 100 mysql clones and more are coming out all the time. Each clone might return different version strings / numbers and keeping that mapping up is the problem (this happened already with postgresql dialect).
Also I still don't consider that being very useful feature, because in either way you will have to write cross db compatible code by using the feature set that all the dialects you are abstracting away support.

Doing so would elevate Knex by increasing the number of things the drivers could abstract.

Not really. If you are going to support all the databases, you cannot use json functionality effectively, because all DBs doesn't support them. So you would end up having separate code for DBs using json and separate code for other (which means that you are not really abstracting underlying DB away).
I have not seen any use case where using .json() in schema and then having it as text column in some dialect and with real jsonb column in other dialect would have been beneficial, only problems caused by type differences on different platforms. If you have some rare case it is, then implementing that in your own schema building code is trivial and in that case you have to have various versions of your queries too to be able to benefit those jsonb columns in your application.
So I stand by my opinion that that emulating .json() type with text column is more harmful than useful and throwing an error on non supported dialects would be the correct behaviour.

Are there instructions/documentation on how to extend the Knex implementation (through monkey-patching) such that I could expose a new API? That way, in our schema builders, we could reference our function as if it were provided by Knex?

There is really no good way to extend knex API. However for queries with .modify you can emulate that a bit, by having set of custom helpers and pass them to query builder like knex('mytable').modify(mySpecialHelper).where(...).... When I do custom things for schema building I just write simple helpers and call them inside createTable handler like this:
knex.schema.createTable('mytable', t => {
  defaultColumns(t, knex);
  mySpecialMaybeJsonColumnOrSomethingElse(t, knex);
});

That is pretty clear syntax to extend schema builder.

@elhigu This reasoning makes sense from a practical standpoint but the Knex documentation doesn't make this clear.  Specifically the line "defaulting to a text column in older versions or in unsupported databases" for the json() method would lead many people (including myself) to believe that for any client that doesn't natively support json/jsonb, it will switch to text under-the-covers, when in fact it simply errors.

@MNGoldenEagle I agree that how current schema API of knex is confusing in many ways. Because of historical reasons in many places it tries to emulate unsupported datatypes with some non compatible column types among other non-obvious ways for user. Sadly we really cannot change much current API either because it makes it too hard for old projects to migrate to changed behaviour (everyone would need to fix their old migration files etc.).
IMO Its beyond repairing. Thats why right now I've taken my main task in knex to be writing completely new migration API which can address that problem and it will be more consistent in many ways and for example will never try to emulate unsupported column types with incompatible ones. I also home that I can add schema API versioning support to new on, so that we can make also backwards incompatible changes there in case if we see that we made bad API choices at some point. Old API will be left as legacy API which won't get updates anymore and it will be maybe dropped when some day in distant future knex 1.0 is released.


For #208: Issue 208 auth http client

For #208:

refactoring AuthHttpClient to support one more method of authentication (with X-Registry-Config header), which is used when building images

Job #223 is now in scope, role is REV

Pull Request Test Coverage Report for Build 394

22 of 22 (100.0%)  changed or added relevant lines in 4 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.4%) to 87.702%

Totals

Change from base Build 390:
0.4%

Covered Lines:
542

Relevant Lines:
618

💛  - Coveralls

Pull Request Test Coverage Report for Build 394

22 of 22 (100.0%)  changed or added relevant lines in 4 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.4%) to 87.702%

Totals

Change from base Build 390:
0.4%

Covered Lines:
542

Relevant Lines:
618

💛  - Coveralls

This pull request #223 is assigned to @paulodamaso/z, here is why; the budget is 15 minutes, see §4; please, read §27 and when you decide to accept the changes, inform @amihaiemil/z (the architect) right in this ticket; if you decide that this PR should not be accepted ever, also inform the architect; this blog post will help you understand what is expected from a code reviewer; there will be no monetary reward for this job

@rultor merge

@rultor merge

@paulodamaso Thanks for your request. @amihaiemil Please confirm this.

@rultor merge it

@rultor merge it

@amihaiemil OK, I'll try to merge now. You can check the progress of the merge here

@rultor merge it

@amihaiemil Done! FYI, the full log is here (took me 2min)

Job was finished in 16 hours, bonus for fast delivery is possible (see §36)

The job #223 is now out of scope

Order was finished: +20 point(s) just awarded to @paulodamaso/z

Payment to ARC for a closed pull request, as in §28: +10 point(s) just awarded to @amihaiemil/z


[FEATURE] webpack.config.js for server-side rendering

Hello!
First of all, I'd like to thank you for this awesome work! This really got us kickstarted quite well and we'll be able to work with this as a solid base for our React projects! It's awesome!
Still, I found one major concern with the current state of the project and it's mainly SEO.
So, with webpack it is possible to render the HTML staticaly (https://github.com/webpack/react-webpack-server-side-example) but I haven't figured out how to configure my relay-fullstack instance to do that, at all.
Here's my webpack.config.js, maybe you can tell me what is wrong or maybe suggest a way to do it properly?
Regards
Tizian
webpack.config.js:
'use strict';
const path = require('path');
const webpack = require('webpack');
const autoprefixer = require('autoprefixer');
const precss = require('precss');
const HtmlWebpackPlugin = require('html-webpack-plugin');
const FaviconsWebpackPlugin = require('favicons-webpack-plugin');

let appEntry;
let devtool;
let plugins;

if (process.env.NODE_ENV === 'production') {
  appEntry = [path.join(__dirname, 'client/index.js')];
  devtool = 'source-map';
  plugins = [
    new webpack.optimize.DedupePlugin(),
    new webpack.optimize.OccurrenceOrderPlugin(),
    new webpack.optimize.CommonsChunkPlugin('vendor', 'vendor.js'),
    new webpack.DefinePlugin({
      'process.env': {
        NODE_ENV: JSON.stringify('production')
      }
    }),
    new webpack.optimize.UglifyJsPlugin({
      compress: {
        warnings: false,
        screw_ie8: true
      }
    }),
    new HtmlWebpackPlugin({
      title: 'Relay Starter Kit - Integrated with Relay, GraphQL, Express, ES6/ES7, JSX, Webpack, Babel, Material Design Lite, and PostCSS',
      template: './client/index.html',
      mobile: true,
      inject: false
    }),
    new FaviconsWebpackPlugin('./client/assets/logo.png')
  ];
} else {
  appEntry = [
    path.join(__dirname, 'client/index.js'),
    'webpack-dev-server/client?http://localhost:3000',
    'webpack/hot/only-dev-server'
  ];
  devtool = 'eval';
  plugins = [
    new webpack.optimize.CommonsChunkPlugin('vendor', 'vendor.js'),
    new webpack.NoErrorsPlugin(),
    new webpack.HotModuleReplacementPlugin(),
    new webpack.DefinePlugin({
      __DEV__: true
    }),
    new HtmlWebpackPlugin({
      title: 'Relay Starter Kit - Integrated with Relay, GraphQL, Express, ES6/ES7, JSX, Webpack, Babel, Material Design Lite, and PostCSS',
      template: './client/index.html',
      mobile: true,
      inject: false
    }),
    new FaviconsWebpackPlugin('./client/assets/logo.png')
  ];
}

var commonLoaders = [
    { test: /\.js$/, loader: 'babel-loader', },
    { test: /\.png$/, loader: "url-loader" },
    { test: /\.jpg$/, loader: "file-loader" },
];

var assetsPath = path.join(__dirname, "public", "assets");
var publicPath = "assets/";

module.exports = [
    {
        // The configuration for the server-side rendering
        name: "server-side rendering",
        entry: "./server/page.js",
        target: "node",
        output: {
            path: assetsPath,
            filename: "../../server/page.generated.js",
            publicPath: publicPath,
            libraryTarget: "commonjs2"
        },
        resolve: {
            extensions: ['', '.jsx', '.js']
        },
        externals: /^[a-z\-0-9]+$/,
        module: {
            loaders:[
                { test: /\.jsx?$/, loader: "babel-loader", query: { presets: ['react', 'es2015'] } },
                { test: /\.jpe?g$|\.png$|\.gif$/, loader: "file-loader" }
            ]
        }
    }
];

/*
module.exports = {
  entry: {
    app: appEntry,
    vendor: ['react', 'react-dom', 'react-mdl', 'react-relay', 'react-router', 'react-router-relay']
  },
  output: {
    path: path.join(__dirname, 'build'),
    publicPath: '/',
    filename: '[name].js'
  },
  devtool,
  module: {
    loaders: [{
      test: /\.jsx?$/,
      loader: 'babel-loader',
      exclude: /node_modules/
    }, {
      test: /\.css$/,
      loaders: ['style', 'css']
    }, {
      test: /\.scss$/,
      loaders: [
        'style',
        'css?modules&importLoaders=1' +
          '&localIdentName=[name]__[local]___[hash:base64:5]!postcss'
      ]
    }, {
      test: /\.(png|jpg|jpeg|gif|svg|woff|woff2|eot|ttf)(\?\S*)?$/,
      loader: 'url-loader?limit=10000&name=assets/[hash].[ext]'
      //loader: 'file'
    }
    //,{test: /test woff/, loader}
    ]
  },
  postcss: () => [precss, autoprefixer],
  plugins
};
*/

Hi Tizian, Thanks for the question. I have planned to integrate server-side rendering for a long time. Unfortunately, I don't have time to do it very soon. Relay doesn't support server-side rendering out of the box. You might need to take a look at isomorphic-relay-router. A PR would be also very welcomed

The Relay 2 (release date supposedly soon but not yet confirmed) approach to SSR might be of interest:
"Our overall approach with the new core has been to build simple primitives that can be built upon in user space. So for example, there is a clear separation of the React integration layer and the core - the former being implemented entirely via the public API of the latter. It might take a few releases to refine and document this, but i expect that it will be easy for the community to build upon this to make a server rendering module for Relay." source: https://github.com/facebook/relay/issues/1369


How can I run properly the example?

Hi, great library!
Just a question, how I can run the xample, I mean I need run separately node index.js and node bree.js ? because I tried run just index.js  and after that do a POST  request to http://localhost:8080/book-ticket giving it a body like this:
{
    "email"<EMAIL_ADDRESS>    "start_time": "08/09/2020 13:30"
}

however it don't scheduled the email, it sent the email like http://localhost:8080/send-email
Meybe i´m doing a mistake, any way to run the example properly?

Yes, you run node index.js and node bree.js separately at the same time.  I could rename index.js to app.js, but you are correct.

@anjopater I have added a full working example for this repo at https://github.com/breejs/express-example#example.  Let me know if you need anything else.


Upgrade cartodb extension to v0.21.0

Update cartodb extension for some fixes

uh, oh, why are the backend CI tests trying to delete a db named ""?
16:34:57 Creating user publicuser
16:34:57 Creating user tileuser
16:34:57 + sh runParallelTests.sh 12
16:34:57 rm: cannot remove 'parallel_tests': No such file or directory
16:34:57 # Speclist has been created
16:34:57 redis-server(17133): Operation not permitted
16:35:00 ERROR:  zero-length delimited identifier at or near """"
16:35:00 LINE 1: drop database ""
16:35:00                       ^
16:35:00 rm: cannot remove 'parallel_tests/users_databases_new.log': No such file or directory
16:35:00 ERROR:  zero-length delimited identifier at or near """"
16:35:00 LINE 1: drop database ""
16:35:00                       ^
16:35:00 rm: cannot remove 'parallel_tests/users_databases_new.log': No such file or directory
16:35:00 # Cleaner finished
16:35:00 rm: cannot remove 'config/database_*': No such file or directory
16:35:12 # Wrapper finished

Retest this, please.

No space on disk?

Retest this, please.

Retest this, please.

retest this please

Backend tests will fail due to PG10.


ValueSerializer remove legacy mode

Because we have already the string.format, we should consider removing the legacy mode in the ValueSerializer.
Also for this we need to detect mixed mode better, see #2532

I think we should leave it now as is.


Use createAndGet when creating metadata object

This save one REST API call and closes: #112

Please, update also tests


payAck.php returns wrong Content-Length to client

Wrong calculation of the content-length in payAck.php - depending on the http-client behavior, it might get a truncated response.

Thanks!  If I forget to pull this and update the code running on bitcoincore.org within the next week, please remind me.

Please also check #7 - I guess the cert-files got moved or are somehow not accessible by the script.

Wow, this is an old one :) - already forgotten about it...
Is this demo script still somewhere running? the original URL ( https://bitcoincore.org/~gavin/createpaymentrequest.php ) is a 404 (which is even mentioned in the BIP70 and many other locations)


Provide a template for new projects like Cryogenic

Aim is to make it easy for people to create new reverse engineering projects

Implemented.


Country-Guesser Game changed

PR Description 📜
I have changed background color as well as hover effect to make the game user friendly
Fixes #2622

Mark the task you have completed ✅

[x] I follow CONTRIBUTING GUIDELINE & CODE OF CONDUCT of this project.
[x] I have performed a self-review of my own code or work.
[x] I have commented my code, particularly in hard-to-understand areas.
[x] My changes generates no new warnings.
[ ] I have followed proper naming convention showed in CONTRIBUTING GUIDELINE
[ ] I have added screenshot for website preview in assets/images
[ ] I have added entries for my game in main README.md
[ ] I have added README.md in my folder
[ ] I have added working video of the game in README.md (optional)
[ ] I have specified the respective issue number for which I have requested the new game.

Add your screenshots(Optional) 📸
Earlier
https://github.com/kunjgit/GameZone/assets/127978268/e02d6e1c-b019-45c6-8dfa-18ac0ef9bbea
Now
https://github.com/kunjgit/GameZone/assets/127978268/54228ebb-2b25-40ba-890f-afde96e872e7

Thank you soo much for contributing to our repository 💗

Thank you @akankshachanana1 ,for creating the PR and contributing to our GameZone 💗
Review team will review the PR and will reach out to you soon! 😇
Make sure that you have marked all the tasks that you are done with ✅.
Thank you for your patience! 😀

Actually that is a bright yellow color , which I think might distract user.

Thank you  @akankshachanana1 , for your valuable time and contribution in our GameZone 💗.
It’s our GameZone, so Let’s build this GameZone altogether !!🤝
Hoping to see you soon with another PR again 😇
Wishing you all the best for your journey into Open Source🚀


kramdown markup issues

We're having issues with headings now that github pages has been updated.

A lot of the posts have been updated on #30 - might be a good time to get that in (ping @carlwood)

I believe this is no longer an issue so closing. @benfoxall please re-open if i'm mistaken.


Bug in style transform

I found a bug in the style transform. If you do:
          todo-app {

it becomes:
          todo-app todo-app {

When it should skip adding the custom element name if it already exists.

I don't think this is a bug. The SSR behavior is the same. If you want to style the element itself you can use the :host selector. Every rule gets the element name prepended unless it starts with :host.

@ryanbethel is right, this is the expected behaviour for style transform but the question now is, should we fix it?

I ran into this when I was working on the other versions of the shady styles transform.
My opinion is we should fix this since it is a way to shortcut the need of a :host transform.
We could inform users to use scope=global when wanting to use the hardcoded custom element tag selector in their styles.
Currently using the custom element tag name instead of :host in your styles is an anti-pattern as you could specify any custom element tag name when you register the class in customElements.define


Trending youtube videos

Fetching trending videos from youtube based on user location would be a good feature to have.
P.S: This is the first time I am trying to contribute for an open source project.

is it already developed? i want to develop this feature

is it already developed? i want to develop this feature

I'm not working on it anymore. Go on!

I finished this issue, this is the pull request
https://github.com/swapagarwal/JARVIS-on-Messenger/pull/514


Unexpected behaviour of get_densitytensor_to_sampled_expectation_func

In the below MRE the sampled expectation deviates from the exact which I believe is correct.
I think the get_densitytensor_to_sampled_expectation_func needs a rewrite and also tests to check this
from jax import random, numpy as jnp
import qujax

gates = ['H','Rz']
qubit =[[0],[0]]
param_ind =[[], [0]]
no_noise_pvec_to_densitytensor = qujax.get_params_to_densitytensor_func(gates, qubit, param_ind)
state_to_expectation = qujax.get_densitytensor_to_expectation_func(['X'],[[0]],[1])
no_noise_expectation = state_to_expectation(no_noise_pvec_to_densitytensor(0.3))
print(no_noise_expectation)
# 0.5877851

state_to_sample_expectation =qujax.get_densitytensor_to_sampled_expectation_func(['X'],[[0]],[1])
sampled_expectation = state_to_sample_expectation(no_noise_pvec_to_densitytensor(0.3), random.PRNGKey(1),10000)
print(sampled_expectation)
# 0.99986684

Bug fixed in #77 v0.3.4
Now raises a warning for observables that do not commute with gates.Z (as real quantum devices only measure in the computational basis).
The sampled expectation will now still be asymptotically unbiased for all observables but this does reflect any notion of physical measurement (for observables that do not commute with gates.Z).


Apply DesignModules to the main frame of MediaCompose

Filed https://github.com/google/automotive-design-compose/issues/982

Also I'd run ./gradlew spotlessApply to format the kotlin files. @timothyfroehlich do we not do a lint check anymore?

Code to fix JSON generation: https://github.com/google/automotive-design-compose/pull/1004

I'm confused how this is building when my change has not merged https://github.com/google/automotive-design-compose/pull/1004

I'm confused how this is building when my change has not merged #1004

It doesn't. I cherrypicked your change locally and made the change on top of that. Still need to wait for your change to get merged.

Ok my change merged, could you see if the failure is fixed now?


MM-18441 Clarify bot account creation flow (#3632)

Summary
This is a cherry pick of https://github.com/mattermost/mattermost-webapp/pull/3632 into release-5.16

Update en.json

Update admin_definition.jsx

Update bots.jsx

Update bots.jsx

Fix redirect link

Update redirect link

Update bots.jsx

Update bots.jsx

Update en.json

Update en.json

Break message into to components.  One for handling markdown and the
other for a normal formatted message.

Add siteURL prefix to System Console link

@jasonblais, cherry-pick automation failed in https://github.com/mattermost/mattermost-webapp/pull/3632.  This PR will server as the cherry-pick PR into the release-5.16 branch.

@jasonblais checks passed.  Squashed and merged!

yayy, thanks again!


Create subclass for PublicClientApplication.ts in msal-browser

This PR creates a new abstract class called ClientApplication.ts that is a base class for the PublicClientApplication class. Most of the method definitions have been moved there.
This is to prepare for the addition of the broker flow in the browser.

Coverage increased (+0.003%) to 83.052% when pulling 6e26798177883776f642bb78b2750009abe869d2 on abstract-pca-v2 into ac7ee45608244704bca348bfd2c3895c51bf3666 on dev.


@qualweb/core: add CMP support

We've discussed adding the CMP plugin as a built-in addition to @qualweb/core.
This issue tracks work on adding the plugin as part of the API.
Goals:

Good out-of-the-box defaults. Simply enabling the feature in a call to evaluate() or start() should have it use its existing list of known CMP descriptors.
Easy to configure for single runs. It should be straightforward to add a known CMP descriptor when calling start/evaluate that is fed to the CMP plugin before running.

There's also the question in regards to caching CMP cookies between page visits. If a site has already been visited before, and the cookies from that visit were stored, they can be fed back into Puppeteer in order to suppress banners on future visits. This can be accomplished using beforePageLoad in a separate plugin, but might be useful as some sort of default functionality, too.

Brief check-in.
I've been mulling over how to integrate the CMP plugin neatly within QualWeb instead of just being a peer dependency.
It was originally designed to be used from "outside" the qualweb system as a peer dependency, not within it. Some consumer of QualWeb would add both @qualweb/core and @inqludeit/qualweb-plugin-cmp as dependencies and, in its simplest form, apply it with two lines of code:
import qw from '@qualweb/core';
// 1. import
import cmp from '@inqludeit/qualweb-plugin-cmp';

const qwInstance = new qw.QualWeb();

// 2. use
qwInstance.use(await cmp.createPlugin());

qwInstance.evaluate({ /** ... */ });

It feels a bit like over-engineering the solution to add several new parameters to QualWeb to achieve this effect.

Tiny update while I work on a working example.
I've split up the package @inqludeit/qualweb-plugin-cmp into two components. @inqludeit/qualweb-plugin-cmp has been reduced to a thin wrapper than initializes a basic QualWeb plugin for simple uses. This package still depends on QualWeb.
Separately, I've pulled out all the core code into a new package, @inqludeit/cmp-b-gone. This package has no QualWeb-specific code, and can be integrated with @qualweb/core without any risk of cyclic dependencies.
I'll add an update once I've fleshed out a working example in a dev branch.


Added preserve_defined_order flag to annotation builder

This flag when set preserve the elements in the order they are defined in the class as opposed to the default of putting fieldsets after elements.
Fixes https://github.com/zendframework/zf2/issues/6653

Merged to develop for release with 2.4.


FastDL first release

Working for gmod only right now, will add some other source games soon

Not sure why the last test failed, makes no sense :o))


Not able to specify multiple data providers with the cloud live deploy command

It was working before with the param ib-data-feed. I can set a list of data providers with comma as delimiter. The new param --data-provider-live won't work now. please fix if possible.
Usage: lean cloud live deploy [OPTIONS] PROJECT
Try 'lean cloud live deploy --help' for help or go to the following url for a list of common errors:
https://www.lean.io/docs/v2/lean-cli/key-concepts/troubleshooting#02-Common-Errors
Error: Invalid value for '--data-provider-live': 'QuantConnect,Interactive Brokers' is not one of 'QuantConnect', 'Interactive Brokers', 'Tradier',
'Oanda', 'Bitfinex', 'Coinbase Advanced Trade', 'Binance', 'Zerodha', 'Samco', 'Terminal Link', 'Trading Technologies', 'Kraken', 'TDAmeritrade',
'Polygon', 'IEX', 'CoinApi', 'Bybit'.

Hey @lifelonginvestor! The error is showing you the new possible expected values, before we only allowed very specific combinations, now it's generic.

@Martin-Molinero How do I specify multiple providers then? This is not working for me as I was trying to split them with comma. What's the correct way to specify multiple providers.
'--data-provider-live': 'QuantConnect,Interactive Brokers'

For example lean cloud live deploy 17354101 --data-provider-live QuantConnect --data-provider-live "interactive brokers"

Thanks! it works.


Showcase scarb cairo-test arguments in scarb test --help output

Problem
Users are confused by the fact that scarb test does not include scarb cairo-test's arguments in its --help output. The Run 'scarb test -- --help for test program options. message seems to be overlooked.
Proposed Solution
Perhaps add a separate clap heading that we'll somehow populate (semi)automatically?
https://docs.rs/clap/latest/clap/struct.Command.html#method.defer may be helpful
Suggested help outputs

[!IMPORTANT]
These are just suggestions to target. The final code does not have to match this 1:1 if this would be very hard to achieve.

scarb test --help:
Execute all unit and integration tests of a local package

By default, this command delegates to `scarb cairo-test`. This behaviour can be changed by defining a script named `test` in workspace Scarb.toml file.
Run `scarb test -- --help` for test program options.

Usage: scarb test [OPTIONS] [ARGS]...

Arguments:
  [ARGS]...  Arguments for the test program

Options:
  -p, --package <SPEC>         Packages to run this command on, can be a concrete package name (`foobar`) or a prefix glob (`foo*`) [env: SCARB_PACKAGES_FILTER=] [default: *]
  -v, --verbose...             Increase logging verbosity.
  -w, --workspace              Run for all packages in the workspace
  -F, --features <FEATURES>    Comma separated list of features to activate [env: SCARB_FEATURES=]
  -q, --quiet...               Decrease logging verbosity.
      --all-features           Activate all available features [env: SCARB_ALL_FEATURES=]
      --verbosity <VERBOSITY>  Set UI verbosity level by name. [env: SCARB_UI_VERBOSITY=]
      --no-default-features    Do not activate the `default` feature [env: SCARB_NO_DEFAULT_FEATURES=]
  -h, --help                   Print help

Options for cairo-test:
  -f, --filter <FILTER>       Run only tests whose name contain FILTER [default: ]
      --include-ignored       Run ignored and not ignored tests
      --ignored               Run only ignored tests
      --print-resource-usage  Whether to print resource usage after each test

scarb cairo-test --help - this one should stay unchanged
Execute all unit tests of a local package

Usage: scarb-cairo-test [OPTIONS]

Options:
  -p, --package <SPEC>        Packages to run this command on, can be a concrete package name (`foobar`) or a prefix glob (`foo*`) [env: SCARB_PACKAGES_FILTER=] [default: *]
  -w, --workspace             Run for all packages in the workspace
  -f, --filter <FILTER>       Run only tests whose name contain FILTER [default: ]
      --include-ignored       Run ignored and not ignored tests
      --ignored               Run only ignored tests
      --print-resource-usage  Whether to print resource usage after each test
  -h, --help                  Print help
  -V, --version               Print version

Notes by @mkaput
We are using derive-style clap.
scarb cairo-test arguments are defined here:
https://github.com/software-mansion/scarb/blob/7f67815ee8c482edbcd2d52e5d3549de305a87de/extensions/scarb-cairo-test/src/main.rs#L14-L36
scarb test args are here:
https://github.com/software-mansion/scarb/blob/a5e4c114c45005ede8346849c006fe04ad361de2/scarb/src/bin/scarb/args.rs#L386-L399
In scarb test arguments there is a "catch-all" used and we don't want the cairo-test specific arguments to eat them. This is the hard part here that I don't know how to solve. Because I think the easiest would be to add cairo-test arguments as #[flatten]. These could be "imported" via the following module hack:
#[path = "......"]
mod foo

like it is done in scarb-test-support:
https://github.com/software-mansion/scarb/blob/8ea3887f39990f1dd89d9069027fe43a2c3f0128/utils/scarb-test-support/src/fsx.rs#L14-L16

Hi, I would like to try this!

The task is yours 😄
Do you have an idea how to approach this nicely, without copy-pasting help docs?

Thanks for assigning it to me!
I am still figuring some things out, is there a telegram group where I can ask questions if needed?

I am still figuring some things out, is there a telegram group where I can ask questions if needed?

https://t.me/+G_YxIv-XTFlhNWU0

Hi @stevencartavia !
Are you still working on this?

Unassigning from Steven as discussed offline. This task is again open for taking!
I am also going to update issue description with insights we gathered with Steven.

I am applying to this issue via OnlyDust platform.
My background and how it can be leveraged
I am a programmer with a solid foundation in various programming languages, including Cairo, Python, C++, JavaScript, TypeScript, Java, and Ionic. I have had the opportunity to apply my skills in creating an application in Ionic, which has allowed me to gain experience in developing intuitive and functional user interfaces for mobile and web devices. In addition, I have worked on simpler projects using the rest of the aforementioned languages, which has allowed me to understand different programming paradigms and adapt to the needs of each project.
How I plan on tackling this issue
To address the problem of integrating scarb cairo-test arguments into scarb test without them being caught by a catch-all, I propose to reuse the arguments via the module import technique (#[path]) and the #[flatten] annotation on clap. This allows cairo-test arguments to be integrated directly into the ScarbTestArgs structure, ensuring that they are handled properly without being sucked into the catch-all. Additionally, the user experience can be improved by displaying a clear message in the scarb test help indicating how to access the additional options available in cairo-test.

I am applying to this issue via OnlyDust platform.
My background and how it can be leveraged
I have contributed to a lot of project in Starknet and worked in the ecosystem, I have experience in Rust
How I plan on tackling this issue
Read the codebase to see the current implementation and investigate the proposed solution

Hi @chachaleo !
We will welcome any contributions, but please be aware we don't have any funds assigned on the only dust platform.

No problem, happy to work on this :)

I’m interested in this one.

@PedroRosalba PRs welcome :)

applied to this via only dust, idk why didnt show up
On Mon, 4 Nov 2024 at 03:09 Marek Kaput @.***> wrote:

@PedroRosalba https://github.com/PedroRosalba PRs welcome :)
—
Reply to this email directly, view it on GitHub
https://github.com/software-mansion/scarb/issues/1303#issuecomment-2453889862,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AVOFISTQPLSDWGU4J7VNOK3Z64FTDAVCNFSM6AAAAABHTV5YH6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINJTHA4DSOBWGI
.
You are receiving this because you were mentioned.Message ID:
@.***>

@PedroRosalba
We will welcome any contributions, but please be aware we don't have any funds assigned on the only dust platform.

May I pick this up?

@RomThpt sure!

Is this issue still available?


Add diagnose support for KubeSphere

Some potential issues might be able to detect by a CLI. For example, s2ibuildertemplates is missing.

A new idea from the ks forum. Many people might be confused by the Jenkins k8s agent always offline. It's good to check the status of it, then report the status.


New Modbus list

Maybe there will be a new update with the new features.
I've been in contact with Solarfocus support over the last few days.
A few settings have been changed and now the climate control should work. Support also said that there could be a few irregularities in the Modbus control.
But they didn't give any details.
Danke
ecomanager-touch_Modbus-TCP_Registerdaten_Anleitung1.pdf

I got some information from Solarfocus today about cooling. Maybe you can do something with it.


pipeline: check incoming ACHFile is valid prior to accepting

ts=2021-08-03T15:51:38Z msg="begin handle received ACHFile= of 3110 bytes" level=info app=achgateway version=v0.5.1

Codecov Report

Merging #38 (216e8ea) into master (6dea5d5) will increase coverage by 0.13%.
The diff coverage is 0.00%.

@@            Coverage Diff             @@
##           master      #38      +/-   ##
==========================================
+ Coverage   37.01%   37.14%   +0.13%
==========================================
  Files          78       78
  Lines        2977     2980       +3
==========================================
+ Hits         1102     1107       +5
- Misses       1625     1626       +1
+ Partials      250      247       -3

Impacted Files
Coverage Δ

internal/pipeline/file_receiver.go
0.00% <0.00%> (ø)

internal/upload/sftp.go
65.04% <0.00%> (+2.42%)
: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 6dea5d5...216e8ea. Read the comment docs.


REST Server: refine vc errors.

Ping #807

Coverage decreased (-5.6%) to 45.322% when pulling ad69434d4efd612c80d1080c8e6d1950b1d6af2b on qixcheng/rest-server-refine-error/vc into 84a395bc7472b734a898590efb676d1b2907e0ad on qixcheng/rest-server-refine-errors.

Coverage decreased (-5.6%) to 45.322% when pulling ad69434d4efd612c80d1080c8e6d1950b1d6af2b on qixcheng/rest-server-refine-error/vc into 84a395bc7472b734a898590efb676d1b2907e0ad on qixcheng/rest-server-refine-errors.