Provide a way to track scrape error messages that does not involve logging at debug level

Proposal
Users that are running multiple Prometheus servers where more than one target is failing to scrape may find it cumbersome to navigate to each Prometheus UI to retrieve the last logged scrape error for each failing target. A centralized logging solution makes it easier to collect and act on the logs from each running server, but as the scraping errors are hidden behind the debug level, the debug level log verbosity might produce too high of a volume for some self-hosted logging platforms.
To allow users to collect logs on scraping errors without needing to accept a massive increase of log volume, I suggest letting scrape errors be logged at the info level. To prevent the volume of scrape errors logged massively increasing during a network outage, logging this message should be rate limited, where the rate limit for this message is shared between all targets.
/cc @RichiH

This has been discussed before, scrape failures are not interesting at a Prometheus application level as scrape failures are normal. You can access these as debug logs, and from the UI.
Dupe of #2820.

The UI isn't particularly useful if you have a target that fails infrequently, as the UI only shows the error (if any) from the most recent scrape.
I recognize scrape failures are normal but there's no other way for users to discover why Prometheus is unable to reach a target, and there should be some other mechanism in place to retrieve historical failures that doesn't require debug-level logging for the entire process.

Do you have a proposal along those lines for intermittent failures that doesn't involve logs?

Precisely because scrape failures are normal, we need a way to routinely track the reasons that does not require to set the whole server into debug-logging mode (because that's something you don't want to do routinely). Inspecting the UI at the right time doesn't really scale.

Along similar line is the problem of out-of-order and duplicate timestamps. It currently involves restarting the server with debug-level logging and wait for the incident to happen again. I'd also like to see some way of logging those routinely in a way that can be tracked by a log processing system. Perhaps we can find one solution for both problems.
Info level logging with some way of dedup'ing / rate limiting might be an easy way out.

I don't see rate limited logs as a solution here, as in my mind application logs are somewhere where more than a log line per minute is spammy. To be useful here you'd need a fair bit more than that, which would detract from their role as application logs.
If the goal is to get these into a log processing system then that limits us to logs, and debug logs already do that. I'd suggest that any solution here cannot be logs and especially not application logs, as they're already as good as they can sanely be.

Debug logs are for debugging Prometheus. What we need to address in case of tracking the error messages of failed scrapes or the time series that get duplicate or out-of-order samples is an operational failure. That's why debug logs are not the right place.

We might want to consider a similar path as the one we took for query logging. Call it "scrape logging" or "ingestion logging". Just as an idea…

That'd be one idea. Another might be to keep the last error/warnings for a target around, similar to how we plan to at some point to keep a copy of the last scrape.

I would be in favour of maybe adding a 'last failure' in the UI.

