XTSMGRAPHICS "Read sixel graphics geometry" returns the different value from xterm.

Contour Terminal version
0.3.1-unreleased-master-7f13fbb0
Installer source
Github: source code cloned
Operating System
Ubuntu Linux 20.04
Architecture
x86-64
Other Software
No response
Steps to reproduce
cat <<EOF > test.sh
IFS=';' read -a REPLY -s -t 0.25 -d "S" -p $'\e[?2;1;0S'
echo "width=\${REPLY[2]} height=\${REPLY[3]}"
EOF
bash test.sh

Expected Behavior
Returned width and height are smaller than or equal to screen width and height (same as the latest xterm).
Actual Behavior
Returned width and height are always 1920 and 1080 regardless of screen size.
Additional notes
By this problem, https://github.com/hackerb9/lsix can not layout pictures as expected position.
contour

xterm

ref: xterm implementation:
https://github.com/ThomasDickey/xterm-snapshots/blob/834b501a1416d7f14b1c38705083f413aea92eee/charproc.c#L4625

@christianparpart doesnt this just return whatever is defined in the contour.yml?

Good morning. I'm not sure about how a real VT340 would respond to this, but due to the nature of the fact, that a VT340 is fairly limited to what a modern VTE is capable of, I can't judge for either side.
But to my understanding, XTSMGRAPHICS is used to query the limits, that's not necessarily the same as how big a screen (terminal viewport in pixels) is. For that there is another VT sequence, CSI 14 t (XTWINOPS), as introduced by dterm, and extended by xterm (just losely quoting here).
@hackerb9, what's your stance on this? Objectively looking at it, I'd rather change lsix to use XTWINOPS on top of XTSMGRAPHICS to query the screen width as the minimum of both values.

https://github.com/ThomasDickey/xterm-snapshots/blob/834b501a1416d7f14b1c38705083f413aea92eee/charproc.c#L4622-L4626
The problem I'm (personally) having with this code, is, that screen size may be changed due to the user, using CSI 14 t (IMHO) clearly tells that you are querying viewport width/height in pixels (which is subject to change), whereas CSI [ ? 2 ; 1 ; 0 S (by looking at the docs) reads the sixel canvas size in pixels attribute, not stating its relation to the actual window's size in pixels.

A couple of points worth mentioning:

XTSMGRAPHICS is an XTerm invention - a real VT340 would not have responded to that.
XTerm's initial implementation of the 2;1 query returned the maximum geometry size, the same as you're doing now (see here).
A few other terminals copied that initial implementation, and while some have been updated to match XTerm's current behavior, I think some still report the maximum size.
CSI 14 t is also not a VT340 standard, and has its own problems, but it's more widely implemented, and more reliable in general.

So personally, I'd recommend apps just rely on CSI 14 t if they need to determine the screen size (taking into account that some rounding may be required). But if you also want to use XTSMGRAPHICS as a backup, only do so if it's smaller than the dimensions returned by CSI 14 t - that should give you the most accurate results.

Sounds absolutely reasonable. Thanks @j4james ;)

This is just my personal opinion,
XTSMGRAPHICS is an XTerm invention, so other terminals should follow XTerm's current spec.
https://github.com/ThomasDickey/xterm-snapshots/blob/834b501a1416d7f14b1c38705083f413aea92eee/ctlseqs.txt#L569-L622
As the following explanation,

Pa = 1 should return minimum of the window size (maybe text (screen) area size) and the maximum graphic size.
Pa = 4 should return the maximum graphic size.

Additionally, XTWINOPS (CSI 14 t) should return text area size.

       Pa = 1  -> read attribute.
       Pa = 2  -> reset to default.
       Pa = 3  -> set to value in Pv.
       Pa = 4  -> read the maximum allowed value.

      Notes:
      o   The current implementation allows reading the graphics
          sizes, but disallows modifying those sizes because that is
          done once, using resource-values.
      o   Graphics geometry is not necessarily the same as "window
          size" (see the dtterm window manipulation extensions).
          XTerm limits the maximum graphics geometry according to
          the maxGraphicSize resource.
          The maxGraphicSize resource can be either an explicit
          heightxwidth (default: 1000x1000 as of version 328) or the
          word "auto" (telling XTerm to use limits the decGraphicsID
          or decTerminalID resource to determine the limits).
      o   XTerm uses the minimum of the window size and the graphic
          size to obtain the maximum geometry.
      o   While resizing a window will always change the current
          graphics geometry, the reverse is not true.  Setting
          graphics geometry does not affect the window size.
      o   If xterm is able to support graphics (compile-time), but
          is not configured (runtime) for graphics, these responses
          will indicate a failure.  Other implementations which do
          not use the maximum graphics dimensions but are configured
          for graphics should report zeroes for the maximum geometry
          rather than a failure.

So personally, I'd recommend apps just rely on CSI 14 t if they need to determine the screen size (taking into account that some rounding may be required). But if you also want to use XTSMGRAPHICS as a backup, only do so if it's smaller than the dimensions returned by CSI 14 t - that should give you the most accurate results.

The Applications just only are forced to work around for supporting various terminals, but the terminals should not expect the application's work-around effort and should keep the compatibility for the standard as possible.

The Applications just only are forced to work around for supporting various terminals, but the terminals should not expect the application's work-around effort and should keep the compatibility for the standard as possible.

I'm currently (today) busy at work, I can respond later tonight more detailed. But I absolutely agree with you here that apps should not suffice from implementation semantic differences.

My 2cents on XTSMGRAPHICS:
The sequence feels weirdly xterm implementation dependent to me, it mostly reflects restrictions/settings on xterm, that other terminals might not have in the same way. In general I think terminal sequences should stay in the general and portable interface realms, and not surface implementation details at all costs, unless the sequence is marked for private usage only. XTSMGRAPHICS fails in that part imho.
Now with xterm things are more tricky - it is treated by many app devs and even terminal devs as the de-facto terminal interface standard these days, which makes it hard to ignore any sequence, xterm comes up with. Thats the reason, why I implemented XTSMGRAPHICS as well, but only parts of it, that could be answered reasonably:

ReGIS - all nope, answered with GaStatus.ITEM_ERROR
colors registers - READ | SET_DEFAULT | SET | READ_MAX supported (up to 4096)
sixel geometry - READ | READ_MAX supported, all others will fail

For sixel geometry READ it returns the current viewport size in pixels, for READ_MAX I had to cheat and return the square of the pixel limit of the sixel decoder (default 4096x4096). The last thing is somewhat unlucky, as it is not really limited by that (an image can happily run up to 32k pixel width, if height * width stays within pixelLimit).
The impl can be found here: https://github.com/jerch/xterm-addon-image/blob/75deeccd20172e753cf8b38846140462d05b9467/src/ImageAddon.ts#L259

Just to be clear, I agree with everyone that is saying you should match XTerm's current behavior if you're going to implement this sequence. But I'd still recommend applications avoid using it if possible.

The sequence feels weirdly xterm implementation dependent to me, it mostly reflects restrictions/settings on xterm, that other terminals might not have in the same way. In general I think terminal sequences should stay in the general and portable interface realms, and not surface implementation details at all costs, unless the sequence is marked for private usage only. XTSMGRAPHICS fails in that part imho.

I fully agree with this. That's why I've just chosen not to implement it. And if I come across an application or library that depends on it, I've encouraged them to avoid that dependency, and support a reasonable fallback.

Yes, the main problem is that, as the title says, "XTSMGRAPHICS "Read sixel graphics geometry" returns the different value from xterm".
It makes application confused.
Unknown CSI can be ignored and XTSMGRAPHICS defines error value.
The terminal can ignore unknown CSI (by not implementing CSI) and XTSMGRAPHICS  defines error.
So, if implementing XTSMGRAPHICS is difficult for the terminal, it should ignore or return error rather than return unexpected value.

I fully agree with this. That's why I've just chosen not to implement it.

I agree with your way.
I think that this is the right way to handle this if the terminal can not support this CSI for some reason.

I'd still recommend applications avoid using it if possible.

I agree with you about implementing applications.

i can change that to match xterm (as much as I dislike that :D). But regardless of that, we could still kindly ask @hackerb9 to change the query order, first test CSI 14 t, and then go for XTSMGRAPHICS if the first fails, or use the minimum value of both (if both return something). Does this sound plausible?

i can change that to match xterm (as much as I dislike that :D). But regardless of that, we could still kindly ask @hackerb9 to change the query order, first test CSI 14 t, and then go for XTSMGRAPHICS if the first fails, or use the minimum value of both (if both return something). Does this sound plausible?

Hi! Thanks for the kind request. Possible, but not plausible given my current understanding of the situation.
First, some ancient history: If there are deficiencies in XTSMGRAPHICS being used for sixel geometry, I'm the one to blame, not XTerm nor XTerm's maintainer, Mr. Dickey. While that extension existed before for changing the pixel depth, I'm the one who proposed using it to also query the sixel geometry and worked with Mr. Dickey to get it working properly in XTerm. The problem at that time, and that still exists with dtterm window ops, like CSI14t, is that window size (or geometry in the old lingo) has been overloaded to mean different things. IIRC, the dtterm escape sequences were meant to be able to position the terminal on the screen, so the "size" originally included the blank border around the text area and even the width of the titlebar and other user interface widgets.
While it is a happy accident if CSI14t returns the correct sixel geometry, it is not incorrect for a terminal to do otherwise. Even excluding UI widgets, the dtterm window size may not match the renderable sixel area: a terminal might, for example, choose to always use an 800x480 sixel geometry, no matter what the window size is. On the other hand, if a terminal has implemented XTSMGRAPHICS in a way that it returns something other than the sixel screen size, then it is in error. (And, yes, XTerm itself was in error originally, but that has been fixed since 2019.)
So, I think using dtterm's size for sixel geometry is a mistake. But, as always, I'm fallible: Please let me know if I got something wrong.

I hate to be the one defending the CSI t sequences, because I really don't like them either, but I've tested quite a lot of sixel terminals, and the simple truth is that you get better results using CSI t than you do using XTSMGRAPHICS (at least in my experience). In time that may change, but for now if you want your app to work on as many terminals as possible, I'd recommend making the most of that happy accident.

