Themes

(Includes GM edits)
Closes #234
Closes #112
Out of scope or not PR-specific. Should be a separate issue:

[ ] https://github.com/grantmcdermott/tinyplot/issues/263 Not PR-specific, but more visible in "minimal" theme.
[x] Add space between ylab and axis automatically. This is important when axis labels are horizontal, as is default in many themes. https://github.com/grantmcdermott/tinyplot/issues/112 Update: addressed by https://github.com/grantmcdermott/tinyplot/pull/258/commits/9d1380b4482473b7133334f7a18b4aeac82ec042
[x] Plot region is unbalanced when the title and subtitles are both at top.  Update: addressed by https://github.com/grantmcdermott/tinyplot/pull/258/commits/9d1380b4482473b7133334f7a18b4aeac82ec042

This is great and very much aligned with what I was thinking. Thanks for getting it started :-)
I'm pressed for time at work today, but here's a quick laundry list of some additional adjustments that I'd  liketinytheme() to account for:

tpar options like grid, facet.bg, etc. I'm not sure whether it's worth enabling a separate getHook/setHook mechanism for tpar, or whether we should just set it "manually" inside tinytheme() e.g. tpar(grid. =TRUE)?
IIRC the setHook("before.plot.new", ...) approach didn't always play nicely with legends (e.g., text adjustments, etc.) this might have been particular to the basethemes() implementation but we should double check.
Positioning and font style of the sub argument. Personally, I don't find the default sub implementation useful at all and I always end up customizing my base plot subtitles and captions with ex post calls to title and mtext. (Side note: Maybe we should add a caption argument
Slightly more complicated, but I could imagine a "dynamic" theme that automatically adjusts the plot margin spacing to optimize white space. For example, reducing the top margin if no title is detected. See also #112.

FYI, currently tinytheme() passes ... to tpar(). So all the arguments are supported by default. All we have to do is supply a small set of default settings in a named list called theme_something. Then, tinytheme() applies all of these settings, and overrides explicitly given arguments, plus adds new ones.
I'm not sure we want an exhaustive list here, since there will be too many, and it will  up the location of documentation.

Ipsum theme inspired by hrbrthemes required some new tpar() parameters and some refactoring: adj.main, adj.sub, adj.xlab, etc.
library(tinyplot)

set.seed(48103)
tinytheme("ipsum")

tinyplot(mpg ~ hp | cyl,
  data = transform(mtcars, cyl = factor(cyl)),
  pch = 19,
  main = "Title",
  palette = "okabeito",
  xlab = "Treatment", ylab = "Outcome")

Created on 2024-11-17 with reprex v2.1.0

New side.sub parameter in tpar() allows us to move the subtitle above. This is now default in the "ipsum" theme.
Feature request from here: https://github.com/grantmcdermott/tinyplot/issues/234#issue-2582088422
library(tinyplot)
set.seed(48103)
tinytheme("ipsum")
tinyplot(mpg ~ hp | cyl,
  facet = ~cyl,
  data = transform(mtcars, cyl = factor(cyl)),
  pch = 19,
  main = "Title of this plot",
  sub = "A smaller subtitle",
  palette = "okabeito",
  xlab = "Treatment",
  ylab = "Outcome")

Created on 2024-11-17 with reprex v2.1.0

Nice! These look really great.
PS. On theme_ipsum, I haven't had a chance to look at the code yet, but
does the font family default back to the user's system font if Arial Narrow
is unavailable?
On Sun, Nov 17, 2024, 18:23 Vincent Arel-Bundock @.***>
wrote:

New side.sub parameter in tpar() allows us to move the subtitle above.
This is now default in the "ipsum" theme.
Feature request from here: #234 (comment)
https://github.com/grantmcdermott/tinyplot/issues/234#issue-2582088422
library(tinyplot)
set.seed(48103)
tinytheme("ipsum")
tinyplot(mpg ~ hp | cyl,
facet = ~cyl,
data = transform(mtcars, cyl = factor(cyl)),
pch = 19,
main = "Title of this plot",
sub = "A smaller subtitle",
palette = "okabeito",
xlab = "Treatment",
ylab = "Outcome")
https://camo.githubusercontent.com/1bf3940ca570f9103175cf0558bfa1cf7179e3c5875c48d4b161329cb534c6fc/68747470733a2f2f692e696d6775722e636f6d2f35354466476f492e706e67
Created on 2024-11-17 with reprex v2.1.0 https://reprex.tidyverse.org
—
Reply to this email directly, view it on GitHub
https://github.com/grantmcdermott/tinyplot/pull/258#issuecomment-2481794041,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACOO73M2PRAENRPU5ZKDXVL2BFFRTAVCNFSM6AAAAABR3OJV7SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIOBRG44TIMBUGE
.
You are receiving this because you were mentioned.Message ID:
@.***>

Not sure. Will check.
No need for you to look at this yet. I think it's still pretty far from done.
And I'll probably need your help for margins and drawing area.

@grantmcdermott and @zeileis
I think this is ready for review. Of course, there are many things we could improve the in the current themes, but that can be done iteratively in future release. As a basic design, I think most the pieces are there.
The key trick was to add a new argument tpar(hook=TRUE). That allows standard par() parameters to be persistent across devices and code chunks in Quarto notebooks. It is essential for themes, but it's also a nice feature for users.
I implemented several ggplot2-looking plots, and wrote a vignette about them. There's also a section about how to define custom plots. Rendered versions here:
https://arelbundock.com/tinyplot/vignettes/themes.html
https://arelbundock.com/tinyplot/vignettes/introduction.html#themes

Amazing. Very excited to look into this. I still have to finalise  and push some of my proposed changes to the ridges PR, but will turn to this after.
Qq: Can you say a bit more about why all of the tests change? I know you mentioned this elsewhere, but it would be good to keep a paper trail here.

Qq: Can you say a bit more about why all of the tests change? I know you mentioned this elsewhere, but it would be good to keep a paper trail here.

Sorry, forgot about that. There were only two visual changes:

Micro-pixel level changes in the main title due to using mtext() instead of title(). This allows us to place subtitle below title on some themes.
Slight color difference in the standard axes. I couldn't trace exactly the source of this in the code, but the new axes are better. If you look at the old ones very closely, you'll notice that the axes are sometimes darker than the box, so the overlay stands out in some portions. Now the colors of box and axes are a better match by default.

Neither change is visible to the naked eye at all.

I just had a quick look at the rendered themes vignette. Again, it looks fantastic but one thing I noticed: The grid lines are misaligned with the axis labels. I think that this is an issue stemming from our existing grid logic---rather than than the new themeing architecture----but the lack of axes lines throws into sharper focus.

Wow, this really looks wonderful, very excited to have this functionality!
I just played around a little without digging too deep. And these are the things I noticed or wishlist items that would be "nice to have". Feel free to ignore if this is not useful:

Can I set the default color palette as part of a theme? This is particularly relevant for the "dark" theme where you cannot see anything for the first group when using the factory-fresh color palette.( If/when it is possible to set the default palette, then I would recommend "Set 2" for the "dark" theme.)
For the future, it might even be nice to have a default categorical/qualitative and a default numeric/sequential palette.
The grid color should also be lighter (more similar to the annotation color) in the "dark" theme. Currently, you almost don't notice the grid.
For the custom theme, why do I have to go through options()? Couldn't we just use tinytheme(list(...))?
Instead of the default tinytheme(NULL) I would find it more intuitive to have an explicit tinytheme("default").

Can I set the default color palette as part of a theme?

Done

For the future, it might even be nice to have a default categorical/qualitative and a default numeric/sequential palette.

Will open a separate issue

The grid color should also be lighter (more similar to the annotation color) in the "dark" theme. Currently, you almost don't notice the grid.

Agreed. Done

Instead of the default tinytheme(NULL) I would find it more intuitive to have an explicit tinytheme("default").

Absolutely. Done.

For the custom theme, why do I have to go through options()? Couldn't we just use tinytheme(list(...))?

And with "default", the natural way to specify themes is the same as modifying any of the other themes, as documented in the vignette:
tinytheme("default", col = "red", pch = 16)

New look:
library(tinyplot)

tinytheme("dark", palette = "Pastel 2", pch = 16)
tinyplot(mpg ~ hp | cyl, data = transform(mtcars, cyl = factor(cyl)))

tinytheme("default", palette = "Dark 2", pch = 16)
tinyplot(mpg ~ hp | cyl, data = transform(mtcars, cyl = factor(cyl)))

Excellent work, thank you so much. I just want to re-iterate my suggestion to use "Set 2" as the standard palette in the "dark" theme. Without you get:
tinytheme("dark")
tinyplot(Sepal.Width ~ Sepal.Length | Species, facet = "by", data = iris, pch = 16)

Thus, the first facet appears to be almost empty even though there are black dots there. With "Set 2" we can avoid this because the first color is not black. Additionally, the colors are rather light but still with high chroma:
tinytheme("dark", palette = "Set 2")
tinyplot(Sepal.Width ~ Sepal.Length | Species, facet = "by", data = iris, pch = 16)

I'm not familiar with the palette code.
If we set the default to a palette like "Set 2", it will work Ok regardless of data type? I don't need the condition it on x or y?

Sounds great. I'll set it to Sunset.
For the "default" theme we should obviously stick with the default palette.
Should we use a different one for other light themes?
I think it might be OK to be a bit adventurous here, especially since users can easily override it by specifying palette explicitly in either tinyplot() or tinytheme()

I split the tinytheme() argument in two: palette.sequential and palette.qualitative. I don't think we need to do this in the main tinyplot() function, but having separate options for themes makes sense.
I also set the defaults for dark theme to "Sunset" and "Set 2"
library(tinyplot)
tinytheme("dark", pch = 16)

tinyplot(Sepal.Width ~ Sepal.Length | Species, facet = "by", data = iris)

tinyplot(lat ~ long | depth, data = quakes)

tinytheme("dark", palette.sequential = "YlOrRd", pch = 16)
tinyplot(lat ~ long | depth, data = quakes)

Niiice! :star_struck:
We then need to look at the different plot type_* functions which might also want to select either the one or the other palette as the default setting. For example the type_ridge(gradient = TRUE) should use palette.sequential.
And when we can distinguish these two options, I think it would be great to play around with a few more palettes in the themes. If you want to browse the options in palette.colors() and hcl.colors() you can use https://journal.r-project.org/articles/RJ-2023-071/.
Qualitative: The "default" theme should clearly use "R4". For other themes, "Okabe-Ito" would be a good default (colorblind-safe). Furthermore, "Dark 2" and "Tableau 10" provide nice colorful well-established palettes.
Sequential: Currently, we don't have many displays in tinyplot where it would be important to have a strong luminance gradient (going from light to dark or vice versa). Instead, we often need palettes that have only limited luminance differences because we use the colors for shading points or lines (as exemplified above).  The obvious choice for this would be "Viridis". But alternatives are also available, e.g., "ag_Sunset", "Inferno", "Plasma", "Mako", "Purple-Yellow", "Hawaii", "Batlow", "YlOrRd".
Moreover, if we support heatmaps in the future, then we should also offer themes where the sequential palette has a strong light/dark contrast, e.g., using "YlGnBu" instead of "Viridis" etc.