It is correct that this has been discussed in the past, but as at least I disagreed with how it's currently done, there was no consensus in favor of not doing it, merely a stalemate.
Another thing that was discussed back then is how operational messages "this scrape has failed" is not suitable for debug (under the "debugging the code not debugging the system definition at least, then going to "but we only have one STDOUT for more than one type of operational data").
Another thing from back then was to keep a ring buffer of logs: Get them via web endpoint in time, or they are gone. Adjust ring buffer size as needed to make scaling issues go away (at the potential loss of data). Maintaining last scrape result for drill-down was also discussed. Also, the option to make what type of logs are emitted a runtime, not a start time, decision was discussed, e.g. by changing and reloading config files.
Finally, but I can't find references to this off-hand, I think I suggested way back in time that we could use labels for logs.
Cycling back to today:
We need a way to emit logs & events about things going wrong. I would argue strongly that following Loki's format for log lines is the Prometheus Way(TM) as it follows the same data format. I would also argue that we should deliver a useful-to-an-operator default and leave optimizations like disabling things due to volume for advanced users. Having all this through a web endpoint is nice, but STDOUT is the Unix Way(TM) and should thus be used by default as that's what pretty much all tooling supports. Both last scrape and last failure make sense as a default, and we can leave the turning off of things to advanced users. I would argue that all this needs to either only work in a way which is useful for operations with Prometheus, or that if it's optional, it should be run-time via config, not start-time via command line flags.

Maintaining last scrape result for drill-down was also discussed.

We actually have consensus from back in the 2017 dev summit (with the proviso that we might need to limit how much of each scrape to keep for RAM reasons), but it has yet to be implemented. I believe this was in the context of dealing with parse errors, e.g. if the response was JSON.
I suspect you're conflating a few different discussions from different contexts presumably involving private discussions, as I can't find rest in previous dev summit notes and it is either all new to me or new to me in this context.

I would also argue that we should deliver a useful-to-an-operator default and leave optimizations like disabling things due to volume for advanced users.

For keeping the last scrape in memory, I wouldn't even give the option to disable it. Similarly with exposing the last failed scrape logs via the UI.

Both last scrape and last failure make sense as a default, and we can leave the turning off of things to advanced users.

To clarify you mean exposed via the UI, not spamming the application logs on STDOUT by default? If a user wishes to have all this detail on STDOUT, they can already do so by enabling debug logging.

Various people (including myself) claim certain things about what should be logged where and what log levels mean, and those claims are not consistent with each other, and not consistent with reality, either. In fact, our logging philosophy is not really codified, and just by coding along, a consistent logging philosophy didn't just magically appear. See 4y old https://github.com/prometheus/prometheus/issues/1479 , which got addressed in certain parts, but there is still no RFC or agreed-upon design doc, and thus we keep telling each other different impressions what the presumed consensus is and what not and waste time skimming through notes of past dev summits and such.
While I'd appreciate to create clarity about logging, I think there is at least one "emergent" logging rule we apply fairly consistently, out of necessity: On info level and above, we avoid high log volumes that scale with the ingestion volume, while on debug level, everything is allowed. That's the true reason why we don't log scrape failures or out-of-order samples. A minor misconfiguration affecting thousands of targets could trigger a giant log avalanche. The argument that we don't log anything at info or above that is "just normal operation" is wishful thinking at best, as we log tons of stuff at info level that is just normal operation.
The current state has the problem that there are logs that are important to have in daily operations (in particular the two we are talking about here: reasons for failed scrapes and out-of-order or duplicate samples), but operators can only choose between not seeing logs about those at info level, or getting an unsustainable amount of logs at debug level. Waiting for a codification of our logging philosophy and then a solution for this problem that is consistent with that yet-to-be-created logging philosophy is not what I would like to burden our users with, at least not if there is a pragmatic interim solution.
IMHO what would help here is info level logging about failed scrapes and out-of-order or duplicate samples that does not scale with ingestion load. For the former, we could log if a target goes from up to down and vice versa with the corresponding error message. For the latter, we could give a summed up report like 234523 samples for foo_total{code="404"} dropped in the last minute with graceful degradation in case it affects too many metrics, e.g. samples dropped for more than 1000 different time series from target xxx. (I should mention that we already had a less sophisticated version of the latter in Prom 1.x. Like many other things, it got ripped out without any discussion with the author of the original code (which happened to be me), reflected in my comment on #1479, which is still quite relevant in the context of this discussion.)

For the former, we could log if a target goes from up to down and vice versa with the corresponding error message.

That could be a log message per scrape for a target flapping, which would be extremely spammy.

with graceful degradation in case it affects too many metrics, e.g. samples dropped for more than 1000 different time series from target xxx.

We actually already have this, and if anything I'd be looking to remove it as it can produce multiple log entries per scrape. However getting this message at all indicates a misconfiuration or misdesign somewhere, not just a network glitch so the volume tends to be tolerable overall.
My stance is that the only thing we should be logging at info level are things relating to background operations of Prometheus (e.g. compaction), plus things that indicate bugs/system level issues in Prometheus (e.g. corruption). I think trying to log anything else at the info level is only a crutch for the lack of better ways to expose such information, and that we should look at improving things there rather than trying to solve all possible debug use cases via info logs.

That could be a log message per scrape for a target flapping, which would be extremely spammy.

Flapping targets that manage to miss precisely every second scrape are also quite unlikely.

My stance is that the only thing we should be logging at info level are things relating to background operations of Prometheus (e.g. compaction), plus things that indicate bugs/system level issues in Prometheus (e.g. corruption).

This is a valid proposal for the documentation of our logging approach as requested in #1479. Right now, I wouldn't agree that's the way to go, but a proper discussion on it might convince me.
This issue is not so much about the general philosophy but about coming up with a timely solution to deal with an operational concern (troubleshoot failing scrapes without requiring humans to look at the web UI at the right time and without switching Prometheus into debug mode with a restart and hope to see the failure again before the log spam overwhelms anything – ideally, that solution would also help with the out-of-order/duplicate sample troubleshooting). I think it has been described sufficiently, and the necessity has also been established. I'll change the labeling of this issue accordingly.

My currenct inclination would also be to keep scrape errors and OOO/duplicate sample errors out of logging and just put them in the web UI instead. Each target could keep track of its last scrape error (and maybe its timestamp), even if the last scrape was successful. And similarly, we could store and visualize OOO/duplicate sample errors for each target or rule.

My thoughts are in line with @juliusv, though I presume the logs would still be present at debug level. The blackbox exporter has some code along these lines, though a bit more complicated than what'd be needed here.

I can see the logline proposal being controversial. Depending on how you use Prometheus it can be either too spammy or actually fine. Some other options around logging:

Add some logScrapeFailToInfo option to flags or configuration
Allows changing log level during run time (via config). This should be fairly easy to do.

It looks like we also somehow settled on lastScrapeStatus. I would be ok with this as well. Does this solve your problem @rfratto @beorn7 ?
Another alternative (or something to do in parallel) is just scrape failure metrics with few definite types of error. Usually, it is either: Timeout, 404, Bad Gateway, Permission, wrong port etc.. This would give some immediate insight.

I'm personally not satisfied with lastScrapeStatus since it still is only useful within the UI. As I mentioned before, a logging solution that feeds into an aggregated logging platform would be preferred. I'd like to see scraping problems across all of my Prometheus processes at once, and not just for the single process I'm currently viewing the UI for. If a log based solution is completely out of the question, lastScrapeStatus is definitely better than doing nothing here.

For out-of-order and duplicate sample, a UI option would be great, as that's an irregular case to be troubleshot by the operator when it's happening.
Last scrape status in the UI is definitely helpful, but precisely because it is something that happens regularly, there should be a logging option (that doesn't require to also log all other debug messages).

Add some logScrapeFailToInfo option to flags or configuration

We already suffered from flags fatigue in Prometheus 1.x.
A config option is less harmful in relative terms.
But ideally, the info level logging would add so little that the price that it is also logged for those that aren't interested is much lower than the overhead of an additional config option.
As said, logging a target changing state is fairly rare. And should a target really flap at high frequency, we could even guard against that and just log "target foo has flapped 47 times in the last 10m, most common error message was 'foobar blabla'".

I am confused by your request @rfratto, as the debug logs today should already provide exactly what you ask for with little other extraneous information - basically just more detail on duplicates, out of order etc. It sounds to me more like the problem is either that your logging solution can't deal with the (in the grand scheme of things) moderate debug-level log volumes that a Prometheus can produce, or that your logging system can't filter.
Can you explain more about the volume of non-scrape failure debug logs which your Prometheus produces which is causing you problems?

Another alternative (or something to do in parallel) is just scrape failure metrics with few definite types of error. Usually, it is either: Timeout, 404, Bad Gateway, Permission, wrong port etc.. This would give some immediate insight.

That's either a scrape metric in which case it's too high cardinality as it applies to all targets individually, or it's on /metrics across all targets which would not be useful.

But ideally, the info level logging would add so little that the price that it is also logged for those that aren't interested is much lower than the overhead of an additional config option.

I agree with that principle, and that we should avoid adding lots of granular configuration tuneables. In general I think we should be aiming for no more than a few log messages a minute so as not to drown out the Prometheus-level stuff.

And should a target really flap at high frequency

Keep in mind that it's not unusual for a Prometheus to have tens of thousands of targets, so even a message each once every 10m would be extremely spammy. I've yet to see a way that info logs can be realistically useful here.

I am not convinced we're all discussing the same thing. "Debug is (currently) not too spammy" and "Information about failed scrapes is useful by default" seem to be loosely related at best.

That's either a scrape metric in which case it's too high cardinality as it applies to all targets individually, or it's on /metrics across all targets which would not be useful.

As discussed in the past, one label per well-known error type is not going to have high cardinality. Personally, I see this an enhancement to, not a replacement for, "proper" (subjective assessment) logging.

I agree with that principle, and that we should avoid adding lots of granular configuration tuneables. In general I think we should be aiming for no more than a few log messages a minute so as not to drown out the Prometheus-level stuff.

It feels as bit as if in between "keep it in debug" and "not too granular", the status quo would be the only implementation to solve the constraints, but:

Keep in mind that it's not unusual for a Prometheus to have tens of thousands of targets, so even a message each once every 10m would be extremely spammy. I've yet to see a way that info logs can be realistically useful here.

Adapting the way network devices do it, as they needed to solve this precise problem decades ago: Delay log messages by X amount of time and aggregate them when needed.
Doing it better than those devices:

Keep the original time stamp intact in case you do not aggregate, use most current timestamp in case you do aggregate.
Aggregate along more dimensions if needed
Make amount of time and aggregation thresholds configurable

Add some logScrapeFailToInfo option to flags or configuration

We already suffered from flags fatigue in Prometheus 1.x.

At Google there were flags that allowed you to tune log levels separately for each library/module, though I forgot how exactly that worked. But it could be done without introducing a huge number of new flags, e.g. something like --log.debug-level-components=discovery,scrape. You could go even deeper and support sub-behavior indication like scrape.duplicate-errors if necessary.

Is there a distinct advantage to making this a start-time instead of a run-time configuration? If we could find consensus on run-time config through config files, we could remove one dimension from this discussion.

As discussed in the past, one label per well-known error type is not going to have high cardinality.

It depends on where it lives. If it's /metrics it's not - but it's also not useful. If it's done like up then it is, as it's additional overhead on every single scrape that users have no way to avoid. I've worked to keep the scrape_ metrics as minimal as possible, and part of that is avoiding turning them into event logging for every bit of debug information a user might potenitally find useful.

Delay log messages by X amount of time and aggregate them when needed.

At that point aren't we kinda exposing metrics via the log file?

Doing it better than those devices:

These all sounds like the roles of an event-logging system, not something that we should be trying to build inside Prometheus.

flags that allowed you to tune log levels separately for each library/module

To @beorn7's point, if we're trying to do something to make things work better out of the box then it shouldn't need configuration by the user.

If we could find consensus on run-time config through config files, we could remove one dimension from this discussion.

Beyond exposing more things in the UI, I don't think there's any consensus around what we should be adding/removing to the info logs to begin having the discussions about if/how it should be configured.

First step is adding that to the API then: #7797

Maybe prometheus can expose a metric like "prometheus_target_scrape_pool_targets_failed", this metric indicate which endpoint didn't scrape successfully

That's already accomplished by up. What this issue is talking about is the actual error message associated with a failed scrape.

I've read this and it's something we could really use. I saw that the PR 7797 was open. Is there something I, or someone else could help with?

I've read this and it's something we could really use. I saw that the PR 7797 was open. Is there something I, or someone else could help with?

How about augmenting the up scrape metric with the HTTP response status code? It obviously isn't the full log but at least as an operator I'd get a little bit more insight into an error rate spike event straight out of the builtin scraping metrics.
For instance:
up{job="foo", instance="bar", status="200"} 1
up{job="fiz", instance="bar", status="404"} 0

@jaimegago That isn't doable unfortunately, for a number of reasons:

It would be an important breaking change.
up time series would lose their continuity when you introduce labels that are purely informational and whose purpose is not to identify the target. That is, if the error switches from 404 to 500, it would now be a new time series instead of the same one as before, breaking queries, alerts, etc. Thus, up and the other synthetic metrics should only have labels that identify the target in a fixed way.
What if a target already has a status target label? You would have to handle collisions somehow, but then this concept would become less useful as well.

Today I spent a good amount of time trying to find logs associated with a scrape failure. It didn't even occur to me that there were no logs.
Having some logs here would certainly have sped up debugging of my problem.
I don't have enough knowledge to propose an architecture solution, but I wonder about the assertion that there are scrape failures all the time, so we don't want to log them. This seems to me to be exactly what I want to be logged, so I can resolve these.

@micah Just curious, was your case also a case of rare / intermittent failures? Because for frequent / permanent failures, you can usually see the error message on /targets for the latest scrape. But yeah, you can currently log it already (see https://github.com/prometheus/prometheus/blob/b1c179be856043113eb51895f79f8a1d740c4a84/scrape/scrape.go#L1235), but for that you would need to turn on debug logging for the whole server.

I'm trying to get Prometheus to scrape k8s pods. Nothing is happening. There is zero feedback from Prometheus. I don't even know if it's even attempting to scrape anything. I have tried almost every solution posted on StackOverflow.
Even if it's all my fault, Prometheus should at least say something.

I'm trying to get Prometheus to scrape k8s pods. Nothing is happening. There is zero feedback from Prometheus. I don't even know if it's even attempting to scrape anything. I have tried almost every solution posted on StackOverflow.
Even if it's all my fault, Prometheus should at least say something.

It makes more sense to ask questions like this on the prometheus-users mailing list or our forums rather than in a GitHub issue. In our community channels, more people are available to potentially respond to your question, and the whole community can benefit from the answers provided.

Ping, see message above

It's annoying when some scrapes fail and you cannot debug why they happened. It would be awesome if we could either have a metric that will give us more information, or maybe a separate log file for scrape failures.

While metrics are helpful to see which targets fail, with which status code and maybe in which pattern, it does not help to find the actual issue. Especially when TLS or authentication is involved it's sometimes a little troublesome to involve mitmproxy or similar tools just to see that the other end does not like some HTTP parms (and does not log this nicely to its own log). Maybe similar to how debugging works with the blackbox exporter (https://www.robustperception.io/debugging-blackbox-exporter-failures/) a single "debug scrape" could be invoked via API request and then return the request and response including all the headers?
Adding all this info to the debug log level and for every target seems a bit excessive and impractical for production instances. This would then require something like Postfix does to limit debug logging to just a single target (https://www.postfix.org/postconf.5.html#debug_peer_list).

Hello from the bug scrub.
This issue received fairly deep discussions, but then it stalled, and we have still gone nowhere in almost 4y.
We'll add this to the agenda of the dev-summit to get some direction because right now, a contributor wouldn't even know what to implement.

@beorn7 For me the issue was that on a page of 100+ metrics for a given target, it's impossible to know which metric was "bad"

One potential solution would be to use tracing, since sampling can reduce the volume of spans. It looks like there is already some tracing being done in the prometheus server. Even better would be if we could attach an exemplar to up with the trace context keys.


Feat: support enable/disable the isScrolling property by the speed of scrolling

Feat: support enable/disable the isScrolling property by the speed of scrolling

Pull Request Test Coverage Report for Build 884957687

0 of 8 (0.0%)  changed or added relevant lines in 1 file are covered.
1 unchanged line in 1 file lost coverage.
Overall coverage decreased (-0.01%) to 2.143%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

src/useVirtual.ts
0
8
0.0%

Files with Coverage Reduction
New Missed Lines
%

src/useVirtual.ts
1
0%

Totals

Change from base Build 884798185:
-0.01%

Covered Lines:
7

Relevant Lines:
259

💛  - Coveralls

Pull Request Test Coverage Report for Build 884957687

0 of 8 (0.0%)  changed or added relevant lines in 1 file are covered.
1 unchanged line in 1 file lost coverage.
Overall coverage decreased (-0.01%) to 2.143%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

src/useVirtual.ts
0
8
0.0%

Files with Coverage Reduction
New Missed Lines
%

src/useVirtual.ts
1
0%

Totals

Change from base Build 884798185:
-0.01%

Covered Lines:
7

Relevant Lines:
259

💛  - Coveralls


Ignoring mouse events / transparent for inputs / disable hit testing

Hello,
Using a long subject line because I don't know what is the most appropriate cross-platform terminology and people might search for this under different names
This is feature request for a window hint, let's tentatively call it GLFW_MOUSE_PASSTHRU (exact naming to be determined). I am using it as part of the same work I mentioned in #1166 (GIF at the end of this post).
(Note, this is unrelated to transparency from a visual point of view, already discussed many times here: https://github.com/glfw/glfw/issues?utf8=✓&q=transparent)

Windows
The WndProc handler would do:
if (msg == WM_NCHITTEST)
    return HTTRANSPARENT;

Mac
I think we can use the 'ignoresMouseEvents' property of 'NSWindow' (untested)
https://developer.apple.com/documentation/appkit/nswindow/1419354-ignoresmouseevents?language=objc

A Boolean value that indicates whether the window is transparent to mouse events.

Wayland
Possibly 'wl_surface::set_input_region' (untested)
https://wayland.freedesktop.org/docs/html/apa.html#protocol-spec-wl_surface

Input events happening outside of this region will try the next surface in the server surface stack. The compositor ignores the parts of the input region that fall outside of the surface. [...] The initial value for an input region is infinite. That means the whole surface will accept input. Setting the pending input region has copy semantics, and the wl_region object can be destroyed immediately. A NULL wl_region causes the input region to be set to infinite.

X11
I'm not sure how X11 works. For reference, Qt uses xcb_xfixes_create_region()+xcb_xfixes_set_window_shape_region_checked:
https://git.merproject.org/mer-core/qtbase/blob/master/qtbase/src/plugins/platforms/xcb/qxcbwindow.cpp#L1151

Context (gif): I am dragging a glfw window (that is right under my mouse cursor) and need to detect the window under so I can drop into them. Similarly to #1166 I can provide a rough (but usable) approximation on client-side by using the desktop size/position of all my windows, but of course this would bypass the window manager and ignore the proper z-order of windows (including windows from foreign application).
EDIT To clarify, at the moment I am testing this by using win32-specific code and installing a WndProc hook.

The naming and my use case are a little tricky because I toggle this feature on an existing GLFW window, and right now I still receive the currently captured mouse position for that window, which is ideal and desirable in my use case, and I think more flexible. This is why I didn't suggest a name like GLFW_IGNORE_MOUSE_INPUTS, because both CursorPosCallback and glfwGetCursorPos() still work fine.
Thanks for your consideration,
Omar

Hello,
Is there any word on this? I think the idea is great and would love to see it in GLFW.

would like to see something in that way too, having the issue that i need to create an overlay above some other application window on linux but still want to click stuff behind the overlay

This feature has been added as GLFW_MOUSE_PASSTHROUGH with #1568 by @rokups and will be included in 3.4.


Automated cherry pick of #5191: fix: add aliyun new region info

Cherry pick of #5191 on release/3.1.
#5191: fix: add aliyun new region info

Codecov Report

:exclamation: No coverage uploaded for pull request base (release/3.1@0701512). Click here to learn what that means.
The diff coverage is n/a.

@@              Coverage Diff              @@
##             release/3.1   #5192   +/-   ##
=============================================
  Coverage               ?   6.73%
=============================================
  Files                  ?     547
  Lines                  ?   95752
  Branches               ?       0
=============================================
  Hits                   ?    6451
  Misses                 ?   88763
  Partials               ?     538

Flag
Coverage Δ

#aFlag
6.73% <ø> (?)

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 0701512...4418390. Read the comment docs.

/lgtm

/lgtm

/approve


Publish first Gem

[x] Wire Travis
[x] Tag git as part of release
[x] Push gem when running on tag
[x] Establish Changelog approach

Splt out #96 and #97


Config/Context management

What is the goal / desired outcome?
Easily manage configurations for connecting to multiple pachyderm clusters, potentially in multiple K8S clusters, for testing in different environments, or from different projects
If there is a way to accomplish this today via workaround, what does that require?
Right now pachctl has the following cascade of checks for where to connect:

PACHD_ADDRESS env var
ADDRESS env var
~/pachyderm/config.json file
localhost:30650

So changing the env var to change which cluster is being connected to is doable, but not the most ergonomic experience. There is, however, other contextual info that this doesn't work for. For example, AFAIK there is no way to set env vars to sub out auth info, and I believe the config file also can hold some TLS-related keys/certs that should be cluster-specific, but end up being globally scoped, since the config file is global
(Optional) What is your proposal for a feature to solve this?
Current tentative proposal is implement a notion of "config contexts" which contain all the info for connecting to a particular cluster, as a particular user, with a particular setup
By default these contexts would be stored in a user-global config file, but we have also discussed having directory-scoped configs (so you could have a different config used automatically for different projects in different directories, much like how git, heroku etc. work)
Exact user experience of interacting with/changing these contexts is TBD. It would be useful to collect various use-cases for cluster config management, to make sure they're being adequately addressed by the design
Related issues:

Allow setting namespace flag in pach config file #3419
Document use of pachyderm config file #3036
Config info messages should be written to stderr, not stdout #3311
Info about API ingress (incl PACHD_ADDRESS usage) #3466
global pachctl ADDRESS setting can be confusing for users #2606

Agreed that it makes the most sense to put this in config. Contexts would have these values:

Connection methodology (direct, implicit port forwarding, or connect locally with the assumption that port forwarding is already setup.)
IP address
Remote ports (pachd, SAML ACS, dash UI, dash websocket, PFS-over-HTTP, s3gateway)
k8s namespace

In talking about this more, I actually think the "correct" pattern today for switching between multiple clusters is just to have multiple complete config files. I believe there's an env var that lets you switch which config file is being used. That's actually not a terrible way of doing this, so one approach would just be to add some sugar/conventions around that pattern: basically the pach dir would contain a dir full of config files, each config file encapsulating an entire context. This seems like it could potentially make the migration a lot easier, but it's also not clear to me how exactly this would work, since it still relies on an env var, which pach is unable to export across runs

I think this design basically makes sense, one small tweak, I think rather than having ~/.pachyderm/config.json contain a key that points to a different config why not just have it be a symlink? This is how I've manually handled multiple configs for both k8s and Pachyderm and it works really well and I think should be pretty obvious what's going on to users. This also probably eliminates the need for the PACH_CONFIG variable.

@Tryneus brought up the good point that pachyderm isn't file- or repository-oriented in the way that heroku is, so having configs scoped in specific directories doesn't make as much sense. Moreover, I think it would be confusing to people accustomed to k8s contexts. Between that and the added complexity of config migrations (or broken symlinks), I don't think scoped configs makes sense.
I do like the idea of building on ConfigV1 as it stands for contexts via multiple config files, and will see how far we can take that.
One other note: ADDRESS is gone as of 1.9. I am somewhat concerned about churn on this end of things with pachctl (deprecation of ADDRESS, addition of implicit port forwarding, and with this, the removal of PACHD_ADDRESS), so will try to see if there's a clean way to do this without an immediate deprecation of PACHD_ADDRESS.

Should contexts contain NodePort values for services, in case they're customized? i.e. do we want first-class support for NodePort customization?


Design a logo for Open Life Science

as part of the open life science program, we'll want a logo of some sort for our projects. What should it look like?

would be nice to reflect aspects of openness as well as life science
something that would work well as a sticker and as an icon, so not too complex

All ideas welcome - I'm also tagging this with the Hacktoberfest label so newcomers are welcome to suggest ideas (and we'll send you some copies of the sticker if we use your design, of course!)

Hello! How could I participate? I can totally help you :)

Hi @htmluke! We are happy that you want to participate 😄
Let us know how we can help you

Hi... i'll work in a logo propose. ASAP i have an idea i'll send to you

Wow, two volunteers already - thanks @htmluke @shbr! Feel free to share ideas as quick sketches or verbal descriptions first of all if it's easier ✨

👍  nice I would like to share a logo propose too :) I'll work on that

@joelibaceta wow, awesome - thanks! :)

Nice! @bebatut do you have any document about your project? Something that describes the idea behind the project or explains what's the concept? Thanks for the oportunity <3

We have a website (https://openlifesci.org/) in which we describe the project.
Let us know if you have questions or if something is not clear. Thanks a lot!

We have now a logo (thanks to @htmluke)


Load external url not working

Dear Friends,
I would like to ask you how to work with load the external url.
Example:
Excel::load('http://dfat.gov.au/international-relations/security/sanctions/Documents/regulation8_consolidated.xls', function($reader) {
});
But it tried to find the find in internal directory.
Thanks you for in advance.  :)

I don't think from what I saw, that you can use Laravel Excell like that. You need to obtain the file to your local filesystem and load it afterwards.

Sorry, external files are not supported. You will have to download the file to the storage folder manually and then pass it into the load method of the package.


Undefined method `<<' for Hash when using custom rule and errors.yml

Running the following
require 'dry-validation'

Schema = Dry::Validation.Schema do
  configure { config.messages_file = "config/errors.yml" }
  each do
    schema do
      optional(:name).maybe(:str?)
      optional(:url).maybe(:str?)
      optional(:is_home).maybe(:bool?)

      # needs is_home or name
      rule(be_reasonable: [:is_home, :name]) do |is_home, name|
        is_home.eql?(true) ^ name.filled?
      end
    end
  end
end

validation = Schema.call([{ url: {foo: :bar} }])

validation.messages

will result in an error:
/usr/local/bundle/gems/dry-validation-0.9.3/lib/dry/validation/message_set.rb:51:in `block (2 levels) in to_h': undefined method `<<' for {:url=>["must be a string"]}:Hash (NoMethodError)
	from /usr/local/bundle/gems/dry-validation-0.9.3/lib/dry/validation/message_set.rb:50:in `each'
	from /usr/local/bundle/gems/dry-validation-0.9.3/lib/dry/validation/message_set.rb:50:in `block in to_h'
	from /usr/local/bundle/gems/dry-validation-0.9.3/lib/dry/validation/message_set.rb:47:in `each'
	from /usr/local/bundle/gems/dry-validation-0.9.3/lib/dry/validation/message_set.rb:47:in `reduce'
	from /usr/local/bundle/gems/dry-validation-0.9.3/lib/dry/validation/message_set.rb:47:in `to_h'
	from /usr/local/bundle/gems/dry-validation-0.9.3/lib/dry/validation/message_set.rb:22:in `dump'
	from /usr/local/bundle/gems/dry-validation-0.9.3/lib/dry/validation/result.rb:42:in `messages'
	from bug.rb:21:in `<main>'

config/errors.yml looks like this:
en:
  errors:
    be_reasonable: Please provide name or set is_home!

I am using dry-validation 0.9.3 with ruby 2.2.3.
Can someone help me with this issue? Thanks in advance!

Looks like a bug. I'll investigate and fix.

This is no longer an issue on master


Cassandra 2.x support

Cassandra moves on and we need to upgrade.  This task needs a little research and at least a dependency change.

Can you guys confirm if there is support for commit log readers with Cass2X in c2_support Aegisthus yet. I dont see any changes but I just want to know if there are any plans to provide any such support in future. Advice is much appreciated.

We haven't updated the commit log reader yet as we no longer use it in our pipeline.  @danielbwatson Can we merge the 2.0 pull request and then open the commit log reader as a separate issue?  I believe the change should be a matter of refactoring the deserialization into something we can use for commit logs as well.
@narsing3 The reason that we don't support it is that we thought it would allow us to do point of time pulls of a cluster without needing a flush.  Which is still true.  But the problem for us is that our clusters are write heavy so we would have to be constantly flushing out the commit logs to S3 (which is how we manage this flow).  So we have remained content to pull from the sstables themselves.

@narsing3 Issue #40 is the issue for adding a commit log reader back to Aegisthus.  There are no immediate plans to work on this.
Closing this issue now that PR #39 has been merged in.  Thanks @danchia for all your help with this.


Unable to disable devmapper tests

I'm trying to update containerd in LinuxKit to v1.3.2 but running into issues with the recently added devmapper snapshot support (probably a combination of Alpine utilities and kernel config, see https://github.com/linuxkit/linuxkit/pull/3426#issuecomment-571801117  for details).
For LinuxKit we are not really that interested in the devmapper snapshotter but would like to continue to run the containerd root tests. I can compile containerd with BUILDTAGS="no_devmapper" but root-test would still try to run the devmapper tests.
On my Ubuntu dev machine (where make root-test works:
root@rlin01:~/src/go/src/github.com/containerd/containerd# make root-test BUILDTAGS="no_devmapper"
+ root-test
ok      github.com/containerd/containerd/archive        4.578s
ok      github.com/containerd/containerd/metadata       31.426s
ok      github.com/containerd/containerd/mount  2.860s
ok      github.com/containerd/containerd/snapshots/btrfs        31.901s
time="2020-01-07T22:04:08Z" level=info msg="initializing pool device \"test-pool-device-258912702\""
time="2020-01-07T22:04:08Z" level=info msg="using dmsetup:\nLibrary version:   1.02.145 (2017-11-03)\nDriver version:    4.37.0"
--- FAIL: TestPoolDevice (1.36s)
    --- FAIL: TestPoolDevice/CreateSnapshotDevice (0.19s)
        assert.go:122: assertion failed: error is not nil: 2 errors occurred:
                        * failed to activate new thin device "snap-1" (dev: 3): 1 error occurred:
                        * device or resource busy

                        * failed to delete device "snap-1" (dev id: 3): 1 error occurred:
                        * no data available

                : failed to create snapshot from 'thin-1' volume
        assert.go:122: assertion failed: error is not nil: failed to mount /tmp/containerd-mount726925173: no such file or directory

This is with current tip of master:
0d276ece0e28 ("Merge pull request #3932 from AkihiroSuda/ovl-test-opts")

We normally try to avoid putting the build tags into the go packages themselves, but I can add a way to filter out specific tests run through the makefile.

@dmcgowan thanks for the quick reply. The PR linked would work for us

Thanks for the quick turnaround. I cherrypicked the fix into Linuxkit https://github.com/linuxkit/linuxkit/pull/3458 and it now works locally


services/soroban-rpc: getContractData method

Add the getContractData method to soroban-rpc. Use the stellar-core http endpoint to fetch the ledger entry data from the captive-core.

See https://github.com/stellar/soroban-cli/issues/63


Stop media player before starting voice assistant in m5stack-atom-echo

Stop playing any media before starting listening.
When long-pressing the button while a command result is playing, STT fails because of the noise from the internal speaker at the same time we talk.
If nothing is playing, voice_assistant starts directly.

Thanks


Attempt to add direct MIDI-opening support for OSX

Description

Test Instructions

Ticket Links

Readiness Checklist

[ ] I have run make format to format the changes
[ ] I have compiled the firmware and the changes have no warnings
[ ] I have compiled the emulator and the changes have no warnings
[ ] I have run make cppcheck and checked that cppcheck_result.txt has no warnings for the changes
[ ] I have added doxygen comments to any code used by more than one Swadge mode. This includes /*! \file comments with Design Philosophy, Usage, and Example sections for new headers.
[ ] I have run make docs and checked that doxy_warnings.txt has no warnings for the new code

This python hack seems to be the only full-fledged example of doing this with actual C code that does this on the internet:
https://github.com/pyinstaller/pyinstaller/issues/1309
https://github.com/pyinstaller/pyinstaller/pull/50/files

This seems like such a pain,

This seems like such a pain,

It really is... why can't macs be normal!? Apparently it is actually possible to get a mac VM without giving apple any money: https://github.com/foxlet/macOS-Simple-KVM so I'm trying that now and hoping this gets a lot easier when I can actually try things locally...


The size of the cloned repository is too large during tests.

The repository cloned in the case of testing the program contains several thousand files and builds for several hours. Therefore, it is problematic to test any improvements to the CAM. Tests require reducing the cloned repository.

@Nypiaka it's fixed, try make REPO=yegor/tojos for testing purposes


StubSession shouldn't throw RuntimeException

I have an App Engine sandbox application that doesn't use sessions (false). It works perfectly.
On Managed-VM, I get the following exception:
java.lang.RuntimeException: Session support is not enabled in appengine-web.xml.  To enable sessions, put <sessions-enabled>true</sessions-enabled> in that file.  Without it, getSession() is allowed, but manipulation of sessionattributes is not.
thrown by https://github.com/GoogleCloudPlatform/appengine-java-vm-runtime/blob/master/appengine-jetty-managed-runtime/src/main/java/com/google/apphosting/vmruntime/jetty9/StubSessionManager.java#L100
To make my app work on MVM, I'm forced to activate sessions, thus creating more load and more writes on the datastore.
Strangely, the problem doesn't happen when I access through the appspot url. The session set or remove calls are probably generated by frameworks (using Jersey + JSP + JSTL) but the call success aren't necessary to the app.
Thanks

As a workaround, and until a better solution is found, here's what we did in case anybody is interested:

Created a queue named "sessions". And I paused it on the web admin interface so that no task is processed

Added the following in the config xml:
true

Created a cron that is called every minute and does: QueueFactory.getQueue("sessions").purge();

Like that, we don't waste resources writing on the datastore (and we don't pay for useless writes/read/storage and deletes).
However we are still uselessly writing and reading from memcache so that's not good but it's still better :(

looking into it.
We might not need at all the stubsessionmanager.

FYI, the problem still seems present in app engine 1.9.30.


⚠ Bofrost.at has degraded performance

In 28ddd6a, Bofrost.at (https://www.bofrost.at) experienced degraded performance:

HTTP code: 200
Response time: 994 ms

Resolved: Bofrost.at performance has improved in 055f128.


Support for markdown extensions?

I found that multi-lined fenced code blocks doesn't working out of the box. How about adding support of markdown extension to load?
settings:
MARKDOWNIFY_MARKDOWN_EXTENSIONS = ['markdown.extensions.fenced_code']

module:
 html = markdown.markdown(text, extensions=MARKDOWNIFY_MARKDOWN_EXTENSIONS)

Thanks, I will look into it!

Added the option to add extensions to markdown.


Dapr release download within the workflow sometimes gets 403

Bug information
Steps to reproduce (required)

Some workflow runs fail with a 403 code from Dapr.

Observed behavior (required)
See this run: https://github.com/radius-project/radius/actions/runs/6075876574/job/16483097337.
❌  cannot get the latest release version: https://api.github.com/repos/dapr/dashboard/releases - 403 Forbidden
❌  Deploying the Dapr dashboard with latest version to your cluster...

Desired behavior (required)
Not getting 403 during the Dapr download from GitHub.
Workaround (optional)
Rerunning the run works.
System information
rad Version (required)
Operating system (required)
Additional context
AB#9268

I merged another fix for this. If we continue to see the problem we can reactivate this issue.


doc: add documentation around adding new config variables

Adding some more documentation about environment variables.
For more context, see thread.

Thanks for this @fladson! So do want to draw a distinction between the development environment and the staging and production runtime environment. For development, the env.shared should be sufficient. But if you want to test those changes in staging or see them in production, then that is when you need to use hokusai ... env set .... This is mentioned here: https://zoom.us/j/93825693217, so wondering if better to note as a follow up and link to the existing doc? What do. you think?

Thanks for this @fladson! So do want to draw a distinction between the development environment and the staging and production runtime environment. For development, the env.shared should be sufficient. But if you want to test those changes in staging or see them in production, then that is when you need to use hokusai ... env set .... This is mentioned here: https://zoom.us/j/93825693217, so wondering if better to note as a follow up and link to the existing doc? What do. you think?

Thanks @mc-jones for the "review", now I realised that this refers only to the local environment, sorry.
I guess you meant this doc, right?
I updated the change to what you suggested.

Sorry about the delayed merge on this!


Delete tag function

Suggestion: to delete specific tag from person only, for example you have many neighbours but only 1 neighbour shifted house, delete t/neighbour will remove all neighbours.

oh, the 'delete t/neighbour' command is used to delete all the neighbour tags, if you want to clear the neighbour tag of one specific person, you should use "edit 1 t/" to clear it.
Maybe it's not clear in UserGuide, sorry.


Don't do async work in ctor of oracle and monitor actor

bors r+

This PR was included in a batch that successfully built, but then failed to merge into master. It will not be retried.
Additional information:
{"message":"Required status check \"block-fixup\" is expected.","documentation_url":"https://docs.github.com/articles/about-protected-branches"}

Ah this needs a rebase on latest master.

bors r+


Add filters and sorters for sorting and filtering users

Description
As the number of contributors is growing and it's quite hard to find one's own profile, we need a feature to sort and filter out users. It is to be done on the client-side.
The filterable fields are:

Github user name
User name
Country

The sortable fields are:

Country
Github user name
User name
Total commits (this year)
Followers

Acceptance criteria

The above-listed fields should be filterable and sortable as listed.
The filtering should be done on the client-side. (All the contributor data is present in UI as JSON)
Add form fields to filter and sort.

Reference
src/pages/index.js

@subeshb1 I can take this up.

Yes sure @Abhikumar98. Be sure to post updates if you get stuck or need clarification

Hey @subeshb1 , getting this error while trying to start run the project in local.
Cannot query field "allContributor" on type "Query"..
Could you help me out here ?

Use the following for development
ENV_TYPE=mock gatsby develop

The project uses github graphql api to fetch user stats. So it requires Github token . The above command mocks github api
@Abhikumar98

Fixed bt #237. Thanks a lot @Abhikumar98 for your wonderful work.

@subeshb1 Most welcome 😄


Warning: This plugin slows down Homebridge.

I'm running the plugin as a child bridge, and I am getting warnings about the plugin slowing down Homebridge. Also, the child bridge process seems to end and restart frequently. I'm not sure if these issues are related or not
Do you have idea what the issue could be? Thanks for your help.
[1/7/2023, 7:28:20 AM] [homebridge-spanet] This plugin generated a warning from the characteristic 'Target Heater-Cooler State': characteristic was supplied illegal value: number 3 exceeded maximum of 2. See https://homebridge.io/w/JtMGR for more info.
[1/7/2023, 7:28:22 AM] [homebridge-spanet] This plugin slows down Homebridge. The read handler for the characteristic 'Target Temperature' was slow to respond! See https://homebridge.io/w/JtMGR for more info.
[1/7/2023, 7:28:22 AM] [homebridge-spanet] This plugin slows down Homebridge. The read handler for the characteristic 'Current Heater-Cooler State' was slow to respond! See https://homebridge.io/w/JtMGR for more info.
[1/7/2023, 7:28:22 AM] [homebridge-spanet] This plugin slows down Homebridge. The read handler for the characteristic 'Active' was slow to respond! See https://homebridge.io/w/JtMGR for more info.
[1/7/2023, 7:25:03 AM] [homebridge-spanet] Child bridge process ended
[1/7/2023, 7:25:03 AM] [homebridge-spanet] Process Ended. Code: 1, Signal: null
[1/7/2023, 7:25:10 AM] [homebridge-spanet] Restarting Process...

Sorry for very late reply haven't caught up on this library for a while. If you're still interested in using your spa with homebridge you may have noticed that SpaNET transitioned to a newer app and their API is rewritten now. I will be rewriting this library for the new API over next 2 weeks and this should iron out all the bugs and slowness in the plugin right now.

Thanks heaps!!

Thanks for reviewing this. Look forward to an update. Reach out if you need help with testing.

@darrendrysdale @shayneob Thanks both for your interest, I will keep in contact over you next few weeks when I get time to finish it off and am ready for testing 👍

Hey Blake @BlaT2512 any progress with the update that you can share?

Hi @BlaT2512, I'll also be keen to test and provide feedback

Me tooSent from my iPhoneOn 31 Aug 2023, at 6:52 pm, TheTeeDot @.***> wrote:
Hi @BlaT2512, I'll also be keen to test and provide feedback
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: @.***>

Hey @BlaT2512, just checking to see if you have had any success with updating your code to work with the changes to the SpaNet servers.

@BlaT2512 would really love to get this working with my spa also. let me know if i can contribute in any way.

@darrendrysdale @shayneob @joelhinch @aldobalducci @TheTeeDot Apologies for the very long delay, been very busy and hardly on Github the past few months. Have rewritten and just about to publish new version of the library, haven't tested it that much so please feel free to let me know how it works for you and any bugs encountered, feature requests or make pull requests. Cheers
It is not necessary to run the plugin on a child bridge, however due to the SpaNET api rate limit 3 requests per second, when the Home app requests to refresh all the spa accessories it takes a good 5-6 seconds. So if you have lots of other devices on Homebridge, may be a good idea to make it a child bridge still to improve speed.

Sounds great, thanks for looking into this. Happy to share any issues that may pop up. Cheers,DarrenSent from my iPhoneOn 4 Nov 2023, at 6:20 pm, Blake Tourneur @.***> wrote:
@darrendrysdale @shayneob @joelhinch @aldobalducci @TheTeeDot Apologies for the very long delay, been very busy and hardly on Github the past few months. Have rewritten and just about to publish new version of the library, haven't tested it that much so please feel free to let me know how it works for you and any bugs encountered, feature requests or make pull requests. Cheers
It is not necessary to run the plugin on a child bridge, however due to the SpaNET api rate limit 3 requests per second, when the Home app requests to refresh all the spa accessories it takes a good 5-6 seconds. So if you have lots of other devices on Homebridge, may be a good idea to make it a child bridge still to improve speed.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>

Hey @BlaT2512, have tried loading this and still generating an error. I am using regular username and password which is used for spanet server/app. Is this correct as I know that in previous build you needed it to be encrypted/hash using the other password generator.
Error I have is as follows which suggests that the details are incorrect but I have rechecked and they are what's used to access app/server.
4/11/2023, 7:40:32 pmSpa BridgeLoading 1 platforms...
4/11/2023, 7:40:32 pmSpa BridgeBridge is running on port 51836.
4/11/2023, 7:40:32 pmSpa BridgeSpaNETPluginERRORError: Unable to login with details provided. Please ensure that you have the correct username and encrypted password (see Github for details).
4/11/2023, 7:40:32 pmSpa BridgeSpaNETPluginWARNINGWarning: SpaNET plugin inactive. Please address specified issue and reboot Bridge to re-attempt setup.
Suggestions?

Hey @darrendrysdale, it appears you are still on the old version as this error message is not in the new version I published. Please ensure you are on version 2.0.0 or update with npm i -g homebridge-spanet.

Thanks @BlaT2512 , I was using a HB client and thought it had updated but obviously not. Have tried again and getting this error:
8:28:46 pmWARNINGplugin site unavailable
8:28:47 pmyarn add v1.22.19
8:28:47 pm[1/4] Resolving packages...
8:28:48 pmerror An unexpected error occurred: "https://registry.yarnpkg.com/homebridge-spanet: getaddrinfo EAI_AGAIN registry.yarnpkg.com".
8:28:48 pminfo If you think this is a bug, please open a bug report with the information provided in "/var/lib/hoobs/spabridge/yarn-error.log".
8:28:48 pminfo Visit https://yarnpkg.com/en/docs/cli/add for documentation about this command.
Possibly it's not accessing the updated version and I can check again tomorrow, wonder if you have thoughts though.

This is odd @darrendrysdale , I don't use yarn but just made a folder and tried yarn add homebridge-spanet and worked fine. Looks like this is normally a yarn bug or internet/vpn issue or something https://stackoverflow.com/questions/54254121/error-an-unexpected-error-occurred-https-registry-yarnpkg-com-react-getaddr
Maybe try updating through the homebridge online UI, restart, reconnect internet or wait till tomorrow and hopefully fixes itself.

Thanks @BlaT2512. Possibly it's an issue with Hoobs. I'll check tomorrow and if still happening look at another way to install/update. Appreciate your help.

No worries @darrendrysdale, let me know how it goes. Can always locally clone the repo if needed.

Hey @BlaT2512. I attempted to ssh to hoobs terminal and install the home bridge-spanet package that way but I'm still getting error. Not sure if you can help me find another way to get around this yarn error - you did mention clone but apologies Im not sure how to do that but am willing to try if you can lead me through it

Thanks for the update!
I’ve updated and get “crypto is not defined error”, see below.
@.***
From: Blake Tourneur @.>
Sent: Saturday, November 4, 2023 8:20 PM
To: BlaT2512/homebridge-spanet @.>
Cc: Shayne O'Brien @.>; Mention @.>
Subject: Re: [BlaT2512/homebridge-spanet] Warning: This plugin slows down Homebridge. (Issue #6)
@darrendrysdalehttps://github.com/darrendrysdale @shayneobhttps://github.com/shayneob @joelhinchhttps://github.com/joelhinch @aldobalduccihttps://github.com/aldobalducci @TheTeeDothttps://github.com/TheTeeDot Apologies for the very long delay, been very busy and hardly on Github the past few months. Have rewritten and just about to publish new version of the library, haven't tested it that much so please feel free to let me know how it works for you and any bugs encountered, feature requests or make pull requests. Cheers
It is not necessary to run the plugin on a child bridge, however due to the SpaNET api rate limit 3 requests per second, when the Home app requests to refresh all the spa accessories it takes a good 5-6 seconds. So if you have lots of other devices on Homebridge, may be a good idea to make it a child bridge still to improve speed.
—
Reply to this email directly, view it on GitHubhttps://github.com/BlaT2512/homebridge-spanet/issues/6#issuecomment-1793368619, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ASZYV6APZKD6H2XU7WS3YQDYCXUALAVCNFSM6AAAAAATTZEGPKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOJTGM3DQNRRHE.
You are receiving this because you were mentioned.Message ID<EMAIL_ADDRESS>

@shayneob Have fixed this, will push in an update once I fix one other thing in the next couple hours

@darrendrysdale This does look correct, strange you are still getting the error. You could try these commands to manually install it:
git clone https://github.com/BlaT2512/homebridge-spanet
cd homebridge-spanet
yarn run build
yarn link

Thanks so much for putting in the work here. I am having some trouble setting the Operation Mode: Normal/Away doesnt seem to stick. Just reverts?

@joelhinch Yeah same for me going to fix that shortly. Setting a lot of the controls has strange behaviour like the jets turn on when clicked but are stuck saying loading, will work to fix it all. Have also reduced the time for refreshing all the devices now from 6 seconds to 1.

@joelhinch Yeah same for me going to fix that shortly. Setting a lot of the controls has strange behaviour like the jets turn on when clicked but are stuck saying loading, will work to fix it all. Have also reduced the time for refreshing all the devices now from 6 seconds to 1.

Awesome! Thanks a heap.
Do you use home assistant at all? I’ve actually got homebridge paired directly to home assistant so I can use this plugin. Which works well enough. Have you ever consider writing the plugin for HA?

@joelhinch I do not use home assistant, however would be open to this. Just quickly googled and appears intergrations are written in Python, doesn't look like it'd be too big an effort to port it over so I will consider this in future.
Also please find fixed operation mode switch in the latest release just published

Hi @BlaT2512 I appear to be getting a bunch of errors, but things seem to work.

@shayneob Appears still rate limit error happens every now and again which causes these errors, happens for me about every 20th open of the home app. Will try work again on the rate limiting in next release

@joelhinch I do not use home assistant, however would be open to this. Just quickly googled and appears intergrations are written in Python, doesn't look like it'd be too big an effort to port it over so I will consider this in future.
Also please find fixed operation mode switch in the latest release just published

youre an absolute champion! would be amazing to have it direct if you do get around to it one day. i love homekit but have started moving to homeassistant (have been holding off for so long)

Hey Blake @BlaT2512. Managed to install finally however it seems the temp settings for spa are not coming across (unless I am doing something wrong). I have cleared the Homebridge cache and installed a couple of times but result still the same. Is this a known issue or something I need to fix on this end.
Thanks D

Hi Blake @BlaT2512
Is there a way to soecify the power save level? You have on/off but it defaults to low, rather than high when on, (spanet has 3 states for power save, off, low, high). Trying to automate when my spa is allowed to heat. Cheers!

Hi @joelhinch , currently you can change whether the switch turns it to low or high by default when switching on in the plugin settings in Homebridge.
However, if you prefer it to be similar to the operation mode with 3 seperate switches for off, low and high let me know.
Cheers

Hi @joelhinch , currently you can change whether the switch turns it to low or high by default when switching on in the plugin settings in Homebridge. However, if you prefer it to be similar to the operation mode with 3 seperate switches for off, low and high let me know. Cheers

Thats fantastic @BlaT2512 I missed that, but have found that setting and turned it on. This is great as is, the low setting is kind of irrelevent in most use cases when schedules can accomplish the same thing.

Hi @joelhinch , currently you can change whether the switch turns it to low or high by default when switching on in the plugin settings in Homebridge. However, if you prefer it to be similar to the operation mode with 3 seperate switches for off, low and high let me know. Cheers

@BlaT2512 hi mate I have the option ticked but it still seems to switch to Low not High. Are you able to test to see if the behaviour is the same on your end? Thanks!

Hi @joelhinch, I was not able to reproduce this bug on my end. The only thing I can think of is that you didn't restart Homebridge after changing the setting, as the plugin loads the config when it first starts up. Try restarting Homebridge and let me know if that works.

Hey Blake @BlaT2512, I have now installed plugin under Hoobs and it brings down all function except the spa temp function. Is this something that others have experienced or is there a way to correct this within the config. Appreciate any support that may help fix this, Cheers.


ESP32 Flashed but now cannot connect to the AP

I see Smoke X Receiver show up in the SSID search briefly occasionally but not every time I reset the esp32.  When I do and put in the password, it says its unable to connect and then I have troubles seeing the SSID again.  Any ideas?  Ive tried in linux and on my Mac.

Ok, try pulling the latest commit (c35e0bf and build/flash to your esp32. The bootloop should be fixed and you'll be able to connect any device to the Smoke X in its default AP mode. From there you can continue the rest of the configuration.

got it connected.  now stuck at the Sync.  My smoke x isn't getting the sync pulse from the lora.  I do have the x4 wonder if that different?

The web UI doesn't automatically refresh after a successful sync. Try refreshing your browser to see if the sync status changed. If not, I'll probably need your help to understand what the X4 sync message is though a more verbose debug build.

Nope no success. Let me know what you want me to try!  I appreciate your help this project is awesome!  I was going to try to write something but I found this before I started!

Ok, if you pull the latest commit, the esp32 should dump the received raw bytes to the log by default now. You'll need to capture the esp32 logs with make monitor while you attempt the sync. This will display the bytes received on the sync channel (920 MHz). It's also possible the sync is succeeding, but I made an incorrect assumption of the X4 data packet which is causing a crash during the parsing. If you paste your logs, I should be able to figure it out. Also, if you happened to have already played around with the LoRa radio and know what the data format is already, I can just implement it quickly.
Here is the log of my X2 during a successful sync (the first two lines describe the sync packet):
I (37578) app_lora: Packet received - Size: 27 RSSI: -71, SNR: 8.000000
I (37578) app_lora: 000000,|dhHWl,160,32,69,54,
I (37578) smoke_x: Received sync message: 000000,|dhHWl,160,32,69,54,
I (37588) smoke_x: DeviceID set to: |dhHWl
I (37588) smoke_x: Frequency set to: 910500000 MHz
I (37598) app_lora: Setting radio parameters
I (37698) app_lora:   Frequency 910500000
I (37698) app_lora:   Bandwidth 125000
I (37698) app_lora:   Spreading Factor 9
I (37698) app_lora:   Transmit Power 12
I (37698) app_lora:   Coding Rate 5
I (37708) app_lora:   Sync Word 18
I (37708) app_lora:   Implicit Header 0
I (37718) app_lora:   CRC Enable 1
I (37718) app_lora: New radio parameters set
 f=910500000
 bw=125000
 sf=9
 tx_power=12
 cr=5
 sync=12
 impl_hdr=0
 crc_on=1

I (38728) smoke_x: Sending sync acknowledgement to transmitter
I (38908) app_lora: 15 bytes transmitted (|dhHWl,SUCCESS,)
I (39658) app_lora: Packet received - Size: 48 RSSI: -70, SNR: 11.000000
I (39658) app_lora: |dhHWl,30,1,1,0,766,1,200,32,0,766,1,160,32,0,0,
I (39668) smoke_x: Received data transmission from |dhHWl, saving config
I (39668) smoke_x: X2 DATA: |dhHWl,30,1,1,0,766,1,200,32,0,766,1,160,32,0,0,
I (39678) app_mqtt: Sending Home Assistant MQTT Device Discovery

I'm glad I finally have an X4 user to test and fix the code!

here's what I get...  I tried it a couple of times with same result.
'I (646) smoke_x: Device is not paired, waiting for sync on 0
I (2666) app_lora: Setting radio parameters
I (2766) app_lora:   Frequency 910500000
I (2766) app_lora:   Bandwidth 125000
I (2766) app_lora:   Spreading Factor 9
I (2766) app_lora:   Transmit Power 12
I (2766) app_lora:   Coding Rate 5
I (2776) app_lora:   Sync Word 18
I (2776) app_lora:   Implicit Header 0
I (2776) app_lora:   CRC Enable 1
I (2786) app_lora: LoRa module initialized
I (2786) smoke_x: Frequency set to: 920000000 MHz
I (2796) app_lora: Setting radio parameters
I (2796) app_lora:   Frequency 920000000
I (2806) app_lora:   Bandwidth 125000
I (2806) app_lora:   Spreading Factor 9
I (2816) app_lora:   Transmit Power 12
I (2816) app_lora:   Coding Rate 5
I (2826) app_lora:   Sync Word 18
I (2826) app_lora:   Implicit Header 0
I (2826) app_lora:   CRC Enable 1
I (2836) app_lora: New radio parameters set
f=920000000
bw=125000
sf=9
tx_power=12
cr=5
sync=12
impl_hdr=0
crc_on=1
I (2846) app_lora: Starting LoRa Rx
I (2866) wifi:wifi driver task: 3ffc6798, prio:23, stack:6656, core=0
I (2866) system_api: Base MAC address is not set
I (2866) system_api: read default base MAC address from EFUSE
I (2876) wifi:wifi firmware version: eb52264
I (2876) wifi:wifi certification version: v7.0
I (2876) wifi:config NVS flash: enabled
I (2876) wifi:config nano formating: disabled
I (2886) wifi:Init data frame dynamic rx buffer num: 32
I (2886) wifi:Init management frame dynamic rx buffer num: 32
I (2896) wifi:Init management short buffer num: 32
I (2896) wifi:Init dynamic tx buffer num: 32
I (2906) wifi:Init static rx buffer size: 1600
I (2906) wifi:Init static rx buffer num: 10
I (2916) wifi:Init dynamic rx buffer num: 32
I (2916) wifi_init: rx ba win: 6
I (2916) wifi_init: tcpip mbox: 32
I (2926) wifi_init: udp mbox: 6
I (2926) wifi_init: tcp mbox: 6
I (2926) wifi_init: tcp tx win: 5744
I (2936) wifi_init: tcp rx win: 5744
I (2936) wifi_init: tcp mss: 1440
I (2946) wifi_init: WiFi IRAM OP enabled
I (2946) wifi_init: WiFi RX IRAM OP enabled
I (2956) app_wifi: Wifi config SSID: Hardin1
I (2956) app_wifi: Wifi config password: katiedog
I (2966) phy_init: phy_version 4670,719f9f6,Feb 18 2021,17:07:07
I (3066) wifi:mode : sta (7c:9e:bd:5b:bc:4c)
I (3066) wifi:enable tsf
I (3186) app_web_ui: Partition size: total: 956561, used: 268319
I (3186) app_web_ui: Starting HTTP Server
I (4046) wifi:new:<9,0>, old:<1,0>, ap:<255,255>, sta:<9,0>, prof:1
I (4896) wifi:state: init -> auth (b0)
I (4906) wifi:state: auth -> assoc (0)
I (5046) wifi:state: assoc -> run (10)
I (5186) wifi:connected with SSID, aid = 2, channel 9, BW20, bssid = 16:0c:6b:44:e1:6c
I (5196) wifi:security: WPA2-PSK, phy: bgn, rssi: -54
I (5196) wifi:pm start, type: 1
I (5236) wifi:AP's beacon interval = 112640 us, DTIM period = 3
W (5586) wifi:idx:0 (ifx:0, 16:0c:6b:44:e1:6c), tid:0, ssn:0, winSize:64
I (6146) smoke_x_main: IP address obtained
I (6146) esp_netif_handlers: sta ip: <IP_ADDRESS>, mask: <IP_ADDRESS>, gw: <IP_ADDRESS>
'

Can you try waiting a little bit longer after esp32 reset before attempting the sync? I'm not seeing any received bytes. The esp32 resets automatically when you invoke make monitor. The esp32 is parked on the sync frequency so there is no rush.

Also, FYI, the logs display your WiFi creds within the first few seconds of booting. Sorry I forgot to warn you about that.

Thanks I saw that after posted. I've edited it.  Given it a bit of time before putting the smoke x in to sync with nothing received in the log.

Please confirm you're using the latest commit and have recompiled and reflashed (the latest commit should display all received bytes whether or not they are recognized smoke x packets). Otherwise we'll need to find some way to discover the sync frequency for the X4. Do you have an rtlsdr?

App "smoke-x" version: e258115
yep just fetched it again to verify, I'm not getting any hits in the log.  I've got a hackrf and im looking at the spectrum, any specific frequency profiles im looking for?

Set the hackrf in the 915 ISM band and put the smoke-x in sync mode. Make sure it stays in sync mode and watch the spectrum for a loud fairly long (half second or so) chirp spread spectrum burst. X2 syncs at 920.000 MHz every 5 seconds or so.

yep looks like its 917 MHz

Nope I think its 915, moved the transmitter around and it varied the strength.

On the spectrum, the signal should appear to be a very narrow sinusoid that sweeps linearly over time with a span of 125kHz. The pattern of the sweep varies to represent the modulated bits. The sync burst is around 0.2 seconds in duration and repeats every 3 seconds. An example from my X2 is shown below:

If you can confirm your sync burst is similar to the above, it's probably just a software difference between the X2 and X4...let's hope that's the only one of significance! We can patch your code to get you running, but we'll eventually want the esp32 to monitor both 920 and 915 during the sync phase (i.e. dwelling on a freq for 1 second and then swapping).

If you want to give 915MHz a try now, make the following change in https://github.com/G-Two/smoke-x-receiver/blob/e258115d41c3b349914bf4c16286d22ebede4793/main/smoke_x.c#L11
to:
#define SMOKE_X_SYNC_FREQ 915000000

Compile/flash and your esp32 will now monitor 915MHz for the sync burst.
If you could, please have make monitor running during the sync attempt and send me any logs that show the bytes received over LoRa. My X4 parsing is just a guess based on extrapolating the X4 data format, and I'd be surprised if there were no errors.

I will give it a shot tonight. I’ll try to get a IQ capture of the sync pulse and convert it to time domain… will take a bit of MATLAB work but I’ll see what it can come up with and let you know.

On Aug 26, 2022, at 08:27, Garrett @.***> wrote:

If you want to give 915MHz a try now, make the following change in https://github.com/G-Two/smoke-x-receiver/blob/e258115d41c3b349914bf4c16286d22ebede4793/main/smoke_x.c#L11
to:
#define SMOKE_X_SYNC_FREQ 915000000
Compile/flash and your esp32 will now monitor 915MHz for the sync burst.
If you could, please have make monitor running during the sync attempt and send me any logs that show the bytes received over LoRa. My X4 parsing is just a guess based on extrapolating the X4 data format, and I'd be surprised if there were no errors.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.

I (7524) app_lora: Packet received - Size: 71 RSSI: -57, SNR: 13.750000
I (7524) app_lora: 4oF_Ee,30,1,1,3,0,1,203,32,3,0,0,160,32,3,0,0,160,32,3,0,1,275,225,0,0,
I (7534) smoke_x: X4 DATA: 4oF_Ee,30,1,1,3,0,1,203,32,3,0,0,160,32,3,0,0,160,32,3,0,1,275,225,0,0,

used another esp32 and got it to provide the packet

Great, glad the receiver is working! This was with the code patched to sync on 915 MHz, correct?
I think I may have only implemented two probes on the web UI. I'm pretty sure the backend is parsing all the probes and passing their data to the web browser, but the vue component is just not graphing them for you on the front end.

Correct 915MHz for sync. What’s the best way to grab the data to store it?  I know you said the http api get do you have an example?

On Aug 26, 2022, at 21:59, Garrett @.***> wrote:

Great, glad the receiver is working! This was with the code patched to sync on 915 MHz, correct?
I think I may have only implemented two probes on the web UI. I'm pretty sure the backend is parsing all the probes and passing their data to the web browser, but the vue component is just not graphing them for you on the front end.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.

I designed it to work best with MQTT. The esp32 publishes the information from each received smoke-x data burst to a local MQTT broker I have running on my network. I have an MQTT  subscriber (home assistant) that then receives the data and stores it in its local database. It also forwards the data to an influxDB instance for longer term storage and query.
Home Assistant really does all the magic when it comes to handling the data after the esp32 publishes it. But any MQTT client could work with it.

You could also write a script to use the http interface to periodically get http://smoke_x/data and record the current temperatures from the JSON response.

The original issue has been solved, so I'm going to close this. I opened up two new issues that describe the X4 problems that still remain.

@MikonosII please give b4fe55c a try and let me know if all four probes show up in the web UI. Sync on 915 or 920 MHz should happen automatically now as well without the need to patch the code.

Great! Are all 4 probes plotted?

Yep! No issues!

On Aug 30, 2022, at 20:28, Garrett @.***> wrote:

Great! Are all 4 probes plotted?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.


Path glitch when rendering to Canvas and when clipping.

When certain Paths are combined either for painting or clipping, a slight vertical and/or horizontal gap appears between the paths that are combined when there should be no gap.
The visual artifact can be reproduced at least on an Nexus 5X and an iPhone 7, though the artifacts are slightly different on each.  It is also possible to see a visual artifact in the iPhone simulator, and possibly also in an Android emulator.
An example of code that causes the issue can be found at the link below with relevant code starting at line 588:
https://github.com/matthew-carroll/flutter_ui_challenge_springy_slider/blob/6989f19b6ed7a6a9de094cbeb49434ffb98213cb/lib/main.dart

I have verified that this is an issue with Skia. The engine does not seem to be introducing any additional layers or populating raster cache entries. An SKP dump of this scene is available here.

I was able to reproduce this on an iPhone 8.

cc @brianosman

This was brought up in the Skia sync and the update says @reed-at-google is talking a look. Thanks.

@matthew-carroll Is this still an issue?
The repro code link leads to a 404 for me so I can't check it without the code.

Without additional information, we are unfortunately not sure how to resolve this issue.
We are therefore reluctantly going to close this bug for now.
Please don't hesitate to comment on the bug if you have any more information for us; we will reopen it right away!
Thanks for your contribution.
Could everyone who still has this problem please file a new issue with the exact description of what happens, logs, and the output of flutter doctor -v.
All system setups can be slightly different, so it's always better to open new issues and reference related issues.


Table rows without Roman numerals / columns without letters

E.g. Ch. 13 p. 1099 [1]

(Receiving # from add_page_numbers.py but not making it into YAML)

Ch. 3 p. 209

Ch. 3 p. 210

Ch. 4 p. 251

Ch. 4 p. 258 (note lexical row headers):

Ch. 4 p. 261 [24], [25], [26]
Ch. 5 p. 338

A tricky one: postTags describing relation between column entries
ch. 3 p. 176

ch. 5 p. 455 (also [16] on p. 456): feature-value matrix where the sentences are row headers. Currently the column-headers are omitted (maybe that's OK).


Migrate from Travis to Github Actions

Migrations should be quite easy, it should be enough to reimplement same steps in travis.yml to Github Actions config.
PLEASE if you're going to start working on this issue, comment below, to discuss the solution, thanks in advance.

Hello, I'm interested on this issue. Can I do it? I'll start by reimplement from the travis.yml

@gnomeria yep, good luck

I was having an issue with uploading the cover results to the coverall using goverall. Do you think we could switch to Codedov @cristaloleg ?

@gnomeria yeah, coverall returns 5xx last weeks as I see (other projects too). I'll make an issue regarding migration (let's make it in separate PRs, please)

Fixed in #180


gqap results in "par error: Impossibility #5 has occurred. Please report it."

How to reproduce this bug:
Linux, create a document without extension.
Fill in random Chinese paragraphs (Chinese characters in unicode take two slots instead of one)
use gqap, I get the error in the title, and the paragraph is completely gone.

After some googling, I disabled "use par for prettier line formatting" in .vimrc
In my opinion, this default option is pretty dangerous, because it empties out the paragraph it tries to format.

What's a better formatting program we should use?

I have no idea. vim default seems fine.


Add platform-specific window code

What I'm proposing is that platform-specific window code be added to winit, such as override-redirect, setting Atoms, etc. on Xorg. This would be very useful to my current project, and allow it to be implemented in a much less hacky way. I'd be willing to write a PR for this if you would be willing to potentially merge it.

The API design already exists: https://github.com/tomaka/winit/blob/master/src/os/unix.rs
What may need to be discussed is the actual platform-specific features to expose.

I think we should expose override-redirect at the very least, since that would only require changing a few lines of code. We could also provide a way to create Atoms, like setting _NET_WM_WINDOW_TYPE = _NET_WM_WINDOW_TYPE_DESKTOP. The other thing I need personally is XLowerWindow, but I'm sure other people have other things they'd like to see.

For Alacritty, we use the following platform-specific APIs

XSetWMProperties - causes WM_CLIENT_MACHINE to be set which is required to set _NET_WM_PID. This is actually used to set a number of properties including WM_CLASS. It's nice to be able to call this before mapping the window so WMs can apply rules immediately.
XInternAtom - required for creating atoms
XChangeProperty - we're only using this to set _NET_WM_PID; it uses an Atom returned from XInternAtom

I'm not sure it's appropriate for winit to serve as a low-level platform-specific API binding. I think we already expose all the handles necessary to do whatever stuff you want yourself, and handling everything that people might commonly want could be a very large project.

Long term, platform::linux::x11::util could be extracted into its own library, but that's not something I'm interested in doing any time soon. I don't believe it's appropriate for winit to expose any general-purpose X11 abstractions; besides the more obvious aspects of maintaining winit's API surface area and concept, X11 is footgun-heavy, and I'd rather people just request/PR any window configuration stuff they need.
@ashkitten do you still need this? Anything that can be reasonably abstracted via WindowBuilderExt can generally be added without much hassle.
@jwilm in the near future I plan on improving the situation with hints on X11, specifically aiming for ICCCM+EWMH compliance and removing the need for directly calling Xlib stuff in Alacritty.

I would still love to have this, if it would allow me to set properties on windows before they are mapped (right now I have to hackily create the window, set override-redirect, and unmap/remap it)

@ashkitten is override-redirect all you need? I can likely get that done before the next release.

I'd prefer to be able to set Atoms such as _NET_WM_WINDOW_TYPE but override-redirect is the main thing bugging me.

Is this good? #529

Okay, so apparently both EventsLoopExt and WindowExt have a method called get_xlib_xconnection. it's #[doc(hidden)] on EventsLoopExt, but not on WindowExt (I imagine this discrepancy is unintentional, and it should probably always be hidden). Anyway, the reason this matters is because I just merged #534, which means I've unintentionally given you (undocumented) access to a bunch of X11 utils. Even if I hadn't done that, the entire X11 module has been secretly exposed here for a long time: https://github.com/tomaka/winit/blob/30f798b24608aaee9b727f40fb051ad66f445920/src/os/unix.rs#L15-L17
This means you can do stuff like this:
use winit::os::unix::WindowExt;
use winit::os::unix::x11::util;
let xconn = window.get_xlib_xconnection().unwrap();
let prop_atom = unsafe { xconn.get_atom_unchecked(b"CUTEST_CONTRIBUTOR\0") };
let type_atom = unsafe { xconn.get_atom_unchecked(b"UTF8_STRING\0") };
xconn.change_property(
    window.get_xlib_window().unwrap(),
    prop_atom,
    type_atom,
    util::PropMode::Replace,
    b"francesca64\0",
).flush().expect("Failed to set `CUTEST_CONTRIBUTOR` property");

While this likely goes without saying, this API is unstable and unsupported, so use at your own risk.


Add the option for a unified app button, for both the Convenient Effects app and the Remove Effects app.

This is a personal preference to save sidebar buttons real estate, which you might find interesting.
It breaks Foundry convention of one sidebar button one function, so it is totally understandable if this isn't implemented in the end 👍
Note: It has some mentions to additions made in the https://github.com/DFreds/dfreds-convenient-effects/pull/282 , which even though not breaking, might be a bit conflicting.

Remove the secondary button added by DFreds remove effects app and using an event to open it if needed.
Add a World setting for choosing to unify the buttons and choose the relevant key to use alongside left mouse click to open the remove effects app.
Will respect the settings for visibility of the apps based on game.user.role

Might also need a meta key option if the client is Apple based, but not sure how to implement that.

Cool stuff. Honestly, I don't really see the point of explicitly letting them choose what key would open it. Could probably just go with shift left-click always, and state as such in the setting as well as the hover text. That's my one overall suggestion. Thoughts?
I'll review what you have though.

Reviewed, some minor things. Make sure to format with prettier as well.
Also, I could probably be convinced this should just be the default behavior without any settings. But maybe too breaking of a change

Will take a stab at these later.
My initial version had only an on/off setting for using the Shift + LMB combo. So I will just revert to that one.


Roadmap to a production ready version?

Hey Carlos, first of all thank you for your hard work on bootstrap-vue-3.
In the documentation you mention that this library is not production ready and still is in alpha version.
Is there a list of components/features/requirements that are still needed for this library to reach a production version?
I would like to upgrade the product I work on to this repo, and want to contribute to this library in order to reach a production ready version

Hi & thanks,
Feel free to contribute with whatever you're missing from your project. We could also use help on

building docs (having an error now; might be useful to migrate from vuepress to vitepress)
reviewing all form components (maybe comparing with bootsrap-vue) and adding what's missing

Also see https://github.com/cdmoro/bootstrap-vue-3/projects/1


Fixes submodule build failure

moving header from checkstyle to plugin allows users to run from subproject as well
Fixes https://github.com/Microsoft/azure-spring-boot-starters/issues/46
@xscript @yungez @aovechki @ZhijunZhao

@rajadilipkolli,
Thanks for having already signed the Contribution License Agreement. Your agreement was validated by Microsoft. We will now review your pull request.
Thanks,
Microsoft Pull Request Bot

Codecov Report

Merging #60 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master      #60   +/-   ##
=======================================
  Coverage   21.45%   21.45%
=======================================
  Files          32       32
  Lines         564      564
  Branches       45       45
=======================================
  Hits          121      121
  Misses        428      428
  Partials       15       15

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 53d0c62...f8e39df. Read the comment docs.

Wrong fix hence closing


Formrecognizer update to ResponseError usage

API change check
APIView has identified API level changes in this PR and created following API reviews.
azure-ai-formrecognizer


interactive combat chat cards

combat cards should chain, so an attack provides a clickable for the defender, which potentially provides a clickable for the attacker, and so on.

Hi,
i was thinking to take this issue. As a first step, my idea was to implement alt+click to select a target as it's made in some modules :

before rolling attack
after rolling attack
after rolling attack, by the DM

then

display target's name in the attack card
if target is set after rolling, resend a new card or redisplay the old one if possible
if card.target = himself, display defend option

I'm in the middle of a fairly heavy refactor of most parts of the game (replacing old placeholder code with something a little less ridiculous). Specifically, things having to do with stats of any kind are shifting. I'm worried some of the work you do here will break with some of my own PRs, once they get to the dev branch. Still, I don't believe this sort of addition would break very much, as I don't believe this issue heavily touches the areas being redesigned.
Even were this not the case, it's probably much wiser to keep this sort of thing stateless and simple until the game system matures a bit more. Many of the subsystems are little more than stubs and could shift wildly once they finally -are- refactored. It's wise to 'go small' to start.
I believe the following is more reasonable if you'd like to take this on.

No targeting.
Attack cards include a button which anyone may press to bring up a defend dialog.
Defend cards include a button which anyone may press to bring up a damage dialog.
Damage cards include a button which anyone may press to automatically wound their character.

This would provide a third way to interact with the game (Character sheet, combat macros, and chat carts), while cleaning up the chat manager in the process.
No targeting yet, simply because we'd need to push target data into the dialog->roll->chat pipeline somehow, and that system is quite immature. It would probably create technical debt for less value. Also to clarify, by 'card' I am referring to the Chat message sent to everyone.
You'd want to create actual combat card templates (the one in templates/chat/spell.hbs was meant as a test of concept), and I imagine some scss additions might be necessary as well. Most of the necessary jQuery bindings probably exist already in actor-sheet.js. It's unclear if you could reuse them directly, or if ChatMessage would need to be overloaded in some fashion (which I suspect may be the case).

Thank for the answer.
If you do have issues that won't break up the current refactoring, and are newbie-friendly, i will glady look into them.
I may also wait the refactoring is complete if you think it's the best option for now.
Otherwhile i can do the suggested work on attack, defend and damage card :)

Yeah, it's just a fact that this issue touches on lots of the internals and probably isn't a great choice if you're not ready to dive in. I think you'd have a lot of trouble with this one. I'll try to earmark a few simpler tasks which need to get handled and will set them as good first issues, though.
Learning the basics of foundry will help you immensely and I highly recommend the boilerplate system. You can find it and a tutorial here. It's what I started with, and it made things a lot clearer. I saw you started a foundry system. You'd be hardpressed to find a better start for it than this!


Fix install for MongoDB extension

Azure Data Studio Version: 1.40.2 Insider
OS Version:  Windows 11

Steps to Reproduce:

Within extension gallery select MongoDB for ADS extension
Install takes you to the GitHub page, it doesn't launch the visx

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

The Mongo extension install appears to working as expected following the merge of the referenced PR.


O12S Hello World alerts multiple times

During HW, the alert pops up every second your debuff goes down until it pops. Not sure what is causing the issue but it hasn't happened until today.

I think this is the same as #473.  It should get fixed in the next version of the plugin.

This should be fixed now.


Power Restructure and New Generators

!!Mapping ID changes!!

SalternAPC > APCBasic
SalternSMES > SMESBasic
SalternSubstation > SubstationBasic
SalternGenerator > GeneratorBasic

There is now also GeneratorPlasma (kW) and GeneratorUranium (15kW) which you may prefer to use instead as they produce a decent amount of power.
About the PR
This PR was originally just going to be wallmount stuff for more compact shuttles and escape pods but scope creep. So this PR:

Adds a wallmount substation at 2MW (half the big substation capacity).
Adds a wallmount generator at 3kW (same as the existing small generator).
Adds a 6kW wallmount generator (APU) specifically for shuttles and escape pods. Should power 2 thrusters, console and lights.
Adds the TG portable generators (plasma and uranium, 5kW and 15kW respectively). Currently no fuel consumption as that's above me.
Adds the RTG (20kW). Traditionally these were lower power but then they'd be useful for lighting only. This can atleast power an abductor ship or tiny outpost. There's a damaged variant that emits radiation 2 tiles and are intended to be obtained from derelicts only. (In future would be nice to have them only emit rads when open or damaged and to produce fallout when destroyed).
Renamed all SalternPower stuff to PowerBasic e.g. SalternSMES is now SMESBasic. Also moved each power structure to it's relevant file to get rid of the SalternPower file.
Added APCs for each of the large power cell states. Also buffed large power cells to match. The existing APC / normal large power cell was actually useless. PRing as a draft as I imagine this will be under discussion whether these are needed. Future PRs that use large cells will just have to adapt their power usage to be balanced.
All power stuff now has a suffix with it's power supply / capacity so mappers can see at a glance.
Made generators now blow up with the same values as substations. They don't produce any debris currently.

Currently awaiting some feedback hence draft.
Screenshots

Screenshot was prior to changes. Scroll down for improved portagen animation and TEG glow.

Example of the wallmount stuff. The HV cable under them will need to be made before the wall unless cable terminals can be used.

APC sizes. Note the duplicate high was fixed to super. In future each APC will have the correct cell inside.

Damaged RTG

Improved portagen animation - It now loops properly. The power level going up and down can be attributed to the generator being not so efficient since it's consuming raw sheets of fuel of varying grades (hypothetically for now).

Changelog

:cl:

add: Added new generator types: 2x portable generators. Research their boards to build them.
add: Added the RTG. Find them in a deep space wreck and try not to get burnt...
add: Added wallmount generator and substation for use in shuttles and escape pods.

Not sure what exactly is wrong with the RSI as it's the same as the rest format wise.
I still need to add construction in for the generators and maybe for the different APCs so they can be built (in future it will just be changing out the cell).
These generators will probably end up being a machine frame construction.

Passes tests but construction graphs don't work on local soooo, interesting.

Probably better to split this pr as:

it has mapping changes
it has a bunch of new content that needs checking
it changes a bunch of existing content that also needs checking

Probably better to split this pr as:

it has mapping changes

it has a bunch of new content that needs checking

it changes a bunch of existing content that also needs checking

Good idea. Got bogged down in construction graphs so I'll split this into new stuff in one and changes in the other.


chore: Align snapshots in expect

Summary
Display colors concisely and clearly to review changes quickly and confidently
Too bad about the blame, but the next pull request to expect will illustrate the benefit
Test plan
Updated 903 snapshots:

file

1
assertionCounts.test.ts.snap

7
extend.test.ts.snap

521
matchers.test.ts.snap

308
spyMatchers.test.ts.snap

66
toThrowMatchers.test.ts.snap

Substring differences for the win to review changes locally before updating snapshots :)
But double tests for spy and toThrow matchers added insult to eye injury :(

Codecov Report

Merging #8976 into master will not change coverage.
The diff coverage is n/a.

@@          Coverage Diff           @@
##           master   #8976   +/-   ##
======================================
  Coverage    63.9%   63.9%
======================================
  Files         277     277
  Lines       11652   11652
  Branches     2860    2860
======================================
  Hits         7446    7446
  Misses       3576    3576
  Partials      630     630

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 3adb67b...71db313. Read the comment docs.


Add support for filtering based on project name to the API variant of the Timing plugin.

Also extends the searched date range, as the default only covers the past 30 days.

Daniel added filter