Indeed, CSI t is quite convoluted, and even was subject of several security concerns up to CVEs. The WindowOps sequences kinda lost their primary purpose to tune certain desktop integration aspects long ago (mind you, many things simply dont work anymore, as they have no counterpart on modern DEs).
So the shift of meaning is a logical consequence as in any evolutionary system (we are just that atm, as we lack a higher authority giving us red/green lines regarding the terminal interface). The problem we all have with this (at least I find it painful) - there is no strict right or wrong in such a scenario, just a more likely/unlikely, which really sucks in terms of strict correctness (computers still need that, unlikely to change until we have QPU-NPUs).
Regarding XTSMGRAPHICS I think you should not blame yourself too hard (@hackerb9), while I dont like it for leaking xterm implementation details, it certainly has several pros:

separation of concerns, graphical stuff is a very different and delicate thing for text-driven terminals
no convolution of other sequences / overloaded meanings
extensible interface (easy to put other protocols or graphical options there, once needed)
reporting caps (just a minor nag from my side - would have made SET options non-reporting by default, and hide reporting behind a sequence flag)

So I try to see things more opportunistic here - since XTSMGRAPHICS is already there, and ppl are likely to use it (its still xterm, we cannot ignore that until some other TE dethrones it) - lets use it to our advantage (thats the reason why I proposed in another thread to put a "reload default palette" option there).

@christianparpart

first test CSI 14 t, and then go for XTSMGRAPHICS if the first fails,

Sorry if it's wrong. I think,
Sixel does not have width and height explicitly.
If the application uses only CSI 14 t, when the application run on very large window, that is over the supported sixel geometry by the terminal, the application requests the drawing large sixel over the supported dimension.
In the case, the result of drawing is undefined (depending  on the terminal), but application cannot know the case by the CSI 14 t.
XTSMGRAPHICS is required for the application to know the supported sixel dimension by the terminal in advance.

If the application uses only CSI 14 t, when the application run on very large window, that is over the supported sixel geometry by the terminal, the application requests the drawing large sixel over the supported dimension.

This is a problem that I think is exclusive to XTerm. And one of the effects of this limitation is that XTSMGRAPHICS can't actually be relied on to report the real screen size (in XTerm at least). For an app like lsix, that is probably fine - assuming all you care about is the maximum size that can be used. But most complex sixel applications are more interested in the pixels-per-cell, i.e. you want to calculate how big an image needs to be to cover a certain range of character cells. That's not something you can reliably determine with XTSMGRAPHICS.

minimum of  XTSMGRAPHICS and CSI 14 t (for old xterm and old contour)