Sounds good. I selected:

Qualitative Okabe-ito: @zeileis likes it and it is my own top choice.
Sequential Mako: @zeileis and @grantmcdermott both said they liked it in a different issue, and I think it looks pretty and clear. I'm not a fan of viridis, from a purely aesthetic standpoint, so if we can agree on a good alternative like Mako, I'd prefer that.

Internally, we should use try to use get_tpar() to retrieve graphical parameters. This allows an order of precedence among parameters, and a default value.

lol, I think I've come around to "Mako". But really, I don't mind at all either way. Just tell me what to do :)

For heatmaps etc. I would also prefer a palette with a stronger luminance difference like "YlGnBu" or "Mako" etc. But as we are currently mostly using it for shading points/lines w.r.t. a continuous variable, I think that a palette with high chroma throughout is the better default.
Hence, "ag_Sunset" seems to be a good default choice. For the "dark" theme I would recommend to keep "Sunset", though. But it's nice that we have similar palettes for the standard light themes and the dark theme then.

Sold! Sunset and ag_sunset it is.
Should we truncate the black out of Okabe-Ito so that dark is really similar to light themes?
Or are the other colors hard to see as well against charcoal background?

The question of truncating palettes is important for any palette in the themes, I think. For qualitative palettes re-ordering would be useful in addition. One way to support this would be to accept not just palette name but also a vector of colors in the theme. Optionally, we can always turn these into a color ramp function which might be useful, especially for sequential and diverging palettes.
In this specific case: Set2 has eight colors (with light gray being the 8th color) while Okabe-Ito has nine colors (with black being 1st and light gray 9th). If we shuffle the colors from the palettes in some suitable way, then we can also find a setup so that the colors roughly match. The benefit of this would be that you could talk about the "blue" and the "green" group, no matter whether you use the light or dark theme.
Another general question is whether the first color should always be black - only be black if there are no groups - or should always be non-black.
I suggest that we defer these questions to a different issue, though. They will likely need more discussion and experimentation. Maybe we should just say on the manual page that the themes are still work in progress or something like that...

@vincentarelbundock I'm finally able to take a look at this PR again. What's the current status? From memory, we had some minor issue with grid alignment in the "minimal" and family themes. And it looks like we've moved over to the sunset palettes as agreed.
Are the rendered docs that you linked to above up to date? If not, would you mind regenerating so that I can see how things look with the recent updates? Thanks.

@grantmcdermott
Newly rendered site: https://arelbundock.com/tinyplot/vignettes/themes.html
I listed the TODOs in the first post, but I actually think that all of them should be dealt with in separate issues, as they are not specific problems with this PR. For example, the grid misalignment is a general issue; it is just more visible here. Same thing with margins when sub is on top.
The only thing I don't understand is why we don't get y-axis labels in the "minimal" theme. Surely has to do with the facet code, but I don't have a clue. Any ideas?

Super, thanks. I'll look tomorrow.

Busy working through some examples and I noticed that theme resetting doesn't seem to be fully working in an interactive session. In particular, the plot frame (governed by par("bty")) is still missing from the second plot below.
pkgload::load_all("~/Documents/Projects/tinyplot_vincent/")
#> ℹ Loading tinyplot
# apply theme
tinytheme("ipsum")

# plot
tinyplot(Temp ~ Day, data = airquality,
         main = "Daily temperature",
         sub = "Air quality data")

# reset theme to default
tinytheme()

tinyplot(Temp ~ Day, data = airquality,
         main = "Daily temperature",
         sub = "Air quality data")

Ugh, this is a nightmare.

The best way to restore parameters is to close the device.
We cannot close the device in Quarto notebooks.

So I just pushed a commit to call set_saved_par("first", par()) the first time we ever call tinyplot(), so that we record the original parameters. Then, when tinytheme() is called, we check if the session is interactive. If that's the case, then just shutdown the device. If the session is not interactive, then restore with get_saved_par("first").
That might lead to slightly inconsistent results in notebooks and interactive use, if par() was called before tinyplot(). But I'm not sure how to do this otherwise...

Ugh, sorry man. Thanks for checking. I'm slowly working way my through. I think we can get around the use to mtext instead of titles for the main title and still accommodate the subtitles. Only a trivial difference in most cases (as you note), but it ends up being more important for titles with plotmath from my tests. Will continue testing and make suggestions/changes at the end.

Qq: Can you say a bit more about why all of the tests change? I know you mentioned this elsewhere, but it would be good to keep a paper trail here.

Sorry, forgot about that. There were only two visual changes:

Micro-pixel level changes in the main title due to using mtext() instead of title(). This allows us to place subtitle below title on some themes.
Slight color difference in the standard axes. I couldn't trace exactly the source of this in the code, but the new axes are better. If you look at the old ones very closely, you'll notice that the axes are sometimes darker than the box, so the overlay stands out in some portions. Now the colors of box and axes are a better match by default.

Neither change is visible to the naked eye at all.

@vincentarelbundock I've tested some small tweaks the resolve these differences for the "base" case, whilst preserving the functionality that we want for themes (e.g., space allowance for sub at the top). This also means that we can revert back the original snapshots without breaking all of the test. Any objections to me pushing these changes to your fork?

it's all yours!

Ugh, this is a nightmare.

The best way to restore parameters is to close the device.
We cannot close the device in Quarto notebooks.

So I just pushed a commit to call set_saved_par("first", par()) the first time we ever call tinyplot(), so that we record the original parameters. Then, when tinytheme() is called, we check if the session is interactive. If that's the case, then just shutdown the device. If the session is not interactive, then restore with get_saved_par("first").
That might lead to slightly inconsistent results in notebooks and interactive use, if par() was called before tinyplot(). But I'm not sure how to do this otherwise...

Thanks, this fixes the interactive use case... but unfortunately tinytest::test_all() isn't working anymore.
Error in grDevices::dev.off() :
  cannot shut down device 1 (the null device)

Unfortunately, I have to step away from my PC now, so don't have time to troubleshoot. I'll also be heading out of town tomorrow for the (US) Thanksgiving long weekend, so I may not be able to finish my review until next week... But I think we're close. Let's just keep iterating and see how far we get.

The issue is that we try to shut down the device when running tinytest in interactive mode.
You can just run the test suite using the Makefile, from outside R:
make testall

This may be something we want to smooth over before merge, by detecting whether we are in a tinytest run, but I don't think this should hold up the rest of the review.
I'm in no rush at all. Take your time.

Thanks for actioning all those change @vincentarelbundock. I left a few more comments above, but the gist of it is that I'm happy to implement these additional proposed changes if you are okay with it?
Similarly, I'd like to implement a few more themes:

"clean" (similar to "bw" but with darker, dotted grid lines, like the default grid() case, which I personally prefer).
"linedraw" (again, similar to "bw" but with black facet text fill)
"tufte" (floating axes with bty = "n" and grid = FALSE, as well lab = c(10,10,7) to help avoid "short" axis artifacts).
"void"

All of this sounds excellent.
I probably won't have time at all to work on this in the next 10 days. But feel free to push whatever you want directly to the PR.

Deal. Will ping you!

Proof of concept for adjusting margins (par(mar)) and axis lines (par(mgp)) to reduce whitespace:
No witespace adjustment
tinytheme("clean")
plt(mpg ~ hp | factor(am), data = mtcars,
    legend = list(bty = "o"),
    main = "Here is a plot title", sub = "Subtitle of the plot")
box("outer", lwd = 2, col = "hotpink")

With whitespace adjustment
(Side note: We currently have to subtract 2 from the righthand margin b/c of a logic "bug" here in how we avoid recursive legend spacing adjustment. We'll need to update/automate this logic part of the current PR.)
tinytheme(
  "clean",
  las = 0,
  tck = -0.02,
  mgp = c(2, 0.5, 0),
  mar = par("mar") - c(1.5 ,1 ,0 , 2)
)
plt(mpg ~ hp | factor(cyl), data = mtcars,
    legend = list(bty = "o"),
    main = "Here is a plot title", sub = "Subtitle of the plot")
box("outer", lwd = 2, col = "hotpink")

Bonus: Facets
The picture is slightly more complicated for facets, since (ideally) would account for the scaling factor that is applied to axis ticks and labels. Again, hopefully we can accommodate/automate this as part of the internal code logic.
Facet no whitespace adjustment
tinytheme("clean")
plt(mpg ~ hp | factor(cyl), data = mtcars, facet = vs ~ am,
    legend = list(bty = "o"),
    main = "Here is a plot title", sub = "Subtitle of the plot")
box("outer", lwd = 2, col = "hotpink")

Facet with whitespace adjustment (incl. facet scaling factor)
fct_adj_factor = 0.66
tinytheme(
  "clean",
  las = 0,
  tck = -0.02,
  mgp = c(2*fct_adj_factor, 0.5*fct_adj_factor, 0),
  mar = par("mar") - c(1.5/fct_adj_factor, 1/fct_adj_factor, 0, 2)
)
plt(mpg ~ hp | factor(cyl), data = mtcars, facet = vs ~ am,
    legend = list(bty = "o"),
    main = "Here is a plot title", sub = "Subtitle of the plot")
box("outer", lwd = 2, col = "hotpink")

Created on 2024-11-29 with reprex v2.1.1

Oooh, very nice.
Does it work with very long yaxis labels, lie if you multiply the y var by 1000000?

I've just pushed what should hopefully be a simpler (safer?) workaround for setting and reverting themes. The basic idea is that "default" initially retrieves the user's base graphics settings---which are all held in par()---on load. But the "default" theme here is also special, insofar as calling tinytheme()/tinytheme("default")  completely resets the "before.plot.new()" hook after instantiating the original pars. Resetting the hook is important because it allows us to start from a clean slate midway through a session and also means that regular (t)par(x = y) calls are recognized as part of the updated user defaults. E.g. You can run:
tinytheme("dark")
plt(1:10)
tinytheme()
par(las = 1)
plt(0:10)

and the second plot will have horizontal axis labels even though they were specified at load time.
I've tested with Quarto and everything seems to be working as expected there too. Feel free to kick the tyres yourself.

Does it work with very long yaxis labels, lie if you multiply the y var by 1000000?

Not yet, but I'll take a crack at that next; hopefully tomorrow.

P.S.

Instead of the default tinytheme(NULL) I would find it more intuitive to have an explicit tinytheme("default").

This is super pedantic since most users would just call tinytheme() anyway... but I think the argument for the NULL -> "default" change is weaker with the updated code logic. For one thing, "default" here involves resetting to an original state... but that original state can also change as the user invokes manual par(x=y) calls during the session. Personally, I'm tempted to revert back to tinytheme(NULL) if you two agree.

I don't have very strong opinions on this - but I also don't fully get what you are proposing. Do you want to get rid of theme_default() entirely or do you just want to have theme = NULL as the default rather than theme = "default"?
My feeling is still that having an explicit theme_default() and using theme = "default" makes it easier for the user to understand what is going on and to find the corresponding documentation.
But maybe I'm also missing the details of the new logic of the implementation...I haven't been following this thread very carefully. By calling tinytheme(theme = ...) are tpar() settings overwritten or preserved? And par() settings are preserved?

Tried it on my computer, and things look great. Thanks for the better solution!
Looks like you reverted to boldface for the titles. I feel pretty strongly that all our themes except default should use normal weight for the main title. The title is already at the top, and in larger size. Like Robert Bringhurst says: there's no need to shout at your readers. (Also, bold is just ugly, and we're trying to draw pretty plots.)
I also kind of agree with Achim that "default" is more natural, despite the slight complications in implementation that you note. But I don't feel as strongly about that one.

