Discussion on Path-Lookup Strategy (Recursive or Non-Recursive)

tl/dr: I see some problems with the new path-lookup system, namely dropping the recursion at core CSes, and would like to have a (brief) discussion about whether the advantages of the new system outweigh its disadvantages.
In the context of writing the new SCION book, I've taken a closer look at the new path-lookup system, mostly based on #3731, the documentation introduced in #3747, and an offline discussion that @matzf pointed me to. There is the first change, mainly removing the path syncing in core ASes, which is discussed in some detail in #3731. I agree with those points and think that the changes make sense.
In addition, the lookup process was changed significantly. (To simplify the text I will use "local CS" for the CS in the source's non-core AS, "local core CS" for a CS in a core AS of the source's ISD, and "remote CS" for a CS in a core AS of the destination's ISD.)
In the old system, the request from the local CS to the local core CS was recursive, i.e., the local CS queried the local core CS and that in turn fetched (and cached) down-segments from the remote CS. In the new system, the local CS asks the local core CSes and remote CSes separately for core- and down-segments, respectively.
Problems of the old system (with recursion)
As far as I understand, the main arguments for the new system are the following:

Caching of remote down-segments at core CSes is cumbersome and may cause issues.
Without the consistency among core CSes, the recursive lookup becomes somewhat problematic:

If both local CS and local core CSes send requests to multiple CSes simultaneously, this causes a lot of redundant requests and information (as every local core CS would talk to every remote CS).
If the local core CS sends a request to a single (random) remote CS, the lookup becomes somewhat unpredictable for the local CS.
The best solution might be that the local CS only sends a request to a single local core CS, which then contacts all remote CSes, but that reverts back to the first case if the local CS wants/has to retry.

Without recursion, the tasks of core CSes become much simpler as they only need to look up paths in their data base instead of having to communicate with other CSes and caching results.
The new system gives more control to non-core CSes.

Problems of the new system (no recursion)
I do understand these points, but I also see significant issues with the new system:

In the old system, core CSes only needed to communicate with other core CSes and CSes within their ISD; thus filtering based on the SCION paths (only single segment) and per-AS rate limiting was feasible. In the new system, the core CSes need to serve requests from all ASes, which makes them much more difficult to defend against (D)DoS attacks.
In several cases, latency of path lookups may increase substantially:

If the local CS doesn't have core-segments to the destination ISD cached, it needs to first fetch them from the local core CS before being able to contact the remote CS.
Remote down-segments are no longer cached at core CSes; thus the local CS always needs to contact the remote CSes (unless it has down-segments cached), which may cause much higher latency than a communication with the local core CS.

Options
In my opinion, we should choose either the old (recursive) or new (non-recursive) system and try to fix their respective shortcomings.
Concerning the old system:

I don't know too much about the difficulties of caching and cannot comment much on point 1.
A solution to point 2 could be to have separate requests for (i) only core- and (ii) both core- and down-segments; this would allow the local CS to obtain all possible segments but without causing redundant requests and information.
Point 3 is outweighed by point 5 in my opinion.
I don't see a good way of addressing point 4, but I also don't think it is too problematic.

Concerning the new system:

I am particularly worried about point 5, as this might cause severe availability issues, in particular as the core CSes no longer cache remote down-segments. Using DRKey as a "first line of defense" and per-AS or per-ISD rate limiting may still work, but cause quite some additional complexity and weaker guarantees. For example, per-ISD rate limiting would allow ASes to perform DoS attacks on other ASes within the same ISD.
Problem 6 could be addressed by longer caching times at non-core CSes or proactive requests for segments towards frequently used destinations.

One thing that is not mentioned yet:
Synchronizing down segments among the core ASes in the old system is very hard.
Essentially, you need to run a consens algorithm across ASes. Just running consensus between local services is hard enough, but ASes are operated by different entities, so it is even worse.
This was papered over in the previous version by constantly resyncing ALL the segments in the database, which is very suboptimal.

One thing that is not mentioned yet:
Synchronizing down segments among the core ASes in the old system is very hard.
Essentially, you need to run a consens algorithm across ASes. Just running consensus between local services is hard enough, but ASes are operated by different entities, so it is even worse.
This was papered over in the previous version by constantly resyncing ALL the segments in the database, which is very suboptimal.

Synchronizing down segments among the core ASes in the old system is very hard.

Right, this was already discussed in the original Issue #3731. From my point of view, abolishing the syncing system is not really disputed; instead, I'm more worried about the non-recursive path lookup (which is only partially related).

Synchronizing down segments among the core ASes in the old system is very hard.

Right, this was already discussed in the original Issue #3731. From my point of view, abolishing the syncing system is not really disputed; instead, I'm more worried about the non-recursive path lookup (which is only partially related).

TL;DR I'm not convinced that the problems you describe will actually turn out to be problems, at least not any time soon. Given the lack of evidence, I prefer the simpler system that is easier to implement and reason about over a (potentially) more performant and better defendable but more complex system.
Hi @mlegner. Thanks for your write up. I will try to respond to the raised points individually.

Caching of remote down-segments at core CSes is cumbersome and may cause issues.

Right. Each layer of caching introduces complexities. How long to retain segments? When to check for new segments? How to deal with stale paths, e.g., revoked paths. All of these points add complexity both for implementing and reasoning about the system. I'm not convinced that the gains in path lookup latency outweigh the added complexity, especially, since local CSes do in fact cache path segments.

Without the consistency among core CSes, the recursive lookup becomes somewhat problematic

It's again about added complexity for questionable gains (at least in terms of performance) as you argument yourself.

In several cases, latency of path lookups may increase substantially:

If the local CS doesn't have core-segments to the destination ISD cached, it needs to first fetch them from the local core CS before being able to contact the remote CS.
Remote down-segments are no longer cached at core CSes; thus the local CS always needs to contact the remote CSes (unless it has down-segments cached), which may cause much higher latency than a communication with the local core CS.

Both of these cases should be relatively rare overall, since there is one level of caching in the local CS. Besides, the latency difference between contacting a local core CS vs a remote CS might not be that large after all (depending of course on the geographic distribution of CSes and interconnections). In the end, I don't think it matters much if a single first path lookup takes 200ms instead of 10ms, because already the caching in the local CS will amortize this well enough. Of course, we cannot say this definitely, but without compelling evidence that this is a problem I prefer to err on the side of simplicity over premature optimization.

In the old system, core CSes only needed to communicate with other core CSes and CSes within their ISD; thus filtering based on the SCION paths (only single segment) and per-AS rate limiting was feasible. In the new system, the core CSes need to serve requests from all ASes, which makes them much more difficult to defend against (D)DoS attacks.

This seems to be your main concern about the new lookup strategy. I don't fully understand the filtering based on SCION path argument. Why does it matter that there is only a single segment? Regarding per-AS rate limiting, again we have no evidence that the increased number of source ASes will lead to problems. It's simply to early to tell. Again, my argument here is to err on the side of simplicity over premature optimization.

I am particularly worried about point 5, as this might cause severe availability issues, in particular as the core CSes no longer cache remote down-segments

I'm not convinced by this (as argued above). You'd need to elaborate a bit more on why you think this is the case and ideally have some data to back it up (maybe from simulations or related literature).

TL;DR I'm not convinced that the problems you describe will actually turn out to be problems, at least not any time soon. Given the lack of evidence, I prefer the simpler system that is easier to implement and reason about over a (potentially) more performant and better defendable but more complex system.
Hi @mlegner. Thanks for your write up. I will try to respond to the raised points individually.

Caching of remote down-segments at core CSes is cumbersome and may cause issues.

Right. Each layer of caching introduces complexities. How long to retain segments? When to check for new segments? How to deal with stale paths, e.g., revoked paths. All of these points add complexity both for implementing and reasoning about the system. I'm not convinced that the gains in path lookup latency outweigh the added complexity, especially, since local CSes do in fact cache path segments.

Without the consistency among core CSes, the recursive lookup becomes somewhat problematic

It's again about added complexity for questionable gains (at least in terms of performance) as you argument yourself.

In several cases, latency of path lookups may increase substantially:

If the local CS doesn't have core-segments to the destination ISD cached, it needs to first fetch them from the local core CS before being able to contact the remote CS.
Remote down-segments are no longer cached at core CSes; thus the local CS always needs to contact the remote CSes (unless it has down-segments cached), which may cause much higher latency than a communication with the local core CS.

Both of these cases should be relatively rare overall, since there is one level of caching in the local CS. Besides, the latency difference between contacting a local core CS vs a remote CS might not be that large after all (depending of course on the geographic distribution of CSes and interconnections). In the end, I don't think it matters much if a single first path lookup takes 200ms instead of 10ms, because already the caching in the local CS will amortize this well enough. Of course, we cannot say this definitely, but without compelling evidence that this is a problem I prefer to err on the side of simplicity over premature optimization.

In the old system, core CSes only needed to communicate with other core CSes and CSes within their ISD; thus filtering based on the SCION paths (only single segment) and per-AS rate limiting was feasible. In the new system, the core CSes need to serve requests from all ASes, which makes them much more difficult to defend against (D)DoS attacks.

This seems to be your main concern about the new lookup strategy. I don't fully understand the filtering based on SCION path argument. Why does it matter that there is only a single segment? Regarding per-AS rate limiting, again we have no evidence that the increased number of source ASes will lead to problems. It's simply to early to tell. Again, my argument here is to err on the side of simplicity over premature optimization.

I am particularly worried about point 5, as this might cause severe availability issues, in particular as the core CSes no longer cache remote down-segments

I'm not convinced by this (as argued above). You'd need to elaborate a bit more on why you think this is the case and ideally have some data to back it up (maybe from simulations or related literature).

Thank you for the feedback. It seems we agree with most points. Unfortunately it is a bit tricky to underpin all these points with real-world data as it is difficult to find datasets for the traffic distributions that we are interested in and to map them to SCION ISDs and ASes. Still, we will look into this to get some more confidence and to better assess the potential caching benefits etc.
As my point 5 seems to have been unclear, let me elaborate on that somewhat. For the following, I make the (conservative) assumption that we have 100k ASes, 100 ISDs, 10 core ASes per ISD, so 1k core ASes in total. (With full SCION deployment, the number of ASes would likely increase substantially.)
Old (recursive) lookup

A core CS receives path registrations from (i) non-core CSes in its own ISD and (ii) other core CSes.
A core CS receives (i) recursive path-lookup requests from non-core CSes in its own ISD and (ii) down-segment lookups from other core CSes.

For both registration and lookup, there is small set (around 2k on average) of allowed clients, which makes DDoS defenses much easier:

As a first line of defense, the CS can filter out all packets that use more than one path segment; this is possible as ASes within the same ISD only need an up-segment and other core ASes only need a core-segment.
The CS can keep persistent TLS or QUIC connections with all of those entities, employ rate limiting, etc.

New (non-recursive) lookup
While path registration remains unchanged, the lookup requests now can come from every CS anywhere in the Internet. Instead of 2k different clients, we now have 100k (and maybe 1M at some point in the future).
This makes DoS defenses more tricky: The simple path-based filtering doesn't work any more and also keeping persistent connections with all these CSes may not be practical. However, using authentication with DRKey as a first line of defense would still work. Rate-limiting probably still works as well but becomes more difficult due to the large number of potential clients.
The core CSes in the new lookup system are somewhat comparable to authoritative TLD name servers in their scope and the number of clients they have to handle. Still, there are a few reasons why the situation is worse for CSes:

Responses for path lookups are generally much larger than DNS replies and probably require a TCP/TLS/QUIC connection with additional overhead.
I would expect that increasing the number of CSes is more difficult than increasing the number of name servers as they need to be kept consistent and the set of path segments is much more dynamic than DNS entries.
If the CSes go down, everything goes down; for DNS this is at least somewhat less severe as the network's forwarding abilities themselves are not affected. (In the old system, if a core CS goes down, at least other core CSes would still have cached down-segments.)

Current situation
I fully understand that all the potential problems would only occur in a much larger system and are not relevant at the moment. Therefore, I agree that it makes sense to keep the simpler system in the current implementation. In the book, we could describe both variants and discuss their pros and cons. Then, at some point in the future, standardization efforts would need to revisit this decision.

Thank you for the feedback. It seems we agree with most points. Unfortunately it is a bit tricky to underpin all these points with real-world data as it is difficult to find datasets for the traffic distributions that we are interested in and to map them to SCION ISDs and ASes. Still, we will look into this to get some more confidence and to better assess the potential caching benefits etc.
As my point 5 seems to have been unclear, let me elaborate on that somewhat. For the following, I make the (conservative) assumption that we have 100k ASes, 100 ISDs, 10 core ASes per ISD, so 1k core ASes in total. (With full SCION deployment, the number of ASes would likely increase substantially.)
Old (recursive) lookup

A core CS receives path registrations from (i) non-core CSes in its own ISD and (ii) other core CSes.
A core CS receives (i) recursive path-lookup requests from non-core CSes in its own ISD and (ii) down-segment lookups from other core CSes.

For both registration and lookup, there is small set (around 2k on average) of allowed clients, which makes DDoS defenses much easier:

As a first line of defense, the CS can filter out all packets that use more than one path segment; this is possible as ASes within the same ISD only need an up-segment and other core ASes only need a core-segment.
The CS can keep persistent TLS or QUIC connections with all of those entities, employ rate limiting, etc.

New (non-recursive) lookup
While path registration remains unchanged, the lookup requests now can come from every CS anywhere in the Internet. Instead of 2k different clients, we now have 100k (and maybe 1M at some point in the future).
This makes DoS defenses more tricky: The simple path-based filtering doesn't work any more and also keeping persistent connections with all these CSes may not be practical. However, using authentication with DRKey as a first line of defense would still work. Rate-limiting probably still works as well but becomes more difficult due to the large number of potential clients.
The core CSes in the new lookup system are somewhat comparable to authoritative TLD name servers in their scope and the number of clients they have to handle. Still, there are a few reasons why the situation is worse for CSes:

Responses for path lookups are generally much larger than DNS replies and probably require a TCP/TLS/QUIC connection with additional overhead.
I would expect that increasing the number of CSes is more difficult than increasing the number of name servers as they need to be kept consistent and the set of path segments is much more dynamic than DNS entries.
If the CSes go down, everything goes down; for DNS this is at least somewhat less severe as the network's forwarding abilities themselves are not affected. (In the old system, if a core CS goes down, at least other core CSes would still have cached down-segments.)

Current situation
I fully understand that all the potential problems would only occur in a much larger system and are not relevant at the moment. Therefore, I agree that it makes sense to keep the simpler system in the current implementation. In the book, we could describe both variants and discuss their pros and cons. Then, at some point in the future, standardization efforts would need to revisit this decision.

I fully understand that all the potential problems would only occur in a much larger system and are not relevant at the moment. Therefore, I agree that it makes sense to keep the simpler system in the current implementation. In the book, we could describe both variants and discuss their pros and cons. Then, at some point in the future, standardization efforts would need to revisit this decision.

I think we can agree on that. Nobody really knows what the future will bring, however, we are not closing any door with the current approach. If it turns out that we'll need more levels of caching to be able to scale, we can add them - in a backwards-compatible way even. Your arguments about DDoS defense being more difficult if there is a larger potential set of sources intuitively makes sense, but no one can say at which point this would become a problem.
I propose that in the book we'll describe the currently implemented approach and have a section about the alternative with some of the tradeoffs you listed here. I do believe that before the SCION network becomes this large a standardization body would be addressing these questions and probably would have more insight and experience about the involved tradeoffs.

I fully understand that all the potential problems would only occur in a much larger system and are not relevant at the moment. Therefore, I agree that it makes sense to keep the simpler system in the current implementation. In the book, we could describe both variants and discuss their pros and cons. Then, at some point in the future, standardization efforts would need to revisit this decision.

I think we can agree on that. Nobody really knows what the future will bring, however, we are not closing any door with the current approach. If it turns out that we'll need more levels of caching to be able to scale, we can add them - in a backwards-compatible way even. Your arguments about DDoS defense being more difficult if there is a larger potential set of sources intuitively makes sense, but no one can say at which point this would become a problem.
I propose that in the book we'll describe the currently implemented approach and have a section about the alternative with some of the tradeoffs you listed here. I do believe that before the SCION network becomes this large a standardization body would be addressing these questions and probably would have more insight and experience about the involved tradeoffs.

That sounds like a good solution to me, thank you for the discussion. I will close this issue for now but will keep it in mind if anything changes in the future.

That sounds like a good solution to me, thank you for the discussion. I will close this issue for now but will keep it in mind if anything changes in the future.


apolipoprotein A-I , OMIM, and possible children

apolipoprotein A-I in orphanet (https://www.orpha.net/consor/cgi-bin/OC_Exp.php?lng=EN&Expert=425) references OMIM: 604091  and 618463, but MONDO_0011393 references only 604091
https://omim.org/entry/618463 is defined as HYPOALPHALIPOPROTEINEMIA, PRIMARY, 2 and https://omim.org/entry/604091 is defined as HYPOALPHALIPOPROTEINEMIA, PRIMARY, 1.
Should MONDO_0011393 be retained to represent the equivalent of ORPHA:425 ,
two new records be created for the MIM numbers and
604091 be removed from MONDO_0011393?

cc @kanems

@ana-rath-orphanet
Looks like Orphanet is xref'ing two OMIM terms as exact for Orphanet:425, but we think they should be NTBT instead:

OMIM:618463 (E (Exact mapping: the two concepts are equivalent))
OMIM:604091 (E (Exact mapping: the two concepts are equivalent))

Note to self:
we will create a new Mondo entry for a class that has mutations in both genes
It seems like there are 3 different diseases:

New class: Combined ApoA-I and ApoC-III Deficiency - where there is mutations in both genes (PMID: 3118360)
MONDO_0011393 rename to hypoalphalipoproteinemia, primary, 1, equiv to OMIM:604091 (gene variation in ABCA1)
MONDO_0032766 'hypoalphalipoproteinemia, primary, 2', equiv to OMIM:618463 (gene variation in APOA1)

Additionally, we will add a grouping class for these three terms that correspond to Orphanet:425 Apolipoprotein A-I deficiency (child of hypoalphalipoproteinemia). @ana-rath-orphanet Does this make sense to you?
@ahamosh would OMIM consider creating a new class too? (in 1 above, Combined ApoA-I and ApoC-III Deficiency)

Thanks @nicolevasilevsky - all the above looks good though now I'm wondering why the ORDO class isn't simply equivalent to OMIM:618463 based on the name?


[FEATURE] Token caching

Describe the feature
Use a cache for the authentication token. The tokens have different lifetimes depending on the account type.
It would be nice if restarting HA and/or the integration did not always result in retrieving a new token.
Account type

[ ] Installer
[ ] DIY / DHZ
[x] Home Owner (This integration is not (fully) functional with a home owner account!)

Envoy

[x] Metered with CTs installed

[ ] Metered without CTs

[ ] Standard

FW version: D7.6.175

Amount of micro inverters connected: 15

Home Assistant

Version: 2023.8.3

Hi @jsimonetti, this is already implemented. Do you see other behaviour?

Hi @vincentwolsink,
I do NOT explicitely see behaviour a cache is not used.
I did not find a cache option or log entry in my logs, nor did I see it mentioned in release notes, so I made the assumption that is was not implemented. (Initialising the integration took quite some time, which led me to think the token was retrieved every time).
Thank you for confirming it is implemented. If I happen to see behaviour that does not indicate caching, I will open a bug report.
Thank you for the work!


[release-1.7] Apply standard prom annotations in manual injection mode

This is an automated cherry-pick of #26589

ref: #26582


cannot import operations from compas.datastructures.mesh

cannot import operations from compas.datastructures.mesh
probably compas_fab version compatibility issue
Steps to reproduce the behavior:

Rhino 6, Grasshopper
See the image
See the image
cannot import operations from compas.datastructures.mesh

Windows 10
Python 3.7
conda

It looks like the problem is not there when the compas_fab=0.10.2 instead of compas_fab=0.10.2-c9793b32 (see the image)

it would make sense this is somehow related to compas_fab because i have checked release 0.13.3 and everything should be ok with the imports there...

I cannot reproduce the problem. I tested the exact same revisions mentioned in the issue, but it worked out fine. The only explanation I can think of is that maybe you had Rhino open and another version of COMPAS was already loaded in memory, when you updated to a different checkout the old version was still in memory and then the imports didn't match.
Since it seems to work for you, and I cannot reproduce, I will go ahead and close, but if you see this again, please re-open or open a new one.


Expose StreamSpan

Issue #, if available:
Description of changes:
In order to create a "build_app" function, it needs to see StreamSpan like so:
pub fn build_app() -> App<
    impl ServiceFactory<
        ServiceRequest,
        Config = (),
        Response = ServiceResponse<tracing_actix_web::StreamSpan<BoxBody>>,
        Error = actix_web::Error,
        InitError = (),
    >,
> { ... }

Thanks!


What's the best way of modelling changing volumes?

Hi there, I just started out with tellurium and it's looking great!
One thing I can't quite figure out though is how to best deal with changing compartment volumes. For example, if I wanted to simulate decreasing concentrations of my species due to dilution because of the compartment volume increasing, how would I best go about that? I know that there is the substanceOnly keyword and that I can define the volume with an assignment rule and time, but was wondering if there is a more canonical way to represent changing volumes. I couldn't really find anything tangible in the documentation. Any hints (or ideally a simple working example) would be greatly appreciated.
Thanks!

You can change a compartment volume just like you change any other variable!  Assignment rules, rate rules, and events all work.
In this particular case, it sounds like you probably want a rate rule.  In Antimony, that's just something like:
C' = 1.3
to indicate that dC/dt is 1.3  (any formula is fine there; it doesn't have to be a constant).
The deal with 'substanceOnly' is that normally, when a species ID ('X') shows up in math, that ID means 'the concentration of X'.  However, if you define X as a 'substanceOnly' species, that means that when it shows up in math, that ID means 'the amount of X'.  In a model with changing volumes, it's obviously very important to get this right ;-)  If, say, your reaction rates increase with an increase of the concentration of X, and your rate law is something like 'k1X', X should be a normal non-substance-only species.  If your rate law instead is "k1X/C', then that's when you want X to be the substanceOnly species.
Here's a simple worked example:
import tellurium as te

r = te.loada("""
   S1 -> S2; k1*S1;
   S1 = 10
   S1 in C1
   S2 in C1
   C1 = 1
   C1' = .4
   k1 = 0.4
   S2 = 0

""")

r.simulate()
r.plot()

In the plot, you can see both concentrations slowly go down in the end as the volume continues to increase.  If you were to plot S1 and S2 amounts, instead, you wouldn't see the decrease (but would still see the decrease in the rate at which S1 is converted to S2.

Ah, nice! I didn't realise that one can simply change the volume of a compartment in this way. This definitely makes the model definition more straightforward than my original approach. Thanks!

@julibeg Yes, compartment sizes can be changed dynamically.
Just be careful if you use other SBML tools beside tellurium/roadrunner for analysis. Many of them do not handle changing compartment volumes (e.g. AMICI and other tools for parameter fitting, JWS online, ...). If you only use roadrunner/tellurium for simulation (or COPASI) things will work fine.

You can change a compartment volume just like you change any other variable! Assignment rules, rate rules, and events all work.

@luciansmith sorry for being dense, but would you mind showing how you would use an Assignment Rule on a compartment? I tried to modify your snippet from above, but the below (and other variations) all didn't work
r = te.loada(
    """
    S1 -> S2; k1*S1;
    S1 = 10
    S1 in C1
    S2 in C1
    C1 := 1 + 0.4 * time
    k1 = 0.4
    """
)

print(r.simulate(0, 5, 6, selections=["time", "C1", "S1", "S2"]))
# this prints
#     time,  C1, S1, S2
#  [[    0,   1, -0, -0],
#   [    1, 1.4,  0,  0],
#   [    2, 1.8,  0,  0],
#   [    3, 2.2,  0,  0],
#   [    4, 2.6,  0,  0],
#   [    5,   3,  0,  0]]
# C1 increases, but S1 and S2 are 0

That's a bug!  Somehow tellurium is getting confused and thinking that S1 is initialized to 0.  You can work around the bug with by setting S1 back to 10 expliciitly, i.e.:
import tellurium as te
r = te.loada(
    """
    S1 -> S2; k1*S1;
    S1 = 10
    S1 in C1
    S2 in C1
    C1 := 1 + 0.4 * time
    k1 = 0.4
    """
)
r.S1 = 10
print(r.simulate(0, 5, 6, selections=["time", "C1", "S1", "S2"]))
'''

My guess is that something about putting 'time' into an assignment rule is causing an unexpected result. I'll look into it.


Feature request: show env in deployments

What would you like to be added:
Some sort of overview of a deployment's environment settings in the sidebar/summary screen.
Why is this needed:
One of the most common things I'm doing when viewing a deployment is to view or change environment variables. Currently, the only way I can find to do this is through the edit screen, which is somewhat clumsy - especially when only trying to view the data.
Ideally, there would be a UI similar to configMap/secret at least for viewing, if not directly editing. I understand this could get a bit complex for the various valueFrom environment providers, as well as the overall envFrom system so an initial version could certainly exclude those while still adding a lot of value.
Environment you are Lens application on:

Kubernetes distribution: GKE; K8S 1.14
Desktop OS: macOS 10.14

+1

+1

+1
I would hope that you'd be able to see the same info as (or more than) the kubectl describe command in the sidebar for any of the k8s objects.


feat(errors): use @adobe/ims-lib-core-errors for errors. fixes #79

Description
Remove all direct creation of Error objects in favor of staticlly defined errors using @adobe/aio-lib-core-errors
Related Issue
#79
Motivation and Context
Ensures that consumers of this library can properly differentiate errors.
How Has This Been Tested?
Unit tests
Screenshots (if appropriate):
Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[X] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

[X] I have signed the Adobe Open Source CLA.
[X] My code follows the code style of this project. (well, sort of... this PR is essentially changing the code style of this project but other than that it follows the general style)
[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[X] I have read the CONTRIBUTING document.
[X] I have added tests to cover my changes.
[X] All new and existing tests passed.

Great to get a PR that fast @justinedelson ! I'll ask @shazron to have a quick look into it.


[2.2.x backport] Fix service pipelines not picking up new jobs.

2.2 backport of #8050

Missed the release, will be in 2.3


Move LongPollingMockConsumer to main artefact

It's too difficult to use as test artefact.

Any update on this?
Having to copy paste this code in each project and maintain it is annoying. It would be great if clients could just depend on it.


Separate IO stuff from env.c

I think the event loop should be placed in rts.c and common io functions, like our kqueue and epoll wrapping functions should go in a common file, like rts/io.c
A module like net can import rts/io.c to gain access to relevant functions.
fd_data will need to become global I suppose.
There's some logic in the event loop itself that handles connection setup etc. That will need to be carved out into separate functions, eventually placed in the net module. The core event loop should just support registering events and getting callbacks pulled. All actual logic need to happen in those callbacks.
Makes me think about libuv again. Are we implementing the same thing that already exists?

Superseded by #691. Closing.


Remove reliance on {fake:true} constraint which is going away in Firefox 60.

Browsers and versions affected
Firefox 60+
Description
Remove reliance on non-spec {fake: true} getUserMedia constraint which is going away in Firefox 60.
See for example https://github.com/webrtc/apprtc/blob/master/src/app_engine/apprtc.py#L94
Please switch to setting the pref "media.navigator.streams.fake" to true".
Steps to reproduce
v.srcObject = await navigator.mediaDevices.getUserMedia({
  fake: true, video: true, audio: true
});

Expected results
Solid color video track and 1KHz sine wave.
Actual results
Real camera and microphone or  NotFoundError starting with Firefox 60 once bug 1436424 is fixed.

@KaptenJansson can you please take a look?

Yes will do.

Reassigning for FYI and possible delegation.

Make that 61.


Typeahead does not allow blur on select

I'm trying to configure my UI so that if a typeahead suggestion is selected, the UI automatically focuses the next field in the form. The behavior I'm seeing is that the next field is focused correctly, but then the typeahead field takes the focus back. It looks like the code that is causing this is:
$timeout(function() { element[0].focus(); }, 0, false);

It seems like this behavior should be optional. Thanks!

Just to verify, you don't want it to focus on the input element after blur with typeahead-select-on-blur="true"? The Plunker here displays this behavior currently.

I think my issue is not that the field is refocused on select, but that the refocus happens after the onSelectCallback() callback is called, so the refocus can't be prevented.
Maybe the onSelectCallback() callback could be called inside the $timeout callback just after the call to element[0].focus()?

In reality, it sounds like you want a way to cancel the focus - let me think on this a bit, not sure what the best way to approach this would be.


Registration

I am receiving the error "It was not possible to verify your email address. Please try again later" When trying to register.

This should be fixed now, apologies

Apologies?? No need! This is so awesome. About 10 years ago I made a drafting site for agot (using PHP), that worked with Chad’s program that he developed of the iPad. Then after a couple years of that FFG wrote a cease and desist. L
Thank yoU!
From: Stuart Walsh<EMAIL_ADDRESS>Sent: Tuesday, February 27, 2018 3:24 PM
To: cryogen/throneteki<EMAIL_ADDRESS>Cc: arcanjl69<EMAIL_ADDRESS>Author<EMAIL_ADDRESS>Subject: Re: [cryogen/throneteki] Registration (#1784)
This should be fixed now, apologies
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub https://github.com/cryogen/throneteki/issues/1784#issuecomment-369048357 , or mute the thread https://github.com/notifications/unsubscribe-auth/AjMSsvRuKl4OqAi5tuKNKWaQqjhIdOetks5tZIBygaJpZM4SVpwt .  https://github.com/notifications/beacon/AjMSspWx873qUlc6W_FOmVXosLDpWv2Wks5tZIBygaJpZM4SVpwt.gif


Override theme color for dark mode

Is your feature request related to a problem? Please describe.
The web manifest spec has a known limitation of lacking a way to define a different theme color for when a device is in Dark mode, what causes some weird color matching between app top content and android (e.g) status bar.
Describe the solution you'd like
It would be awesome if bubble wrap could provide a way to override the status bar color (or theme color) when the device is in Dark mode.
On the user side, probably adding a themeColorDark analogous to the existing navigationColorDark.
I'm assuming this should be doable on the generated android code.
Describe alternatives you've considered
There are a few ways to supposedly working around this, I could not have any of them to work. I'll briefly list them:

swapping between two different <meta name="theme-color" one for dark and one for light themes
skip defining a theme color in manifest so the system use the background color of the root element
somehow loading different manifest for depending on device theme

Hum, android-browser-helper does support it, but we have never added to TwaManifest. Can't remember if there's a reason why we didn't. To make this work, we'd need to:

Update TwaManifest to include a themeColorDark (setting defaults and handling manifests that don't yet have one)
Add the theme color to app/build.gradle on the template project, similar to this
Include the information on AndroidManifest.xml, similar to this

I may be forgetting something, but those should at least be the initial steps.

Just for the record, I was able to accomplish it with this hack:
function reflectColorScheme(scheme){
    // scheme = 'light', 'dark' or 'auto'

    // Hack found in https://stackoverflow.com/a/75124760
    for(var s = 0; s < document.styleSheets.length; s++)

        for(var i = 0; i < document.styleSheets[s].cssRules.length; i++) {
            const rule = document.styleSheets[s].cssRules[i];

            if(rule && rule.media && rule.media.mediaText.includes('prefers-color-scheme'))

                switch(scheme) {
                    case 'light':
                        rule.media.appendMedium('original-prefers-color-scheme');
                        if(rule.media.mediaText.includes('light')) rule.media.deleteMedium('(prefers-color-scheme: light)');
                        if(rule.media.mediaText.includes('dark')) rule.media.deleteMedium('(prefers-color-scheme: dark)');
                        break;
                    case 'dark':
                        rule.media.appendMedium('(prefers-color-scheme: light)');
                        rule.media.appendMedium('(prefers-color-scheme: dark)');
                        if(rule.media.mediaText.includes('original')) rule.media.deleteMedium('original-prefers-color-scheme');
                        break;
                    case 'auto':
                        rule.media.appendMedium('(prefers-color-scheme: dark)');
                        if(rule.media.mediaText.includes('light')) rule.media.deleteMedium('(prefers-color-scheme: light)');
                        if(rule.media.mediaText.includes('original')) rule.media.deleteMedium('original-prefers-color-scheme');
                        break;
                }
        }

    const previousMetas = document.querySelectorAll('meta[name="theme-color"]');

    if(scheme == 'light' || scheme == 'dark') {
        const meta = document.createElement('meta');
        meta.name = 'theme-color';
        meta.content = scheme == 'light' ? '#ffffff' : '#1f1f1f';
        document.head.appendChild(meta);
    }
    else{
        const meta = document.createElement('meta');
        meta.name = 'theme-color';
        meta.content = '#1f1f1f';
        meta.media = '(prefers-color-scheme: dark)';
        document.head.appendChild(meta);

        const m2 = document.createElement('meta');
        m2.name = 'theme-color';
        m2.content = '#ffffff';
        m2.media = '(prefers-color-scheme: light)';
        document.head.appendChild(m2);
    }

    previousMetas.forEach(n => n.remove());
}


Rebase on top of 1.8 k8s

Rebase on top of 1.8 k8s to make service catalog api depend on k8s.io/api e.g. use k8s.io/api/v1 instead of k8s.io/client-go/pkg/api/v1.
This issue blocks https://github.com/kubernetes-incubator/service-catalog/pull/1208 due to the reason mentioned in https://github.com/kubernetes-incubator/service-catalog/pull/1208#issue-256142352.

Closing in favor of #1334.
I will rebase #1208 soon :)

@mengqiy Oops sorry missed this issue :)


EID BE 4.1.11

Changes to a cask
Editing an existing cask

[x] Commit message includes cask’s name (and new version, if applicable).
[ ] brew cask audit --download {{cask_file}} is error-free.
[ ] brew cask style --fix {{cask_file}} left no offenses.

Haven't been able to check the uninstall behaviour yet.

There are three packages:

beid "middleware" (the driver + PKCS lib)
beid "viewer": a java desktop GUI app that allows you to get information from a card, print out the contents, change the PIN etc
beid "QuickInstaller", which wraps those two packages in one installer and adds a GUI installer.

The old package only packaged the middleware. This Pull Request seems to package the QuickInstaller. My personal opinion is that there should be 2 casks: one for the middleware, another one for the GUI java app.

@fanquake How’s progress on this?

I wanted to give this a go, have a free day tomorrow and might get around to doing it.
Will create 2 seperate casks (beid-viewer & beid-middleware) and submit a PR.

@thibmaek I ask you to keep the eid-be nomenclature. You may add the viewer and middleware as suffixes.
A couple of questions, though:

Would it not be possible to just have the quickinstaller, since that seems to encapsulate the other two?
Does the viewer require the middleware to function?

@vitorgalvao oh yeah sure I was confused with how they named their packages instead of these cask names. While the quickinstaller suffices for most people, I and some others I know require only the middleware. The middleware is the only essential part in making belgian eid applications work, the viewer is just an extra to display information already on your card in digital form.
The viewer requires the middleware to function, the middleware packs the drivers etc.

The viewer requires the middleware to function

In that case, be sure to add a depends_on cask: to the viewer.

Closing in favour of https://github.com/caskroom/homebrew-eid/pull/16.

@thibmaek Thanks for cleaning this up 👍


[3.0] Godot wont run, Error: Could not obtain an OpenGL 3.3 context

Operating system or device - Godot version:
Linux Ubuntu 16.04 64 bits Godot 3.0 master commit edacc986d6bd14602e32e0fba95a6bb1738b423b
Issue description:
godot master was working yesterday,
after updating Godot with a git pull, compile and try to open godot, I get the following errors:
ERROR: initialize: Could not obtain an OpenGL 3.3 context!
At: platform/x11/context_gl_x11.cpp:149.
ERROR: set_custom_property_info: Condition ' !props.has(p_prop) ' is true.
At: core/project_settings.cpp:841.
ERROR: set_custom_property_info: Condition ' !props.has(p_prop) ' is true.
At: core/project_settings.cpp:841.
ERROR: initialize: Error initializing GLAD
At: drivers/gles3/rasterizer_gles3.cpp:163.
Segment violation
Steps to reproduce:
git pull origin master
scons platform=x11 bits=64 -j 4
bin/./godot.x11.tools.64
UPDATE:
Could this be realted to me removing some unused i386 versions of the libraries?, like:
libxrender1:i386
libxrandr2:i386
libfreetype6:i386

That's weird. Does it work again if you revert f5277e347df4228fc875acaa3acb9581a30ab43e ?

Tried reinstalling the i386 versions, and recompiling with scons, but getting the same errors,
Im gonna try reverting to commit f5277e347df4228fc875acaa3acb9581a30ab43e as @akien-mga says

@akien-mga same errors after compiling in f5277e347df4228fc875acaa3acb9581a30ab43e
Im doing a compile from zero starting with a clean
git clone https://github.com/godotengine/godot

I meant reverting that commit, not reverting to it. Alternatively, checkout the previous one: d2d48e2a7a7ed04331597bcfd7b6c719da2b67c3

Tried a clean check out and a checkout to d2d48e2a7a7ed04331597bcfd7b6c719da2b67c3
in both cases got the errors when runing godot:
ERROR: initialize: Could not obtain an OpenGL 3.3 context!
At: platform/x11/context_gl_x11.cpp:149.
ERROR: set_custom_property_info: Condition ' !props.has(p_prop) ' is true.
At: core/project_settings.cpp:841.
ERROR: set_custom_property_info: Condition ' !props.has(p_prop) ' is true.
At: core/project_settings.cpp:841.
ERROR: initialize: Error initializing GLAD
At: drivers/gles3/rasterizer_gles3.cpp:163.

Thanks. Do you remember when you last compiled it and got it working? Also, did something change on your system? (graphic drivers update for example?)

Thank @akien-mga
My last compilation was yesterday morning, 24Hrs ago aprox. not sure about the exact commit, today I did apt-get update, apt-get upgrade (but also did it yesterday). Yesterday godot was working but the "ice" PBR material on the new demo was not working, like everyone else
wich commit from the last 48 to 24hrs did you recomment to do some testing?

@akien-mga
I purged and reinstalled the graphics drivers, and no more GLES errors, godot master is working
Im so, sorry for the trouble, the rest of the applications and desktop was working O.K.
please close this report, and thank you for your help

Good news :)


Fractal crashes when displaying inline video

Describe the bug
Fractal crashes on opening a chat with an embedded video( or some other form of gstreamer thingy?).
To Reproduce
Steps to reproduce the behavior:

Get fractal nix-shell -p fractal
Start fractal fractal
(optional) create account and login.
Open a channel with an embedded video. (I tried the fractal channel #fractal-gtk:matrix.org)
See a few messages getting rendered, right before the crash. (This last step takes about 2 seconds)

Expected behavior
The channel's contents are displayed. The application does not crash.
Screenshots Output
% nix-shell -p fractal

[nix-shell:~/src/nixpkgs]$ RUST_BACKTRACE=1 fractal
thread 'main' panicked at 'Missing dependency: element gtksink is needed (usually, in gstreamer-plugins-good or in gst-plugin-gtk).: BoolError { message: "Failed to create element from factory name", filename: "/build/fractal-4.4.0-vendor.tar.gz/gstreamer/src/auto/element_factory.rs", function: "gstreamer::auto::element_factory", line: 184 }', fractal-gtk/src/widgets/inline_player.rs:249:20
stack backtrace:
   0: <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt
   1: core::fmt::write
   2: std::io::Write::write_fmt
   3: std::panicking::default_hook::{{closure}}
   4: std::panicking::default_hook
   5: std::panicking::rust_panic_with_hook
   6: rust_begin_unwind
   7: core::panicking::panic_fmt
   8: core::result::unwrap_failed
   9: fractal_gtk::widgets::inline_player::VideoPlayerWidget::new
  10: fractal_gtk::widgets::message::MessageBox::build_room_msg_body_bx
  11: fractal_gtk::widgets::message::MessageBox::widget
  12: fractal_gtk::widgets::message::MessageBox::create
  13: fractal_gtk::widgets::room_history::create_row
  14: glib::source::trampoline
  15: g_main_context_dispatch
  16: g_main_context_iterate.isra.0
  17: g_main_context_iteration
  18: g_application_run
  19: <O as gio::application::ApplicationExtManual>::run
  20: fractal_gtk::main
  21: std::rt::lang_start::{{closure}}
  22: std::rt::lang_start_internal
  23: main
  24: __libc_start_main
  25: _start
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
Aborted (core dumped)

Additional context
I tried adding gst-plugins-good as the output suggests, but had no luck.
diff --git a/pkgs/applications/networking/instant-messengers/fractal/default.nix b/pkgs/applications/networking/instant-messengers/fractal/default.nix
index 2abd733b277..f36a51a800f 100644
--- a/pkgs/applications/networking/instant-messengers/fractal/default.nix
+++ b/pkgs/applications/networking/instant-messengers/fractal/default.nix
@@ -59,6 +59,7 @@ rustPlatform.buildRustPackage rec {
     gst_all_1.gst-editing-services
     gst_all_1.gst-plugins-bad
     gst_all_1.gst-plugins-base
+    gst_all_1.gst-plugins-good
     gst_all_1.gstreamer
     gst_all_1.gst-validate
     gtk3

Notify maintainers
@dtzWill @worldofpeace @jtojnar
Metadata
% nix-shell -p nix-info --run "nix-info -m"
 - system: `"x86_64-linux"`
 - host os: `Linux 5.4.59-hardened, NixOS, 20.09.git.c59ea8b8a0eM (Nightingale)`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.3.7`
 - channels(root): `"nixos-20.09pre239318.c59ea8b8a0e"`
 - channels(user): `""`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixos`

Maintainer information:
# a list of nixpkgs attributes affected by the problem
attribute: pkgs.fractal
# a list of nixos modules affected by the problem
module:

gtksink is not build by default, you would need
(gst-plugins-good.override {
  gtkSupport = true;
})

The suggested fix works for me. :tada:
I created a PR so in the future installing fractal just works out of the box.


Fix pointer types and use std::mem on std::tx

std::tx uses u32s for pointers while it should use u64.
It could also use the new std::mem to simplify things. (https://github.com/FuelLabs/sway/pull/1928#discussion_r899366977)

https://github.com/FuelLabs/fuel-specs/pull/353/files will also help make std::tx a lot cleaner I believe.


Docs: Open in colab button and better accesible `html' quickstart

Description
Adds Open in Colab button at the top of each notebook-generated docs page. We still need to review the Setup section of each notebooks to add context about new deployment types and normalize everything. This would actually add the button to deep-dives or other notebooks but I think is more a feature than a bug as people can follow through by running code cells.
Closes #2162
Type of change

[x] New feature (non-breaking change which adds functionality)
[x] Documentation update

How Has This Been Tested
Please describe the tests that you ran to verify your changes. And ideally reference tests.

[x] Tested locally with autobuild sphinx docs

@davidberenstein1957 finally my robot friend was talking shit, it should be as simple as this. We can do the same with a Jupyter badge pointing to the ipynb, and some other crazy ideas that come to mind like linking to a live dataset inside a deployed Argilla instance (might involve mapping dataset names with file names, but why not 🥸 )

@dvsrepo I corrected the Open in Colab Button and added a Source.ipynb button. Also, I restructured the docs section w.r.t. quickstart and deployments. I am not sure if this is clearer, but perhaps you have some more ideas. https://docs.argilla.io/en/docs-open_in_colab_button/

I want to remove Setup and installation, and just use the "deploy" and "configure"

@leiyre we need some quick css position adjustments for two new buttons that will appear on top of tutorials and guides.
For mobile they overlap with slack and stars so we can add more space on top of the buttons (or maybe hide them all together as they're not very useful @davidberenstein1957 what do you think?)

For desktop, at least some more space and maybe align them to the right? If we align them to the right there's the dark mode button too we need to take into account.
The html mark-up is on the prolog section of the conf.py file.
Here's the link to docs for this branch: https://docs.argilla.io/en/docs-open_in_colab_button/tutorials/notebooks/template.html
Can be done on Monday to finish this issue


where is the documentation?

where is the documentation?
where is the documentation?
where is the documentation?
where is the documentation?

for the most part, see http://box2d.org/documentation.html
the README explains some of the differences.


[BUG] Can't connect to database

Describe the bug
I'm trying to connect to the database, but I always get the following error:

When I run the docker ps command known as webserver_database it is always restarting, with exit code 1:

which Branch / PHP Version are you using ?
php56
To Reproduce
Steps to reproduce the behavior:
git clone https://github.com/sprintcube/docker-compose-lamp.git
change .env file
PHPVERSION=php56
See error

Expected behavior
I expect to connect to the DB
Screenshots
(see descrition)
Desktop (please complete the following information):

OS: Windows [WSL2 Ubuntu20.04]
Browser Chrome
Docker Version:

docker -v
Docker version 19.03.8, build afacb8b7f0

Hi @Kasui92 If i remember correctly, this sounds familiar to me. There was something with ubuntu and WSL. I try to search for it in the closed issues.

Can you post us the error logs of the mysql container please ?
Also please take a look at this issues, please note that the mentioned docker-compose file looks a little bit different back then, but in general you could give it a shot.
#67
#41

I got the same problems some days ago.  I'm using WSL2 Ubuntu 20.04, too.
I got the problems with mysql, and later some problems with wordpress while "uploading" plugins.
I figured out that its a problem with the /mnt permissions.
I followed this description and remounted the volume with DrvFs to solve my problem.
#41  seems to follow the same approach.

Hi everyone,
I really thank you in advance for your answers!
I had already seen those issues and adopted the solutions, but without success. The error I kept getting was the following.

However, following the advice of @Egahras and remounting the volume, it seems to have worked properly and now I no longer receive that error.
Thanks again to everyone for the excellent support!


Release 1.18.4

This is a draft of changelog for the 1.18.4 release.
Here you can find all related translations changes: 1.18.3...master.

⚠ Do not merge this pull request manually ⚠
You should approve this pull request instead. After approving, I will automatically update it (release date needs to be adjusted), merge, and tag a new release. You can read more about the process on forum.

Show release notes preview
1.18.4

Perubahan umum:

Memperbarui terjemahan untuk Flarum core.

Terjemahan terbaru untuk ekstensi:

acpl/flarum-lscache
akr/chevereto
askvortsov/flarum-auto-moderator
askvortsov/flarum-categories
askvortsov/flarum-discussion-templates
blomstra/flag-duplicates
blomstra/sort-order-toggle
clarkwinkelmann/flarum-ext-anonymous-posting
clarkwinkelmann/flarum-ext-author-change
clarkwinkelmann/flarum-ext-email-whitelist
clarkwinkelmann/flarum-ext-external-email-validation
clarkwinkelmann/flarum-ext-formatted-banner
clarkwinkelmann/flarum-ext-group-list
clarkwinkelmann/flarum-ext-username-blacklist
dalez/flarum-msemoji
dalez/flarum-twemoji
danirod/flarum-plausible
datitisev/flarum-maintenance
datitisev/flarum-webhooks-pro
datlechin/flarum-chatgpt
datlechin/flarum-pronouns
davwheat/virtual-authors
flamarkt/taxonomies
flarum/flags
flarum/suspend
fof/anti-spam
fof/best-answer
fof/cookie-consent
fof/discussion-thumbnail
fof/follow-tags
fof/gamification
fof/mason
fof/pages
fof/polls
fof/recaptcha
fof/sentry
fof/stopforumspam
fof/subscribed
fof/upload
ianm/follow-users
ianm/html-head
ianm/syndication
ianm/twofactor
jeromegillard/map
justoverclock/flarum-ext-newsfeed
justoverclock/steam-api
justoverclock/flarum-ext-toastme
kilowhat/flarum-ext-formulaire
kilowhat/flarum-ext-rich-embeds
kilowhat/flarum-ext-wordpress
litalino/flarum-geo-weather-widget
madeyedeer/avatar-tools
malago/flarum-achievements
migratetoflarum/canonical
muhammedsaidckr/flarum-gemini
nearata/flarum-ext-dsts
nearata/flarum-ext-twofactor
sycho/flarum-advanced-extension-categories
sycho/flarum-profile-cover
the-turk/flarum-mathren
the-turk/flarum-nodp
v17development/flarum-blog
v17development/flarum-user-badges
xsoft-ict/mason-tag
yippy/flarum-ext-auth-ldap

Semua perubahan: 1.18.3...1.18.4.

Success! Now you can announce new release on forum:
## Versi [`1.18.4`](https://github.com/flarum-lang/indonesian/releases/tag/1.18.4)

**Perubahan umum**:

* Memperbarui terjemahan untuk Flarum core.

**Terjemahan terbaru untuk ekstensi**:

* [`acpl/flarum-lscache`](https://github.com/android-com-pl/flarum-lscache)
* [`akr/chevereto`](https://github.com/AKR-Developers/flarum-chevereto)
* [`askvortsov/flarum-auto-moderator`](https://github.com/askvortsov1/flarum-automod)
* [`askvortsov/flarum-categories`](https://github.com/askvortsov1/flarum-categories)
* [`askvortsov/flarum-discussion-templates`](https://github.com/askvortsov1/flarum-discussion-templates)
* [`blomstra/flag-duplicates`](https://github.com/blomstra/flarum-ext-flag-duplicate)
* [`blomstra/sort-order-toggle`](https://github.com/blomstra/flarum-ext-sort-order-toggle)
* [`clarkwinkelmann/flarum-ext-anonymous-posting`](https://github.com/clarkwinkelmann/flarum-ext-anonymous-posting)
* [`clarkwinkelmann/flarum-ext-author-change`](https://github.com/clarkwinkelmann/flarum-ext-author-change)
* [`clarkwinkelmann/flarum-ext-email-whitelist`](https://github.com/clarkwinkelmann/flarum-ext-email-whitelist)
* [`clarkwinkelmann/flarum-ext-external-email-validation`](https://github.com/clarkwinkelmann/flarum-ext-external-email-validation)
* [`clarkwinkelmann/flarum-ext-formatted-banner`](https://github.com/clarkwinkelmann/flarum-ext-formatted-banner)
* [`clarkwinkelmann/flarum-ext-group-list`](https://github.com/clarkwinkelmann/flarum-ext-group-list)
* [`clarkwinkelmann/flarum-ext-username-blacklist`](https://github.com/clarkwinkelmann/flarum-ext-username-blacklist)
* [`dalez/flarum-msemoji`](https://github.com/DellZHackintosh/flarum-msemoji)
* [`dalez/flarum-twemoji`](https://github.com/DellZHackintosh/flarum-twemoji)
* [`danirod/flarum-plausible`](https://github.com/danirod/flarum-plausible)
* [`datitisev/flarum-maintenance`](https://flarum.org/extension/datitisev/flarum-maintenance)
* [`datitisev/flarum-webhooks-pro`](https://flarum.org/extension/datitisev/flarum-webhooks-pro)
* [`datlechin/flarum-chatgpt`](https://github.com/datlechin/flarum-chatgpt)
* [`datlechin/flarum-pronouns`](https://github.com/datlechin/flarum-pronouns)
* [`davwheat/virtual-authors`](https://flarum.org/extension/davwheat/virtual-authors)
* [`flamarkt/taxonomies`](https://github.com/flamarkt/taxonomies)
* [`flarum/flags`](https://github.com/flarum/flags)
* [`flarum/suspend`](https://github.com/flarum/suspend)
* [`fof/anti-spam`](https://github.com/FriendsOfFlarum/anti-spam)
* [`fof/best-answer`](https://github.com/FriendsOfFlarum/best-answer)
* [`fof/cookie-consent`](https://github.com/FriendsOfFlarum/cookie-consent)
* [`fof/discussion-thumbnail`](https://github.com/FriendsOfFlarum/discussion-thumbnail)
* [`fof/follow-tags`](https://github.com/FriendsOfFlarum/follow-tags)
* [`fof/gamification`](https://github.com/FriendsOfFlarum/gamification)
* [`fof/mason`](https://github.com/FriendsOfFlarum/mason)
* [`fof/pages`](https://github.com/FriendsOfFlarum/pages)
* [`fof/polls`](https://github.com/FriendsOfFlarum/polls)
* [`fof/recaptcha`](https://github.com/FriendsOfFlarum/recaptcha)
* [`fof/sentry`](https://github.com/FriendsOfFlarum/sentry)
* [`fof/stopforumspam`](https://github.com/FriendsOfFlarum/stopforumspam)
* [`fof/subscribed`](https://github.com/FriendsOfFlarum/subscribed)
* [`fof/upload`](https://github.com/FriendsOfFlarum/upload)
* [`ianm/follow-users`](https://github.com/imorland/follow-users)
* [`ianm/html-head`](https://github.com/imorland/html-head)
* [`ianm/syndication`](https://github.com/imorland/syndication)
* [`ianm/twofactor`](https://github.com/imorland/flarum-ext-twofactor)
* [`jeromegillard/map`](https://github.com/JeromeGillard/flarum-map)
* [`justoverclock/flarum-ext-newsfeed`](https://github.com/justoverclockl/flarum-ext-newsfeed)
* [`justoverclock/steam-api`](https://flarum.org/extension/justoverclock/steam-api)
* [`justoverclock/flarum-ext-toastme`](https://github.com/justoverclockl/flarum-ext-toastme)
* [`kilowhat/flarum-ext-formulaire`](https://flarum.org/extension/kilowhat/flarum-ext-formulaire)
* [`kilowhat/flarum-ext-rich-embeds`](https://flarum.org/extension/kilowhat/flarum-ext-rich-embeds)
* [`kilowhat/flarum-ext-wordpress`](https://flarum.org/extension/kilowhat/flarum-ext-wordpress)
* [`litalino/flarum-geo-weather-widget`](https://github.com/Litalino/flarum-geo-weather-widget)
* [`madeyedeer/avatar-tools`](https://github.com/MadEyeDeer/avatar-tools)
* [`malago/flarum-achievements`](https://github.com/malago86/flarum-achievements)
* [`migratetoflarum/canonical`](https://github.com/migratetoflarum/canonical)
* [`muhammedsaidckr/flarum-gemini`](https://github.com/muhammedsaidckr/flarum-gemini)
* [`nearata/flarum-ext-dsts`](https://github.com/Nearata/flarum-ext-dsts)
* [`nearata/flarum-ext-twofactor`](https://github.com/Nearata/flarum-ext-twofactor)
* [`sycho/flarum-advanced-extension-categories`](https://github.com/SychO9/flarum-advanced-extension-categories)
* [`sycho/flarum-profile-cover`](https://github.com/SychO9/flarum-profile-cover)
* [`the-turk/flarum-mathren`](https://github.com/the-turk/flarum-mathren)
* [`the-turk/flarum-nodp`](https://github.com/the-turk/flarum-nodp)
* [`v17development/flarum-blog`](https://github.com/v17development/flarum-blog)
* [`v17development/flarum-user-badges`](https://github.com/v17development/flarum-user-badges)
* [`xsoft-ict/mason-tag`](https://github.com/xsoft-ict/fof-mason-tag)
* [`yippy/flarum-ext-auth-ldap`](https://github.com/Yippy/flarum-ext-auth-ldap)

Semua perubahan: [1.18.3...1.18.4](https://github.com/flarum-lang/indonesian/compare/1.18.3...1.18.4).

Untuk memperbarui, jalankan perintah ini:

```console
composer update flarum-lang/indonesian
php flarum cache:clear
```


CONFIG_BT_ACL_CONNECTIONS cannot be set to 1 when using SPP (Classic) (IDFGH-8360)

Answers checklist.

[X] I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
[X] I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
[X] I have searched the issue tracker for a similar issue and not found a similar issue.

General issue report
I need to prevent our companies interface from allowing more than one SPP connection at a time. When I set CONFIG_BT_ACL_CONNECTIONS to 1, It allows us to connect one time only. IE: If we connect then disconnect, the interface has to be reset before we can connect again.  A strange message appears in the log on this second connect attempt:
BT_BTM: btm_sec_l2cap_access_req() PSM: 3 no application registerd
We are using legacy paring if that makes any difference.
ESP32-MINI-01
4.4.2 framework
Regards,
Travis
TTS Inc.

Hi @travis012,
Thanks for your report! CONFIG_BT_ACL_CONNECTIONS  in host means the number of L2CAP connection. Before the start of SPP connection, the host will initiate an SDP connection to check if the peer device has SPP service.
If you want to implement the functionality of I need to prevent our companies interface from allowing more than one SPP connection at a time. . There are two ways:

Set the BTDM_CTRL_BR_EDR_MAX_ACL_CONN to 1 which is located in the configuration of Bluetooth controller.
Call the function esp_bt_gap_set_scan_mode(ESP_BT_NON_CONNECTABLE, ESP_BT_NON_DISCOVERABLE); once the SPP connection is established.

Excellent!  Thank you very much for your quick response and clarification.  This solved my problem.
For clarification to others that might read this:
I was setting Bluedroid Option->BT/BLE MAX ACL Connections to 1
The correct config item is Bluetooth Controller->BR/EDR Max ACL Connections


Changed the color theme for the contact us form

Related Issue
Closes: #1364

Description

Changed the color theme for the contact us form heading and made it match with the color theme of the website.
Hope this solves the issue.
Looking forward for merging this PR.
Screenshots

Updated ScreenShot:

Checklist

[x ] My code adheres to the established style guidelines of the project.
[ x] I have included comments in areas that may be difficult to understand.
[ x] My changes have not introduced any new warnings.
[ x] I have conducted a self-review of my code.

Hey @akshitagupta15june can you please review my PR and can please merge it. :)

Not required


Fix Error Formatting Issue

So at the moment, when there is a validation error, it only outputs the stack trace, and not the actual error message. Simple reproduction:
const webpack = require('webpack')
webpack({ foo: 'bar' })

If you run this, you'll see that the stack trace shows up, but not the actual error message, which is pretty unfortunate.
[...]/webpack/lib/webpack.js:19
		throw new WebpackOptionsValidationError(webpackOptionsValidationErrors);
		^

Error
    at webpack ([..]/webpack/lib/webpack.js:19:9)
    at Object.<anonymous> ([...]/test.js:3:1)
    at Module._compile (module.js:571:32)
    at Object.Module._extensions..js (module.js:580:10)
    at Module.load (module.js:488:32)
    at tryModuleLoad (module.js:447:12)
    at Function.Module._load (module.js:439:3)
    at Module.runMain (module.js:605:10)
    at run (bootstrap_node.js:418:7)
    at startup (bootstrap_node.js:139:9)

I messed around with this for a while and was rather confused about why it happens, and finally stumbled across the answer. Basically, when you call Error.captureStackTrace, it not only captures and sets the MyError.stack property, it also messed with the error message a bit.

"The first line of the trace, instead of being prefixed with ErrorType: message, will be the result of calling targetObject.toString()."
-- The Docs

It does this immediately upon being called, so in this instance, it was calling toString on the instance before the error message was set, and therefore setting the error message to blank, leaving only the stack trace to show up when the error is thrown.
The fix here is simply moving it down to the bottom of the constructor, where it will run after the error message has been set. When I tested this, the error message was logged out correctly as expected 🙌

can you tell me what node version you are running?
I saw this quite a lot here in the issues but cant reproduce.
Also i think i read somewhere mentioning that you can skip the Error.captureStackTrace entirely as this is now default anyways, can you verify that? Just omitting these lines?

Running node v7 over here. I did try removing captureStackTrace entirely but the result wasn't as good. The error message still contained a stack trace, but there was no .stack property, and the relative paths to the affected files weren't as accurate.

can you explain: "weren't as accurate"?

Sure -- they referenced the path to the file where the error occurred relative to the file throwing the error, which was in webpack/lib, instead of relative to the place that the error was ultimately thrown.

@jescalan Thanks for your investigation. The same construct is used very often in other Errors too. Would you like to fix these Errors too?
https://github.com/webpack/webpack/search?utf8=✓&q=captureStackTrace

@sokra You are welcome, thanks for making webpack! It is a fantastic project, hoping I will be able to give back more as contributions in the future. I'll definitely fix this in the rest of the places I can find it.

Hi! Ok so I changed over the rest of the errors in the source, they should now all be working correctly.
I also noticed that some of the errors had a check to see if Error.captureStackTrace was supported. According to my research, this method has been supported since at least node 0.10.x, so I think we should be quite safe assuming it's supported with webpack2's minimum version, which, if I'm not mistaken, is 4.x. On top of that, some errors had this check and others didn't. So I removed all these checks as well for consistency.
Let me know if there's anything else I can help out with here!

Ok found a couple more that slipped by the first time somehow. Want me to squash these before merge?

it should fix https://github.com/webpack/webpack/issues/3522 as well right?

It definitely seems like it to me, although the way the issue was written isn't 100% clear to me!

Thanks


Release 0.1.7

@tomaszdurka wdyt?

lgtm

As you can see there is no travis with automatic release on tag here. Need to manually npm publish.


Editor help is broken

Godot version:
3.0 (d81bd965b)
OS/device including version:
Windows 10, 64-bits
Issue description:
The editor help font is wrong in the list of items. The method description section disappeared. Seems like a recent issue, only noticed it yesterday.

Steps to reproduce:

Open the help page for some class.

CC @poke1024, sounds like a regression from #14692.

Fixed by #14814.


Filter Operation with "in" operator overwrites .Id property on manipulated object

I have just found that the Filter() function will drop and replace the .Id property of all rows in the Table with a sequentially-assigned whole number (1, 2, 3, etc.) if the Filter function includes an In operator.

This behavior may be specific to the context where I have implemented my code: I am writing the PFX in a Custom Page in a Dataverse Model Driven App, using Dataverse as my datasource (hence, my Ids are all GUIDs to begin).

I was not able to replicate this scenario. Can you share more details?

Sure, so first, the datasource is a custom dataverse table [ 'Tags' ] and the "Valid For" column is a Multiselect Optionset from Dataverse. In PowerFx, the value of this column presents as a table, which is why I need to use the "in" operator to check for the presence of an expected value [ 'Valid For (Tags)'.Opportunity ].
My actual use case is another nested filter deep, but it isn't relevant to the issue I am observing. I only bring that up to explain that even three or four nested filters deep, the .Id property normally persists as a GUID: it is only once I apply a Filter using the " in " operation that the .Id property is replaced with a sequentially assigned whole number (1, 2, 3, etc.).
Now, ordinarily this is not much of an issue (the .Id property is quite optional which is probably why this has not been reported before) but I am then using this content inside a custom code component where it is important for me to be able to initiate WebAPI operations on these rows, and without a GUID that becomes a headache. There is an easy enough workaround (just include the id attribute as a column in the Items input) but I would venture that workaround shouldn't be necessary, as the .Id property should be persistent no matter the filter operation.
If it helps for quick repro, I can add you as a guest user in my Tenant so you can directly observe it.


Update links to the correct repo org

I feel like this repo should really live under @bolshakov's namespace. It's not associated with OrgSync or Campus Labs anymore.

Yeah, I agree!

@tasomaniac thank you for pointing out the problem! As @tfausak suggested, I moved the repo. I'll update links and other things by myself later this weekend.


Support Manual approval notification

Hi! what do you think about the support of codepipeline-pipeline-manual-approval-needed event type? In this way can be notified about approval needed. I'm available to code this part.
Let me know
cheers

I believe we already support this through the event_type_ids attribute. See the PR introducing this change for exactly this purpose: https://github.com/kjagiello/terraform-aws-codepipeline-slack-notifications/pull/9

looking at the lambda code and the README I don't see support for this event :(

This should work:
module "codepipeline_notifications" {
  source  = "kjagiello/codepipeline-slack-notifications/aws"
  version = "1.1.3"

  name          = "codepipeline-notifications"
  namespace     = "kjagiello"
  stage         = "sandbox"
  slack_url     = "https://hooks.slack.com/services/(...)"
  slack_channel = "#notifications"
  event_type_ids = [
    "codepipeline-pipeline-pipeline-execution-failed",
    "codepipeline-pipeline-pipeline-execution-canceled",
    "codepipeline-pipeline-pipeline-execution-started",
    "codepipeline-pipeline-pipeline-execution-resumed",
    "codepipeline-pipeline-pipeline-execution-succeeded",
    "codepipeline-pipeline-pipeline-execution-superseded",

    # Manual approvals
    "codepipeline-pipeline-manual-approval-needed",
  ]
  codepipelines = [
    aws_codepipeline.example,
  ]
}

The function code should be change because the approval event is a little bit different:
{
    "Records": [
        {
            "EventVersion": "1.0",
            "EventSubscriptionArn": "arn:aws:sns:eu-west-1:11111111:DeveloperNotifications:d3ab24eb-3a37-4b6b-810d-4724ad1a378a",
            "EventSource": "aws:sns",
            "Sns": {
                "Signature": "nsTcPYxyTfqzHhynf7cFLESjxsccT4MeDJKouyZjt9YZFyEp1+j/TiXUx3wLA4z+7r3EuEO5P+hFgUgf6Nx5V7Bv8J1sYswIo2R9f1Zle0HJCByKoBhesCXid4hIswHnq3CeRab/vntlUCSSx/UZXN/1fjEe4kDx5FuLwsgrqhXgrLDOMzrIrAss/2nYk+kRYcUPm6IyTYjmc33/EcR/dZ+Zj5gNXpfcLH6slVT3sQw+1aHTDmoTediB/uxOZi7+7yIs4B6k6O6tkYDKJBnUZit7V6JnNmwEvn6Ed0gOyjKhCSxn1Xx5/SC39mtcA+oVq8B93bqKhSzsxbsYI8iJUg==",
                "MessageId": "6ff02de3-b1de-55b6-8f47-75102439001f",
                "Type": "Notification",
                "TopicArn": "arn:aws:sns:eu-west-1:11111111:DeveloperNotifications",
                "MessageAttributes": {},
                "SignatureVersion": "1",
                "Timestamp": "2021-04-16T13:39:51.88Z",
                "SigningCertUrl": "https://sns.eu-west-1.amazonaws.com/SimpleNotificationService-010a507c1833636cd94bdb98bd93083a.pem",
                "Message": "{\"account\":\"11111111\",\"detailType\":\"CodePipeline Action Execution State Change\",\"region\":\"eu-west-1\",\"source\":\"aws.codepipeline\",\"time\":\"2021-04-16T13:39:46Z\",\"notificationRuleArn\":\"arn:aws:codestar-notifications:eu-west-1:11111111:notificationrule/978d75c8bab46fbc53be39e96592029eedfa4510\",\"detail\":{\"pipeline\":\"DeployDashboard\",\"execution-id\":\"1d86ec1d-b048-470d-a8dc-5a45ac8659f7\",\"stage\":\"DeployApproval\",\"action\":\"Approve\",\"state\":\"STARTED\",\"region\":\"eu-west-1\",\"type\":{\"owner\":\"AWS\",\"provider\":\"Manual\",\"category\":\"Approval\",\"version\":\"1\"},\"version\":4.0},\"resources\":[\"arn:aws:codepipeline:eu-west-1:11111111:DeployDashboard\"],\"additionalAttributes\":{\"externalEntityLink\":\"\",\"customData\":\"\"}}",
                "UnsubscribeUrl": "https://sns.eu-west-1.amazonaws.com/?Action=Unsubscribe&SubscriptionArn=arn:aws:sns:eu-west-1:11111111:DeveloperNotifications:d3ab24eb-3a37-4b6b-810d-4724ad1a378a",
                "Subject": ""
            }
        }
    ]
}

As you can see the state, used to determine the color, is always STARTED, but the type nested object is different.

Yeah, I agree. Both the color and the message itself might need some more love. Right know it looks just confusing.

I know it's long overdue, but I have found some time to improve the state of approval notifications. See https://github.com/kjagiello/terraform-aws-codepipeline-slack-notifications/pull/35.


Plugin problems in a CJS environment

After bumping esbuild-plugin-eslint from v0.3.3 to v0.3.8 in order to use the new release from #11, I encountered the problem of importing ESM in a CJS environment (which appears to have been introduced in v0.3.4). Since this is for use with the Serverless Framework (using serverless-esbuild), I can't just move to ESM, unfortunately.
To work around this, I added https://github.com/nktnet1/import-sync in order to import this plugin. This worked great, as I got back to the error of "no eslint configuration found" from v0.3.3. However, once I bumped eslint to the v9 beta, I got the following error

The above error, but in a code block
✘ [ERROR] A dynamic import callback was not specified. [plugin eslint]

    /home/james/projects/LabelLogicLive_Monorepo/packages/api/node_modules/eslint/lib/eslint/eslint.js:315:19:
      315 │     const config = (await import(fileURL)).default;
          ╵                    ^

    at new NodeError (node:internal/errors:393:5)
    at importModuleDynamicallyCallback (node:internal/process/esm_loader:39:9)
    at loadFlatConfigFile (/home/james/projects/LabelLogicLive_Monorepo/packages/api/node_modules/eslint/lib/eslint/eslint.js:315:20)
    at async calculateConfigArray (/home/james/projects/LabelLogicLive_Monorepo/packages/api/node_modules/eslint/lib/eslint/eslint.js:394:28)
    at async ESLint.lintFiles (/home/james/projects/LabelLogicLive_Monorepo/packages/api/node_modules/eslint/lib/eslint/eslint.js:803:25)
    at async /home/james/projects/LabelLogicLive_Monorepo/packages/api/node_modules/esbuild-plugin-eslint/dist/index.js:15:29
    at async /home/james/projects/LabelLogicLive_Monorepo/packages/api/node_modules/esbuild/lib/main.js:1481:27

  This error came from the "onEnd" callback registered here:

    /home/james/projects/LabelLogicLive_Monorepo/packages/api/node_modules/esbuild-plugin-eslint/dist/index.js:14:8:
      14 │         onEnd(async () => {
         ╵         ~~~~~

This makes me wonder whether the problem is with the importing of ESM in a CJS environment, since my workaround I had while waiting on your fix for #11 was working perfectly fine without the need for any hacks. I also tried it with v9 of eslint, and it still worked perfectly fine. The problem is somewhere between importing esbuild-plugin-eslint, and the loading of eslint itself.

For reference, this is the plugin workaround code
const eslintPlugin = ({ filter }) => ({
    name: "eslint",
    setup: ({ onLoad, onEnd }) => {
        loadESLint().then(eslintClass => {
	    /** @type {import("esbuild").OnLoadArgs["path"][]} */
	    const filesToLint = [];
	    const eslint = new eslintClass();

	    onLoad({ filter }, ({ path }) => {
	        if (!path.includes("node_modules")) filesToLint.push(path);
	        return null;
	    });

	    onEnd(async () => {
		const results = await eslint.lintFiles(filesToLint);
		const formatter = await eslint.loadFormatter("stylish");
		const output = await formatter.format(results);
		if (output.length > 0) console.log(output);

		const warnings = results.reduce(
		    (count, result) => count + result.warningCount,
		    0
	    	);
	        const errors = results.reduce(
		    (count, result) => count + result.errorCount,
		    0
		);

		const ret = { errors: [] };
		if (warnings > 0) {
		    ret.errors.push({
			text: `${warnings} warnings were found by eslint!`
		    });
		}

                if (errors > 0) {
                    ret.errors.push(
			{ text: `${errors} errors were found by eslint!` }
		    );
                }
                return ret;
            });
        });
    }
});

Would it be possible to get a release of esbuild-plugin-eslint with a cjs build alongside the esm build?
For example, the dist folder would look like
dist
|- cjs
| |- index.cjs
|- esm
| |- index.mjs
|- types
  |- index.d.ts

and the package.json would include the following
"exports": {
  "require": "dist/cjs/index.cjs",
  "import": "dist/esm/index.mjs",
  "types": "dist/types/index.d.ts"
}

Can confirm: the problem is in the module loading. Replacing usage of loadESLint with new ESLint() still works

Fixed in v0.3.11.


Testing issue bot!

Sails version: 1.2.3
Node version:
NPM version: 5.5.5
Operating system:

wow that's real fast

test


Fixed: Improve single place result handling and job completion

Add delay when waiting for redirect URL to handle single place results
Fix scrollbar detection for single result cases
Add proper job completion handling with exit monitor

@bugkerb thanks for the PR.
I haven't found the time to check yet. Will do the next days
apologies for the delay

@bugkerb
do you mind fixing the linter error?
https://github.com/gosom/google-maps-scraper/actions/runs/12029219575/job/34432880229#step:5:201
run locally with make lint to see the error in your computer.
thank you very much for the PR


Typo in class variable declaration on preprocessing example

model_config is declared twice: once as a class variable (self.model_config) and once as a local variable (model_config) in the same statement. I think it is better to declare it only once as class variable.
I have updated the only line where it is used with the new name.

It is intentional to avoid typing self. every time model_config is used.


Serialize DeadlineMessage payload and metadata instead of entire message

We are currently serializing the entire DeadlineMessage in the DeadlineManager implementations, whilst we should only be serializing the payload and metaData.
Currently the DeadlineManager does not function when using the JacksonSerializer due to the fact that the Generic...Message implementation don't (nor should they) have any Jackson annotation.
Adjusting the serialized object to the part of the DeadlineMessage which matter will solve the issue, as well as that it resembles how we're serializing the EventMessage for the EventStore.

This issue has been resolved in #681.


Save finished extraction as a datafile/into the Renv

Currently outputs a datafile into the terminal but not into the folder as a .csv or Renv

Now creates a .csv when all graphs have finished extraction


Move over sourceforge references and remove unused donation section

@Veracity0 I removed the donation buttons and references thereto.  Not a huge worry either way. If we ever needed to go back to accepting donations, we could register with https://opencollective.com/
The only thing left is the code for running a buffbot. I don't know how it works and can't see why it needs to pull buffbot.xsl from our old website. Anyone have any ideas?

I would just download the buffbot.xsl file and bundle it with the rest of our data depedencies. It looks like it's just some HTML templating.

* textui/command/FortuneCommand.java (in a comment, it seemed)

Weird... I can't see this at all!

* the aforementioned BuffBotManager logic.

Done

I'm still getting used to the New World Order and didn't notice I was tagged.  I'm still getting used to the context but if this is grep driven removals of sourceforge references previously missed then they look fine.  I am surprised that there is mafia licensing/copyright info in spellcast since at one point there was a deliberate decision not to make any claims about third party source we used, but just include their license somewhere.  But mu surprise is just historical commentary.
I recall past discussion of donations and there weren't many donations, if at all.  We should consider reinstating it once we have a sense of who should be steward and how donations should be spent.
I'm going to Close with Comment which may mean this is an approving review (which is fine but I don't know for sure).

Nope! This closes it without merging, you need to hit the green accept button on the top right!


Backport changes for newest crate-docs-theme, plus missing 1.1.3 release notes, plus RST fix

I noticed the 1.2 release branch wasn't building on RTD any more. this changeset fixes that problem

We'd also have to port over a Jenkinsfile that fits to make the tests pass.
Do we even need to inlcude versions so far back in the docs menu?

related 2.3 backport PR here: https://github.com/crate/crate/pull/10338

dropping 1.2 from our hosted docs versions. closing


Remember Password is not selected on saved connections causing password to be forgotten

Azure Data Studio Version: 1.33.0
OS Version: Windows 11

Steps to Reproduce:

Open up Azure.
Open a new tab.
Click "Connect" along the top bar
Select a saved connection from my list
The "Remember password" box is always unticked now

Does this issue occur when all extensions are disabled?: Yes

Probably related to https://github.com/microsoft/azuredatastudio/issues/10424

Possibly. I should probably specify that this issue just happened to me with the latest release. The other looks to be well over a year old.

Possibly. I should probably specify that this issue just happened to me with the latest release. The other looks to be well over a year old.

Yep me too. It was there aways. After the last update the passwords showed up but the checkbox to save it was not checked. So I proceed to 'connect' without noticing that at first. Lost the password.....
After a few tryouts, it seems the checkbox to save the password only works once. So everytime you need to check it before connecting. If not, the password will be lost.


Provide the support to decode to abstract type when the header contains specific type info

I use Spring Cloud stream with reactive Kafka binder.
I have an interface Pet. I have 2 implementations.
Cat
Dog

Producer:
The Spring cloud stream producer produces Cat or Dog messages as Message. I use CloudEventMessageBuilder to build the messages. I also notice that Message has the headers to indicate that what type of message is that. That is, every message contains the type info com.mypkg.Pet$Cat, com.mypkg.Pet$Dog
Consumer:
I set this
spring.cloud.stream.kafka.binder.consumer-properties.spring.json.trusted.packages=*
I get this exception.
java.lang.ClassCastException: class [B cannot be cast to class com.mypkg.Pet  ([B is in module java.base of loader 'bootstrap';
Steps to replicate:
Check this repo.

spring-kafka works fine though. It seems to be specific to spring-cloud-stream

spring.cloud.stream.kafka.binder.consumer-properties.spring.json.trusted.packages=*
Is meaningless in this context - Spring Cloud Stream uses ByteArrayDeserializer by default, that property is for the JsonDeserializer.
You need to use native decoding, by specifying the JsonDeserializer.
See https://docs.spring.io/spring-cloud-stream/docs/current/reference/html/spring-cloud-stream.html#_consumer_properties useNativeDecoding.
The property is not actually needed for Kafka consumers if you simply specify a deserializer; you can set it using spring.kafka.consumer.value-deserializer and it will be applied to all bindings, or you can specify it as a configuration property at the binder or binding level.

I understand Gary. It works with native decoding. I thought we would not have to do that as we already have the type info in the header. Please close this my request does not make sense. I will be fine with native decoding.

There was a fix pushed recently where you can communicate type information with content type parameters.
For example content-type=application/json;type=org.acme.Cat.
Is that what you are looking for?


Adding force https metadata key

Description
Added ForceHTTPS key to metadata and simple if statement that will handle forcing https in the Location header of the final redirect from oauth2 middleware.
Issue reference
Reference to the issue this PR will close: #486
Checklist
Please make sure you've completed the relevant tasks for this PR, out of the following list:

[x] Code compiles correctly
[x] Created/updated tests - there were no tests for this middleware, so I didn't created any new ones.
[x] Extended the documentation / Created issue in the https://github.com/dapr/docs/ repo: dapr/docs#836
[x] Tested in the k8s environment with the latest stable dapr release v0.10.0.

Thanks for this @TenSt

@yaron2 it was my pleasure


Please add SRID 900913 for the spatial viewer

According to https://epsg.io/900913 it is equivalent to SRID/EPSG 3857, so an alias could suffice.
Alternatively please provide a hint, how custom SRIDs can be added.

You can read more about it here


Maybe get rid of most package level variables

Maybe I should have thought this through a bit more, but it seems to me that there is too much package level variables. I think that prevents memguard from being used by multiple dependencies of a Go program. For example; consider a program "package a" that depends on memguard/core and also on "package b", which in turn depends on memguard/core. Suppose both "a" and "b" try to set core.Interval, then there is a data race as it is not known which store to core.Interval happened last and which will affect the memguard funcs.

That's a good point. In a situation like that one of the dependencies would unpredictably have control over the interval, and the only way to be sure of its value would be for the root module to set it itself. The only way to rectify this is likely to remove it altogether or discourage its use.
That's the only package level variable though as far as I can see.

Actually thinking about this, if A relies on B and C, and both B and C rely on this package, then both B and C should have separate instances of memguard with separate interval values.
I'm not actually sure that this is the way the Go runtime handles dependencies, but intuitively it should do.

both B and C should have separate instances of memguard with separate interval values.

Looks like they don't:
Interval A: 8
Interval B: 8
Interval External: 8

Interval A set to 15
Interval A: 15
Interval B: 15
Interval External: 15

Interval B set to 20
Interval A: 20
Interval B: 20
Interval External: 20

Interval External set to 25
Interval A: 25
Interval B: 25
Interval External: 25

https://github.com/marinewater/package-import-test

@marinewater But it does seem as though the root preference is the preferred one: https://github.com/awnumar/package-import-test

and the only way to be sure of its value would be for the root module to set it itself

Interval A: 10
Interval B: 10
Interval External: 10

The fix I had in mind is to remove var Interval and func SetInterval, and then just add an interval argument to func NewCoffer and func NewEnclave.

@nsajko The interval value is used only within the core package and nowhere else. I was wary of exporting it in #100 and I'm now even more so. I don't believe that the specification of its value should be made an even more intrinsic part of the interface.
That being said, if NewCoffer took the interval as an argument and then this line in the core package hard coded the default value:
https://github.com/awnumar/memguard/blob/e3e7b95f838b7332c78c736aba627517e76b2315/core/enclave.go#L10-L13
That might work. It would no longer be a global variable. However then there would be no way for any external user to modify it.
At this point I'm in favor of adding a note of this in the documentation, raising the default slightly, and leaving it at that.

I am not sure what is your understanding of the situation, but the current situation is simply unacceptably buggy - it is racy. Surely you want your packages to be safe for concurrent use by multiple dependencies of a single program.

I mean you do not have to solve it as I proposed, you could instead have a method to modify the interval, the important thing is that it must not be a package level variable.

var buffers is also unsafe for concurrency.

A method would suffer from exactly the same issue as there is only one global key.
Operations are atomic so it's not "unsafe" racy. The issue is unpredictability in the precise value when multiple dependencies want to specify it. I see this as fine as the value does not matter too much as long as it is low enough.
buffers is protected by a mutex.

Also var key, it is unsafely destroyed in enclave.go

Also var key, it is unsafely destroyed in enclave.go

Where?

buffers is protected by a mutex.

It is not in func NewBuffer. Really the underlying issue here is that you are using package level variables at all. That is only OK to do in general if they are effectively constant (only assigned to during initialization).

It is not in func NewBuffer

https://github.com/awnumar/memguard/blob/e3e7b95f838b7332c78c736aba627517e76b2315/core/buffer.go#L222-L228

OK sorry, so it is protected by mutex. But you would not need mutexes if the variables were not package level.

There's no way around having to keep global state in an application like this. I'm sorry it makes you uncomfortable but "package-level variables" (i.e. globals) are not inherently bad.
The issue with SetInterval I can at least sympathize with since callers are able to mutate it, but the rest of these are not even exported.

There's no way around having to keep global state in an application like this.

Not true.

The issue with SetInterval I can at least sympathize with since callers are able to mutate it, but the rest of these are not even exported.

The callers are able to mutate the other ones too, through the exported funcs, that is why you need locking (with mutual exclusion locks). You would not need locking if the variables were session based instead of package level.

https://dave.cheney.net/2017/06/11/go-without-package-scoped-variables

There's no way around having to keep global state in an application like this.

Not true.

Thinking about this more deeply, I'm still not convinced that it's possible to remove globals from the library. Let me explain.
In a session-based scheme where the caller creates a session that has a local key and list of buffers, there would still need to be a global buffer containing the list of sessions in order to implement the safe termination procedures. Perhaps it's still worth the effort in order to get rid of having to handle init() functions being called multiple times.

You would not need locking if the variables were session based instead of package level.

This is simply not true. Each session could also have multiple threads accessing the session state and this would need to be internally thread-safe.
For now, the pull request I just opened (#114) gets rid of the specification of the interval value among some other small changes. I will continue looking into the feasibility of a session-based approach and how specifically it would be implemented.


Automated cherry pick of #8278: fix host-deployer base image

Cherry pick of #8278 on release/3.4.
#8278: fix host-deployer base image

/lgtm
/approve


Provide a test for number-parsing of UHDM::constant in getValue().

Writing it, a number of bugs were discovered: the unsigned
binary values (BIN, HEX, OCT) were not actually parsed as
unsigned values. Also no out-of-range detection was done.
Fixed all of these in the course of this change.
Signed-off-by: Henner Zeller<EMAIL_ADDRESS>

Codecov Report

Merging #2864 (27f4159) into master (8bfb369) will increase coverage by 0.07%.
The diff coverage is 80.64%.

@@            Coverage Diff             @@
##           master    #2864      +/-   ##
==========================================
+ Coverage   27.04%   27.11%   +0.07%
==========================================
  Files          99       99
  Lines       32102    32106       +4
==========================================
+ Hits         8682     8707      +25
+ Misses      23420    23399      -21

Impacted Files
Coverage Δ

src/DesignCompile/CompileExpression.cpp
28.63% <80.64%> (+0.66%)
: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 8bfb369...27f4159. Read the comment docs.

I am not sure what is going on with the clang macos test (regression not working), but that is also already upstream so not caused here.


Metis prints unexpected warning

Short summary about the issue/question:
MetisTuner uses gaussian_process from scikit-learn which has a known bug related to this issue and this PR.
It raises an unexpected warning below when there is few data point for gaussian_process.
Predicted variances smaller than 0. Setting those variances to 0.
warnings.warn("Predicted variances smaller than 0. "）

Brief what process you are following:
Run the Metis Tuner.
How to reproduce it:
Sometimes when there is few data point in Metis Tuner.

nni Environment:

nni version: v<IP_ADDRESS>
nni mode(local|pai|remote): local
OS: Ubuntu (WSL)
python version: 3.6
is conda or virtualenv used?:  conda
is running in docker?: Nope

Anything else we need to know:

For this warning, we will update the scikit-learn version in requirment file when they fix their bugs.

So is this problem fixed?

Do you think this bug could be refactored into a minimal non-regression test for scikit-learn/scikit-learn#11116? If so please feel free to post such a test as a comment in the scikit-learn/scikit-learn#11116 discussion.

So is this problem fixed?

popping up to know the status.

@kvartet - need to test whether this issue exists in the latest version.


Add bitrate fmtp parsing for G7221

hi, could you please merge this?

Hi @spscream! I am sorry, I didn't notice your PR. LGTM, thanks!

Released as v0.16.0


PROD-80 updated profile page

✅ Add Linear ID (e.g., PROD-123) to PR title to automatically link issue
Link to the Linear https://linear.app/gator/issue/PROD-80/first-pass-on-profile-page

Description
UI and content updates. Added possibility to remove image (sets our default avatar image) on click
What are the steps to test that this code is working?
Screen shots or recordings for UI changes
New profile setting page

Code lgtm. Will let @Yihwan approve.

i am still getting zoomed in on mobile in-app phantom browser. input font size may need to be adjusted to prevent this accessibility feature.
the X icon next to profile picture is too close to the edit profile tap target. clicking on the X currently opens up the edit modal. please place X in upper right hand corner of containing rectangle for now (and hide if user has not selected profile pic). we can revisit placement later.
clicking "Go home" from the unsaved changes modal results in 404

I checked 404. The redirect is setup correctly to /application as it is required. I think this is preview thing, but I'll check once again. Will see what I can do with this "zoomed in" thing.

i am still getting zoomed in on mobile in-app phantom browser. input font size may need to be adjusted to prevent this accessibility feature.
the X icon next to profile picture is too close to the edit profile tap target. clicking on the X currently opens up the edit modal. please place X in upper right hand corner of containing rectangle for now (and hide if user has not selected profile pic). we can revisit placement later.
clicking "Go home" from the unsaved changes modal results in 404

Go Home redirection local behaviour
https://github.com/user-attachments/assets/892ad445-c08e-4db0-97ae-5a4a17350ce8