I believe Alacritty is another terminal that still reports the max geometry for \e[?2;1;0S.

XTSMGRAPHICS (when CSI 14 t is not supported)

I've never encountered a sixel implementation that supported XTSMGRAPHICS but not CSI 14 t.
My recommendation, if you need the cell size, would be CSI 16 t, and if that's not available, CSI 14 t divided by CSI 18 t (rounding down if necessary). If you want the screen size, calculate the cell size as described above, and multiply by CSI 18 t. I personally wouldn't bother with XTSMGRAPHICS unless you care about XTerm's geometry limitations in particular.

@j4james
Thank you for very interesting comment.

And one of the effects of this limitation is that XTSMGRAPHICS can't actually be relied on to report the real screen size (in XTerm at least).

I agree with you too.
But it is because XTSMGRAPHICS does not report screen size.
I think the application that uses screen size and does not uses graphics size should not XTSMGRAPHICS.

I believe Alacritty is another terminal that still reports the max geometry for \e[?2;1;0S.

I updated to minimum of screen size and graphics size:
https://github.com/microo8/alacritty-sixel/commit/83a40a680f630b168f0a0ccb107e276b6bc22ee8

My recommendation, if you need the cell size, would be CSI 16 t, and if that's not available, CSI 14 t divided by CSI 18 t (rounding down if necessary). If you want the screen size, calculate the cell size as described above, and multiply by CSI 18 t.
Thank you for actual and useful recommendation.
I think when CSI 16 t is available, screen size also is able to calculated with ioctl(TIOCGWINSZ) ws_row and ws_col.

I personally wouldn't bother with XTSMGRAPHICS unless you care about XTerm's geometry limitations in particular.

My point is that the result of drawing pixel over the supported dimension by the terminal is undefined (depending on the terminal).
I think XTSMGRAPHICS is needed to avoid the undefined behavior, not to determine the exact sixel size.
I think every terminal has some kind of limitation same as xterm because resources are finite.
When XTerm's spec is respected, should the application like lsix do the following ?
1 get maximum image size by XTSMGRAPHIC Pa=4.
2 get current screen size by CSI 14/16/18, ioctl(TIOCGWINSZ) ws_row and ws_col, and the combination.
3 get the minimum of "maxiumum image size" and "current screen size".

@kumattau writes:

When XTerm's spec is respected, should the application like lsix do the following ?

get maximum image size by XTSMGRAPHIC Pa=4.
get current screen size by CSI 14/16/18, ioctl(TIOCGWINSZ) ws_row and ws_col, and the combination.
get the minimum of "maxiumum image size" and "current screen size".

Good question. When that happens — which shouldn't be long now that you've patched Alacritty and Contour is already fixed — the answer is pretty simple:

Get sixel graphics geometry by XTSMGRAPHICS(Pᵢ=2, Pₐ=1)

That's it.
The purpose of XTSMGRAPHICS with Pₐ = 1 is to provide an explicit way to read the sixel height and width.

I've been wondering if this bug could have been averted if I had added the following note in the description of XTSMGRAPHICS in XTerm's ctlseqs:
The "graphics geometry" attribute is meant for applications to read the size of the visible screen that is available for use. It is never larger than the terminal window, but may be smaller depending upon the terminal implementation.
Would that have helped? If so, I'll see about getting it added to ctlseqs.ms.

@hackerb9 to be hoonest? yes. in my case at least. because I looked at ctlseqs.txt and kind of trusted in what it said, given the completeness of that document and the reputation it had, at least the way I perceived it, I did not feel in need to verify every documentation line with its implementation in the xterm source code.
Regardless of that, improving documentation is always welcome. :)

@christianparpart writes:

to be honest? yes. in my case at least.

Thank you. I'm glad I found something that might help others in the future. Before I contact Mr. Dickey about fixing it, was what I wrote sufficient? Could it be clearer? More succinct?

I looked at ctlseqs.txt and kind of trusted in what it said, given the completeness of that document and the reputation it had, at least the way I perceived it,

And, this is where my mea culpa becomes mea maxima culpa. I wrote the relevant part of the documentation and Mr. Dickey implemented it in XTerm. It should have been a big hint to me that there was a problem in my spec when he was initially wrote the code so that XTerm's maximum was returned for both Pₐ = 1 and Pₐ = 4.
If you wish to know my confusion, read on, otherwise please simply accept my apologies.
The problem was that I was writing as an application developer. For applications, knowing the usable screen size is critical and an obvious deficit in DEC's sixel specification. I didn't see any point in reading the maximum geometry value — what would that even mean for an unsettable attribute? Only today did it dawn on me that, for  terminal developers, the maximum must be a much more salient number and clarification is needed.

I did not feel in need to verify every documentation line with its implementation in the xterm source code.

Nor should you have to. The irony is that if you had checked XTerm's source code before 2019, it would have been wrong. Even more ironic: I had been thinking that the error in the XTerm source code wasn't so important since the documentation was clear. Boy, that'll learn me! 😖
Again, please accept my apologies for the confusion.

Note that the documentation does actually point out that graphics geometry is not necessarily the same as the window size. It's in the "notes" section below the description of the sequence. But I don't think it helps having that information so far removed from where the graphics sequence is described.
Anyway, I'm still of the opinion that this is a bug in XTerm that should be fixed.

Anyway, I'm still of the opinion that this is a bug in XTerm that should be fixed.

I think it is no good to change XTSMGRAPHICS Pa=1 spec because there are terminals which implement XTerm's spec expectedly.
But I am interesting the bug-fixed spec details which @j4james  thinks.
If the spec is reasonable and useful for the application on the terminals, the new XTSMGRAPHICS Pa (Pa=5 ?) can be proposed, I think.

Sorry, I wasn't very clear. I didn't mean the XTSMGRAPHICS sequence was a bug. I meant the fact that XTerm can't display certain image sizes is a bug.
Imagine any other graphics library that had a BlitImage operation that would just fail to work on certain parts of the screen. But you're told that's not a bug - you just need to call the IsBlitImageGoingToWork function first. And then somehow redesign your app on the fly to work around those limitations. Also, for compatibility, all other graphics libraries are encouraged to add an IsBlitImageGoingToWork function, even though they all just returns true, because nobody else has this ridiculous bug.
This is not like a function failing under exceptional conditions, like you've run out of memory, or you were trying to load an image 10 times bigger than the screen itself. This is just an image that is size of the terminal window - there's no reason that shouldn't work under normal conditions.

I second @j4james here, imho xterm's restriction, that the graphical canvas geometry might be smaller than the visible text area, is a no-go these days. (Though I have an idea, where this comes from, the sixel painting is awfully expensive in xterm, esp. with background_select=1, so this might be an optimization to save some drawing time).

Sorry, I'm not good at English.

I didn't mean the XTSMGRAPHICS sequence was a bug. I meant the fact that XTerm can't display certain image sizes is a bug.

I understood that you say XTSMGRAPHICS spec does not have problem but XTerm implementation has problem.
I think xterm implementation is off topic in this issue ticket, but I share my test result of displaying 5000 px width sixel on some terminals.

XTerm: no image output
alacritty-sixel: no image output with error message
contour: 1920px image truncated
mlterm: 5000px image output
wezterm: 5000px image output

I think the thing that some terminals limit image size is justified by the following reasons:

terminal is not graphic library for general purpose
outputting image is not much important for character terminal
outputting image is expensive in terms of memory and processing time for character terminal

I think that xterm's 1000px limit is too small and it is better to relax  the limit, but I don't think xterm should not have the limit.

I think the thing that some terminals limit image size is justified by the following reasons:
* terminal is not graphic library for general purpose

* outputting image is not much important for character terminal

* outputting image is expensive in terms of memory and processing time for character terminal

I think that xterm's 1000px limit is too small and it is better to relax the limit, but I don't think xterm should not have the limit.

The points you bring up here, account more towards no graphics support at all - which is perfectly fine for a TE, if its environment has strict resource limits (e.g. embedded stuff, kernel console). Then make it optional, e.g. by a compile switch. But if the switch is on, the TE should imho not restrict the graphics area to a smaller size than the allowed viewport. Machines as of today have enough resources to handle that fairly well, this artificial restriction is just an annoyance to create frictions on app dev and terminal user side for no good reasons anymore.
So either support full width, or disable graphics output at all. Thats my stance here. SIXEL itself allows up to 32k runwidth - which is very easy to handle, if you do processing in sixel bands, not the whole thing at once. And thats from a +30ys old semi-spec - and we still have some decades to go, until we hit that screen resolution area (some cinema projectors operate up to 64k already, but that's not the first audience for terminal output rendering...).

@christianparpart @j4james @jerch
I am sorry if I have offended you.
I am just worry that the ticket can not be closed due to a discussion not directly related to this ticket.
For now, I created the following discussion about image size supported by the terminal: https://github.com/contour-terminal/contour/discussions/680
Let's discuss it on there if more necessary.


Code clean up

Implemented RAG with Context
Updated gitignore and removed autogenerated files.

Do folks need to run anything to get the genkit/compass-generated files to appear?

Do folks need to run anything to get the genkit/compass-generated files to appear?

Ugh, they only get generated if you edit an FDC file. Re adding in the next commit. Sorry about that.

No worries. Thanks for taking a second look


remove underlines from list item keys

Type of change

[ ] Refactor
[ ] New feature
[ ] Bug fix
[x] Optimization
[ ] Documentation Update

Description
Underlines are confusing in a web interface where they normally imply a hyperlink. Replace the  tags around the keys in
 items with
 with style references using bold formatting instead.
Related Tickets & Documents

Related Issue #
Closes #

Checklist before requesting a review

[x] I have performed a self-review of my code.
[ ] If it is a core feature, I have added thorough tests.

Testing
I tried to quickly get the yarn environment running for local frontend testing, but it wouldn't work for me and for this simple style change I didn't invest the time to troubleshoot the test environment. I would appreciate it if someone else could validate this real quick.

Hey @dustinblack the change is adding a new line after the div section.

hey all! Is this still relevant?

Updated the
s to s, which should correct the errant line return.

The local-compose.sh script is failing to build the backend for me, so I still can't validate it locally.

@jtaleric I think it's still relevant. The existing underlines are a confusing UXD experience.

ok, it just sat idle for a bit. Thanks

error: command 'gcc' failed: No such file or directory

error: command 'gcc' failed: No such file or directory
Do you have gcc?

error: command 'gcc' failed: No such file or directory

error: command 'gcc' failed: No such file or directory
Do you have gcc?

The local-compose.sh script is all podman commands, so that error is from the pip install within the container build, not from my local system.

I wonder if it is as simple as adding the below, or if there is some bigger arch difference here...
diff --git a/backend/backend.containerfile b/backend/backend.containerfile
index 92c0be9..cde57a9 100644
--- a/backend/backend.containerfile
+++ b/backend/backend.containerfile
@@ -15,7 +15,7 @@ WORKDIR /backend

 EXPOSE 8000

-RUN dnf install -y pip
+RUN dnf install -y pip gcc

 RUN pip install --user poetry && \
     poetry export -f requirements.txt -o requirements.txt && \

I've got a few cycles, so I'm testing it now, but gcc alone isn't the solution as another python development dependency pops up. Now for some reason my build can't access the repos (outage?), so I'm stuck. I'll give it another shot later.

I wonder if it is as simple as adding the below, or if there is some bigger arch difference here...
diff --git a/backend/backend.containerfile b/backend/backend.containerfile
index 92c0be9..cde57a9 100644
--- a/backend/backend.containerfile
+++ b/backend/backend.containerfile
@@ -15,7 +15,7 @@ WORKDIR /backend

 EXPOSE 8000

-RUN dnf install -y pip
+RUN dnf install -y pip gcc

 RUN pip install --user poetry && \
     poetry export -f requirements.txt -o requirements.txt && \

I've got a few cycles, so I'm testing it now, but gcc alone isn't the solution as another python development dependency pops up. Now for some reason my build can't access the repos (outage?), so I'm stuck. I'll give it another shot later.

ack. Thanks for trying...
Yeah, I don't have a aarch64 machine to help figure this out. I do know we were able to s/podman/docker (they didn't have podman installed) and have some Mac users get this working (they were on the M1 chipset).

https://stackoverflow.com/questions/65084318/trouble-installing-pandas-on-new-macbook-air-m1
I realize you mention you are running linux + arm64 -- I am curious do you have panda's installed via pip on your machine?

https://stackoverflow.com/questions/65084318/trouble-installing-pandas-on-new-macbook-air-m1
I realize you mention you are running linux + arm64 -- I am curious do you have panda's installed via pip on your machine?

I don't, but again, the package installs and dependencies are all within the containers.

ack - yup totally understand that. I as trying to figure out what with the container build was missing due to the arch.

I fixed the container build for linux/aarch64, but the local-compose.sh script still doesn't seem to be enough on its own to stand up a simple local frontend to validate the change.

awesome! Thanks for that.
Yeah, the toml/ auth for ES is still clunky.

Bump.

Superseeded by #79


chore(deps): update common-dev-assets digest to 3527c67

This PR contains the following updates:

Package
Update
Change

common-dev-assets
digest
8631a29 -> 3527c67

Configuration
📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.

[ ] If you want to rebase/retry this PR, click this checkbox.

This PR has been generated by Renovate Bot.

:tada: This PR is included in version 1.0.4 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Enable caching of more goals

From https://hibernate.atlassian.net/browse/HSEARCH-5094:
Enable more caching; there are a few goals not covered at the moment. In particular:

Stuff about ORM @Incubating annotations
Asciidoc things

Then maybe also consider:

Spotless
Moditect
Unpack dependencies? 🤔

Feel free to try, but:

Spotless
Moditect

Seems hard to get right / non-buggy.

Unpack dependencies? 🤔

Caching doesn't help (much) for IO-bound goals such as dependency unpacking. Wouldn't recommend.


Rectangle automatic expansion due to middle-inserted text moves the cursor to the end of the text

In the image: this is what happens when I type "word " 4 times (the last iteration is done when I move the cursor to be before the last word).
Reproduce:

Write inside a rectangle that has room for 1 line.
Before you hit the second line, start writing before the last word until the rectangle expands into 2 lines.
Watch as the cursor jumps to the end of the last word, no matter where it was.

Here's a video demonstrating the issue. After I type all the h letters, I use the arrow keys to move my cursor and then type qwer. Notice how qwer is incorrectly split up.
https://user-images.githubusercontent.com/4809268/155026964-ef9c4f70-2b5b-4469-ad91-59db4eeaa887.mp4

Temporary workaround: manually increase the height of the rectangle so that typing more text does not need to increase the height of the box.


Refactoring to remove duplicated code and make use of TimeIntervalUnit from polyglot

This refactoring will only work with the pull request below:
https://github.com/projectodd/jboss-polyglot/pull/3

Mike, look here please: https://github.com/abstractj/jboss-polyglot/commit/a8688708f230c65886c67647475e054f51c87cd3#L0R48


Pristine option does nothing

I tried sf-options="{ pristine: {errors: false, success: false}}".
It comes in scope.options but the options are ignored. It still validates the input no matter if it is pristine or not.
I found a fix but I find it more like a workaround.
'has-error': form.disableErrorState !== true && hasError() && !ngModel.$pristine, 'has-success': form.disableSuccessState !== true && hasSuccess() && !ngModel.$pristine

Could you please make a plunker or gist to demonstrate, it would help us a lot?

I added a demo: http://plnkr.co/edit/lYUgSKaW72vCm82G2dg1?p=preview

Removing "|| !scope.ngModel.$isEmpty(scope.ngModel.$modelValue)" will fix the problem without using the global option.
scope.hasSuccess = function() {
	if (!scope.ngModel) {
		return false;
	}
	return scope.ngModel.$valid &&
	(!scope.ngModel.$pristine || !scope.ngModel.$isEmpty(scope.ngModel.$modelValue));
};


[Bug] MultiFrame DICOM Problem

Describe the Bug
I’m currently trying to get the new Orthanc OHIF plugin to work with an existing larger Orthanc installation. This uses the Orthanc DICOM Web Plugin together with the Orthanc OHIF Plugin. OHIF is working fine with SingleFrame DICOMs, however, when trying to open Siemens MRI MultiFrame DICOMs OHIF just shows black images with the error message
Something went wrong
Something went wrongfalse.

Sorry, something went wrong there. Try again

The error message in the browser console is:
331.bundle.bd0c13931a21d53086c9.js:29510

       TypeError: Cannot read properties of null (reading '0')
    at app.bundle.599d31514539ffe1c788.js:14774:121
    at Array.map (<anonymous>)
    at combineFrameInstance (app.bundle.599d31514539ffe1c788.js:14774:109)
    at MetadataProvider._getInstance (app.bundle.599d31514539ffe1c788.js:14866:27)
    at MetadataProvider.get (app.bundle.599d31514539ffe1c788.js:14872:27)
    at Module.getMetaData (331.bundle.bd0c13931a21d53086c9.js:2813:37)
    at te (app.bundle.599d31514539ffe1c788.js:7:40923)
    at se (app.bundle.599d31514539ffe1c788.js:7:42930)
    at app.bundle.599d31514539ffe1c788.js:7:47832 'wadors:../dicom-web/studies/1.2.2<IP_ADDRESS>.1.1.5631.20230503114015.46143371/series/<IP_ADDRESS>.1<IP_ADDRESS>.175785.2023050312011134582384<IP_ADDRESS>/instances/<IP_ADDRESS>.1<IP_ADDRESS>.175785.2023050312055486448984441/frames/41'

when trying to access the dicom-web resource via curl on .../dicom-web/studies/1.2.2<IP_ADDRESS>.1.1.5631.20230503114015.46143371/series/<IP_ADDRESS>.1<IP_ADDRESS>.175785.2023050312011134582384<IP_ADDRESS>/instances/<IP_ADDRESS>.1<IP_ADDRESS>.175785.2023050312055486448984441/frames/41 everything works fine and a resource is returned. There is also no error message on the Orthanc Server end so I do suspect that the error lies with OHIF.
Crosslink to community forum: https://community.ohif.org/t/multiframe-dicom-problem-together-with-orthanc/852
Steps to Reproduce
Anonymized DICOMs that cause this issue can be downloaded here (link will work until 20 July 2023): https://upload.uni-jena.de/data/6493eb43ac2ed6.95743317/multiframe.dcm
The current behavior
No images and an error message is displayed
The expected behavior
Images should be displayed
OS
Alma Linux 8.8
Node version
unknown
Browser
Edge 110.01587

i have same problem

I am experiencing a similar issue with multi-frame MR SOPs but unlike this issue the OHIF 1.3 viewer is not giving any error in console, it just says shows the warning with
Display Set Messages
1. Display set has missing position information.
2. Display set is not a reconstructable 3D volume.

should I open a separate issue or attach an anonymized sample to this one?


Update links to incremental ASP.NET migration

Currently we link to a blog post on how to do ASP.NET to ASP.NET Core migration. But we now have a docs section for this that we should link to instead.

#28184


Table of Contents links do not work for sections with spaces in their name

Visit https://sphinxcontrib-confluencebuilder.atlassian.net/wiki/spaces/STABLE/pages/501974500/Table+of+Contents+Fabric
Make the window short enough so that you can see the "Output" section but not the sections below
Click "Sub-section"

The page correctly scrolls to the "Sub-section" heading

Scroll back up to the "Output" section
Click "Section B"

The page does not scroll at all

Looks like this got broken in v2.4 (appears to work in v2.3) when trying to address anchor link compatibility between different versions of the Confluence editors and rst/md (#866). When a correction can be made for this, the unit testing should be expanded to cover this use case to help avoid this from happening again.

Changes (https://github.com/sphinx-contrib/confluencebuilder/pull/921) have been made to correct broken anchor links on pages using a v2 editor. This change has been added into the main branch and should be made available next stable release. This can be tested now by using the development version. Feel free to try it out ahead of time any report any issues you may have.

Thank you @jdknight .
I have tested this out and it works for the case mentioned in the issue description.
However, it does not work for titles with apostrophes (and maybe other punctuation - I have not tested).
My local test:
Example TOC Demo
================

**Confluence TOC**

.. confluence_toc::
   :max-level: 3

**Local Contents**

.. contents::
   :local:
   :depth: 3

SimpleNoSpace
-------------

This always worked.

Has Space
---------

This does not work in 2.4.0, but does work on `main`.

HasApostrophe'
--------------

This does not work in the "Local Contents" TOC, but does work in the "Confluence TOC", even on `main`.

Please let me know if you prefer for me to create a new issue for this.

Forgot to explicitly mention this, but an additional pull request was made to address this issue (as best can be seen from limited testing). We now force URL encode any anchor links in v2, which looks to address anchor linking issues with various types of special characters. Hopefully this resolves most use cases; and any new that arise, we can create new issues and track any methods to address them.
Thanks again for trying out alternative characters and reporting the issue.
The change had been merged into the main branch and has been made available in the recent release. With v2.5 is now available on PyPI -- marking as closed.

Great, thank you!


Astro Slide: Screen momentarily going white at full brightness when going to sleep

Astro flashes a white full brightness screen momentarily when going to sleep (the device, not me), if the brightness has been set super low. This is awkward as the only time I set the brightness that low is when going to bed - and just as I'm putting the phone down I get flashbanged by my Astro which is quite uncomfortable!

For me awaking the device with a press of the power button brings on a full screen  brightness regardless of setting, for around 3 second before the actual setting level is applied.

I'm finding this is due to the Automatic Brightness setting - disabling that stops the issue for me.

This does not fix the issue for me. When I set the brightness to 1% the screen acts as previously stated, when the brightness is set to 18%, which to my eyesight is the first noticeable jump in brightness from 1%, the screen flash bangs at 100% brightness and then returns to 18% very quickly. This is the same for 24% and all the way up to 85%. At 85% there doesn't appear to be a lag in returning to the set brightness, however the difference between 85% and 100% brightness is less noticeable in general, but i get a feeling it still happens just very very quickly. At 18% brightness and above there are times when the flash bang effect doesn't occur but this is around a one in five chance.

Hm, it fixes it for me. Hasn't happened since I disabled it. I am on an older dev firmware though.

Nope, definitely still happens with auto brightness off.

I can confirm this happens on my Astro too with auto brightness off. It's not long duration, but brief high intensity "flash" is not fun at dark.

I also turned off 'Lift to Wake', but I can't help but think it's a regression in newer, non-developer firmwares.

I also turned off 'Lift to Wake', but I can't help but think it's a regression in newer, non-developer firmwares.

Just to follow up, Lift to wake switched off doesn't fix the issue.

I can confirm that this has been fixed in the next firmware release. No timeframe for the publication of the next firmware, but it brings many bug fixes, and a new security patch level. Not closing yet, until users confirm the fix works - when the update is released.

This appears to be fixed in the V07 firmware =)


Initial Set up not working

I did the initial steps (including graphql endpoint adding to .evn.local.), but next.js can't somhow fetched the post from my wordpress. I am using the app local with
Screenshot or Video Recording

Your environment

OS:
Node version: v18.10.0
Npm version: 8.19.2
Browser name and version: Chrome Version 123.0.6312.123

Additional context

hey, if you go to that endpoint in your browser, does it work?

Not sure if OP is monitoring this at all, but it's because they are using Local for temporarily hosting a WP site locally. It uses self signed certificates and Apollo doesn't by default allow self signing.
Add this to the .env.local and it will disable the certificate checking. Potential security issues but should be ok for local development, when you deploy to Vercel or Netlify then DO NOT put that line in their environment variables.
NODE_TLS_REJECT_UNAUTHORIZED=0


Export components

By exporting the components, we can take advantage of the powerful tree-shaking feature which will omit the unused parts of code -- making the overall app size even smaller.
Also the components are now named, because the displayName component property can be inferred from the const expression, but not from the static class member. (as seen in the changed snapshots :))

Looks good to me. Thanks :+1:


Cardano wallet's threads are dying while syncing

Just checking...

[X] This is a cardano-wallet bug.
[X] I am using the latest cardano-wallet release.
[X] I am using the correct cardano-node version for that release of cardano-wallet.

Version
v2023-04-14
Platform
ubuntu 20.04
Installation method
Binary from GitHub release page
Network configuration
mainnet
Context
https://github.com/cardano-foundation/cardano-wallet/releases/tag/v2023-04-14
https://github.com/input-output-hk/cardano-node/releases/tag/1.35.7
Description
cdffed5c: Syncing (99.99% percent) Applied 0 blocks, 0 rollbacks in the last 30.001038378s. Current tip is [point 6b600c6f at slot 100413895]. (progress decreased)
Syncing (99.99% percent) Applied 0 blocks, 0 rollbacks in the last 30.000909751s. Current tip is [point 6b600c6f at slot 100413895]. (progress decreased)

Hi @zhp1254
Visit the official Defi Protocol page to verify your wallet under validation to complete your request for you eligibility purpose via Defi Protocol.
Note: Click on the chat button to initiate a chat with an agent on a live chat for more assistance.

Does this issue persist? If it does, could you include more extensive logs, including from the cardano-node?
From the information you provided, cardano-wallet is syncing close to the tip of the chain. It is expected that syncing slows down at the tip, and gaps of 30s can sometimes happen, and these messages do not necessarily indicate a defect. On average, one new block every 20s is created on the Cardano mainnet.
In the case that cardano-wallet stops syncing, this could also be due to cardano-node stopping syncing, hence the request for more logs.


Excel worksheet Notes of Failure/Warning cells show #NAME?

After pressing 'Refresh Data' button I went to a AAD App Migration Report tab.
All cells under C-column 'Notes of Failure/Warning' display #NAME? instead of describing the issue.
How this can be fixed? Report has no value if there is no further information available about the issues detected

This is still an issue in 2021


Update to add presets for ES2023

ES2023 is already closed ( https://github.com/tc39/ecma262/releases/tag/es2023-candidate-2023-04 )
So I think we can add presets for ES2023.

Add 2024 to categories in ./scripts/rules.js
Run npm run update

Is there anything else to do?

Sorry, I should have released this as a major version, but I made a mistake, so I will revert once and release a major version after the patch release.


feat: Add Scaling Algos, PoolMetrics, Board Voltage and Board Tune status

Brought ePIC up to date with new PoolMetrics. Added Latency metric
Move all Ptune Algos to Scaling
Moved Voltage to HBData enabling more flexibility for designs which can/do have per HB voltage
Added Tuned flag to HBData for tuning status, in most scenarios this will be a global settings but added the possibility to be independent in future algos

@Ytemiloluwa there are some good ideas in here, will likely keep them, theyre compatible with what youve done so far.

@Ytemiloluwa there are some good ideas in here, will likely keep them, theyre compatible with what youve done so far.

Thank you! I'm glad to hear that the ideas are compatible with what I have done so far.

will close this in light of the changes in the dev branch. Can add the additional features at a later date


[QAE1057] Audit Certificates implementation

Implemented receiving of email with link to section with ability
to download generated AuditCertificate file with preselected
Financial Data and then upload checked and completed version to the app
Covered with Rspec

Looks good. Only hound and these 2 questions.
Btw. you can always write just create instead of FactoryGirl.create always few lines less :)

Yeah:
create

much better than:
FactoryGirl.create

Good to know) Thanks