Update: Dynamic margin adjustment is turning out to be a lot harder than expected. Every time I fix one issue, two more appear. Ironically, one of the main sticking points is our new hook mechanism, which conflicts with some of the just-in-time adjustments that we need to make after measuring label widths etc. :-/
I'm still hoping to plug the remaining gaps, but will probably take a few days at least.

Okay, another update. I think I've got dynamic margin adjustment mostly working. Still a few rough edges, but quick demo below.
First, a basic plot for comparison:
tinyplot(
  Sepal.Length ~ Petal.Length | Species, data = iris,
  main = "Dynamic plot adjustment and whitespace reduction",
  sub = "For themes with las = 1, etc."
)

Next, a basic "dark" theme example. Key thing I want to draw attention to is that excess whitespace (esp. around the axis labels and titles) has been removed:
tinytheme("dark")
tinyplot(
  Sepal.Length ~ Petal.Length | Species, data = iris,
  main = "Dynamic plot adjustment and whitespace reduction",
  sub = "For themes with las = 1, etc."
)

Next, a fancier version with a legend but—more importantly—long y-axis labels. Note the left-hand plot margin adjusts to make space for this longer text.
tinyplot(
  I(Sepal.Length*1e9) ~ Petal.Length | Species, data = iris,
  main = "Dynamic plot adjustment and whitespace reduction",
  sub = "For themes with las = 1, etc."
)

Two more examples, just demonstrating that dynamic adjustment also carries over to faceted plots.
tinytheme("clean")
tinyplot(
  I(mpg*1e3) ~ hp | disp, data = mtcars, facet = cyl ~ am,
  main = "Dynamic plot adjustment and whitespace reduction",
  sub = "Works with facets too"
)

tinytheme("dark")
tinyplot(
  I(mpg*1e3) ~ hp | disp, data = mtcars, facet = cyl ~ am,
  main = "Dynamic plot adjustment and whitespace reduction",
  sub = "Works with facets too"
)

# reset theme
tinytheme()

Wow! This looks amazing!!!
Out of curiosity, does the auto margin parameter in tpar() override all user supplied settings, or is it still possible for them to change?
For example, if I think that main and sub are too tight with one a other, can I add some spacing?

Either way, I think this PR is getting massive, and that we should think about merging soon. Then, we can iterate to improve the themes and add flexibility where needed.

Out of curiosity, does the auto margin parameter in tpar() override all user supplied settings, or is it still possible for them to change?
For example, if I think that main and sub are too tight with one a other, can I add some spacing?

Yes and no. It's a bit complicated, but I'll try to explain briefly:
I ended up deciding to narrowly interpret "dynamic" as limited to las adjustment. (That's not completely true b/c there is some minor legend adjustment stuff that happens too, but just go with it for now.)
To that end, the whitespace reduction specifically around the axis titles etc. is actually baked into the theme default mar and mpg settings (see here). We could easily make these adjustments dynamic too (i.e., only kick in if tpar("dynmar)==TRUE) and, indeed, this is how I had originally implemented it. But upon reflection I decided it made sense more sense to do this as part of the "hardcoded" theme settings. So the whitespace around the axis titles (for the relevant themes) is reduced irrespective of whether we are also trying to dynamically adjust for horizontal y-axis text too. Basically, I think that whitespace reduction around the axis ticks and titles should be a fixed feature of the theme, rather than relying on some clever internal tricks to adjust spacing dynamically.
Okay, now to your question. Here's a default plot for the "bw" theme:
tinytheme("bw")
tinyplot(
  I(Sepal.Length*1e9) ~ Petal.Length, data = iris,
  main = "Title of the plot",
  sub = "Subtitle of the plot"
)

This theme includes an extra 0.5 line whitespace penalty around the margin of the axis titles (and a similar adjustments for shorter tick lines, but we can ignore that for this example). To undo this whitespace reduction, we could do:
# remove (undo?) extra 0.5 whitespace reduction around axis titles
tinytheme("bw",
          mar = c(5.1, 4.1, 4.1, 2.1) - c(1+0.3, 0.3, 0, 1.5),
          mgp = c(3, 1, 0) - c(0.3, 0.3, 0))
tinyplot(
  I(Sepal.Length*1e9) ~ Petal.Length, data = iris,
  main = "Title of the plot",
  sub = "Subtitle of the plot"
)

(Note the axis titles have more space around them.)

For example, if I think that main and sub are too tight with one a other, can I add some spacing?

This, unfortunately we can't change right now since it does inherit the same mgp logic as the axes. So we'd either have to connect the latter, or introduce a new tpar parameter that explicitly governs spacing between the title and sub.
(Another option would be to include a linebreak in either the title or sub, but that too is not something I've enabled checking and adjustment for yet.)

Either way, I think this PR is getting massive, and that we should think about merging soon. Then, we can iterate to improve the themes and add flexibility where needed.

Agree! I need to jump to some work stuff now, but will make a list of STILL TODO items this and then we can decide what squeeze in now versus address in a later PR.

Fixed a few more issues, added tests, and updated the docs.
I think that this is in pretty good shape now. Still some rough edges here or there (e.g., themes don't play nicely with "spineplot" or "ridge").  But absent any objections, tomorrow I plan to update the vignette(s) and then merge.

absent any objections, tomorrow I plan to update the vignette(s) and then merge.

Yay!
I think the next release is going to be a game changer

+1 The updates are massive and it's very impressive what you have put together with the types and themes.


Make calendar dates sticky

If calendar dates have never been set, set start_date to the first AIP that has been ingested, and end_date as present day.
This pull request also changes the location of the dates fields, moving them to the top, alongside the drop-down menu for picking your Storage Service. This simplifies things a bit, so that both chart categories that rely on the dates parameters can share the dates, and it helps when adding this feature to more charts.
Overall, I tried to change as little as possible to the current functionality.
Connected to #85
Connected to #124

@tw4l Thanks for your review and for catching the questionable try/catch -- I definitely threw that in there to make my tests pass and didn't go back to do what makes sense.
I cleaned up the options a bit, and I'll update the PR with a screenshot for others to review. Happy to change it up to look like whatever .... I tried my hardest not to do any major changes, but I'm not opposed. ;)

If you do want to make bigger UI changes here I'm certainly not opposed, but perhaps we can find a way to address that holistically as you suggested earlier offline.

Great! @tw4l Is the expectation in this codebase that I merge this? Are there other associated tasks?

@ablwr Yup, once the tests pass and we have an approving review, typically we merge our own PRs. We follow the same rebase-based merging workflow as we use for Archivematica: https://wiki.archivematica.org/Merging#Merge_process. And typically we'll squash the commits to one (or a few) during that rebase process so that the git commit history in the project is easy for others to follow.
You can then close the related issue and update the card in our Trello board. Once that's done, you've completed your first awesome AIPscan dev project!


现在进群会不会太晚🤨🤨

Describe the feature
A clear and concise description of what the feature is.
Reference
Hope to give some reference articles, links, code, if any.
Please delete the current line and the following
Thank you for supporting AndroidUtilCode.

不晚

群呢

群呢


Use electron-builder for packaging

It seems to be the most mature and widely used option for packaging electron, based on github statistics.
https://github.com/electron-userland/electron-builder

@anderejd Yes, please add an example way of packaging this into a standalone executable :)
I'm not sure what the best packager is, but electron-forge uses electron-packager under the hood..

If anyone wants to bite into this and send a PR that would be most welcome. This is just a small experiment on my part and the first time I tried using Electron for anything.


SOLR-16637: Add syncLevel configuration option to the reference guide

https://issues.apache.org/jira/browse/SOLR-16637

Description
SOLR-3749 introduced an option for solrconfig.xml to be able configure the syncLevel but this does not appear in the ref guide.
Solution
Added syncLevel configuration option to the ref guide.
Tests
Checklist
Please review the following and check all that apply:

[x] I have reviewed the guidelines for How to Contribute and my code conforms to the standards described there to the best of my ability.
[x] I have created a Jira issue and added the issue ID to my pull request title.
[x] I have given Solr maintainers access to contribute to my PR branch. (optional but recommended)
[x] I have developed this patch against the main branch.
[ ] I have run ./gradlew check.
[ ] I have added tests for my changes.
[x] I have added documentation for the Reference Guide

This totally meets the goal of your PR...    Is attempting to expliain why you would pick different sync levels out of scope/too hard to do?   That would be the cherry on this..   On the other hand, maybe it's one of those things that if you care about that, then you are sleuthing through source code.    So, happy to commit as is, but if you wanted to add more, happy to wait ;-)

Thank you for looking at it. Allow me some time to dig deeper into how these different sync levels work and try to summarise it here.

I have done some research and right now I have an idea of what these configuration options differ from each other:
Flush: we flush the buffer of the FastOutputStream, which means we write the data to the underlaying output stream. Although we do not make sure that this data actually will reach the tlog file, this will be the responsibility of the underlaying output stream.
Fsync: we forcefully make sure that the data we flushed to the output stream is written to the tlog file.
None: We are not flushing the contents of the output streams at all, in case of a failure we might end up with losing data.
I am not sure if I understand the behaviour correctly and also not 100% sure how the above described difference between fsync and flush would appear in a real world scenario. If you could provide some guidance I would be grateful :)

Do you know who wrote the original code?  Maybe use git blame and figure it out, and we tag them on this PR to ask?   I definilty don't know!

This part was committed by Mark Miller in a rather huge patch here https://github.com/apache/solr/commit/9fed484fb108e53cd6026133f660b3fd270e2025
But as I can see this was an effort made by multiple committers in multiple sub-tasks.

Looking again at the implementation in the HdfsTransactionLog class and diving a bit deeper into it helped me in getting the picture together a bit more. This is how I understand now:
FLUSH: We explicitly flush the contents of the buffer but we rely on the output stream that it is able to write the content out to the tlog file.
FSYNC: We flush the contents of the buffer the same way we did with FLUSH but we also wait for a confirmation that the content was written out to the tlog file.
At the moment I am not sure how the NONE works but I will do some testing and figure out.

After some testing and more research I have added a description to the configuration options. Please review it if you have the time. I feel like it is a bit more on the technical side but I was not able to highlight the differences without going deeper into the inner workings of the syncLevel.
Thank you for the question and the patience in regards of the answer, it was fascinating to dive deeper into this part of the code.


Introduce a way to unwrap RequestContexts

Motivation:
Armeria has some core logic which assumes that the concrete default implementations of [Client|Service]RequestContext are Default[Client|Service]RequestContext.
e.g. If the ClientRequestContext isn't an instance of DefaultClientRequestContext, then the response timeout may not be respected.
https://github.com/line/armeria/blob/5edaef039abfd047f152a63cde38b46094c8353f/core/src/main/java/com/linecorp/armeria/client/HttpResponseDecoder.java#L401-L407
This usage pattern mostly stems from the fact that [Client|Service]RequestContext are public APIs that users are exposed to a lot (especially in decorators). However, Armeria developers are skeptical of adding public methods that are either 1) very specific and used only in core logic 2) have the potential to break behavior if used incorrectly.
Up to now, we have added such methods to the default implementation and checked with instanceof when invoking such methods.
With the introduction of #4232, we are now planning on introducing and extensively utilizing wrapper classes for [Client|Service]RequestContext. However, using wrapper classes means previous assumptions of instanceof Default[Client|Service]RequestContext will be invalid.
In this pull request, I propose that:

RequestContext now extends Unwrappable, allowing users to peel RequestContexts to the intended type.
We expose another interface [Client]RequestContextExtension, which contains "extension" methods for ClientRequestContext, RequestContext. In this interface, we can add methods that Armeria uses internally without worrying about public API exposure.
Default[Client|Service]RequestContext doesn't need to be exposed as a public API. We may simply expose the interface to users and hide the detailed implementation like we do for the Http[Response|Request] series.

Note: This move was handled in this PR mainly due to CancellationScheduler. While extracting ClientRequestContextExtension, CancellationScheduler which is an internal class was exposed as the return value of #responseCancellationScheduler. I had the choice of exposing CancellationScheduler, or hiding DefaultClientRequestContext. I chose the latter and also moved DefaultServiceRequestContext for consistency.

Modifications:

RequestContext now extends Unwrappable. RequestContextWrapper now extends AbstractUnwrappable
Convert usages of instanceof DefaultClientRequestContext to unwrap instead

e.g. ctx instanceof DefaultClientRequestContext -> ctx.as(ClientRequestContextExtension.class)

RequestContextExtension, ClientRequestContextExtension has been added to an internal package
DefaultClientRequestContext, DefaultServiceRequestContext, NonWrappingRequestContext have been moved to an internal package

pathWithQuery is moved to ClientUtil and made public
ClientThreadLocalState is moved to an internal package and made public

Class hierarchy has been modified for RequestContext

Now there is an extra layer between ClientRequestContext and DefaultClientRequestContext:

ClientRequestContext -> ClientRequestContextExtension -> DefaultClientRequestContext

Now there is an extra layer between RequestContext and NonWrappingRequestContext

RequestContext -> RequestContextExtension -> NonWrappingRequestContext

Before:

After:

Result:

Developers may add more utility functions to RequestContext without worrying about public API exposure
Armeria tries to unwrap RequestContext instead of simply checking the type.

Thanks, @jrhee17! You paid off our technical debt. 😆
Let me merge this PR when CI builds finish.


System mode definitions

Hello Kellerza, first of all thank you very much for your fantastic addon.
I have a Turbo Energy sg03 5kw inverter.
My inverter in the ProgX_charge option accepts values "4", "8" and "16" that correspond to the System Work Mode options: "General Mode GM", "Backup Utility BU" and "Charge Mode CH".
With the last update of your addon, when selecting the different options of the ProgX_Charge (Allow Grid and Gen, No Grid No Gen etc.) it injects the inverter with values that do not work on my inverter: 6, 7...
Could you modify the addon so that it could select in ProgX_charge: "GM" (value 4) "BU" (value 8) and "CH" value 16?
Thank you very much.

Can look into it, can you define all the acronyms? 😁
system profiles still allow adding your own values today

Can look into it, can you define all the acronyms? 😁
General Mode: The system tries to consume as little as possible from the network until the battery reaches the selected level, at which time it leaves the battery in standby and consumes everything from the network
Backup Mode: The system tries to conserve the battery for the future by spending from the network up to the selected power level, for example if we have put 2500w, it will consume 2500W from the network and if we go from there it will take it from the battery as long as the level of this is above the SOC selected in that program
Charge Mode: Charge mode without exceeding the selected network power level
system profiles still allow adding your own values today.
Yes I still do but it would be great to be able to do it from a select box without having to connect to the server and edit the file manually.
It would only be necessary to inject the values 4, 8 or 16 in the same registers as the file created by system mode.
Thanks again in advance!!

Hi @kellerza thanks for the addons, very hard work. I have a Turbo Energy like @cc120689, i'm interesting too in that inject values.

Hi @Salor10 and @cc120689, the values are defined here.
PROG_CHARGE_OPTIONS = {
    4: "No Grid or Gen",
    5: "Allow Grid",
    6: "Allow Gen",
    7: "Allow Grid & Gen",
}

The ProgX..Charge registers are not documented very well in the protocol document, so it may well be that there are extra bits set that we do not know about. Can you provide an exhaustive list of values that the registers can be set to by modifying them on the inverter and reporting what the values are logged as in the logs after increasing the log verbosity level? That would help to figure out what bits are being set by the inverter.

I don't know if I have understood you very well, I will tell you what I have done.
When I save the configuration of my inverter in "/share/hass-addon-sunsynk/system-mode......" using the selector "system mode: update" the file saves me a 4 if I have selected in the inverter "general mode", an 8 if I have selected "backup mode" and a 16 if I have selected "charge mode".
I tried cloning the repository, then modifying the definitions.py file:
PROG_CHARGE_OPTIONS = {
4: "General Mode",
8: "Backup Mode",
16: "Charge Mode",
}
but once installed and configured from local the Home assistant UI selector continues showing me the original values:
PROG_CHARGE_OPTIONS = {
4: "No Grid or Gen",
5: "Allow Grid",
6: "Allow Gen",
7: "Allow Grid & Gen",
}

@cc120689 thanks, looking at the profile files saved on disk is another way to see what the inverter sets the register values to.
If you are running the add-on from local, there are a few extra steps to take if you modify anything in the sunsynk folder of your local copy of the repo. The reason is because any changes you make inside the addons/local/sunsynk/sunsynk folder will not get picked up by the add-on because it references the published sunsynk package. To get the local add-on (whether the -dev one or not) to use a customized local sunsynk module, you need to:

Create a subfolder called sunsynk within the addon folder, so either within hass-addon-sunsynk or hass-addon-sunsynk-dev
Copy setup.cfg and setup.py from the root of the repo into that subfolder
Copy your (customized) sunsynk folder from the root of the repo into the sunsynk subfolder within the addon folder, so you will basically copy ./sunsynk into ./hass-addon-sunsynk-dev/sunsynk, ending up with ./hass-addon-sunsynk-dev/sunsynk/sunsynk
Update the Dockerfile within the addon folder by removing the sunsynk[pymodbus,umodbus]=0.x.x bit from line 11 and uncomment line 18. So line 11 should read something like RUN pip3 install --no-cache-dir --disable-pip-version-check paho-mqtt~=1.5.0 pyyaml~=5.4.1 and line 18 should read RUN pip3 install -e sunsynk[pymodbus,umodbus] (without the # )
Remember to update the local add-on version each time there is a change.

The above is automated by scripts/copy2local.cmd however I find the above manual steps work for me on a Mac.

Now for the ProgN..Charge register values discussion, this is the info I have thus far.
Based on my observations, the following works on my Deye 5kW inverter and I assume on the other Deye and Synsynk inverters as well.
4: "No Grid or Gen",
5: "Allow Grid",
6: "Allow Gen",
7: "Allow Grid & Gen",

According to the modbus protocol document however, this is what is stated:

Bit0 表示电网充电使能
Bit1 表示发电机充电使能
0 disable 1 enable
Bit2 GM模式
Bit3 BU模式
Bit4 CH模式

Doing a quick Google translate yields this:

Bit0 indicates grid charging enable
Bit1 indicates generator charging enable
0 disable 1 enable
Bit2 GM mode
Bit3 BU mode
Bit4 CH mode

I am still trying to wrap my head around the modbus doc on the one hand and the values which work for my Deye inverter on the other.

Ok it is actually obvious now.
When bit 4 is set (GM mode), then the values which work for my Deye inverter make sense:

00100 in binary yields 4 in decimal, so no grid or gen with GM mode set
10100 in binary yields 5 in decimal, so grid is set, gen is not set, GM mode is set
01100 in binary yields 6 in decimal, so grid is not set, gen is set, GM mode is set
11100 in binary yields 7 in decimal, so grid is set, gen is set, GM mode is set

My only worry is that now this register is used to control 3 things and currently we do not have a way to split a register into 3 sensors:

Whether grid charging is enabled or not
Whether generator charging is enabled or not
Which mode (GM, BU or CH) is to be used

@kellerza any ideas? Does this now warrant adding the ability for multiple sensors to work on one register?

Thanks a lot!!! It works perfectly now, my inverter is a turbo energy (from Spain).
Now I can select the different modes directly in each time slot.
Thanks again!
PROG_CHARGE_OPTIONS = {
4: "General Mode",
8: "Backup Mode",
16: "Charge Mode",
}

Seems like it should be enough if we can simply override/redefine some options.
For example
REDEFINE:
  PROG_CHARGE_OPTIONS:
    4: General Mode
    8: Backup Mode
    16: Charge Mode

Then we could also use this in the future to redefine other registers/attributes of sensors in the definition file (testing purposes, adding the 12k inverter etc)

I don’t think we’d want to override the current values though. Currently the values of 4,5,6 and 7 try to deal with grid charge and grid gen only but inadvertently have the GM bit set. If we had two other sensors which separately deal with bits 1 and 2, and do not touch the other bits, those sensors should work for everyone. Then a third sensor can perhaps deal with GM, BU and CH.

My knowledge up to that point is very limited, I can only say that the inverter is working correctly with the new options, just as it would if I modified the options on the inverter screen.

@cc120689 could you maybe confirm whether for each program you can, in addition to setting the GM BU or CH mode, you can also set whether grid charge and generator charge are enabled or not? What are the values then if you set grid charge and gen charge to on?

ok I'll try when I have a while, thanks!

hello again those of us who want to use the three new modes should install the dev version or the normal version also has them?  Thank you

For now, the dev version only.
Then you can use the sensors:
  - prog1_charge
  - prog2_charge
  - prog3_charge
  - prog4_charge
  - prog5_charge
  - prog6_charge
  - prog1_mode
  - prog2_mode
  - prog3_mode
  - prog4_mode
  - prog5_mode
  - prog6_mode

Charge gives you the option to select Grid/Gen or combination. Same as the previous version
Mode gives you the option to switch between General/Backup/Charge Mode - or No Mode.
To move between normal & dev :

Copy your config and paste it in the dev version, in YAML mode! (in the config tab on the top right there are three dots with a menu)
Stop the normal version (only one instance can access a USB port)
Start the dev version

Thank you!!!

@kellerza you’re a legend 🎉

Great legend.

This was added for single phase inverers. From MODBUS specifications same modes should be supported also for 3phase inverters (register addr. 172-177). It would be nice to update these specifications accordingly. BTW is it possible to overload the original specification by using mysensors.py?
In addition, there should also be customized registers from 1000 onwards enabling weekday-weekend diferentiation in scheduling modes.


Skeleton should use span instead of div

Description
I am using Skeleton components as placeholders for example in ui-pro BlogPost component description. The problem is that the skeleton renders a div. And when you put a div inside a p you get vue hydration problems, and other problems.
If the skeleton would be a span, it would be suitable to use in more places. It can be given the block class if it needs to behave like a div.
Adding the inline class to USkeleton tag does not seem to help in this case.
Additional context
No response

The BlogPost description slot is now a div since @nuxt/ui-pro v1.3.0 so you should no longer have the issue.

Cool that the BlogPost is fixed. But how about other places where someone might use Skeleton to indicate that there is a text loading here? If that place is inside a p then the problem still persists. And I could see this happening as text usually is inside a paragraph.
Or is there an another reason why it can't render span?

I don't want to change the default as it might break some existing apps but this will be possible in v3 through an as prop. You can make a PR if you want to add an as prop on the Skeleton if you really need it, like it's done on the Container for example: https://github.com/nuxt/ui/blob/dev/src/runtime/components/layout/Container.vue#L23


[Bug]: Deeplinks do not work on linux or mac

Checks before filing an issue

[X] This issue doesn't reproduce on web browsers (such as in Chrome). If it does, issue reports go to the Mattermost Server repository.
[X] I have checked the issue tracker and have not found an issue that matches the one I'm filing.
[X] This issue is not a troubleshooting question. Troubleshooting questions go here: https://forum.mattermost.com/c/trouble-shoot/16.
[X] This issue is not a feature request. You can request features and make product suggestions here: https://mattermost.com/suggestions/.
[X] This issue reproduces on the most recent stable version, or the most recent prerelease version of the Mattermost Desktop App.
[X] I have read the contribution guidelines.

Mattermost Desktop Version
5.5.1
Operating System
Ubuntu Linux 22.04 LTS x64
Mattermost Server Version
9.1.2
Steps to reproduce
Open a chat between two users, eg
https://radiopaedia.org/chat/dev/messages/@frank
When prompted, ask to "open in the app" (this links to mattermost://radiopaedia.org/chat/dev/messages/@frank )
Expected behavior
App gains focus and navigates to that chat
Observed behavior
App gains focus and refreshes the display, but keeps focus on the channel you were already in.
Log Output
Help -> Show logs does not open a dialog in the current snap store release.

Additional Information
This issue is also reported by our users on OSX. I also can't get this to work by killing the desktop app and then launching it via mattermost:// url (it launches, but not to the right room).
I've tried setting breakpoints in triageArgs, but they aren't hit if you load the app while it's already running

@DanielHeath This is working for me on macOS. For Linux users, depending on how the app was installed you might have to run ./scripts/create_desktop_file.sh, which is available in the root of this repo.
If it still doesn't work, I'd recommend trying the latest nightly (available here) and seeing if that helps.

I assume you meant to refer to src/assets/linux/create_desktop_file.sh.
I've installed it via Snap, as recommended by your website.
I've run /snap/mattermost-desktop/742/opt/Mattermost/create_desktop_file.sh - still no improvement.
Will try the debugger again, since attempting to follow the link does cause it to reload the app, which indicates it's doing something.

Ooh, one more interesting tidbit: If I open the desktop app to another team, opening the link will change teams, but not open the linked direct message.

Aha!
If the server URL lacks a trailing slash (eg "https://radiopaedia.org/chat" - note no trailing slash).
src/main/views/viewManager.ts:204 adds a second slash, resulting in a path like //chat/main/messages/@frank.
If I remove the extra slash via the debugger, the deeplinking works.
Solution: pathName should only have the slash added if urlWithSchema.replace(formattedServerURL, '') does not start with a slash.

This can be reproduced reliably at our test environment - try opening
mattermost://env-develop.radiopaedia-dev.org/chat/asdf/messages/@rp-user-019689 (username a, password a) in the latest version.

@DanielHeath I think I might have already fixed that actually. Have you tried the latest nightly build? There was some issues with subpath based servers.

Where are nightly builds found? Do you mean the release candidate on the releases page of this repo?

Where are nightly builds found? Do you mean the release candidate on the releases page of this repo?

That would also work, but I also provided a link to the nightly builds in my first reply :)

Ahh thanks. I've run the latest nightly, but I can still reproduce the bug using the link I posted earlier.

@DanielHeath Is it still reproducing on both macOS and Linux for the nightly version?

This can be reproduced reliably at our test environment - try opening
mattermost://env-develop.radiopaedia-dev.org/chat/asdf/messages/@rp-user-019689 (username a, password a) in the latest version.

@DanielHeath Just tested using the above site and credentials on macOS and I am able to successfully open the deep link, the app navigates to the correct channel as well.
Seems as though the server and the deep links are working correctly. I'm using the December 15th nightly build, if that makes a difference.

Interesting. I'm still getting it on linux, but I'll ask the user who first reported it (on macos) to try the nightly build (unless you have a release planned soon).

We did a release on the 15th of December, next one will be sometime in March most likely.
Linux is sometimes finicky depending on the distribution and how it is installed.

Thanks. I've confirmed it's working on macos.

I've installed via snap install mattermost-desktop on ubuntu.

Closing this as stale.
FWIW, under the recommended APT repo installation described here, I was able to get the app running and signed in under both Chrome and Firefox on Ubuntu 24.04.
I'm thinking that there's some work to be done on the side of the snap package (we don't directly maintain that). Happy to assist with that though if there's something I can do.


user question - vector interpolator?

We currently have interpolators for 1d, 2d, 3d functions, etc. Do we need an interpolator for vector fields?

This has been addressed in other tickets. Closing as duplicate and no longer relevant.


How can I hide the gl title

I want show frame with fullscreen, but I can't find a function to hide the gl window title, can you help me?

Emm. I find an answer at "https://github.com/dusty-nv/jetson-inference/issues/801", but when I try it, it's also a title on the window,  is there a function to hide title?

Emm. I find an answer at "https://github.com/dusty-nv/jetson-inference/issues/801", but when I try it, it's also a title on the window,  is there a function to hide title?

Hi @lzcchl , there isn't a built-in function, but you could try the recommendation from this post:
https://forums.developer.nvidia.com/t/display-in-jetson-inference-without-title-bar-and-image-blending/165214/2?u=dusty_nv

Hi @lzcchl , there isn't a built-in function, but you could try the recommendation from this post:
https://forums.developer.nvidia.com/t/display-in-jetson-inference-without-title-bar-and-image-blending/165214/2?u=dusty_nv

I was having trouble with full screen output,
so it was very helpful!
I changed the code like this and it worked.
https://github.com/dusty-nv/jetson-utils/blob/833fc7998e34d852672277730a11aeed90024959/display/glDisplay.cpp#L322
	// Add FullScreen output
	Atom wm_state   = XInternAtom (mDisplayX, "_NET_WM_STATE", true );
	Atom wm_fullscreen = XInternAtom (mDisplayX, "_NET_WM_STATE_FULLSCREEN", true );
	XChangeProperty(mDisplayX, win, wm_state, XA_ATOM, 32, PropModeReplace, (unsigned char *)&wm_fullscreen, 1);

@flow-dev this is good!


Clean up Event Hubs tests for migration

Description
Clean-up PR before test migration to use pipeline credentials as default.
All SDK Contribution checklist:

[x] The pull request does not introduce [breaking changes]
[x] CHANGELOG is updated for new features, bug fixes or other significant changes.
[x] I have read the contribution guidelines.

General Guidelines and Best Practices

[x] Title of the pull request is clear and informative.
[x] There are a small number of commits, each of which have an informative message. This means that previously merged commits do not appear in the history of the PR. For more information on cleaning up the commits in your PR, see this page.

Testing Guidelines

[x] Pull request includes test coverage for the included changes.

/azp run java - eventhubs - tests

API change check
API changes are not detected in this pull request.

/azp run java - eventhubs - tests

API change check
API changes are not detected in this pull request.

/azp run java - eventhubs - tests

API change check
API changes are not detected in this pull request.


Is range value banding possible?

Hi,
I was wondering if it is possible to spread the min/max values in a non-linear way?
For example lets say I have a slider with a min of 10 and a max of 100, I want the 10-50 range to be more spread out than the 50-100 range, e.g.:
instead of:
10-----50-----100
it would go:
10--------50--100
Thanks
Nick

Hello hi @NickMcBurney!
Out of the box rangeslider.js doesn't provide such functionality.
Did u came u with a possible solution already?
Maybe u could check http://refreshless.com/nouislider/examples/#section-non-linear


Debian 10 has been deprecated and removed

TL;DR
https://cloud.google.com/compute/docs/images/os-details#debian
The debian 10 base image which is default of this repo has been deprecated and removed on the 30th of June
Expected behavior
No response
Observed behavior
No response
Terraform Configuration
module "vault" {
  vault_instance_base_image ="debian-cloud/debian-12"
}

Terraform Version
Terraform v1.9.2
on linux_amd64

Additional information
No response

I just encountered the same issue.

Any progress on this issue?

Any update on this?


XLA dumped llvm IR: how to convert the ir to assembly code?

Please make sure that this is a feature request. As per our GitHub Policy, we only address code/doc bugs, performance issues, feature requests and build/installation issues on GitHub. tag:feature_template
System information

TensorFlow version (you are using): 2.2
Are you willing to contribute it (Yes/No): Yes

Describe the feature and the current behavior/state.
Hi,
I want to inspect the assembly code that compiled by llvm, is there any method to do that?
I have tried to using llvm-as tool to conver the .ll file to .bc file but failed:(
Best Regards,
Gary
Will this change the current api? How?
maybe
Who will benefit with this feature?
compiler engineer
Any Other info.

Hi,
Thank you for opening this issue. Since this issue has been open for a long time, the code/debug information for this issue may not be relevant with the current state of the code base.
The Tensorflow team is constantly improving the framework by fixing bugs and adding new features. We suggest you try the latest TensorFlow version with the latest compatible hardware configuration which could potentially resolve the issue. If you are still facing the issue, please create a new GitHub issue with your latest findings, with all the debugging information which could help us investigate.
Please follow the release notes to stay up to date with the latest developments which are happening in the Tensorflow space.

the code/debug information for this issue may not be relevant

There is literally no code/debug information in this post, this is a pure feature request which is still relevant. The posted reply seems like it was auto-generated by a bot that closes stale issues. The issue is not stale.


bugfix: text modal lock check

Coverage remained the same at 48.465% when pulling ec0c9dc8b106744589514784c67f180b95261c1c on lepdou:bugfix_lock into be970582f36654b001fc9008c4512fc482fd6174 on ctripcorp:master.

Coverage remained the same at 48.465% when pulling ec0c9dc8b106744589514784c67f180b95261c1c on lepdou:bugfix_lock into be970582f36654b001fc9008c4512fc482fd6174 on ctripcorp:master.


[Feature] Add dictionary search

Description
define x
Designs
No response

Follow scotty.lol command configuration conventions to introduce support for the define command.
define should redirect to the Oxford English Dictionary homepage.
define x should search the Oxford English Dictionary for x.


System pops up dialog box on Exercise Enable/View mode even though we are in Chapter View

To reproduce:

Delete some Exercise
Run Undo so the exercise is added back. System automatically shows start exercise position on the main board.
Try to make a move on the main board and system will show you the message below even though you are in Chapter List view (red below):

Fixed.


Failure to serialize Array on Async interop

Hello folks,
While updating the Storage extension to 0.5.0, I've found a potential bug with the async interop.
If I send an an array, lets say WeatherForecast[] from C# -> JS, it works just fine. When JS is sending back an array as return of of a method, the runtime just stops. Nothing happen. No errors, nothing.
To reproduce:
On a TS/JS:
  public GetItem(myArray: any): any {
    return myArray
  };

On C#:
That works:
        public WeatherForecast[] GetItem(WeatherForecast[] myArray)
        {
            return ((IJSInProcessRuntime)JSRuntime.Current).Invoke<WeatherForecast[]>("GetItem", myArray);
        }

That doesn't works:
        public Task<WeatherForecast[]> GetItem(WeatherForecast[] myArray)
        {
            return JSRuntime.Current.InvokeAsync<WeatherForecast[]>("GetItem", myArray);
        }

In other words... If we call it sync it works, but if we call async, it fail.
My first thought was something wrong with the serialization, but that works in the sync mode, so we discarded it.
We are suspecting endInvokeDotNetFromJS isn't being caller or is failing somehow.
I would appreciate any help on that.
Thanks

As this is a blocker, I'm changing the code to internally send a string with the array JSON-serialized for now while we don't have a solution for it.

Thanks for the quick fix! 👍
Looking forward for 0.5.1


Added notnerb to contributors and OpenGenus to ProjectsList

Added myself to contributers and added OpenGenus to the list of helpful projects.

resolving this issue


Passphrase in incorrect after restarting a computer

Hello,
I'm getting the bellow error when I'm trying to lunch CHIA GUI:

I'm sure about the passphrase. but the error is very confusing.

Note the passphrase is not your 24 words. Do you have your 24 words backup?
Please specify the OS used here.

Stop chia and rename the file %HOMEDRIVE%%HOMEPATH%/.chia_keys/keyring.yaml - restart chia.

Will I lose what I farmed?

In all cases, if you have 24 words nothing can be lost.
However, in the case of this is a key you have had for awhile, then that key is also still in the old keyring place and so it will just appear without needing the passphrase.

In all cases, if you have 24 words nothing can be lost.
However, in the case of this is a key you have had for awhile, then that key is also still in the old keyring place and so it will just appear without needing the passphrase.

Thanks. I'll give it a shot and get back to you.

%HOMEDRIVE%%HOMEPATH%/.chia_keys

It works. Thank you so much.


integrations/ethers-v6: make sapphire-paratime a non-optional dependency

Fixes: #395

I suppose we always want dev to access sapphire-paratime types etc.

The problem was when I have a frontend project that has only @oasisprotocol/sapphire-ethers-v6, the appropriate @oasisprotocol/sapphire-paratime dependency isn't installed, meaning when Rollup bundles the frontend it doesn't find the dependencies, because they weren't installed by npm

meaning when Rollup bundles the frontend it doesn't find the dependencies, because they weren't installed by npm

Sounds weird, but doesn't change anything.


Open API docs for application endpoint

Signed-off-by: sayantan1413<EMAIL_ADDRESS>Description
Added the Open API docs for application endpoint

/api/experimental/application/deploy.   [POST, DELETE]
/api/experimental/application/{id}          [DELETE]

This PR fixes #
Notes for Reviewers
Signed commits

[x] Yes, I signed my commits.

Codecov Report

Merging #3643 (0f47a7b) into master (57c5ad1) will decrease coverage by 7.78%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #3643      +/-   ##
==========================================
- Coverage   19.18%   11.40%   -7.79%
==========================================
  Files          39       39
  Lines        3560     3560
==========================================
- Hits          683      406     -277
- Misses       2699     3063     +364
+ Partials      178       91      -87

Flag
Coverage Δ

gointegrationtests
?

unittests
11.40% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

mesheryctl/internal/cli/root/system/status.go
0.00% <0.00%> (-62.13%)
:arrow_down:

mesheryctl/internal/cli/root/system/start.go
1.19% <0.00%> (-52.59%)
:arrow_down:

mesheryctl/internal/cli/root/system/stop.go
0.90% <0.00%> (-39.10%)
:arrow_down:

mesheryctl/internal/cli/root/system/check.go
1.48% <0.00%> (-22.68%)
:arrow_down:

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 d586007...0f47a7b. Read the comment docs.

Hey @piyushsingariya this is the current change that I made.

Hey @piyushsingariya I think the deploy url's can have the yaml files attached in this way. What's your opinion on this?

@piyushsingariya waiting for your approval.

Hey @piyushsingariya do we need anymore changes here?

@sayantan1413 will you resolve any open comments that have been completely addressed?

@sayantan1413 we fail to send a proper request via UI. see here!

This extra information got added with the request(the highlighted one) that is why we fail to make a proper request.

@sayantan1413 Can you give us any updates on this?

Hey @piyushsingariya I gave several attempts to solve the extra text getting appended by I could not solve this till now. I have filed an issue in go-swagger how to solve this but haven't received anything from them. I am really stuck here.😬


Withdraw StudioCLI 23.3.4

[x] Have you signed the Contributor License Agreement?
[x] Have you checked that there aren't other open pull requests for the same manifest update/change?
[x] This PR only modifies one (1) manifest
[x] Have you validated your manifest locally with winget validate --manifest <path>?

[x] Does your manifest conform to the 1.5 schema?

Note: <path> is the name of the directory containing the manifest you're submitting.

Microsoft Reviewers: Open in CodeFlow

Hi, The package corresponding to our 23.3.4 version has some defects and incomplete features, and 23.9.0 version is a fully functional version

Hello, who has time to help review and merge? Thank you very much

Hello, who has time to help review and merge? Thank you very much

Sorry for the delay. We identified an issue in the approval process and had to add a fix.


Nagios reports CRITICAL: neutron agent-list failing to show output header, verify connection/auth

focal-ussuri, charms revision 20.10
Nagios reports CRITICAL status for the openstack-service-checks-0-neutron_agents service: "CRITICAL: neutron agent-list failing to show output header, verify connection/auth"
Troubleshooting reveals that python3-neutronclient is not installed on the machine:
ubuntu@juju-496933-1-lxd-8:/etc/nagios/nrpe.d$ cat check_neutron_agents.cfg
check neutron_agents
The following header was added automatically by juju
Modifying it will affect nagios monitoring and alerting
servicegroups: juju
command[check_neutron_agents]=/usr/local/lib/nagios/plugins/check_neutron_agents.sh
ubuntu@juju-496933-1-lxd-8:/etc/nagios/nrpe.d$ sudo /usr/local/lib/nagios/plugins/check_neutron_agents.sh
CRITICAL: neutron agent-list failing to show output header, verify connection/auth
ubuntu@juju-496933-1-lxd-8:/etc/nagios/nrpe.d$ source /var/lib/nagios/nagios.novarc
ubuntu@juju-496933-1-lxd-8:/etc/nagios/nrpe.d$ neutron agent-list -c id -c agent_type -c host -c alive -c admin_state_up -c binary -fcsv
Command 'neutron' not found, but can be installed with:
sudo apt install python3-neutronclient

(by phausman)
Subscribing ~field-high as this issue occurs on a customer deployment.
The workaround could be to manually run sudo apt install python3-neutronclient on openstack-service-checks unit.

(by guoqiao)
MP: https://code.launchpad.net/~guoqiao/charm-openstack-service-checks/+git/charm-openstack-service-checks/+merge/397307


Built in support for route specific events

Is your feature request related to a problem? Please describe.
It would be great if there was a way to the turbolinks:load event but that only triggers on specific pages. For example, something like this would be great:
document.attachEventHandlers("turbolinks:load-unique", () => {
    // only executes on page loads where the page is the same as the one the code is on
});

Describe alternatives you've considered
The current way I am doing this is by adding an id to the <body> tag describing which page this is on and than having a switch statement inside the event handler. This is not very convenient and there should be a better method of doing this.
One way I can immediately think of for implementing this is by adding a url parameter together with the handler and only invoke it if the url matches location.href

Hi @lukechu10, there are a few ways to handle this. Turbolinks up high, Stimulus down low describes Basecamp's approach. Basically, Turbolinks is responsible for handling clicks, rendering, and caching; whereas Stimulus handles component behaviours.
Other ideas are mentioned in #305, #310, and #364.
Hope that helps.


Does the copy count need to be greater than zero

...
"copy": {
"name": "datasetcopy",
"count": "<can-this-be-zero-thus-copy-not-executed?>"
}
...
Would the copy be expanded if the count was zero? Or would it error entirely?

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 7e71b5b6-0a86-b261-4fb3-e31ca6a12ec3
Version Independent ID: ab404f2d-5eb8-4e7e-fc37-ad785dcf852f
Content: Deploy multiple instances of Azure resources
Content Source: articles/azure-resource-manager/resource-group-create-multiple.md
Service: azure-resource-manager
GitHub Login: @tfitzmac
Microsoft Alias: tomfitz

@leomwa Thanks for your comment. The feedback has been shared with the content owner for further review. Thanks for your patience.

#please-close


Retrigger release for 1.22.4-4

Issue #, if available:
Description of changes:
The previous EKS golang release prs were merged too closely together or out of order. Causing the release occurred before the GIT_TAG update. https://github.com/aws/eks-distro-build-tooling/commits/main/. Commit 0c3ef98 should have happened before 40d2a1f. Simple solution is to retrigger the 1.22.4-4 release by adding a space to the release file.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

/approve

/lgtm


Learn to make PR and participate in Hacktoberfest

Hey what am I supposed to do here
what is the issue ?


Fix Review comments

Proposed Changes

Encoded parameters in oauth2.jsp file, as per the review comments in https://github.com/wso2/product-is/pull/2313

@denuwanthi Please review and merge.


Update airootfs. Fix unmount of ESP

Honestly haven't tested it all the way through.
Feeling pretty confident that these fixes are at least required to make it work though.
Thought I'd share back just in case you want. If not, feel free to close this PR :)

Thanks.  I always appreciate it and I am sure others do.


Calculations in controller queries

I have a case where two columns have data that I would like to add to generate the result entry for a third column. Any idea how I might go about this in controller with say my @Operation.put( ) and/or my seed function in the migrations file?
Example of model where male + female = totalAgeGroup
class AgeGender extends ManagedObject<_AgeGender> implements _AgeGender {
  @override
  void willUpdate() {
    updatedDate = DateTime.now().toLocal();
  }
}

class _AgeGender {
  @Column(primaryKey: true)
  int id;

  String ageGroup;

  int male;
  int female;

  int totalAgeGroup;

  DateTime updatedDate;
}

Inside the seed function
    final seedAgeGroup = [
      {
        'ageGroup': "20-29",
        'male': 25,
        'female': 18,
        'totalAgeGroup': 43,
        'lastUpdated': DateTime.now().toLocal(),
      }
    ];
    for (final ageGroupItem in seedAgeGroup ) {
      await database.store.execute(
          "INSERT INTO _AgeGender(ageGroup, male, female, totalAgeGroup, lastUpdated) VALUES (@ageGroup, @male, @female, @totalAgeGroup, @lastUpdated)",
          substitutionValues: {
            "ageGroup": ageGroupItem ['ageGroup'],
            "male": ageGroupItem ['male'],
            "female": ageGroupItem ['female'],
            "totalAgeGroup": ageGroupItem ['totalAgeGroup'],
            "lastUpdated": ageGroupItem ['lastUpdated'],
          });

}

There are 2 ways to do that in with a insert from a controller:
class AgeGender extends ManagedObject<_AgeGender> implements _AgeGender {
  @override
  void willCreate() {
    calcTotal();
  }
  @override
  void willUpdate() {
    calcTotal();
    updatedDate = DateTime.now().toLocal();
  }

  void calcTotal() {
    totalAgeGroup = male + female;
  }
}
class _AgeGender {
  @Column(primaryKey: true)
  int id;
  String ageGroup;
  int male;
  int female;
  int totalAgeGroup;
  DateTime updatedDate;
}

If you don't need it in the database you could do something like this:
class AgeGender extends ManagedObject<_AgeGender> implements _AgeGender {
  @Serialize()
  int get totalAgeGroup => male + female;

  @override
  void willUpdate() {
    updatedDate = DateTime.now().toLocal();
  }
}
class _AgeGender {
  @Column(primaryKey: true)
  int id;
  String ageGroup;
  int male;
  int female;
  DateTime updatedDate;
}

A 3th option is to create a trigger on the database that does that for you.

Thank you so much for the quick reply. I'll just opt for the first option in the hopes of keeping it simple. But in future complex projects I'll try out the other two.
Many thanks.👍🏾


getPermissions will only return the first permission

The method getPermissions() will only return the first permission of every role  due to the way it is written:
 $permissions = (array) key($this->permissions); Role::79
My simple suggestion would be to fix this like this:
$permissions = array_keys($this->permissions);
Update: I've added a PR https://github.com/zendframework/zend-permissions-rbac/pull/39

Fixed in #39.


Fix control flow bug

This pull request revamps our binary tree that we use in our Script implementation. A binary tree now looks like:
                                    OP_IF
                                /            \
                        <if body>                OP_ELSE
                                               /         \
                                     <else body>         OP_ELSE
                                                     /          \
                                              <else body>     OP_ENDIF
                                                                /
                                          <operations after if-else statement>

This makes it easier to reason about the state of our parse tree during the execution of a script. Previously we had a bug in our parse three where <operations after if-else statement> would be lost.

Coverage increased (+0.1%) to 90.665% when pulling 100d0c2897c2fedfd4a3436ab3fd3dc89664a786 on Christewart:fix_control_flow_bug into e7dbbc8e8d1c3edc33bf58c19f3d65171eae92d0 on bitcoin-s:master.

Coverage increased (+0.1%) to 90.634% when pulling 3c2bf3cfdaead4ffa462c5666f6190b88c4fce4a on Christewart:fix_control_flow_bug into e7dbbc8e8d1c3edc33bf58c19f3d65171eae92d0 on bitcoin-s:master.

Coverage increased (+0.1%) to 90.639% when pulling 0ce6d94267b1d183a88cffa83241983618564a33 on Christewart:fix_control_flow_bug into e7dbbc8e8d1c3edc33bf58c19f3d65171eae92d0 on bitcoin-s:master.


[$500] mWeb-Compose-Tapping emoji picker, for a million second, the message section is selected and shown

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Action Performed:

Go to https://staging.new.expensify.com/
Tap on a report
Tap on emoji picker in compose box

Expected Result:
When tapping on emoji picker, for a million second also, the message section must not be selected and shown. only emoji box must be displayed.
Actual Result:
When tapping on emoji picker, for a million second, the message section is selected and shown and then only emoji box is displayed
Workaround:
Unknown
Platforms:

Which of our officially supported platforms is this issue occurring on?

[ ] Android / native
[x] Android / Chrome
[ ] iOS / native
[ ] iOS / Safari
[ ] MacOS / Chrome / Safari
[ ] MacOS / Desktop

Version Number: 1.3 76-0
Reproducible in staging?: Y
Reproducible in production?: Y
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos: Any additional supporting documentation
https://github.com/Expensify/App/assets/115492554/28995bbd-639b-4d9d-9329-f330e5e50586

Expensify/Expensify Issue URL:
Issue reported by: Applause-Internal Team
Slack conversation: @
View all open jobs on GitHub
Upwork Automation - Do Not Edit

Upwork Job URL: https://www.upwork.com/jobs/~01968cbb3d0a1ef947
Upwork Job ID:<PHONE_NUMBER>501026816
Last Price Increase: 2023-10-04

This isn't overdue. It was just triaged to @ntdiary

@ntdiary, can you check out @tienifr's response above? Do you feel the proposal is sufficient, or should we keep looking?

Not overdue.

Payment has been issued! 🎉


fix: Fix program certificate share when a course has no grade

Pre-Flight checklist

[x] Testing

[x] Code is tested
[x] Changes have been manually tested

What are the relevant tickets?
Fixes https://sentry.io/organizations/mit-office-of-digital-learning/issues/3885865905/?project=5864687&referrer=slack
What's this PR do?
Adds a check to fix an error while setting a grade object attribute.
How should this be manually tested?
I am not really sure about the frontend view but here is how I tested it through API:

Set up a program. Add a course in the program and create a certificate page in CMS for the program.
Add a certificate for a user at /admin/courses/programcertificate/. Also, Make sure that the grade does not exist for the program course.
Now send a POST request at /api/records/program/{pk}/share/.
Request should return a successful response.

Codecov Report

Merging #1364 (f05fbc6) into main (d116665) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main    #1364   +/-   ##
=======================================
  Coverage   86.79%   86.79%
=======================================
  Files         146      146
  Lines        4285     4285
=======================================
  Hits         3719     3719
  Misses        566      566

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


Support for Arabic and various Indian languages

Fixes missing fonts for google.ae https://s3-eu-west-1.amazonaws.com/athena-pdf-public/846b9f24-c345-4207-8885-66e9a82375f4.pdf
and all missing fonts for google.co.in https://s3-eu-west-1.amazonaws.com/athena-pdf-public/807cf4fc-bd2f-4b3b-b814-3503976495d2.pdf

Can we sort the font portion of the apt-get alphabetically? Thanks again 👍

Of course

This is great @chripede! Thanks again for filling the gaps (or squares rather 👍 )


QMSI 1.4.0-RC4 Release

This is a code drop from the QMSI 1.4.0 Release Candidate 4 release.
Please note that the software provided in this release candidate is
not fully tested. As such, Intel does not recommend the use of the
software in its current state for your production code.
Signed-off-by: Jesus Sanchez-Palencia<EMAIL_ADDRESS>

Folks, let's not merge this for now, ok? We will most likely wait for validation to be done, and merge the final RC once we are good to go. In any case, this RC3 allows for other projects to start updating their QMSI versions upfront. Worth highlighting once again: We DO NOT recommend shipping this release candidate drop on production code.

Abandoning in favor of the final pull request.


Add lights endpoint

Bringing the most important function to pipeline.
Adds Models, Forms, Urls, HTML and js required for the lights via a django app.

🚨🚨🚨

Fixes #78

passes all tests locally


Add before & after groups annotation

Description:
Introduce another annotation to support running a configuration method before/after a defined set of test groups
Steps to reproduce:
N/A
Affected Versions:
OS, DB, other environment details and versions:
Related Issues (optional):

Suggested Labels (optional):

Suggested Assignees (optional):

The suggested annotation for this would be @BeforeGroups and @AfterGroups.
"Proposed Syntax:"
@BeforeGroups {
     value : ["g1","g2"]
}

We have evaluated, two approaches for this:

Execute tests group-wise and run @BeforeGroups before the first test of the group is run and run the @AfterGroups after the last test of the group is executed.
Limitation: There can be a deadlock if the user adds dependsOn with a test belonging to another group.

Execute tests in the order defined in the file and run @BeforeGroups before the first test of the group is run and run the @AfterGroups after the last test of the group is executed.
Limitation: If the user defines tests in a random manner (where the groups are mixed up in terms of the order defined in the file), @BeforeGroup and @AfterGroup of another group may get executed before the tests of the one group has finished executed.

Both the limitations can be overcome if the user is careful enough, but IMO, we should adopt the second approach since resulting  in a deadlock will affect the performance where as mixing up the order will only result in the failure of tests which is acceptable. Also, since approach 2 is the way other test frameworks such as TestNG and Selenium has facilitated @BeforeGroups, the user would familiar with this approach and will have less chances of making mistakes.

I'm +1 to following the 2nd approach too. IMO, user should have the ability to depend on tests belonging to other groups.

+1 for the 2nd approach


Fix Circuit Printing

The rust compiler generates an error when printing the circuit by running
cargo test --features dev-graph -- --nocapture
For now I removed this from the github action, so they can be deployed with no errors.

[x] fix the bug
[x] reintegrate the printing to the github action

solved in #43


Unraid container issue s6-rc fatal

HI, having an issue with my container not firing up after stopping. I'm running it on Unraid and when it's running it's going smooth with no issue but if I stop the container for backups or need to reboot, I'm having a hard time getting it going again. It will try to start and then shut right down. This is what the log shows.
s6-rc: info: service s6rc-oneshot-runner: starting
s6-rc: info: service s6rc-oneshot-runner successfully started
s6-rc: info: service fix-attrs: starting
s6-rc: info: service fix-attrs successfully started
s6-rc: info: service legacy-cont-init: starting
cont-init: info: running /etc/cont-init.d/configurations.sh
s6-rc: fatal: timed out
s6-sudoc: fatal: unable to get exit status from server: Operation timed out
/run/s6/basedir/scripts/rc.init: warning: s6-rc failed to properly bring all the services up! Check your logs (in /run/uncaught-logs/current if you have in-container logging) for more information.
/run/s6/basedir/scripts/rc.init: fatal: stopping the container.
s6-rc: info: service fix-attrs: stopping
s6-rc: info: service fix-attrs successfully stopped
s6-rc: info: service s6rc-oneshot-runner: stopping
s6-rc: info: service s6rc-oneshot-runner successfully stopped
Sometime if I restart it a few times, it will eventually start running but I usually have to remove the container and reinstall or, do a clean reboot to get it going.
Not sure if this is an Unraid issue or something I messed up when making the container. This is my first try at one so my guess is the latter. All my other containers that I'm running from the community application center in Unraid are running just fine.  Does anthing jump out at you from the log?

Hi @motif82,
This error seems to be related to an issue with s6-overlay, which is used for process management in a container.
With the version where you encountered the problem, I was not able to reproduce the issue.
Perhaps there is a peculiarity with Unraid  ¯ \ _ (ツ) _ / ¯
I have just pushed a new version for ruTorrent v4.3.6.
It's a new Docker image. Maybe this will solve your problem?

Thanks for the reply, I'll give the new version a try this weekend. I have been doing some searching and it looks like this was an ongoing problem with the s6-overlay timing out too soon in a lot of different programs. They removed the time out command in its latest version. Not sure if that's written into the program or in unraid.
https://github.com/just-containers/s6-overlay/commit/e2738d136bbdedbe3553b947f3c18183fc70e56c

I did try the new version but it was giving me the same errors with s6-overlay. I put in a variable command of S6_CMD_WAIT_FOR_SERVICES_MAXTIME = 0 as suggested on the S6 page and it started right up. I'll do some more testing to confirm that this fixed the issue.

Hi @motif82,
It seems to me that the version of S6 in Alpine repository (latest) is version <IP_ADDRESS> which still has S6_CMD_WAIT_FOR_SERVICES_MAXTIME of 5000 milliseconds.
I'm waiting for a new version of the Alpine package from @skarnet. Thanks for your finding :)

s6-overlay has been updated in Alpine edge. The new version should appear in the next release of Alpine.


copy instructions in readme are not screen reader friendly

the instructions in the readme are not screen reader friendly and my instance admin is blind.
for example:

Copy the files from this folder to your Mastodon themes directory app/javascript/styles/:

app/
  javascript/
    styles/
      tangerineui.scss                                | **new**
      tangerineui-purple.scss                         | **new**
        tangerineui/                                  | **new**
          layout-single-column.scss                   | **new**
        tangerineui-purple/                           | **new**
          layout-single-column.scss                   | **new**

it is not clear what needs doing based on this. instead it should make a clear instruction, and then explain that the code block that follows is an example of what this looks like:

Copy the files from mastodon/app/javascript/styles/ in this repository to your Mastodon themes directory app/javascript/styles/. when complete the folder should contain:

app/
  javascript/
    styles/
      tangerineui.scss                                | **new**
      tangerineui-purple.scss                         | **new**
        tangerineui/                                  | **new**
          layout-single-column.scss                   | **new**
        tangerineui-purple/                           | **new**
          layout-single-column.scss                   | **new**

the directory listing will still be inaccessible as it relies on indentation to indicate the relationship between each listing, however at least the instruction on what needs doing are clear. a better solutions would be appreciated.

the best way would be to format it as commands, like so
cd dir1
cp $INSTALLDIR/path/filename.ext .
cp $INSTALLDIR/path/filename1.ext .
cd ..
cd dir2

... and so on
Better still would be to have an installer script for this that can be run from ~/live in the mastodon user

something like this?

Copy the files from mastodon/app/javascript/styles/ in this repository to your Mastodon themes directory app/javascript/styles/:

cp -r $REPO/mastodon/app/javascript/styles/* $INSTALLDIR/app/javascript/styles

Copy the files from mastodon/app/javascript/skins/vanilla/ in this repository to your Glitch-soc skins directory app/javascript/skins/vanilla/:

cp -r $REPO/mastodon/app/javascript/skins/vanilla/* $INSTALLDIR/app/javascript/skins/vanilla

Compile theme assets and restart. Run RAILS_ENV=production bundle exec rails assets:precompile and restart your Glitch-soc instance for the changes to take effect.

the best way would be to format it as commands, like so
cd dir1
cp $INSTALLDIR/path/filename.ext .
cp $INSTALLDIR/path/filename1.ext .
cd ..
cd dir2

... and so on
Better still would be to have an installer script for this that can be run from ~/live in the mastodon user

I wouldn't know how to make such a script, but if anyone wants to give it a try I will add it to the instructions :)

something like this?

Copy the files from mastodon/app/javascript/styles/ in this repository to your Mastodon themes directory app/javascript/styles/:

cp -r $REPO/mastodon/app/javascript/styles/* $INSTALLDIR/app/javascript/styles

Copy the files from mastodon/app/javascript/skins/vanilla/ in this repository to your Glitch-soc skins directory app/javascript/skins/vanilla/:

cp -r $REPO/mastodon/app/javascript/skins/vanilla/* $INSTALLDIR/app/javascript/skins/vanilla

Compile theme assets and restart. Run RAILS_ENV=production bundle exec rails assets:precompile and restart your Glitch-soc instance for the changes to take effect.

Alright, I'll edit the instructions to add commands.
Thank you for reporting this!


Expanding JSON recusivly

If you have an object inside an object like
{
status: "ok",
serverTime: "2018-08-29T11:34:34.930Z",
serverTimeEpoch:<PHONE_NUMBER>930,
apiEnabled: true,
careportalEnabled: true,
boluscalcEnabled: true,
head: "02a02c7",
settings: {
units: "mg/dL",
timeFormat: 24,
theme: "default",
alarmUrgentHigh: true,
alarmUrgentHighMins: [30, 60, 90, 120]
}
}
i'm not able to populate the hole object. settings is just a string '{ units: "mg/dL", timeFormat: 24,...'. The top elements are processed correctly.

Can you explain what info you want and how you try to get it?

imagine a json like
{
a: {
b: 12,
c: { c1:'Hi', c2: true, ... }
},
d: [{
more objects/arrays
},{
also more objects/arrays
}
]
}
returned form a server via http. I try to import the hole json including all sub structure into ioBroker using
status.[*] | web | [URL] | (empty filter) | json | (no write) | */15 * * * *
i also test
status.* and different filters.

Hi volkerrichert!
If you want the full json converted to an object and stored in variable then put (@) into filter (it returns the full object converted from json) and set no role/type
status| web | [URL] | (@) | json | (no type) | (no write) | */15 * * * *
if you want only the settzings the use (@.settings)  or settings only should work as well if on main level
otherwise the json itself is returned as a string ....

i did it and the status is just a single string

the config looks like

What's wrong?
Volker

nope


netlify deploy --toml  is missing

I find it very very odd that simply supplying a path to the toml file is not something that is included in this cli, this blows my mind actually.
We are not using netlify builders and want to simply deploy from circleci but we are in a subdirectory of a monorepo.
All issues would be removed if you could simply supply a path to the config toml, I am not sure I have ever used a cli where this is not one of the most basic arguments to a command like deploy.

unless providing a --site flag to the deploy command removed the need to use the link command all together?

Yes, exactly. The --site flag can be provided without having to perform netlify link. Based on the above, it appears this might solve your problem. :+1:

Well that is frustrating, seems we should have used this to begin with rather than supplying the toml file path. The hanging user supplied inputs make it seem as if the toml file could not be found, as it "can" include the ID under [Settings] but that seems to be ignored completely, which is VERY odd.

Yes, you're correct.
Did this solve your problem?

Yes, --site is all that was needed. Seems the docs do not make this clear, nor does it make it clear that the [Settings] ID from toml is completely ignored...

Hi @dan003400, I'm glad to hear you've got things working. To better understand potential docs improvements, could you help me understand the following?

What caused you to try adding [Settings] ID to your netlify.toml file? We don't support this configuration option, so I'm hoping to figure out if there's a place where we need to remove an errant reference to it.
The --site flag is documented in the deploy command reference and in the output for netlify deploy help. Did you find either of these sources when looking for a --toml flag? Are there other places you checked for this information? Understanding where you looked and what you found can help us improve discoverability.

Hi,
I'm trying to target 2 different toml files depending on build mode.
I'm working on Angular applications, with Scully for SSG.
SSG is only triggered for master branch and tags, otherwise it's a default Angular build.
When I'm building a default Angular App, I need Netlify to redirect every url to index.html.
When I'm on SSG mode, the urls targets some real SSG folders and I don't want the default SPA redirection to index.html. I need also to redirect to language prefix when I'm on SSG mode.
So if I could easily target a toml file or another depending on the type of build, it would be very helpful.

I hope this command will work soon :
netlify deploy --config <path-to-toml>
Meanwhile I had to deal with file rename while CI process (netlify-default.toml OR netlify-scully.toml depending on context to netlify.toml).

Closing as stale. Please re-open if needed


Java 8 hangs (not 1.8.0_05 though)

Please use the following bug reporting template to help produce actionable and reproducible issues:
Java 8 hangs when typing java -version. I've tested this with a few installations.
I first tried the popular ppa:webupd8team/java:
$ sudo add-apt-repository ppa:webupd8team/java
$ sudo apt-get update
$ sudo apt-get install oracle-java8-installer

That installed successfully, but it hung when I typed java -version. Here's the strace results.
Then I went to check out if others were experiencing the same issue when I came across #49 specifically this post of manual installation instructions for java 1.8.0_05.
I tried it out and it works just fine:
root@ALI:/home/supaham# java -version
java version "1.8.0_05"
Java(TM) SE Runtime Environment (build 1.8.0_05-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.5-b02, mixed mode)

However 1.8.0_05 has a few bugs and invalid compilation errors.
So I went to update to 1.8.0_102 but then it hung again. The instructions to install 102 were the same as the one in the post linked above, but the url replaced with:
wget --header "Cookie: oraclelicense=accept-securebackup-cookie" http://download.oracle.com/otn-pub/java/jdk/8u102-b14/jdk-8u102-linux-x64.tar.gz

Here's the strace results of the java -version command on version 1.8.0_102
Windows build number: Microsoft Windows [Version 10.0.14393]
No packages are required to install that I know of.
Edit: Although I can get java -version to work, I can't get a Minecraft instance to run without it hanging after displaying a message saying "Loading Libraries", usually on the same computer in normal Windows this step takes at most 5 seconds. So far it's been over two minutes and it's still stuck on that step with a very similar strace result as far as I can see.

Java has some known issues on the Anniversary Update.  The strace you provide looks very similar to some of the issues I have seen.  I believe that specific issue should be in the fix for #746.

I was unable to repro this in the 14971 build after following the repro $ sudo add-apt-repository ppa:webupd8team/java $ sudo apt-get update $ sudo apt-get install oracle-java8-installer
But, this is 1.8.0_111


Interactive shell

Is it possible to launch a python interactive shell?

Currently the best option is "make run", like this:
$ make run
print 'hola'
^D
I'll leave this issue open to track progress on a nicer interactive experience.