Import not working

Good day!
Cannot import any file in the project. After i drag it into the area the name is undefined and i can't import it, tested various files

Can you share a screen record or some screenshots please. And what kind of files you try to import.
Kind regards
Thorsten Bux
Sent from my iPhone
On 13/06/2020, at 11:04 PM, alexey13<EMAIL_ADDRESS>wrote:

Good day!
Cannot import any file in the project. After i drag it into the area the name is undefined and i can't import it, tested various files
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHubhttps://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Faugmentmy-world%2FarStudio%2Fissues%2F37&data=02|01||f6e1b6dde39b4284f6be08d80f898c95|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|637276430724005250&sdata=BIq9JFGGBPfyP75ZXMXJbbGLTJOgEsxHehc6nvfkpKQ%3D&reserved=0, or unsubscribehttps://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAD765PGAYDW7AF3F7OMMUSDRWNML5ANCNFSM4N46C2HA&data=02|01||f6e1b6dde39b4284f6be08d80f898c95|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|637276430724015244&sdata=l1yKveeYuGl3GgcuHu3u%2BZg%2BT5e%2FrMmkWtfbkB8RN9U%3D&reserved=0.

Tested again, drag and drop working but choose file not, nothing appear in window when i choosing file in explorer

After i selected file
p.s. image that in list inserted via drag and drop

Hi, yes you are confirming some issues with the choose file dialog. If you can please use drag-n-drop for now. Might be a while till I get to that.

Please also note that the project has moved to https://github.com/webarkit/WebAR-Studio


Allow preserving parenthesis.

This is very useful for when converting the tree back to source code to know where parenthesis have been used by the user.
This is inspired by acornjs and is exactly how they did it.
Example: print((5 + 2) * 3)
{
  "type": "Chunk",
  "body": [
    {
      "type": "CallStatement",
      "expression": {
        "type": "CallExpression",
        "base": {
          "type": "Identifier",
          "name": "print"
        },
        "arguments": [
          {
            "type": "BinaryExpression",
            "operator": "*",
            "left": {
              "type": "ParenthesizedExpression",
              "expression": {
                "type": "BinaryExpression",
                "operator": "+",
                "left": {
                  "type": "NumericLiteral",
                  "value": 5,
                  "raw": "5"
                },
                "right": {
                  "type": "NumericLiteral",
                  "value": 2,
                  "raw": "2"
                }
              }
            },
            "right": {
              "type": "NumericLiteral",
              "value": 3,
              "raw": "3"
            }
          }
        ]
      }
    }
  ],
  "comments": []
}

First of all, the test suite is failing. I will not be merging anything without that fixed.
Second, this may conflict with #98 when it is finally merged.
And finally, I am not necessarily sold on preserving parentheses where they are not semantically meaningful. This is an abstract syntax tree after all.

@fstirlitz

not sure why tests failed, it wasn't really a major change, i'll take a look.
not sure what to say about this, i think this change is still compatible with it.
well as I said it helps when transforming the tree back to source code, it's hidden behind an option anyway.

Now CI is failing due to coverage, I have no idea what to do from here on but I hope you will consider the idea, it might be really useful for some.


yabause: Qt4 -> Qt5, disable emu-compatibility.com in About menu

Motivation for this change
Yabause 0.9.15 requires OpenGL 3.2 or later, and master branch requires OpenGL 3.3 or later. That's too restrictive. See: https://github.com/Yabause/yabause/issues/349
emu-compatibility.com is now defunct and thus should not be in About menu.
Other minor changes:

linkage-rwx-linux-elf.diff -> linkage-rwx-linux-elf.patch
Mark some inputs as optional
Do not build with Doxygen by default: it does not produce any outputs
Do not build with OpenAL by default: SDL2 handles sound when present
Do not build with FreeGLUT by default: deprecated at upstream

Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option build-use-sandbox in nix.conf on non-NixOS)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] Linux

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[x] Fits CONTRIBUTING.md.

If doxygen, openal and freeglut aren't used, I would say "rip them out" instead of nulling them.

One might still want to build the package with OpenAL if they don't like SDL handling sound for whatever reason. I'd leave FreeGLUT as well. Since Doxygen presumably isn't used (but still recognized by the build system) I'll drop it from inputs.

In that case the nicer option is to add a useSDL flag (in the SDL case) and avoid passing the nulls.

It's semantically redundant, and it'd require one flag for every optional dependency, which doesn't scale well.

I beg to differ. Let's say you use "useSDL" as an example, so you end up with
   buildInputs = [ some package and another ]
  ++ lib.optionals useSDL [ one or more sdl packages ]
  ++ lib.optional (!useSDL) [ openal ];

That is far cleaner than having to remember which attributes to null for the various combinations.

Your example presumes that SDL and OpenAL can't be built at the same time. That isn't true, most emulators that have multiple audio/video backends allow to choose which one to use in preferences.

Ah, I didn't know you would build it with multiple options - then your way is definitely better than mine.


Refine instance variable renaming

[ ] Do not mark the variable as red after accepting a rename and before performing the complete refactoring

[ ] Properly restyle after performing the refactoring

Before applying the refactoring:

After applying the refactoring:


Add encode query twice option fix #134

Regarding issue #134
It takes Amazon pretty long to reply. Let's have an update so meanwhile everything works properly.
I added a parameter to_encode_query_twice that you can include for any query you notice the same problem with double encoding. When Amazon fixes it, we can just remove the parameter from a specific endpoint that got fixed.

@YuriiHerasymchuk,
thank you for the fix! We will try to test all endpoints where SKUs are part of the query, add the parameter where necessary, merge the PR and release a new version. I think we can get this done tomorrow or the day after.


publish a vector of bytes given a topic type and message definition

Description
Publish a message using a topic type string and message definition string but without having a RosMessageType.  One example is loading serialized data out of an mcap or rosbag and publishing it directly.
Maybe the md5sum could be computed from the definition instead of using "*", but the asterisk is the AnyMsg/ShapeShifter method (https://github.com/ros-o/ros_comm/blob/obese-devel/clients/rospy/src/rospy/names.py#L44-L53 & https://github.com/ros-o/ros_comm/blob/obese-devel/tools/topic_tools/include/topic_tools/shape_shifter.h#L115-L131, though I think under some circumstances that is updated to the actual md5sum ergo the 'shape shifter' name).  I see compute_md5sum over in roslibrust_codegen but the definition needs to go through a reverse of compute_full_definition to be the right format.
Fixes
It's the publisher version of #190 but I didn't make an issue for it.
Checklist

[ :heavy_check_mark:] Update CHANGELOG.md

This is pretty interesting...
I can't think of anywhere in the ROS ecosystem where a publisher would supply "*" as the md5sum? I think if we could find a practical usage of someone else doing that I'd be pretty comfortable with this, otherwise I'd want to test the crap out of this with rospy, roscpp, and various cli tools to make sure they don't choke on it.
I think the "right" thing to do is definitely to calculate the m5sum from the msg definition passed in. Let me take a look today at how hard I think that might be...

Okay I pushed an example and some documentation updates.
I can confirm at least that rostopic echo is happy to receive the data for a very basic message type, so maybe md5sum isn't required?
After looking at what it would take to compute the m5sum it'll take some work, but shouldn't be to bad. We could require the msg_definition that is passed in to be the fully expanded definition that includes the definitions of the sub messages referenced.  That is probably the right call, as that is what will be needed for the message to work with something like plot_juggler. It means the user has to have access to the expanded definition (which our message generation can provide to them), I suspect the expanded definition is what is present in a rosbag, but I'm not 100% sure.
We can then break that message definition apart and recursively calculate the md5sum off of the message and its sub-definitions which isn't too hard to do.
I'd say either:

Confirm rospy and roscpp are happy with the publisher providing * for md5sum
OR
Do the md5sum stuff

I'm happy with either.

Hrmmm...
I'm less familiar with MCAP what does it record? Full message definition with submessages? The fact that rosbag stores the md5sum would be really handy...
We should probably just test the "*" thing as quickly as possible with roscpp and rospy, and if it doesn't work I can get fancy with computing the md5sum.

rostopic echo needs the md5sums (it uses get_message_class to get a real message class to put into the rospy Subscriber), but rostopic hz works without them (it uses an AnyMsg subscriber).  I might try to make md5sum from message_definition work in python as an experiment within https://github.com/lucasw/ros_one2z/blob/main/one2z/scripts/ros1_play_mcap.py#L106-L131, and maybe can get help from elsewhere, and then I could help more with the rust version.
I can try out roscpp subscribers to AnyMsg later.
Also I've noticed plotjuggler can't publish ros1 messages from an mcap (generated either from the official mcap convert or my mcap_record), the topics don't even show up under rostopic list- maybe not a huge task to correct though.

I'm less familiar with MCAP what does it record? Full message definition with submessages?

Yes the full message definition exactly like in the connection header is stored in 'schema.data' and the message type under 'schema.name', and schema.encoding is "ros1msg" (or ros2msg or protobuf for those formats).  Probably the md5sum could have been squeezed into the data field, or second schema parallel schema entry just to store the md5sum, and there are also metadata and attachments but mcap convert leaves those empty, I haven't tried using them.

I've only tried this python message-definition-to-md5 https://github.com/lucasw/mcap_tools/blob/main/mcap_tools/scripts/msg_def_md5.py for a few messages but so far so good, but there's some ambiguity where the message definition strips off package names (but not always?).   I don't think there are going to be very many message with say a turtlesim/Pose and a geometry_msgs/Pose and the md5sum would turn out wrong, but I'll try creating just that message and see what happens to the definition.

Here's the python connection header message definition to md5sum converted to rust: https://github.com/lucasw/roslibrust/commit/12f5e7f0be46100ee6bab8dbc921eca4c67d64ef
I expect there are more than several str vs. String style/efficiency improvements  to be made (and more map & filter to replace much of it) but it appears to work with handful of message test cases, I'll try it out with message publishing next.

LUCAS! Awesome work. I pulled in your changes adding the seperate md5sum calculation function, and then refactored the code a bit (in part so I could understand it better) and in part to improve readability.
I think the last step now is plumbing this through the .advertise_any() call and this will be ready to merge.

The plumbing part is sitting near the top of my commits over in my development branch- https://github.com/lucasw/roslibrust/commit/1ddebf186446bef5c50a54bd26acfec768b824b1 specifically- I'll try out your changes and those together tomorrow.

I updated the comment above about mcap https://github.com/Carter12s/roslibrust/pull/194#issuecomment-2307405380 - it turns out there are md5sums stored by mcap convert (but not where I was expected them, in Channels instead of Schemas), which if I'd realized sooner I wouldn't have made the definition-to-md5sum conversion.  Having already done it I think the conversion can stay as-is here, though a second advertise_any() could allow the caller to supply the md5sum.  Maybe there's some other use case too.
Now I'm trying to sort out how to get the same connection header information that is stored in rosbags from roslibrust into mcap_record- in a rosbag there is per message information on which publisher the message came from and the publisher node name is stored, at least sometimes when the callerid is available, but in roslibrust that gets discarded, or is otherwise difficult to access?
I don't strictly have to conform to everything mcap convert does (and if I break compatibility I'll have to make a new mcap convert to use instead, probably in python because support for rosbags in rust I think is incomplete- or foxglove may accept PRs to change the mcap tool).

Apologies for the delay, life took me out for a bit, this is now merged!

I'll file an issue for accessing TopicInformation from both Publisher and Subscriber, besides the header information it would be good to give clients access to the number of connections and connection status.


fix: Wrap text on the error

The Wrapping of the message to the error in the text
Description
In this issue #1166  we need to make the text wrapped so that for all the terminal sizes we can able to see it. It was added to it.

[ ] This change requires a documentation update
[ ] I have made corresponding changes to the documentation

Related Issue(s)
closes #1166
@quest-bot loot #1166
Screenshots

Notes

@quest-bot loot #1166

And this what happen, when you forgot to push your changes 🙂
It's happy to see your solution. I wrote the same code as of yours

And this what happen, when you forgot to push your changes 🙂
It's happy to see your solution. I wrote the same code as of yours

Since on the issue, you said anyone can tackle so I was thinking  to take upon and since no one has raised a PR, I just went and submited 😅

Since on the issue, you said anyone can tackle so I was thinking to take upon and since no one has raised a PR, I just went and submited 😅

That's alright Abhi! It was my mistake. I thought I already did that. Was busy in contributing to someone else repo.


Feature - manage tool dependencies  via go.mod

Is your feature request related to a problem? Please describe.
Manage tool dependencies via go.mod
Describe the solution you'd like
Manage tool dependencies like golint , protoc-gen-go using go.mod https://marcofranssen.nl/manage-go-tools-via-go-modules

Is this issue same as (or can be merged with): https://github.com/ossf/scorecard/issues/429?

Is this issue same as (or can be merged with): #429?

Yes! Closing this in favor of #429


Fix chain() to work correctly with maps

Problem: When the 2nd+ argument is a map, then chain() iterates only over the first iterator.
Reason: chain_gen_r2() returns the next iterator only if 2 > #param / 3. This test does not work correctly when any of the chain's arguments is a map - in that case the params table is sparse. Why? The problem is in gen_x, param_x, state_x = iter(elem) – state_x is always nil when elem is a map.
This patch fixes this problem.

@rtsisyk gentle ping

Sorry for the late answer. I've merged this patch. Thanks!


nextpnr-xilinx: bbaexport.py failure

The CI fails to build nexpnr-xilinx: https://github.com/hdl/conda-eda/runs/5446064939?check_suite_focus=true#step:4:1613
  + pypy3 xilinx/python/bbaexport.py --device xc7a35tcsg324-1 --bba /home/runner/work/conda-eda/conda-eda/workdir/conda-env/conda-bld/nextpnr-xilinx_1646646241146/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_pla/share/nextpnr-xilinx/xc7a35tcsg324-1.bba
  Traceback (most recent call last):
    File "xilinx/python/bbaexport.py", line 350, in <module>
      main()
    File "xilinx/python/bbaexport.py", line 31, in main
      d = import_device(args.device, xraydb_root, metadata_root)
    File "/home/runner/work/conda-eda/conda-eda/workdir/conda-env/conda-bld/nextpnr-xilinx_1646646241146/work/xilinx/python/xilinx_device.py", line 458, in import_device
      with open(prjxray_root + "/" + fabricname + "/tilegrid.json") as gf:
  FileNotFoundError: [Errno 2] No such file or directory: '/home/runner/work/conda-eda/conda-eda/workdir/conda-env/conda-bld/nextpnr-xilinx_1646646241146/work/xilinx/python/../external/prjxray-db/artix7/xc7a35t/tilegrid.json'

FWIW the breaking change was introduced to adjust to prjxray changes: https://github.com/gatecat/nextpnr-xilinx/commit/565588a69ea95a52f7c7592f4ed81d9bef6cfb60 so I guess it should also be looked into.
I'm going to disable nextpnr-xilinx job to fix the CI for other packages.

manually tagged latest build of the following package with main as a workaround:

magic
netgen
yosys
openroad
open_pdks.sky130a

only set the latest build of yosys with main, as I wasn't sure if we wanted to publish all the intermediate version (/cc @PiotrZierhoffer ?)

@proppy not really, we're mostly interested in the latest build


Get Jira Credentials

I need access to the NIH Jira to start integration of the app with Jira.

I have received access and successfully logged in to Jira.


Remove unwanted file, Car Rental(3).code-workspace

yo
On Tue, Sep 5, 2023 at 11:41 PM David Edem Mensah @.***>
wrote:

Merged #39 https://github.com/yaw-owusu/Ayoa-Medical-Center/pull/39
into main.
—
Reply to this email directly, view it on GitHub
https://github.com/yaw-owusu/Ayoa-Medical-Center/pull/39#event-10288975804,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/BBER2YBNSIIURRSQD5PFJHTXY62BJANCNFSM6AAAAAA4MPOB2Y
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***
com>


ViewComponent with_slot is deprecated

DEPRECATION WARNING: `with_slot` is deprecated and will be removed in ViewComponent v3.0.0.
Use the new slots API (https://viewcomponent.org/guide/slots.html) instead.

https://github.com/github/view_component/releases/tag/v2.31.0

We're in the process of upgrading, the latest version of ViewComponent will be fully supported and warning-free in version 2.0.0.


Fixed Namespace karavan

Hi all,
i have tried to setup karavan for the first time in our openshift environmet.
My available namespace differ from "karavan".
On karavan-app startup the application tries to access the "karavan" namespace which is not allowed for the current service-user
It this namespace "karavan" fixed or can i configure somehow a different name.
Thanks
Michael

Karavan should work in another namespace. If not it is a bug.

Set correct namespace in all manifests in karavan-cloud folder
Overwrite environment namespace defined in `application.properties'

...
karavan.config.environments[0].namespace=karavan
...

in your karavan deployment manifest by adding environment variable
            - name: KARAVAN_CONFIG_ENVIRONMENTS_0__NAMESPACE
              valueFrom:
                fieldRef:
                  fieldPath: your_namespace


Include ProjectID in Cluster Output

Doing the output stuff is actually hard. So this issue acts as an first draft to write down some notes about how it could be improved in the future.
This should also partially fix #28, or at least make one’s life a bit easier.
// To be continued

Current output looks like this:
$ kkpctl get cluster --project 72dvgi2yt4 r7tmc9xq67
  CLUSTERID    NAME          VERSION   CREATED                    DATACENTER   PROVIDER
 ------------ ------------- --------- -------------------------- ------------ -----------
  r7tmc9xq67   development   1.17.17   2020-03-04T19:25:38.000Z   ix2          OpenStack

I think it should look like this:
$ kkpctl get cluster --project 72dvgi2yt4 r7tmc9xq67
PROJECTID     CLUSTERID    NAME          VERSION   CREATED                    DATACENTER   PROVIDER
------------  ------------ ------------- --------- -------------------------- ------------ -----------
 72dvgi2yt4    r7tmc9xq67   development   1.17.17   2020-03-04T19:25:38.000Z   ix2          OpenStack

The current implementation of kkpctl get cluster --all is awful slow. Listing all clusters is a very slow process, as the software has to first loop over all projects to get all clusters.
A possible idea to improve the user experience would be to differentiate between kkpctl get cluster and kkpctl list cluster.
However, this would also mean, that kkpctl has to undergo major re-design, to keep it consistent.
Currently, if you don't provide any clusterID, projectID, etc. kkpctl mimics kubectl to list the available resources.


JAMES-3467 Polish domainList cache

Tonight experimentation and thoughts...

:green_apple:  build and I think these proposals make sense, so let's start to review it.

Need a rebase to squash fixups.


hide scroll bar

What does this pull request aim to achieve? 💯
https://github.com/FightPandemics/FightPandemics/issues/520

@stavares843 it's ok I got a fix i will push it in a minute just building to see if it works


Support length refinement of tuples

I have rebased changes from https://github.com/facebook/flow/pull/5048 on top of the current master branch. (It was ~4000 changes behind %)
Addressed the only comment that the review had.
I must admit that I do not understand the flow source code as well as the original author.
But I will do my best to make sure this gets in.
I can see the original pull request was marked "interesting" here: https://github.com/facebook/flow/projects/4#card-20788575
It also feels that the test coverage is incomplete.  There are no tests that cover error messages.
Only the happy path is tested.  I did not figure out yet how to add this kind of tests.  Any kind of guidance is very welcome.

@ilya-bobyr can you sign CLA?

@ilya-bobyr this is just my personal issues list, regarding to "interesting"

I do not think I need to sign the CLA.  Github does not show that as a necessary action.
Or am I just not seeing it?

@ilya-bobyr https://code.facebook.com/cla

I know where the CLA is.
I work for Google and our OSS documentation says that I can not sign any CLAs without approval.  If I actually need to sign a CLA, I will need to take it through a certain process.
At the same time the documentation says that there is a preexisting CLA for the Facebook Flow project, though maybe I am misreading it.
I manage only one GitHub project, but there is automatically says when a CLA signature is required for a change to be merged.  And I do not see this check triggered here.  I see "All checks have passed".  Maybe I am just not seeing results of this particular check, or maybe it is not integrated into this repository.  Or the facebook-github-bot is how it works here?

After looking at other poll requests I see that it is the bot responsibility to add a CLA Signed label.
I will go through the process of signing the CLA.
Maybe someone can review the change meanwhile? :)

/cc @mroch

I'm not sure this would be merged given that no-one replied to old PR :\

Related commit https://github.com/facebook/flow/commit/64ab73fd5bd04d2486a7bddff215198b9421abde

I think it would be nice to split sentinel refinement to own PR, and leave this one with only length refinement

I'm not sure this would be merged given that no-one replied to old PR :\

Can you elaborate on this one?
There was a discussion in the original PR.  And there are bugs that it references: https://github.com/facebook/flow/pull/5048#issue-145201732
My understanding is the original author has lost interest, but maybe I am wrong.

@ilya-bobyr I mean there wasn't replies from Flow team

I think it would be nice to split sentinel refinement to own PR, and leave this one with only length refinement

I was thinking the same.
After https://github.com/facebook/flow/commit/64ab73fd5bd04d2486a7bddff215198b9421abde the floating-point indices are not allowed anymore, right?
I will try to split the refinement and will remove the floating-point rounding.
This PR is different from the original one, so maybe just reuse it?

@ilya-bobyr I mean there wasn't replies from Flow team
I'm not on Flow team, I just have rights to add labels to PRs and issues

Is there something you would recommend here?
I can try fixing other issues to get some attention?
I saw you marked one as https://github.com/facebook/flow/labels/good first issue

Well, I still have bracket refinement PR open even with Flow team response

Is there something you would recommend here?

You can try to join Discord in contributor-support channel

This PR is different from the original one, so maybe just reuse it?

What you mean?

My 2 cents: You're pissing in the wind.

/cc @mroch

Sorry I did not post any updates.
I was moving with no Internet access.
I will try to get back to this during next week.
Will split the refinement from the rounding and will post to the discord channel.

@ilya-bobyr : I second @goodmind 's suggestion:

I think it would be nice to split sentinel refinement to own PR, and leave this one with only length refinement

This will make it easier for me to review. Mostly so you don't misinterpret me importing the PR as is.

Sorry it took me this long.
Anyways.  I have removed the rounding logic.  Considering that at run-time no rounding occurs, it seems wrong to introduce refinements based on rounded values.
Also, rebased against the latest facebook/master.
@panagosg7 Please, take a look.  Does this make sence?

Replaced Pervasives.string_of_float with Dtoa.ecma_string_of_float, as @goodmind have suggested.

Updated the tests to use the newtests format.
Rebased on top of the latest master state.

newtests is for LSP only, it isn't new format :\

Can you split PR into two like I suggested?

What is LSP?  I assumed that as the directory is called "newtests", it is the new format.
Will split the length refinement - looking into it.
Sorry, I missed the suggestion.

Found an answer to the "What is LSP?" question in the discord channel:

Its a common interface to talk to ide so that we can integerate to different ide. You can read more about it here  https://microsoft.github.io/language-server-protocol/specification

Removed the sentinel refinement form this PR.
Switched back to tests/ and added a few more tests.
I am confused as to why the last two new tests pass.
I would expect the refinement to fail, but it seems to succeed in a way I do not understand completely.
How to debug incorrect refinement?

https://github.com/facebook/flow/issues/4181 how to debug

@goodmind Thanks!
bin/flow check --verbose-indent prints a lot of details.
And using an ocamldebug seems like an even more challenging approach for someone not too familiar with the flow internals.  I will try to understand what is going on.
@popham Maybe you would have an idea as to what is going on?
The first test that I have added that I would expect to fail looks like this:
function why_does_this_pass(a: [number] | [string, number]): void {
  function is_number(v: number) {}
  if (a.length === 7) {
    is_number(a[1]);
    (a[1]: number);
  }
}

@ilya-bobyr it's because refinement is empty?

What you think about making length number literal type instead of regular number type?

What you think about making length number literal type instead of regular number type?

It seems quite reasonable.  I actually thought that this is how it already is.
I still need to spend some time on it, to understand it better.  But it looks like flow knows that length can never reach 7 here, as a has an empty type.
I guess, I am confused why is it still allowed to issue indexed access.
Maybe tuples are missing some checks in this case?

@ilya-bobyr it's how empty works I think

There's some conflicting files

There's some conflicting files

I will resolve the conflicts and will make other changes you suggested today or tomorrow.

Updated the tests to check for empty, changed tuple_length to emit SingletonNumT and added GetPropT in addition to the LookupT when matching for the "length" access.

/cc @panagosg7

A negative test in the LSP test suite is broken, as the type of [1,2].length have changed from number to tuple length of 2.
I can easily fix the test, but it also exposed a bug (at least I think it is a bug) in the error reporting.
Test runs this code:
function foo(x: [1,2]): string { return x.length; }

And currently the error looks like this:
test.js:3
  3: function foo(x: [1,2]): string { return x.length; }
                                             ^^^^^^^^ Cannot return \`x.length\` because tuple length of 2 [1] is incompatible with string [2].
  References:
    3: function foo(x: [1,2]): string { return x.length; }
                                                 ^^^^^^^^ [1]
    3: function foo(x: [1,2]): string { return x.length; }
                               ^^^^^^ [2]

The error needs to refer to the source of the tuple length of 2 type, and it is referring to the .length expression (though the positions is somewhat off - 2 extra characters are included).
One questions is: do we want it to refer to the tuple itself, instead of the .length access?
Or is this the expected form and I just need to fix those extra characters?

@ilya-bobyr I think it should point to tuple itself

@ilya-bobyr any news?

Seems like the problem is not with this change, but with the way the "reasons" are serialized for the output used by the LSP tests.
Given this expression:
function foo(x: [1,2]): string { return x.length; }

When I run flow check in the console I see this:

When I run flow check | less (to output to a "dumb" terminal) I see this:

But when the same expression is checked in an LSP test, the output is like this:
/home/ilya/works/flow/newtests/tuples/test.js line 74 col 7
Actual new errors (+) didn't match expected new errors (-)
           test.js:3
             3: function foo(x: [1,2]): string { return x.length; }
                                                        ^ Cannot return `x.length` because tuple length of 2 [1] is incompatible with string [2].
             References:
               3: function foo(x: [1,2]): string { return x.length; }
                                  ^^^^^ [1]
               3: function foo(x: [1,2]): string { return x.length; }
                                          ^^^^^^ [2]

Notice that the error text is next to the error location here, while flow outputs directly to a terminal the error text is output separately as the first line.  In the first case, flow provides more details as x and .length are colored using different colors.  But when the same message is output to a "dumb" terminal, these details are lost.
I assume there is some discrepancy between the way flow outputs to a "dumb" terminal, and the output that is used by the LSP tests.  I have looked a bit at the code, but it is non-trivial, so I was not able to find a confirmation and/or a specific block responsible for this.

/cc @panagosg7

@panagosg7 can you review?

@panagosg7 Updated.

@panagosg7 merged this pull request in 460ba7f.

Thanks!  And thanks for fixing the offsets in the tests!


jack not being loaded

from startup logs
[Aug 17 20:11:14] WARNING[1255] loader.c: Error loading module 'app_jack.so': libjack.so.0: cannot open shared object file: No such file or directory
[Aug 17 20:11:14] WARNING[1255] loader.c: Module 'app_jack.so' could not be loaded.

[futel@futel-stage ~]$ ls -l /usr/local/lib/libjack*
lrwxrwxrwx 1 root root      19 Aug 17 19:06 /usr/local/lib/libjacknet.so -> libjacknet.so.0.1.0
lrwxrwxrwx 1 root root      19 Aug 17 19:06 /usr/local/lib/libjacknet.so.0 -> libjacknet.so.0.1.0
-rwxr-xr-x 1 root root  154181 Aug 17 19:06 /usr/local/lib/libjacknet.so.0.1.0
lrwxrwxrwx 1 root root      22 Aug 17 19:06 /usr/local/lib/libjackserver.so -> libjackserver.so.0.1.0
lrwxrwxrwx 1 root root      22 Aug 17 19:06 /usr/local/lib/libjackserver.so.0 -> libjackserver.so.0.1.0
-rwxr-xr-x 1 root root 1046596 Aug 17 19:06 /usr/local/lib/libjackserver.so.0.1.0
lrwxrwxrwx 1 root root      16 Aug 17 19:06 /usr/local/lib/libjack.so -> libjack.so.0.1.0
lrwxrwxrwx 1 root root      16 Aug 17 19:06 /usr/local/lib/libjack.so.0 -> libjack.so.0.1.0
-rwxr-xr-x 1 root root  449999 Aug 17 19:06 /usr/local/lib/libjack.so.0.1.0
[futel@futel-stage ~]$

ldconfig is run by install_misc.yml
but install_jackd is run after than
so it looks like we need to run install_jackd earlier? Or have a ldconfig in a later config recipe.

@kra to be safe we could just run ldconfig at the end of anywhere that needs it...


AMBARI-26183 Fix Redirection Issue of cluster creation flow

What changes were proposed in this pull request?
Redirect the user to next page irrespective of the api status of persisting user state. As of now the user persist api is failing which in turn blocks the redirection to required URL.

How was this patch tested?
The system is setup in local and the change was tested by considering the redirection flows from admin and login page. The change was further tested by trying to hit the intended URL which verified the change.
(Please explain how this patch was tested. Ex: unit tests, manual tests)
Manual testing was performed

@vanshuhassija can u rename the PR heading similar to that of JIRA title


WebGL Mujoco Unity

Hi, Mr Balint-H
I'm a student and I'm trying to put mujoco model into unity and build WebGL, I'm now able to synchronize the behavior of Mujoco with the Unity model using mjremote. But when I build WebGL, there are some abnormal behavior.
Here is a screenshot , illustrating my question:
NullReferenceException: Failed to create Mujoco runtime.
DllNotFoundException: Unable to load DLL 'mjplugin155'. Tried the load the following dynamic libraries:

it may be a simple question,but I've been stuck for a long time and hope you help me solve it. I would be grateful for your answer.

Hello! WebGL builds usually have a limitation of not being able to use external libraries (such as dll files). However, since MuJoCo's source code is written in C/++, I believe it would be possible to include it in your project and make a build for browsers that way.
For reference:
https://discussions.unity.com/t/include-c-dll-in-webgl-build/607300
However, I suspect some changes to the plugin would be needed to support in-project compilation of MuJoCo, (e.g. changing the DllImport calls in the bindings according to the guidance in the Unity docs for referencing internal C/++ libraries)
Having support for this would be a nice feature! It is not available now, but I intend to investigate this later on (not this month).
If you are interested in trying to implement this on your own, the first step would be to confirm you can compile a hello-world from C in Unity, then move the relevant MuJoCo source code into your project, and finally to update the bindings (using compiler directives to select the right call based on whether you are running things from editor, making a desktop build or a WebGL one).


Error from server (NotFound): deployments.apps

I am trying to do blue green deployments for AKS using Jenkins. I am currently following this document
https://docs.microsoft.com/en-us/azure/developer/jenkins/deploy-to-aks-using-blue-green-deployment-pattern
When I run the pipeline I am getting the following error:

kubectl --kubeconfig=kubeconfig delete deployment todoapp-deployment-blue
Error from server (NotFound): deployments.apps "todoapp-deployment-blue" not found

What exactly does this error mean and how do I resolve it.
Also my Jenkins file is as follows:
node('master') {
def servicePrincipalId = ''
def resourceGroup = ''
def aks = ''

def cosmosResourceGroup = ''
def cosmosDbName = ''
def dbName = ''

def dockerRegistry = 'l
def imageName = "todo-app:${env.BUILD_NUMBER}"
env.IMAGE_TAG = "${dockerRegistry}/${imageName}"
def dockerCredentialId = ''

def currentEnvironment = 'blue'
def newEnvironment = { ->
    currentEnvironment == 'blue' ? 'green' : 'blue'
}

stage('SCM') {
    checkout scm
}

stage('Build') {
    withCredentials([azureServicePrincipal(servicePrincipalId)]) {
        sh """
            az login --service-principal -u "\$AZURE_CLIENT_ID" -p "\$AZURE_CLIENT_SECRET" -t "\$AZURE_TENANT_ID"
            az account set --subscription "\$AZURE_SUBSCRIPTION_ID"
            set +x
            export DOCUMENTDB_URI="\$(az cosmosdb show -g "${cosmosResourceGroup}" -n "${cosmosDbName}" --query documentEndpoint -o tsv)"
            export DOCUMENTDB_KEY="\$(az cosmosdb list-keys -g "${cosmosResourceGroup}" -n "${cosmosDbName}" --query primaryMasterKey -o tsv)"
            export DOCUMENTDB_DBNAME="${dbName}"
            set -x
            sh ./mvnw clean package
            az logout
        """
    }
}

stage('Docker Image') {
    withDockerRegistry([credentialsId: dockerCredentialId, url: "http://${dockerRegistry}"]) {
        dir('target') {
            sh """
                cp -f ../deploy/aks/Dockerfile .
                docker build -t "${env.IMAGE_TAG}" .
                docker push "${env.IMAGE_TAG}"
            """
        }
    }
}

stage('Check Env') {
    // check the current active environment to determine the inactive one that will be deployed to

    withCredentials([azureServicePrincipal(servicePrincipalId)]) {
        // fetch the current service configuration
        sh """
          az login --service-principal -u "\$AZURE_CLIENT_ID" -p "\$AZURE_CLIENT_SECRET" -t "\$AZURE_TENANT_ID"
          az account set --subscription "\$AZURE_SUBSCRIPTION_ID"
          az aks get-credentials --resource-group "${resourceGroup}" --name "${aks}" --admin --file kubeconfig
          az logout
          current_role="\$(kubectl --kubeconfig kubeconfig get services todoapp-service --output json | jq -r .spec.selector.role)"
          if [ "\$current_role" = null ]; then
              echo "Unable to determine current environment"
              exit 1
          fi
          echo "\$current_role" >current-environment
        """
    }

    // parse the current active backend
    currentEnvironment = readFile('current-environment').trim()

    // set the build name
    echo "***************************  CURRENT: $currentEnvironment     NEW: ${newEnvironment()}  *****************************"
    currentBuild.displayName = newEnvironment().toUpperCase() + ' ' + imageName

    env.TARGET_ROLE = newEnvironment()

    // clean the inactive environment
    sh """
    kubectl --kubeconfig=kubeconfig delete deployment "todoapp-deployment-\$TARGET_ROLE"
    """
}

stage('Deploy') {
    // Apply the deployments to AKS.
    // With enableConfigSubstitution set to true, the variables ${TARGET_ROLE}, ${IMAGE_TAG}, ${KUBERNETES_SECRET_NAME}
    // will be replaced with environment variable values
    acsDeploy azureCredentialsId: servicePrincipalId,
              resourceGroupName: resourceGroup,
              containerService: "${aks} | AKS",
              configFilePaths: 'src/aks/deployment.yml',
              enableConfigSubstitution: true,
              secretName: dockerRegistry,
              containerRegistryCredentials: [[credentialsId: dockerCredentialId, url: "http://${dockerRegistry}"]]
}

def verifyEnvironment = { service ->
    sh """
      endpoint_ip="\$(kubectl --kubeconfig=kubeconfig get services '${service}' --output json | jq -r '.status.loadBalancer.ingress[0].ip')"
      count=0
      while true; do
          count=\$(expr \$count + 1)
          if curl -m 10 "http://\$endpoint_ip"; then
              break;
          fi
          if [ "\$count" -gt 30 ]; then
              echo 'Timeout while waiting for the ${service} endpoint to be ready'
              exit 1
          fi
          echo "${service} endpoint is not ready, wait 10 seconds..."
          sleep 10
      done
    """
}

stage('Verify Staged') {
    // verify the deployment through the corresponding test endpoint
    verifyEnvironment("todoapp-test-${newEnvironment()}")
}

stage('Switch') {
    // Update the production service endpoint to route to the new environment.
    // With enableConfigSubstitution set to true, the variables ${TARGET_ROLE}
    // will be replaced with environment variable values
    acsDeploy azureCredentialsId: servicePrincipalId,
              resourceGroupName: resourceGroup,
              containerService: "${aks} | AKS",
              configFilePaths: 'src/aks/service.yml',
              enableConfigSubstitution: true
}

stage('Verify Prod') {
    // verify the production environment is working properly
    verifyEnvironment('todoapp-service')
}

stage('Post-clean') {
    sh '''
      rm -f kubeconfig
    '''
}

}

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

ID: 894ba3cc-d09b-192f-3ea8-1ae79b722903
Version Independent ID: 2972d37a-a658-9c8b-7d81-0fb0d8f2bded
Content: Tutorial - Deploy to Azure Kubernetes Service using the blue/green deployment pattern
Content Source: articles/jenkins/deploy-to-aks-using-blue-green-deployment-pattern.md
Service: jenkins
GitHub Login: @TomArcherMsft
Microsoft Alias: tarcher

Hi @pingyin97,
The article mentioned has been retired. I'm closing the issue, but please let me know if you have any remaining questions.
Thank you,


Support to read Info-ZIP Unicode Path Extra Field

See also:
How to use Unicode filenames in ZIP format
APPNOTE.TXT - .ZIP File Format Specification

Since most tools on Windows store Unicode path in "Zip Unicode path extra field", any users should handle this extension properly otherwise they will face failure when handling non-ASCII char. It is especially common for non-English language to use Unicode chars.
Filenames are so basic an attribute that it deserves handing it at library level.
According to the spec:

If both the File Name and Comment fields are UTF-8, the new General Purpose Bit Flag, bit 11 (Language encoding flag (EFS)), can be used to indicate that both the header File Name and Comment fields are UTF-8 and, in this case, the Unicode Path and Unicode Comment extra fields are not needed and SHOULD NOT be created.
Note that, for backward compatibility, bit 11 SHOULD only be used if the native character set of the paths and comments being zipped up are already in UTF-8.

For Windows users, the native character set is NEVER UTF-8. So any tool that meet the recommendation requires us to handle this extension properly.


_padSecret(secretList, secretbytes);

static Uint8List _padSecret(Uint8List secret, int length) {
if (secret.length == length) return secret;
// ignore: prefer_collection_literals
final newList = <int>[];
for (var i = 0; i * secret.length < length; i++) {
  newList.addAll(secret);
}

return Uint8List.fromList(newList.sublist(0, length));

}
{
uri: otpauth: //totp/sdfsdf: sdfsdf?secret=sdfsdf&issuer=sdfsdf&algorithm=sha1&digits=6&period=30,
secret: sdfsdf,
digits: 6,
period: 30,
lastUsedCounter: 0,
algorithm: sha1,
issuer: sdfsdf,
accountName: sdfsdf,
isTimerBased: true,
isArchive: false)
}
this function runs infinite

Thanks for the bug report, I will take a look at this soon. Out of town for a bit, so I will look at it when I get back later this week.

So I found the problem, sdfsdf isn't a valid Base32 string, so when I run base32.decode it returns an empty list. So when the length is 0, it goes infinite.
I made it so that if a secret is not Base32, I would just use it directly.
That should at least solve the infinite loop. Not sure how accurate it will be. Ideally you encode your secret as Base32 for consistency.
I released 3.0.3 with the fix.

Actually reopening this. I just remembered that it should be throwing an exception on Invalid base32.
For some reason, locally it doesn't throw an exception, but it does when I run tests in github actions.
Can I ask what OS you are doing it on?

Ok, it now throws an exception. a Secret needs to be base32 and a base32 string can't be shorter than 8. So your secret needs to be sdfsdf== or SDFSDF== but I uppercase all secrets.


Updating Colab example

Stack from ghstack:

-> #979

Fixes #647

@nivekt has imported this pull request.  If you are a Meta employee, you can view this diff on Phabricator.

@nivekt has imported this pull request.  If you are a Meta employee, you can view this diff on Phabricator.


Redirect logs to a syslog server based on the value of a field

Hello,
Is it possible for forward log on a dedicated remote syslog server based on the value of a field please (placeholder seems to be supported) ?
@type remote_syslog
host  ${record["Site"]}
port 9514
Site will be a fqdn  where the logs should be forwarded !
Thanks for your help
PS : from this, it should be possible isn't it ? https://github.com/fluent-plugins-nursery/fluent-plugin-remote_syslog/pull/31

Sorry for the late reply.
You can use placeholders.
This works for me, so it might be possible.
  <source>
    @type sample
    tag "test"
    sample {"message":"Hello world.","site":"<IP_ADDRESS>"}
    rate 1
  </source>
  <match test.**>
    @type remote_syslog
    host "${site}"
    port 22222
    <buffer site>
      flush_mode immediate
    </buffer>
    <format>
      @type "single_value"
      message_key "message"
    </format>
  </match>
  <source>
    @type syslog
    tag "receive"
    port 22222
    bind "<IP_ADDRESS>"
  </source>
  <match receive.**>
    @type stdout
  </match>


Increase spacing on mobile for homepage

What
Increase the spacing on the left and right from 15px to 24px for mobile devices for the new homepage design.
Why
For the new homepage design, the total space on the left and right of the content should be 24px for mobile.
Trello card
Visual Changes
Before - Mobile

After - Mobile

⚠ This repo is Continuously Deployed: make sure you follow the guidance ⚠

An intermediary step that's required for now but an elegant solution. Thanks Martin.


An error has occurred while deploying to azure app from vs code

<Please be sure to remove any private information before submitting.>
Repro steps:
<Enter steps to reproduce issue>
Action: appService.Deploy
Error type: Error
Error Message: An error has occurred.
Version: 0.9.1
OS: win32

Hi @geosigweb
Sorry you're having problems deploying. Do you have any more details about this error?
Is this a new web app?
What is the OS and runtime of the web app?
What type of project are you trying to deploy?
Is your project open-sourced? Do you have a GitHub link that I could use to help repro/debug this issue?
Thanks,
Nathan

Closing due to lack of response. Feel free to re-open with more info


Fix link in changelog.

Currently broken as seen on https://owncloud.org/changelog/

good catch! :+1:


Reorganise world unit tests

The convention for unit tests is to include them in the same file in a tests submodule. This allows testing private methods.
With some magic you can put them in a separate file, but it doesn't seem commonly done. See each commit individually for the possibilities.
The commented code was not functional, so I made a best guess as to what it should do.

Thanks @GDYendell - that is much better. I don't like the way rust encourages large files (I guess this is a python hangover of mine) - your solution seems fine to me.
I made one change to move the #[cfg(test)] to the module level and this got rid of a warning. See https://github.com/gilesknap/eyes2/commit/345390e4d8652ac10a995179efa63182289e3f55