🐛 [Firestore-send-email] The default replyTo field is not overridden when using GMAIL smtp

Configuration

Extension name: _ firestore-send-email
Extension version: _<EMAIL_ADDRESS>Configuration:
_ SMTP connection URI: smtps://xxx@gmail.com@smtp.gmail.com:465
_ Both the default FROM and default REPLY-TO are set. Mail sending works. Reply to header gets set in received emails.

Problem
Trying to override default Reply To address but it's not working.
Steps to reproduce:
Create a firestore document for use by the extension as follows:
 export const sendEmail = functions.https.onCall((data, context) => {

  const emailAdress = data.to;
  const subject = data.subject;
  const body = data.body;
  const replyTo = data.replyTo;

  try {
    db.collection("mail")
      .add({
        to: emailAdress,
        message: {
          subject: subject,
          html: body,
          replyTo: replyTo
        },
      });
    functions.logger.info("Completed sendEmail for: " + subject);
    return null;
  } catch (error) {
    functions.logger.error("Error within sendEmail: " + error.message);
  }
});

Expected result
The email address sent along with the document appears in the Reply To header of the received email.
Actual result
There are no errors but the default email address from the extension's configuration appears in the email's reply to header instead of the replyTo email address sent along in the document.

same problem.
my replyTo field contains email address (string), but same result =(

Have you tried moving the replyTo field one level higher?
Like this:
db.collection("mail")
  .add({
    to: emailAdress,
    replyTo: replyTo
    message: {
      subject: subject,
      html: body
    },
  });

The documentation says it should be present within sender and recipient fields, not message fields.


Add property name to file metadata.

This means we no longer have join to file property to get file metadata by property name. This is part of an incremental change to avoid down time.

Naming look consistent.

Naming look consistent.


Build failure on aarch64

Build seems to fail for aarch64.
This seems to be due to 3rd party dependencies (sqlite in marian).
Build log: https://logs.ofborg.org/?key=nixos/nixpkgs.251051&attempt_id=59cfb6f3-9818-4ff3-8172-a2903dda85e5

Hmmm, it used to work but we lost our arm automatic runner.
Will try to get it running again soon, sorry about that.

And we should cut out sqlite.

Quoting Nikolay Bogoychev (2023-09-11 18:01:31)

I removed sqlite from the build, try again?

Still seems to fail on aarch64-linux,
due to other clock-related errors this time (need to scroll up in the log):
https://logs.ofborg.org/?key=nixos/nixpkgs.254580&attempt_id=92ac380b-c503-44cf-8b0b-91d68876299f
It still builds fine on x86_64-linux.

You are missing the fix_ruy step from ARM's build. tl;dr; QT MOC messes up header inclusion order, and ruy itself has a time.h header which clashes with the system time.h. I couldn't figure out how to fix inside cmake, so before building arm there's an intermediate step for fixing the header include order.
https://github.com/XapaJIaMnu/translateLocally/blob/master/.github/workflows/build.yml#L330

Oops I missed that warning.
It now builds fine on aarch64-linux with the fix script.
Thanks!


Update stable version in repo from 3.12.0 to 3.13.1

Think about update stable version to 3.13.1
Version: stable=3.12.0 (114 days old) => latest=3.13.1 (20 days old)
Installs: stable=6152 (50.65%), latest=608 (5.01%), total=12145
Click to use developer portal
Click to edit
Do not close this issue manually as a new issue will be created if condition for update still exists.
Please drop a comment if any reason exists which blocks updating to version 3.13.1 at this time.
Note: This is an automatically generated message and not personally authored by bluefox!
@mcm1957 for evidence

This issue seems to be outdated.
This issue suggests to update the stable version of this adapter to 3.13.1 but the current stable version is already 3.13.1.
So this issue should be closed.
@mcm1957 for evidence


dsh will run cli commands and mysql-import non-interactively if launched from no-tty shel

@achekulaev let's make the tty check a function and add the tty check to the _confirm function.
This way we can avoid extra checks around _confirm in different places.


api: make  api/version and release version consistent (#2191)

Signed-off-by: nolouch<EMAIL_ADDRESS>
What problem does this PR solve?
Fix problem
curl http://pd-ip:2379/api/v1/version

got:  1.0.0

What is changed and how it works?
cherry-pick #2191
Check List
Tests

Unit test

Codecov Report

Merging #2200 into release-3.0 will decrease coverage by 0.25%.
The diff coverage is 100%.

@@               Coverage Diff               @@
##           release-3.0    #2200      +/-   ##
===============================================
- Coverage        69.92%   69.66%   -0.26%
===============================================
  Files              171      171
  Lines            16889    16890       +1
===============================================
- Hits             11810    11767      -43
- Misses            4122     4152      +30
- Partials           957      971      +14

Impacted Files
Coverage Δ

server/api/version.go
100% <100%> (ø)
:arrow_up:

server/api/status.go
100% <100%> (ø)
:arrow_up:

server/schedulers/shuffle_hot_region.go
58.97% <0%> (-6.42%)
:arrow_down:

server/region_syncer/client.go
81.57% <0%> (-3.95%)
:arrow_down:

server/namespace_cluster.go
81.81% <0%> (-3.9%)
:arrow_down:

server/leader.go
78.75% <0%> (-3.75%)
:arrow_down:

server/util.go
72.61% <0%> (-2.55%)
:arrow_down:

server/grpc_service.go
58.38% <0%> (-1.7%)
:arrow_down:

client/client.go
71.81% <0%> (-1.26%)
:arrow_down:

server/cluster.go
81.72% <0%> (-0.51%)
:arrow_down:

... and 5 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update e2e550a...4875131. Read the comment docs.

/merge

/merge

/merge

/run-all-tests tidb=release-3.0 tikv=release-3.0

/rebuild tidb=release-3.0 tikv=release-3.0

/run-all-tests tidb=release-3.0 tikv=release-3.0

/run-all-tests tidb=release-3.0 tikv=release-3.0

/merge


[UI] - min property in metrics calculation is always zero

Tested in latest epinio-dev with Epinio Server Version: v1.9.0-5-gb075df24 deploying example-12factor with source type GitHub and noticed the difference
Before:

After:


added claimAndWithdraw test to claimSellerFunds

simple test - checks users token balance after claimAndWithdraw

Codecov Report

Merging #189 into contracts/test/SCWOF-withNewestTests will increase coverage by 0.85%.
The diff coverage is n/a.

@@                           Coverage Diff                            @@
##           contracts/test/SCWOF-withNewestTests     #189      +/-   ##
========================================================================
+ Coverage                                 97.02%   97.87%   +0.85%
========================================================================
  Files                                         6        6
  Lines                                       470      470
  Branches                                     82       82
========================================================================
+ Hits                                        456      460       +4
+ Misses                                       14       10       -4

Impacted Files
Coverage Δ

contracts/DutchExchange.sol
97.54% <0%> (+0.98%)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update a09de68...3387797. Read the comment docs.


Alternative contrast ratio calculation

The WCAG 2.x contrast ratio calculation is unfortunately not a very accurate metric for text accessibility, especially for non-grayscale backgrounds. It would be great if this tool could bake in some of the calculations proposed for the next version of the standard and let you know if you are hitting the mark in either/both the 2.1 and proposed 3.0 specs.
See discussion here https://github.com/w3c/wcag/issues/695

The SAPC algorithm discussed in this thread are not actively used as part of the standard, and are indicated as of this point in time to be used in research only. I believe this may be an experiential enhancement worth investigating. Use of the SAPC algorithm may produce better generated colors, especially in the area of lighter color over dark backgrounds. This is especially important as in real-world use of Leonardo includes a need for curve modeling for target contrast ratios in order to account for perceptual differences when colors are used on varying lightnesses of backgrounds. SAPC may be able to solve this need, as it's not a desirable solution to create custom curves per-product implementation in order to correct a suboptimal formula for contrast.
I do want to note, however, that until SAPC (or some other formula/variation of SAPC) becomes standardized, Leonardo should not support it as the primary method of calculating contrast. If it is incorporated into Leonardo prior to standardization, it should be combined with a sort of fail-safe in order to ensure WCAG standard contrasts are not lost or are at least referenced in the process. For example, generated colors should still have the post-generation checks done using WCAG standard as it's imperative that the tool aid in conforming to standards.

For reference, this is the SAPC formula mentioned in the thread w3c/wcag#695: https://github.com/Myndex/SAPC

For reference, research project for SAPC or other such formulas for an enhanced standard on contrast can be seen here: https://www.researchgate.net/project/An-Accurate-Programatic-Perceptual-Contrast-Assessment-for-Website-Color-Schemes
See Status Updates.

Also: https://www.myndex.com/WEB/WCAG_CE17polarity

One interesting item to note -- it appears the researcher also proposes a simpler method of determining contrast by subtracting the two color's L* value (CIELAB L value). See "LAB Difference" further down this page https://www.myndex.com/WEB/LuminanceContrast
Some mention in the W3C thread mentions possible use of more perceptually optimized colorspaces such as CIECAM02, which Leonardo currently supports, making this type of contrast generation feasible (https://github.com/w3c/wcag/issues/695#issuecomment-483805436)

HI @NateBaldwinDesign and @alexkrolick
I am the principle researcher on color and the inventor of SAPC, I cam across this thread as it is linked to the 695 thread on WCAG. Just popping in here to answer questions of any.
GENERAL COMMENTS
Predicting how we see contrast is hard because:

Color is not real, it is only a perception.

Hi Andrew! I would love to learn more about the research and possible
solutions for an update to the WCAG standard. I agree this endeavor is not
fully possible to measure effectively. So many factors play into perception
of color and contrast that are beyond digital products’ ability to
accurately measure (ie screen brightness, color calibration, ambient light,
etc). Not to mention size of areas of color and proximity, as you touch on
in the w3c thread. However, any advancement from the current relative
luminosity measurement is better!
I am particularly interested in your short mention of using CIELAB
lightness value as opposed to relative luminosity (in particular your
mention of CIECAM02, as it’s a perceptual improvement upon. CIELAB). Does
SAPC approximate LAB lightness values in RGB? How closely do they relate?
Also, HSLuv appears (to my artistic but not mathematical/research based
eye) to have the most accurate unity of lightness values across hues. Has
this model been considered, or so you have any thoughts/insight there?
By the way thank you so much for reaching out!
On Mon, Dec 23, 2019 at 10:02 AM Andrew Somers<EMAIL_ADDRESS>wrote:

HI @NateBaldwinDesign https://github.com/NateBaldwinDesign and
@alexkrolick https://github.com/alexkrolick
I am the principle researcher on color and the inventor of SAPC, I cam
across this thread as it is linked to the 695 thread on WCAG. Just popping
in here to answer questions of any.
GENERAL COMMENTS
Predicting how we see contrast is hard because:

Color is not real, it is only a perception.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/adobe/leonardo/issues/20?email_source=notifications&email_token=ADKTFZSNWHUXQVUDA5INDCDQ2DVL3A5CNFSM4JYX6PQKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEHRQUFY#issuecomment-568527383,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ADKTFZW7KTTW7RP4ZEPQDBLQ2DVL3ANCNFSM4JYX6PQA
.

--
Thank you,

Nate

[image: Nate Baldwin]
email   |<EMAIL_ADDRESS>web     |  natebaldw.in
phone  |<PHONE_NUMBER>

HI @NateBaldwinDesign and @alexkrolick
I am the principle researcher on color/contrast for some upcoming standards and the inventor of SAPC, I came across this thread as it is linked to the 695 thread on WCAG. Just popping in here to add some comments and answer questions if any.
GENERAL COMMENTS
Predicting how we see contrast is hard because:

Color is not real, it is only a perception.
Contrast is also not real, it is only a perception.
Contrast and color perceptions are context dependant.
The eye responds differently in different conditions of light

The eye's "cone" photoreceptors only work in daylight (photopic)
The eye's "rod" photoreceptors only work in very low light (scotopic)
There is a crossover where they both are active (mesopic)

Contrast and color are processed in the visual cortex in multiple areas and over multiple pathways, being filtered/redirected at each step (gross oversimplification). Luminance contrast is processed in V1, the first stage of the cortex, and the resultant perception is very strongly context dependant, and very strongly dependant on spatial frequency.
See this page for a practical demonstration of the spatial frequency aspect: https://www.myndex.com/WEB/WCAG_CE14weight
As such, a pair of colors in isolation to their context cannot accurately predict contrast perception. In fact, knowing a particular CSS value cannot (in isolation) predict exactly how a color will look. My favorite demonstration of these factors is this image:

Both yellow dots are the same CSS value, as is the grey square they are on.. But the context of each dot is different, and are thus processed and perceived differently by our brain. Some people call this an optical illusion, but there is nothing "optical" about it. It is a neurological illusion, the result of how our brain processes visual stimuli.
CONTRAST
Factors for Predicting Contrast on Computer Monitors
Psychophysical:

Spatial frequency (font weight, stroke width, font size, letter and line spacing)
Color Difference (luminance difference is three times stronger than hue difference)
Light adaptation (where the eye is adapted - both total ambient light, and local to the stimuli)
Individual variation (age, acuity, contrast sensitivity, cognitive, neurological...)

Technical:

Rasterizer (rendering effects such as anti aliasing, font smoothing, etc)
Monitor design and colorspace. (wavelength of color primaries).

SO NOW WHAT ?!
If we make some assumptions at the start, we can narrow down what is the obviously very wide range of perception. Let's assume a monitor in the sRGB colorspace with sRGB primaries, so then assume a black level of 1 to 2 cd/m^2, and a max white at 100 to 200 cd/m^2, and an ambient light that results in a surround of 20% of that max white level (20 to 40 cd/m^2).
That gives us a reasonable "standard observer" from which to estimate certain perceptions like color and contrast. The next set of assumptions is context within the design: Font weight, stroke width, size, spacing, padding, overall page lightness, adjacent elements, etc. etc. And a final set of considerations are the psychophysical aspects of critical contrast and critical size for best readability, not to mention the technical aspects of rasterizers and font smoothing.
SAPC and SLAB
"APC" is "Advanced Perceptual Contrast"
SAPC is a set of algorithms that are intended to provide designers and accessibility testers with a workable means to predict contrast for best readability. The companion SLAB is an L*a*b* type color space specifically tailored for modeling sRGB monitors and modeling visual impairments & related accessibility needs.
SAPC is intended to provide a perceptually uniform prediction of contrast for a pair or group of sRGB colors between #222 and #FFF. In this context, "perceptually uniform" means that 60% contrast will look/feel the same and have the same readability regardless of how dark or bright the brightest color of the pair is.
SAPC is not intended as a "complete" image assessment model like Fairchild's iCAM, or Hunt's very elaborate model of vision. CIECAM02 is also a more complicated appearance model, but could certainly be used. SAPC is specifically about predicting contrast and readability, so it's mission takes us down a slightly different path.

One interesting item to note -- it appears the researcher also proposes a simpler method of determining contrast by subtracting the two color's L* value (CIELAB L value).

∆L* does give a useful result in general, in part because it is easily scaled to the confines of an sRGB monitor. But while CIELAB is still used and very useful, there are better modern methods such as CIECAM02 as you mentioned. While ∆L* is pretty good at indicating lightness difference, as I imply above, contrast is a perception that is not just about the difference. Nevertheless, ∆L* was key to the evolution of SAPC.
Among other things, I wanted the new method to be as simple and easy to implement as possible, and by extension easy to use for designers and accessibility testers. For instance CIELAB has a piecewise linearization near black. For our purposes we can dispense with that as for the narrow context of sRGB contrast, it's actually more useful to clamp or clip the black levels.
Also, while CIELAB uses a single exponent for the luminance power curve, for perceived contrast we find we can attain more accurate results using multiple context-determined exponents for the power curves. Fairchild's R-LAB and some other models do this relating to adaptation for instance. And there is even the question of if log (Weber) or power curve (Stevens) is the best model. Weber models perception at threshold, but for higher luminances a power curve provides a better fit. And the exponent of that curve varies dependent on adaptation and the spatial qualities of the stimuli.
I discuss this more on the CE17polarity page that you linked above.  If you have a data set of color pairs that are perceived as the same relative contrast, the curves that you can fit to that data will have different exponents for the lighter and darker color — BUT ALSO dependant on which was the background, which was the stimulus, and the spatial frequency of that stimulus.
TL;DR
SAPC is a contrast prediction model that is intended to be simpler than a full CAM but still perceptually uniform regarding the narrower scope of perceived contrast & readability on self-illuminated displays.
The most basic implementation simply tests a pair of colors and returns a contrast value and will be part of the first working draft of Silver (the code name for the next generation WCAG) due out February 2020, and expected to become the standard in 2023.
Please feel free to ask questions, I do try to answer when I see a notification.
For a good free resource that covers some of the underlying theories, I suggest Dr. Poynton's thesis, available here: http://poynton.ca/PDFs/Poynton-2018-PhD.pdf
Cheers,
Andrew Somers
Color Perception Researcher
aka User "Myndex" on GitHub, StackExch, etc.

Hi Andrew! I would love to learn more about the research and possible solutions for an update to the WCAG standard. I agree this endeavor is not fully possible to measure effectively. So many factors play into perception of color and contrast that are beyond digital products’ ability to accurately measure (ie screen brightness, color calibration, ambient light, etc).

Hi @NateBaldwinDesign  I see you responded to my abrupt accidental post (I had not finished writing it, and finger-mashed the key combo to post ugh!)
I think I answered most of your questions in the actual intended post, but let me know if you have more.
As to:

Also, HSLuv appears (to my artistic but not mathematical/research based eye) to have the most accurate unity of lightness values across hues. Has this model been considered, or so you have any thoughts/insight there? By the way thank you so much for reaching out!

CIELAB is intended more for reflected colors. CIELUV is intended more for self-illuminated colors.
As such, SLAB may be better named SLUV if that seems appropriate. At the moment, the principal goal has been to predict luminance contrast, which by definition means first converting an sRGB into the spectrally weighted Y, then to L* which is the same for LAB and LUV. (lightness is denoted Ls for SLAB/SAPC to differentiate the different math).
However, SAPC has modules for color, mainly to offset for color vision deficiencies and color related impairments. For example, Protanopia sees red as darker. And blue is a problem for people with some impairments, as chromatic aberration and disability glare can interfere due to the blue component.
The idea with SLAB is a perceptually uniform cartesian space that specifically models sRGB and certain visual impairments — i.e. it's a space for accessibility purposes.
As I mention in the complete post above, SAPC is not intended as an all encompassing CAM, but specific for the task of assisting accessibility with accurate predictions of contrast and related perceptions, none of which can be truly "measured".
Please let me know of any additional questions,
Thank You!
Andy

FYI: Beta script
https://github.com/Myndex/SAPC/blob/master/JS/SAPCsRGB.js

Hey @NateBaldwinDesign  Nate!
As You may know, the first public draft of the new WCAG 3 is soon to publish. Along with the new text, I've also been updating the SAPC tool.
One of the things you asked about was a "full range" down to very low (1%) contrasts. I have a separate link for a version that goes down to under 1%. This is not any sort of official version, it is experimental — but I'd love to hear your feedback. (Especially in terms of tracking consistency).
The link is separate from the main tool that's mentioned in the FWD:
SAPC/APCA Tool, Full Range Version:
https://www.myndex.com/SAPC/FullRange?BG=7a8aaa&txt=828499
It also has a number of other features to make a few things more clear, including a draft lookup table that associates font weight and contrast.
Thank you!
Andy
A Guy Obsessed with Color.

Thank you so much @Myndex ! I took a brief look at the tool and it seems to be exactly what I would hope for. The values below 1% are incredibly valuable to see. I am not sure that I'm seeing any consistency issues, however that would all be based on my own perception, which is highly subjective.
So long as this is available in some form / version of the SAPC formula, I would be ecstatic. The work would be on my part downstream to find how the new formula affects concepts in Leonardo such as "increasing contrast" (eg, linear scaling may not behave as expected, etc), however those would be Leonardo-related issues; not SAPC. I would have to take a much deeper dive into implementing SAPC into Leonardo until making any other conclusions, however I believe that this gives us what we need.
I'm thrilled to start looking into how we can adapt Leonardo in order to support the spirit and objectives of the new SAPC formula. The table that you display is also very helpful, as now the requirements for a color are not entirely based on a desired contrast ratio, but rather they are based on specific font metrics. For designers, this means entering the font size, and weight and then use those as parameters for calculating what contrast ratio Leonardo would need to return. Very exciting!
Thank you again for heeding my pleas and the use-cases and objectives we have for Leonardo and for Adobe's design system, Spectrum.

One thing I have noticed, however, is that contrast percentage is higher for dark color pairs, even when they appear to have just as low of contrast as a lighter color pair

Example URLs:
https://www.myndex.com/SAPC/FullRange?BG=7a8aaa&txt=828499
https://www.myndex.com/SAPC/FullRange?BG=7a8aaa&txt=828499

And the darker end of the spectrum shows as 0% when it appears close to the other examples:

https://www.myndex.com/SAPC/FullRange?BG=7a8aaa&txt=828499

Hi @NateBaldwinDesign
Did you just take those? I ask because this morning I've been working on the code — and then I had to get on a conference call...

As a result some of the offsets were turned off... If you happen to see the "Experiments In Progress" sign, that means that a dev version like this is being tweaked, and may exhibit unusual behavior. To be honest I thought I'd be done before the call, DOH!.
THAT SAID: One of the things I am working on, and a reason I was just clamping at 10% before, is the far extremities have minor inconsistencies (typically less that a few percent). This is in part because again the purpose of this method is readability, so the critical areas to be most accurate are 40% to 80%, and definitely not threshold. Nevertheless, I'm working to smooth out the near threshold levels.
It may not be possible directly, and I may need to create a new method — I was trying to do this with a mod to SAPC which is licensed to W3, so available (MIT License IIR).
I have been also trying to adjust the 1% level close to visibility, as 1% is the normal vision visibility threshold for a contrast chart at the eye doctor. Less than 1% is literally invisible.
But might not be directly possible as the method was designed to be simple and focus on readability critical contrast.

Also, your monitor calibration will affect your results as far as what you see.
On my monitor, the first post comparing 364f81  3d448f and  ffffff  fafafa looks fairly correct. The 364f81  3d448f has clearly more contrast than ffffff  fafafa  The ampersand is clearly visible on 364f81 but nothing is visible for ffffff, at least on THIS monitor. It'll be a bit before i can get to the studio and check on the reference monitors, though this one is hardware calibrated so I expect similar results...
As for the third example, there is a soft black clip that I've been working with/adjusting this morning. It's purpose is to compensate in part for real-world ambient lighting in uncontrolled conditions causing screen flare, and other issues. It affects colors near black, as in less than about 0.6Y or so.

Just FYI I wrote a different lo-contrast module... I think it works more smoothly ... I added to the main tool with a cap at 2%, but I'll leave the fullrange page up for you with no cap, if you want to play around with it.
A

Hey Nate @NateBaldwinDesign
Just wanted to let you know that I've promoted the FullRange version to stable beta, and moved the dev version to another location.
ALSO: in reference to your above examples: I should mention SAPC right now is only doing luminance contrast.
If you compare hue or saturation, even if they have the same luminance, the hue or saturation are perceived as separate contrasts. In the visual cortex, luminance contrast is filtered by v1, but color hue and saturation by v2 and v4.. There is a color module in development, but won't be part of the Silver first draft.
Here are some examples:
Unsaturated
1% luminance, unsaturated it is essentially invisible:
https://www.myndex.com/SAPC/FullRange?BG=dddddd&txt=d6d6d6

Saturated
But if one of the colors is very saturated: it makes it very apparent, even thought the luminance is identical.
https://www.myndex.com/SAPC/FullRange?BG=dddddd&txt=dddd39

Saturated and Equal Luminance
And here's one: absolute zero luminance contrast: luminance is the same 72.83 Y on both, but one is saturated and therefore contrasting:
https://www.myndex.com/SAPC/FullRange?BG=dddddd&txt=22fbb8

Something to mention: Luminance contrast is three times stronger than hue/saturation contrast. And luminance holds more detail, while hue/sat is lower in apparent resolution. This is one reason that it is critical to have luminance contrast first and foremost.
Remember: there is no such thing as contrast in a "real" sense, it's only a perception that happens in your brain.  I have a bunch of this discussed at our Visual Contrast Wiki:
https://www.w3.org/WAI/GL/task-forces/silver/wiki/Visual_Contrast_of_Text_Subgroup

Hey Nate! @NateBaldwinDesign  and also hello Alex! @alexkrolick
I wanted to let you know that the "new improved" SAPC and APCA are now live to play with. There have been some substantial changes and I'm excited to share:
What and Where
The basic simple version is the APCA page, it includes the new scaling and the dynamic font matrix.
The development version is the SAPC page, and this version includes the new RESEARCH MODE, which has some different tools you can activate to investigate the nature of a color or colors, including a simplified version of the middle contrast experiment - on the SAPC app it's called "split contrast mode".
The New SAPC at a Glance

Now substantially more accurate in terms of perceptual uniformity — twice as accurate to perception as the APCA I released last year.
For the majority of the range, doubling or halving the Lc contrast number equates to a doubling or halving of the perceived contrast. (Based on the empirical data from the 2020 "Middle Contrast" experiments.)
If you have been working with the code, it has changed, and there is a whole new set of constants.
This new version sets the levels a little differently, so what was 80 is now about 60, and so on.
Rescaled lookup tables — to adjust to the newly scaled output.
Full range is now standard and via a new method that brings in the uniformity (doubling/halving).
And by full range, I mean all the way to zero, including a smooth crossing over zero.
While 8 bit monitors are too low in rez for actual clinical accuracy, we are now measuring down to clinical threshold values. There may be some more tweaking here... I would be interested to hear your feedback regarding this.
Some of the changes have "improved" the accuracy of saturated colors, particularly red and blue, at least in terms of readability guidelines.

APCA is not specifically addressing the Helmholtz–Kohlrausch effect, as the focus for APCA is on readability, and chroma contrast does not help readability (in some cases it hinders it) — luminance contrast is the key for readability.  I do have a separate color module, but not releasing it at the moment as it is more about aesthetics, not readability, and solving the readability issue was the key goal, which I believe is achieved.
Comments welcome of course. The GitHub repo is https://github.com/Myndex/SAPC-APCA
Thank you!
Andy
Andrew Somers
W3 Invited Expert
Myndex Color Science Researcher
Inventor of SAPC and APCA

Hey Nate! @NateBaldwinDesign  and also hello Alex! @alexkrolick
I wanted to let you know that the "new improved" SAPC and APCA are now live to play with. There have been some substantial changes and I'm excited to share:
What and Where
The basic simple version is the APCA page, it includes the new scaling and the dynamic font matrix.
The development version is the SAPC page, and this version includes the new RESEARCH MODE, which has some different tools you can activate to investigate the nature of a color or colors, including a simplified version of the middle contrast experiment - on the SAPC app it's called "split contrast mode".
The New SAPC at a Glance

Now substantially more accurate in terms of perceptual uniformity — twice as accurate to perception as the APCA I released last year.
For the majority of the range, doubling or halving the Lc contrast number equates to a doubling or halving of the perceived contrast. (Based on the empirical data from the 2020 "Middle Contrast" experiments.)
If you have been working with the code, it has changed, and there is a whole new set of constants.
This new version sets the levels a little differently, so what was 80 is now about 60, and so on.
Rescaled lookup tables — to adjust to the newly scaled output.
Full range is now standard and via a new method that brings in the uniformity (doubling/halving).
And by full range, I mean all the way to zero, including a smooth crossing over zero.
While 8 bit monitors are too low in rez for actual clinical accuracy, we are now measuring down to clinical threshold values. There may be some more tweaking here... I would be interested to hear your feedback regarding this.
Some of the changes have "improved" the accuracy of saturated colors, particularly red and blue, at least in terms of readability guidelines.

APCA is not specifically addressing the Helmholtz–Kohlrausch effect, as the focus for APCA is on readability, and chroma contrast does not help readability (in some cases it hinders it) — luminance contrast is the key for readability.  I do have a separate color module, but not releasing it at the moment as it is more about aesthetics, not readability, and solving the readability issue was the key goal, which I believe is achieved.
Comments welcome of course. The GitHub repo is https://github.com/Myndex/SAPC-APCA
Thank you!
Andy
Andrew Somers
W3 Invited Expert
Myndex Color Science Researcher
Inventor of SAPC and APCA

This looks like it could be a real improvement when generating the best accessible tones. I'd love to be able to ask Leonardo for APCA 15, 30, 45, 60, 75, 90 colors.


Get Contract List

[x] specification (apiary, confluence)
[ ] implementation
[ ]  test

please add route {{host}}/api/contracts? to kong with scope contract:read

[ ] filter by nhs_signer_id doesn't work. return all contracts in response

@danakonovalenko please test and close

[ ]  GET  https://api.dev.asclepius.com.ua/api/contracts \ return 63 entries, however there are 32 contracts in DB


Crash on certain files

Describe the bug
For unknown reasons cjxl crashes when trying to encode to jxl
To Reproduce
Download the next 2 images (a png and a PPM) and try to encode them with:
cjxl "input.ppm" "input.jxl"
Environment

OS: Win7 SP1 x64
CPU type: i7-4790K
djxl version string: JPEG XL decoder v0.7.0 ab775e2 [AVX2,SSE4,SSSE3,Scalar]
cjxl version string: JPEG XL encoder v0.7.0 b432598 [AVX2,SSE4,SSSE3,Scalar]

Fixed using a more recent version


Improve health marker behavior

When a failure happens with the backup, the script will use the existence of a file in /backups to check for health state. But in the cases where the backup is also failing, so will attempting to touch unhealthy. This kinda breaks the health monitoring, and can lead to reports on the failure to touch unhealthy rather than the underlying error that triggered it all in the first place.
Two ideas on how to improve this further:

Invert the process. Try to make a healthy file marker in /backups, and remove it when the service is not healthy. It can also be used as a basic permissions check to ensure the container is properly configured.

Use a tmpfs mount. This way we aren’t reliant on the persistent volume to make this work.

One, the other, or both of these would be a pretty useful improvement.

Since this had to be re-written anyways for the service work, I've done the work there, and it looks ready to roll out.


about SIBR_viewers

Thank you for your great achievements, when can we combine SIBR_viewers?

Hi, thanks for your interest.
We will have a try to integrate the SIBR_viewers once upon our paper is accepted.


Incompatible character encodings: UTF-8 and UTF-32LE

I am not sure if this issue is a function of a problem in the parser gem, or of rubocop itself.
When running running rubocop I see the following error:
$ rubocop
...
lib/tasks/comments.rake:40:1: C: Extra blank line detected.
lib/tasks/comments.rake:41:1: C: Extra blank line detected.
lib/tasks/comments.rake:42:1: C: Extra blank line detected.
lib/tasks/comments.rake:43:1: C: Extra blank line detected.
lib/tasks/comments.rake:43:1: C: Extra empty line detected at block body end.
lib/tasks/comments.rake:45:4: C: Final newline missing.
end

83 files inspected, 880 offenses detected
incompatible character encodings: UTF-8 and UTF-32LE
/usr/local/bundle/gems/parser-<IP_ADDRESS>/lib/parser/lexer/literal.rb:190:in `extend_string'
/usr/local/bundle/gems/parser-<IP_ADDRESS>/lib/parser/lexer.rb:15702:in `advance'
/usr/local/bundle/gems/parser-<IP_ADDRESS>/lib/parser/base.rb:219:in `next_token'
/usr/local/lib/ruby/2.1.0/racc/parser.rb:258:in `_racc_do_parse_c'
/usr/local/lib/ruby/2.1.0/racc/parser.rb:258:in `do_parse'
/usr/local/bundle/gems/parser-<IP_ADDRESS>/lib/parser/base.rb:162:in `parse'
/usr/local/bundle/gems/parser-<IP_ADDRESS>/lib/parser/base.rb:180:in `parse_with_comments'
/usr/local/bundle/gems/parser-<IP_ADDRESS>/lib/parser/base.rb:201:in `tokenize'
/usr/local/bundle/gems/rubocop-0.36.0/lib/rubocop/processed_source.rb:92:in `parse'
/usr/local/bundle/gems/rubocop-0.36.0/lib/rubocop/processed_source.rb:36:in `initialize'
/usr/local/bundle/gems/rubocop-0.36.0/lib/rubocop/processed_source.rb:18:in `new'
/usr/local/bundle/gems/rubocop-0.36.0/lib/rubocop/processed_source.rb:18:in `from_file'
/usr/local/bundle/gems/rubocop-0.36.0/lib/rubocop/runner.rb:270:in `get_processed_source'
/usr/local/bundle/gems/rubocop-0.36.0/lib/rubocop/runner.rb:86:in `process_file'
/usr/local/bundle/gems/rubocop-0.36.0/lib/rubocop/runner.rb:59:in `block in inspect_files'
/usr/local/bundle/gems/rubocop-0.36.0/lib/rubocop/runner.rb:57:in `each'
/usr/local/bundle/gems/rubocop-0.36.0/lib/rubocop/runner.rb:57:in `inspect_files'
/usr/local/bundle/gems/rubocop-0.36.0/lib/rubocop/runner.rb:35:in `run'
/usr/local/bundle/gems/rubocop-0.36.0/lib/rubocop/cli.rb:30:in `run'
/usr/local/bundle/gems/rubocop-0.36.0/bin/rubocop:14:in `block in <top (required)>'
/usr/local/lib/ruby/2.1.0/benchmark.rb:294:in `realtime'
/usr/local/bundle/gems/rubocop-0.36.0/bin/rubocop:13:in `<top (required)>'
/usr/local/bundle/bin/rubocop:16:in `load'
/usr/local/bundle/bin/rubocop:16:in `<main>'

ruby 2.1.2

It's an issue with the parser gem for sure. I will look into it.

Can you send me a copy of the file which causes the error when inspected?

Sure
https://gist.github.com/jottr/3c81d89c1a763d247d06

Could you be so kind and confirm that you received the gist? Thank you. :)
2016-02-01 13:59 GMT+01:00 Jonas T<EMAIL_ADDRESS>
Sure
https://gist.github.com/jottr/3c81d89c1a763d247d06

--

/ _ \ V /\ V /\ V / _
_/_/  _/  _/_/
Please consider using Email encryption: keybase.io/jottr

Got it. Will check what the problem is later when I have time.

It seems that the problem isn't caused by that particular file. You are inspecting the entire "meingrundeinkommen" repo, is that right? Perhaps I can clone it and try inspecting it.

Yes I've simply run the rubocop on the master branch of meingrundeinkommen , even after changing the offending line in comments.rake, rubocop still crashed.

Just discovered a bug in parser which looks very similar to what you show here. Once a fix is merged and a new release made, I'll ask you to try again.

This should be fixed now.

Can you check on master?

Just checked. The issue seems to be fixed. Thank you!


How do I output the original log at the same time when I execute tg.plan?

Excuse me, how do I output the original log at the same time when I execute tg.plan?
tg = tftest.TerragruntTest(fixtures_dir, env=env)
tg.setup()
plan_obj = tg.plan(output=True, tf_vars=tf_vars)
format_data = plan_obj.resource_changes

I want to format the output while also outputting the original execution log file.
Thanks！

hello are you using pytest?  If you are have you had a look at this?
I remember using pytest --capture=tee-sys worked while not interfere with the internals of tftest so pls give it a try.

@davidtam I am sorry to reply to you so late. The method you said is ok, but it may not meet my actual needs. The scenario I use is in the web service.Thank you still for the ideas. thanks


Resubscribe real-time and cumulative usage after connection outage

Currently running the beta with real-time energy usage. I notice that after an internet connection time out, the real-time usage doesn’t resubscribe when connection is restored. The cumulative usage only seems to fail if the outage happens during a reading due to an internet or Duke API outage longer than the 15 minute interval. Seems like any outage requires a restart of HA to restore. I’m unsure if this can be addressed here or should be address in the Duke Python repository.
I think a good solution would be to poll every 1-5 minutes after a connection is out until a successful response is received and at that point resubscribe or reinitialize the integration.
Potentially related, being unable to restart the integration without having to restart HA.

Thanks for bringing this up. When this happened, did you see the integration show a failure in the Integrations page? (it would show with a red outline and an error message).

Honestly can’t recall. I “introduced” a network failure just now and the plug-in did not crash. The cumulative usage was able to resume, but real-time MQTT did not resubscribe.
The errors that I have seen are different than the self-introduced network failure.
The original errors I saw when posting this were as follows:
Error: (update_coordinator.py)
Error fetching homeassistant data: Error
communicating with Duke Energy Usage API: Request
failed with unexpected error [https://cust-api.duke-
energy.com/gep/v2/auth/oauth2/token]: 400,
message='Bad Request', ur|=URL('https: //cust-
api.duke-energy.com/gep/v2/auth/oauth2/token')
Warning: (realtime.py)
Error requesting smartmeter auth, will retry after 5
seconds.
Warning: (realtime.py)
Unexpected message:
<paho.mqtt.client. MQTTMessage object at
0x7fe757d69c80>
Unexpected message:
<paho.mqtt.client. MQTTMessage object at
0x7fe74f6274a0>
What I’ve just experienced from a self-introduced network failure is as follows:
Error: (update_coordinator.py)
Error fetching homeassistant data: Error communicating with Duke Energy Usage API: Request failed with unexpected error [https://app-core1.de-iot.io/rest/cloud/smartmeter/usageByHour]: 504, message='Gateway Time-out', url=URL('https://app-core1.de-iot.io/rest/cloud/smartmeter/usageByHour?startHourDt=2021-11-20T05:00&endHourDt=2021-11-21T05:00')
Error fetching homeassistant data: Error communicating with Duke Energy Usage API: Request failed with unexpected error [https://app-core1.de-iot.io/rest/cloud/smartmeter/usageByHour]: Cannot connect to host app-core1.de-iot.io:443 ssl:default [Network unreachable]
Error: (realtime.py)
MQTT disconnect error, result code: Out of memory. (This may not be accurate)
Both ways though, real-time MQTT doesn’t resubscribe, whether api or internet outage and I have had it where the cumulative was not updating either before restarting HA. I know Duke had an 1-2week outage at the end of October/beginning of November, but this was after that time. Thanks for looking into this; I appreciate your time. If I see an outage again, I’ll make sure to update here with logs.

I had a network outage over the weekend so I did experience this myself. The MQTT stuff does have reconnect logic, but we have to make a separate API request to Duke to initiate that MQTT streams, and I think that API request is the one causing the issues as it does not re-attempt after some period of time.

I believe this should be fixed by the updated pyduke-energy version in v0.1.0b9 (#53). in the event of a connection loss, the error will be caught and we will attempt to reconnect indefinitely with an exponential back-off strategy (starts at 1 minute, maxes out at 60 minutes). the times can be adjusted if wanted later.
a warning log will be logged with the back-off time when this happens.
I tested this by cutting network to the docker container and it worked for that case. however, depending on where and when the internet drops, a different exception may be thrown. I believe I've caught all of them but there is a chance I missed some. any that I missed will be logged as an error log and we will not retry. please open a issue on that instance.


Add mediasdk_c2 unitests

Improper Commit Message
Tracked on not found in commit message,
make sure Tracked-On: Jira-ticket  is present.


suggestion: extract parameters from .ts files into a yml file

Both clean-scheduled-docs.ts and run-scheduled-docs.ts define parameters that a user could tweak to modify where the extension looks for things, but it's a slight hassle to have to change the same thing in two places. Could this be extracted out into a separate, say, config.yml?

Good idea! You're thinking about this line, right?
const ymlPath = '_quarto.yml';

You're exactly right that it's defined in two different places because run- and clean- run at very different times as different processes so clean- doesn't have access to the info in run- writing out a config.yml file seems like a very straightforward approach. Or maybe: just include a config.yml with the extension and both scripts read from it - that's probably easiest since I can just direct users to: go into config.yml and change the only line that's there.

I've put some work on this in:
https://github.com/qmd-lab/scheduled-docs/pull/6
Please test it out when you have a sec.

@paciorek I'm running into an issue running this extension on main. When I follow the README.md and install the extension with quarto use template qmd-lab/scheduled-docs and then run quarto preview, all three of the posts appear on the website.
I can fix the issue by copying metadata-files: [./scheduled-docs_files/draft-list.yml] from _extension.yml into _quarto.yml, which suggests the metadata merge from the extension is not working. I've seen that behavior on 1.5.55 and 1.5.56.
Would you mind testing it on whatever version of Quarto you're running?

This is puzzling.
A course-website repo that I've embedded the extension in seems to be working just fine:
https://github.com/qmd-lab/course-website
While a minimal repo demonstrating what appears to be the issue - the merging of metadata-files - is not working.
https://github.com/andrewpbray/reprex-metadata-merge
This is what I get for leaving this project on the back burner for the spring semester and summer...

Ok, so course-website actually isn't setting docs to draft mode either. The extension code works as intended - draft-list.yml is correctly generated, but it's not getting read into metadata. It only looked like it had because the schedule on the homepage was reading from draft-list.yml.
Seeking help: https://github.com/quarto-dev/quarto-cli/discussions/10568

@paciorek I've merged the config.yml approach, set the default to read from an external _schedule.yml (I think that's a wiser idea), and have an issue on the Quarto CLI to address the lack of merging of metadata-files. In the meantime I'm going to just add that manually to the Stat 20 _quarto.yml so that I'm ready for the fall semester.


The repeat_parsing option can sometimes crash when certain errors occur

Consider the following code snippet:
using System;

procedure void test()
{
    int test = Int64.TryParse("17");
}

The error here is that Int64.TryParse does not return an int (it returns a bool) and Int64.TryParse is not defined like this, it is defined as Int64.TryParse(string, out int) (Among other definitions).
Here we get the error "Error: Exception, INTERNAL ERROR. File: crashtest.sbs. InvalidOperationException; Stack empty.", which make stepbro crash, instead of just giving the error and then letting the user try again.

Can't reproduce


Default value for "qml-ls-client.qmllsPath": "qmlls"

I installed qt with homebrew (Mac), so the qmlls should be available in $PATH.
In terminal I can do:
$ type qmlls
qmlls is /opt/homebrew/bin/qmlls

Added qmlls as a default for qmllsPath config variable. Thanks for the suggestion.


Improve doctests vs. rendered documentation

Hi there,
this is a small proposal I would like to make. Please upvote if you think it should be improved, or downvote if you think it should be left in the current state. Comments are also welcome.
With kind regards,
Andreas.
Introduction
At https://github.com/crate/crate-python/pull/442#discussion_r957012464, we had a conversation about the src/crate/client/doctests/cursor.txt file. On the other hand, there is also docs/query.rst. Both have in common that they demonstrate how to query data from CrateDB.
Problem
Apparently, cursor.txt is being tested ^1, but query.rst is not. Vice versa, query.rst is part of the documentation ^2, but cursor.txt is not.
Proposal
We may think about having both: Add query.rst to the test suite, and add cursor.txt to the rendered documentation. This will both improve code quality (query.rst will be validated) and the documentation (parts of the tests in cursor.txt may be interesting to readers).

Apparently, cursor.txt is being tested, but query.rst is not. Vice versa, query.rst is part of the documentation, but cursor.txt is not.

Coming from this situation, and aiming to implement your suggestions, I think the best way forward would be to:

Convert all the test cases from cursor.txt into regular Python tests.
Add query.rst to the doctests, to make sure the documentation is valid.

Hi. My proposal to steward this into a better shape, is #464, still WIP. Early comments are welcome.

Status
I think #464 is ready now. On this page, the new documentation section is rendered as a preview on RTD:

CrateDB Python client by example

Backlog

[ ] Improve the overall flow of the documenation.
[ ] Rework the documentation about BLOBs. Currently, it is scattered between docs/blobs.rst, docs/by-example/http.rst, and docs/by-example/blob.rst, and apparently outlines different access variants or stages. Let's sort this out.
[ ] Add more reStructuredText documents from docs/*.rst to the test suite as well. Currently, they are not, mostly because they do not contain executable examples.

On behalf of this patch, the situation has been improved significantly already.

https://github.com/crate/crate-python/pull/464

One backlog item to carry over:

GH-627

Closing this.


How to 100% reset everything?

Basically the program takes up my entire screen, can't see anything anymore. But when I remove everything and re-install basically, I keep the same settings.

Yes, something like that. Is there a way to 100% reset this so it gets fixed?

Go to documents->R3nzSkin and delete the file named R3nzSkin64.


Wired Calendar component display errors

The calendar component is showing Feb 28 2021 as a Monday, when it should be a Sunday.

Google calendar as comparison:

Yes, there is an error when the first day of the week in the calendar is NOT Sunday.
This depends by locale region.
Most America is Sunday but most Europe is Monday ...and there are many other possibilities like Saturday and even Friday :confounded:

Since the code is already assuming Sunday as the first-day-of-the-week in a calendar, one solution is to compute the days needed to offset to different first-day-of-the-week.
First, need to include code for the locale region, like "en-GB" or "de-DE".
At present, the code is only using the language part but not the region.
Second, get the first-day-of-the-week by the region stated.
Third, compute the "days distance" from Sunday to be used as first-day-of-the-week offset.
Fourth, offset two places. The weekday names header and the initial day number to fill the calendar. Example: If you start in Monday, you should offset the start day number by one, so the weekdays names match the date number also.

For the First and Second steps there is an option to use a standard built-in property Intl.locale.weekInfo that return an object with a property firstDay among others.
Like:
const enGB = new Intl.Locale("en-GB");
console.log(enGB.weekInfo); // { firstDay: 1, weekend: [6, 7], minimalDays: 4 }

where firstDay is number from 1 to 7 where 1 means Monday, 2 is Tuesday, and so on ...up to Sunday = 7
The problem is that it is not totally supported by all major browsers (Firefox not yet, to date).
So, another option is to hardcode a region map to first-day-of-the-week.
I propose to code the two options but let the Intl.locale option commented in the code until it is fully supported. I understand that the hardcoded map is maintenance debt but al least we will have a solution now (and a pre-coded solution for the future in the comments).
(The Third and Fourth step are straight forward code.)


Color of line numbers and whitespaces are too bright

The color of line numbers and of the invisible characters (like empty space and the vertical lines) is way too bright. In the previous version the color was better.

I guess no plan to allow overwriting colors?

I added the IndentBlanklineChar highlight group in #54

I guess no plan to allow overwriting colors either?

You can use the Lua API for that. In this case, if you want to darken Whitespace, you could link Whitespace to IndentBlanklineChar:
vim.cmd.colorscheme 'melange'

local id = vim.api.nvim_create_augroup('HighlightOverrides', {})
vim.api.nvim_create_autocmd('BufEnter', {
    group = id,
    pattern = '*',
    callback = function()
        vim.api.nvim_set_hl(0, 'Whitespace', { link = 'IndentBlanklineChar' })
    end,
})

That... almost did the trick. Some whitespace are with new color (the brighter ones) and some are with the old color.
When I place the cursor inside the context of the method some whitespaces change the color from new to old one.
Not sure how to make all of them the old color all the time.

That's the intended behavior (I think?). See hl-IndentBlanklineContextChar

I just wanted all the whitespaces to be the old color. Btw feel free to close this ticket if this is not something you are interested in doing, I realise this is just a personal preference of mine.

Yeah, sorry. I misunderstood the question, and also misunderstood how indent-blankline worked. When the docs say:

Default: takes guifg color from 'Whitespace'

The really mean it. These highlight groups are not linked, but manually extended using synID* functions (wtf?) Anyways, I think they do that to set nocombine. 3c430b644a6fe6789db99d0c7d70ba7a5ccd57ba should probably highlight all the indent-related whitespace the same.
Let me know if that works.

Wow, it works now, thank you so much


chore(arcdata): Welcome arcdata v0.0.1 preview

chore(arcdata): Welcome arcdata v0.0.1 preview
Introduce arcdata  v0.0.1 preview. The source is housed in an external repository and not here.

General Guidelines

[X] Have you run azdev style <YOUR_EXT> locally? (pip install azdev required)
[X] Have you run python scripts/ci/test_index.py -q locally?

→ python scripts/ci/test_index.py -q
----------------------------------------------------------------------
Ran 9 tests in 0.015s

OK (skipped=2)

For new extensions:

[X] My extension description/summary conforms to the Extension Summary Guidelines.

arcdata


API Callbacks for Test Automation

Is this adding or improving a feature or fixing a bug?
Adding a set of API Callbacks to use for Cypress tests.
What's the new behavior?
No change in expected behaviors.
How does this change work?
It is only used by test code.
The Cypress UI tests need to test features related to API Callbacks. This code file supports those test cases.
Does this fix any issues or need any specific reviewers?
NO
Fixes: #
Reviewers: @

Since your other PR passed using test branch you can close this as there is no change to develop branch

We created a new test branch that has the necessary test components for this side of the product.


fix committee assignment bugs

2 bugs:

We were modifying current_shuffling_epoch and then calling get_current_epoch_committee_count expecting that it was still getting the committee count from the previous value of current_shuffling_epoch. Switch operations to prevent this error
when getting next epoch committee assignments, we were sometimes modifying committees_per_epoch and shuffling_epoch when these things should have remained constant.

At this point get_crosslink_committees_at_slot is black magic to me. I wish it could somehow be massively simplified, similar to how we massively simplified the validator state machine (which had a bunch of subtle bugs, and was brittle).

These fixes are pretty critical. Let's get it merged and try to simplify after

At this point get_crosslink_committees_at_slot is black magic to me. I wish it could somehow be massively simplified, similar to how we massively simplified the validator state machine (which had a bunch of subtle bugs, and was brittle).

Can confirm, whenever there's a validator run time failure we immediately look at this function then begin to scratch our head 😆

Let's get it merged

Approved!


Staking broken.

I am having problems with the staking program mining machine.  please help me @vellocapital007

The steps I gave yesterday have they been implemented?

I have done it.  I post 2.5% of LP.  then what should i do next?

I have done it. I post 2.5% of LP. then what should i do next?

continue your post in the next day minimum from the server.  do it until your bonus is actually distributed to the wallet normally

Anything else?

Anything else?

no, you only need to post a minimum of every 3 days in a row, 7 days once, 15 days and 30 days once

your problem is exactly the same as my coin problem in 2015. my coin name is CILKROAD

and now my staking program is no longer a problem thanks to these steps.  now that I have my own server, I don't have any problems related to the bonus from the blockchain server.

be patient and prepare your own server machine slowly.  for the above case, try to find a partner who wants to be invited to join to post on your staking project.

thanks bro for the your solution.

your problem is exactly the same as my coin problem in 2015. my coin name is CILKROAD

what day does the bonus come out guys?

your problem is exactly the same as my coin problem in 2015. my coin name is CILKROAD

what day does the bonus come out guys?

after 3 consecutive days of posting then the bonus runs normally


Licensing

It just occurred to me that there is no license for Rat Bot.
Not sure if this intentional or just an oversight.

Free at last, free at last. Ratthew my child is now free at last.


Allow renaming Gist files from the management view

This has been merged into master, and I'll ship it in the next release (~this afternoon).


Look up hostname from controller environment

This is more portable than /bin/hostname (which can be missing in a container image), and most calls in this plugin don't provide any EnvVars.
Requirements for Contributing to this repository

Fill out the template below. Any pull request that does not include enough information to be reviewed in a timely manner may be closed at the maintainers' discretion.
The pull request must only fix one issue at the time.
The pull request must update the test suite to demonstrate the changed functionality.
After you create the pull request, all status checks must be pass before a maintainer reviews your contribution. For more details, please see CONTRIBUTING.

What does this PR do?

Description of the Change

Alternate Designs

Possible Drawbacks

Verification Process

Additional Notes

Release Notes

Review checklist (to be filled by reviewers)

[ ] Feature or bug fix MUST have appropriate tests (unit, integration, etc...)
[ ] PR title must be written as a CHANGELOG entry (see why)
[ ] Files changes must correspond to the primary purpose of the PR as described in the title (small unrelated changes should have their own PR)
[ ] PR must have one changelog/ label attached. If applicable it should have the backward-incompatible label attached.
[ ] PR should not have do-not-merge/ label attached.
[ ] If Applicable, issue must have kind/ and severity/ labels attached at least.

Thanks again @Vlatombe! We aim to release this soon alongside some other hostname detection logic changes.


Update CI

Use GoTool for selecting versions of Go.
Updated matrix to include latest two versions.

/azp run


Make prometheus-adapter config a real object

This allows proper merging adapter configs instead of working with strings.
So modifying the config becomes for addons like https://github.com/coreos/kube-prometheus/pull/374

No clue why Travis CI is not reporting status, but it's green.
lgtm :+1: thanks! :tada:


SIM-Providers are shown even if they are not configured

Context
When starting a fresh install or boot of the simulator, all default providers are shown even if they are not configured in the backend

Impact
Bad UX: This can be very counter intuitive for a user who creates a validator and then finds out through errors that the LLM provider is not configured in the backend
Extra
Highly related to https://github.com/yeagerai/genlayer-simulator/issues/359

@AgustinRamiroDiaz we agree that we should probably wait for #359 before fixing this, right?

@denishacquin yes!


turbo-frame loading=lazy loads eagerly in Safari

It appears that the IntersectionObserver in Safari fires immediately on custom HTML elements. For some apps using lazy turbo frames, this is effectively graceful degradation (which is great!) but there have been a few blog posts written about using lazy turbo frames for infinite scroll (this one, for example, which links to a couple others).
In this use case, due to this issue in Safari, infinite-scrolling feeds will continue loading forever until the user reaches the bottom of the feed, the server rate-limits them, or their browser crashes.

@jgaskins Do you have any solution for this problem? The application that I work on has the same error, even on pages that have the turbo-drive disabled.

@filipemendespi None that I’ve tested, unfortunately. Turbo Frames being implemented in terms of custom elements is a fundamental design decision. As a workaround, you might be able to attach an IntersectionObserver to a standard element with a Stimulus controller and have that observer attach the src attribute to the turbo-frame element. I don’t know if that will work, but the basic idea is this:
On page load:
<turbo-frame id=“my-frame”>

</turbo-frame>

When my-frame-observer hits the viewport:
<turbo-frame id=“my-frame” src=“/my_data”>
</turbo-frame>

I believe this should kick off the request as expected, but I haven’t tested it yet. Note that this is just the HTML part of it and it doesn’t include any Stimulus wiring or even vanilla JS event handlers you’d have to implement. If I can test it out some time this week, I’ll update this thread.

as I said, I have hotwire enabled only in some views of the application, interestingly this error occurs on pages where the turbo-drive is disabled and I do not use anything related to the turbo, just load it because I have the includes in the application layout.
I don't think this solution could help me, considering that the pages that fail do not have turbo-frame.

Then I think your question has landed in the wrong place. This issue is about <turbo-frame loading=lazy>.

In my project turbo-frame loading="lazy" works on Safari as expected.  Does someone have a github repo where it's not working on Safari?

Huh, just checked and it’s working for me now, too. I wonder if this was fixed in the latest Safari release? Because I did reproduce this (worked as expected in Firefox but loaded the whole list in Safari without scrolling) and was even able to replicate it with just an IntersectionObserver watching a custom element that was outside the viewport.
Either way, it looks like it’s fixed in Safari so a workaround shouldn’t be needed. I’ll go ahead and close.


ItemsRepeater renders items outside its control size when it has a large amount of items

Describe the bug
ItemsRepeater renders items outside its control size when it has a large amount of items. In my testing environment, I can reproduce this with 200,000 items.
Steps to reproduce the bug

Create a plain WinUI 3 app.
Add this code below:
Click the button and you'll see that items are rendered outside the control.

MainWindow.xaml
<Window
    x:Class="ItemsRepeaterOutsideRenderingBugSample.MainWindow"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
    xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
    mc:Ignorable="d">

    <Grid RowDefinitions="Auto,*,*">
        <StackPanel Orientation="Horizontal">
            <NumberBox
                x:Name="ItemsCountControl"
                Value="200000" />
            <Button
                Click="Button_Click"
                Content="Create items" />
        </StackPanel>
        <ScrollViewer
            Grid.Row="1"
            BorderBrush="HotPink"
            BorderThickness="2">
            <ItemsRepeater x:Name="ItemsRepeaterControl" />
        </ScrollViewer>
        <TextBlock
            Grid.Row="2"
            Text="Bottom" />
    </Grid>

</Window>

MainWindow.xaml.cs
using Microsoft.UI.Xaml;
using System.Collections.Generic;

namespace ItemsRepeaterOutsideRenderingBugSample;

public sealed partial class MainWindow : Window
{
    public MainWindow()
    {
        this.InitializeComponent();
    }

    private void Button_Click(object sender, RoutedEventArgs e)
    {
        List<int> items = new();

        for (int i = 0; i < this.ItemsCountControl.Value; i++)
        {
            items.Add(i);
        }

        this.ItemsRepeaterControl.ItemsSource = items;
    }
}

Expected behavior
Items should not be rendered outside the ItemsRepeater.
Screenshots

NuGet package version
WinUI 3 - Windows App SDK 1.2.2: 1.2.221209.1
Windows version
Windows 11 (21H2): Build 22000
Additional context
ListView has the same issue but it breaks with less items.

Here is a reproducible project.

This is still reproducible in WindowsAppSDK v1.3.230602002.

@AndrewKeepCoding, thank you for reporting this. Per internal investigation, this is due to a known DWM limitation and is unlikely to be fixed. Following are additional details, including a workaround:
This is the known DWM "2^21" sizing limitation.  The ScrollViewer content clipping gets out of whack starting in that extent neighborhood.
110399 items render properly. With 110400 items, the last one renders below the ScrollViewer's bounds.
Each item is 19px tall. So 110399 items == 2097581px, 110400 items == 2097600px.  As expected, we're in the 2^21 neighborhood. This is more than a decade old DWM limitation.
Explicitly setting a Clip on the ScrollViewer does not address the issue:
        <ScrollViewer Width="150" Height="450">
            <ItemsRepeater x:Name="ItemsRepeaterControl"/>
            <ScrollViewer.Clip>
                <RectangleGeometry Rect="0,0,150,450"/>
            </ScrollViewer.Clip>
        </ScrollViewer>

Using the new ScrollView instead of the old ScrollViewer does get around the bug.
        <ScrollView Width="150" Height="450">
            <ItemsRepeater x:Name="ItemsRepeaterControl"/>
        </ScrollView>

@DmitriyKomin Thanks for the details.


Closing this issue.


Clarification: stateProvince/county/municipality when georeference radius covers more than one

Using a point-radius (or a dwc:footprintWKT) for a georeference, and that radius encompasses several administrative divisions, what should go into these fields? The division that the points falls into, or a list of the divisions that the radius covers?
To illustrate, the Matroosberg mountains in South Africa fall into two districts, the Worcester Distr. and the Ceres Distr. Some specimens are recorded from the 'Matroosberg', with no extra information.
Should the answer to this be included in the documentation for these DwC properties?

I think they should be left blank. The answer is not available.
Yes, it would be useful have this better documented, but this is a general problem and no solution seems to have been found yet.

Hi Ian,
This question is interesting as it approaches the georeference from a perspective opposite to the normal one for retrospective georeferencing. Usually, one has a textual location as raw material from which the georeference is derived. That is usually something akin to Darwin Core's verbatimLocality, where all of the details could be written out. The principles of best practice suggest that the spatial representation should contain all of the possible interpretations of where that textual location can be. That interpretation often intersects multiple entities at the same administrative level (e.g., dwc:stateProvince). But the Darwin Core higher geography terms are meant to be singular, so that they could, in principle, but validated from a geographic authority. We capture that principle in the standardization of geography using the VertNet Geographic Lookup file (see https://github.com/VertNet/DwCVocabs/blob/master/vocabs/Geography.csv and the principles behind it at https://github.com/VertNet/DwCVocabs). Summarizing, to answer you question, I agree with @qgroom, the administrative levels that would have multiple values should be left blank, and the parent administrative level that contains all of the location should be provided. I have cross-referenced this issue in The Darwin Core Questions & Answers repository (see https://github.com/tdwg/dwc-qa/issues/141), where issues lead to documentation improvement.

Thank you for the responses John and Quentin. Blank it will be. Just another example, which may be useful for documentation, would be a verbatimLocality of '5km from Rust de Winter, Transvaal'. Our South African provinces were changed in 2004, with the Transvaal split into four. A radius of 5km around the small town of Rust de Winter includes three, namely Gauteng, Limpopo and Mpumalanga. To further complicate matters, our provincial boundaries are still somewhat fluid, with the last set of changes in 2016, which puts stateProvince values near but within provincial boundaries in peril too.

I am going to keep this one open, following our process to not close the issue until the answers have been incorporated in documentation.

The usage comments for country incorporate the recommendations covered here. The remaining administrative geography terms (continent, countrycode, stateProvince, county, municipality) should do the same.

Closing as having been answered.


PVAYLADEV-69 deb packaging

Utilize jdeb Maven plugin to generate deb package
Update README.md documentation
Fix WSDL problem preventing service import to security server

Maybe the "deb" directory should be in  "src" or "src/main" folder since it is part of the project sources?

@jhyoty conflict resolved and debian control file moved under src/main


TLS 1.2 finished message

In 1.2 version of TLS, verify_data length depends on the cipher suite. Hovewer in openssl 1.1.1a TLS1_FINISH_MAC_LENGTH is always equal to 12. May it would be a good idea to make this value changeable?

There are no currently supported ciphersuites that have a value for this other than 12 (do any exist?). If at some point in the future we were to add support for a ciphersuite that had a different value for this then we would integrate support for it at that time. It seems fairly pointless to do so until then.


set the transactionId of the container explicitly to sid for teardown

rework comments from PR https://github.com/openwhisk/openwhisk/pull/1404

LGTM

@perryibm rebased and started another PG2-455.

PG2-455 failed due to internet meltdown.  Retrying PG2-457.


net.Dial fails with an ip6 addres - connect: invalid argument

go version
go version go1.15.5 linux/amd64

go env
GO111MODULE="on"
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/krasi/.cache/go-build"
GOENV="/home/krasi/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/krasi/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/krasi"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/home/krasi/src/github.com/arribada/i360/go.mod"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build769533656=/tmp/go-build -gno-record-gcc-switches"

running the code below results in
2021/01/27 11:13:51 dial tcp [fe80::42:f1ff:feef:7dc8]:8080: connect: invalid argument
exit status 1

I tried all sort of combination but any ip6 address returns with an error invalid argument (except [::]:8080
package main

import (
	"bufio"
	"fmt"
	"log"
	"net"
	"time"
)

func main() {

	go func() {
		ln, err := net.Listen("tcp", ":8080")
		if err != nil {
			log.Print(err)
			// handle error
		}
		for {
			conn, err := ln.Accept()
			if err != nil {
				log.Print(err)
				// handle error
			}
			fmt.Println("conn", conn)
			// go handleConnection(conn)
		}
	}()

	time.Sleep(100 * time.Millisecond)

	conn, err := net.Dial("tcp", "[fe80::42:f1ff:feef:7dc8]:8080")
	if err != nil {
		log.Fatal(err)
		// handle error
	}
	fmt.Fprintf(conn, "GET / HTTP/1.0\r\n\r\n")
	status, err := bufio.NewReader(conn).ReadString('\n')
	log.Print(err.Error())
	fmt.Println("status", status)
}

 ifconfig

wlp4s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet <IP_ADDRESS>  netmask <IP_ADDRESS>  broadcast <IP_ADDRESS>
        inet6 fe80::7fef:8789:78f1:aeda  prefixlen 64  scopeid 0x20<link>
        ether d4:25:8b:b6:6a:e8  txqueuelen 1000  (Ethernet)
        RX packets 438123553  bytes<PHONE_NUMBER>33 (317.7 GB)
        RX errors 0  dropped 2  overruns 0  frame 0
        TX packets 474445465  bytes<PHONE_NUMBER>83 (191.4 GB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

For questions please refer to https://github.com/golang/go/wiki/Questions

For questions please refer to https://github.com/golang/go/wiki/Questions

Why did you think it is a question?
I am following the official docs and I would either consider the docs incorrect or there is a bug.

Why did you think it is a question?
I am following the official docs and I would either consider the docs incorrect or there is a bug.

the address you used is link local and requires an interface name, which would've been apparent if you tried to search for the error

the address you used is link local and requires an interface name, which would've been apparent if you tried to search for the error

yes I did search quite a bit, but overlooked this bit. Sorry for the noise and for anyone else coming to the same issue here is the answer 	conn, err := net.Dial("tcp", "[fe80::42:f1ff:feef:7dc8%wlp4s0]:8080")

yes I did search quite a bit, but overlooked this bit. Sorry for the noise and for anyone else coming to the same issue here is the answer 	conn, err := net.Dial("tcp", "[fe80::42:f1ff:feef:7dc8%wlp4s0]:8080")


Player's device lobby count not correctly updating

Player count on player's devices does not update accurately.
Player count on presenter's device is accurate for now.

Probably fixed by 3e85f226d6b7f20ea683a3abf33421477807dce9

Probably fixed by 3e85f226d6b7f20ea683a3abf33421477807dce9


PAC instructions ruin dataflow

An Enterprise customer has reported that PAC instructions ruin dataflow. They're currently working around this by using an architecture hook to make manual patches and mark certain instructions as intrinsics, but ideally they wouldn't have to do that. We should modify our code instead such that PAC instructions don't stop dataflow.

I pretty sure this is solved by https://github.com/Vector35/arch-arm64/commit/3847e619459195db64b5a1ea14a445dbe1c4e8ce, but without a test case I can't confirm for this particular situation. More details at https://github.com/Vector35/binaryninja-api/issues/4638.


NIFI-13358 - NiFi Registry - rework action menus for flows and bundles

Summary
NIFI-13358 - NiFi Registry - rework action menus for flows and bundles

Tracking
Please complete the following tracking steps prior to pull request creation.
Issue Tracking

[ ] Apache NiFi Jira issue created

Pull Request Tracking

[ ] Pull Request title starts with Apache NiFi Jira issue number, such as NIFI-00000
[ ] Pull Request commit message starts with Apache NiFi Jira issue number, as such NIFI-00000

Pull Request Formatting

[ ] Pull Request based on current revision of the main branch
[ ] Pull Request refers to a feature branch with one commit containing changes

Verification
Please indicate the verification steps performed prior to pull request creation.
Build

[ ] Build completed using mvn clean install -P contrib-check

[ ] JDK 21

UI Contributions

[ ] NiFi is modernizing its UI. Any contributions that update the current UI also need to be implemented in the new UI.

Licensing

[ ] New dependencies are compatible with the Apache License 2.0 according to the License Policy
[ ] New dependencies are documented in applicable LICENSE and NOTICE files

Documentation

[ ] Documentation formatting appears as expected in rendered files

+1 (non-binding). Tested by creating a bucket, uploading a bundle to the bucket per the instructions here under User Guide / Manage Bundles / Upload Bundle, importing a flow and then running through the different dropdown options to ensure they work as expected.

+1 From my side, I tested with a bundle and a flow. Merging...


po2md does not respect indentation and newline

File contents, stripped down to the core content
Source files english.md:
- Level 1: Situation assessment

    I have identified:

or:
- Level 1: Situation assessment
    I have identified:

and .po file en2de.po:
#. Progress Assessment: Level 1
#: ../content/55_activity_37.md:block 18 (ordered list)
msgid "Level 1: Situation assessment"
msgstr "Ebene 1: Situationsbeurteilung"

#. Progress Assessment: Level 1 Situation assessment
#: ../content/55_activity_37.md:block 19 (unordered list)
msgid "I have identified:"
msgstr "Ich habe identifiziert:"

create the same bad result german.md:
- Level 1: Situation assessment I have identified:

with the command:
po2md -q --po-encoding UTF-8 -p en2de.po -s german.md english.md
Version: po2md 2.0.0

Thanks for the report, this has been fixed in v2.0.1.


Non-fungible token example

Yet to write tests, but tested manually on testnet
Also had to use LookupMap for now, but ideally we should use TreeMap

Yet to write tests, but tested manually on testnet
Also had to use LookupMap for now, but ideally we should use TreeMap

Sounds good! I'm still writing TreeMap, which depends on Vector. Vector is mostly ready.


CouchDbKit Django ext does not work with choices

Here is a code example::
# models.py

from couchdbkit.ext.django import schema

LICENCE_CHOICES = (
    ('gpl', _('GPL')),
    ('lgpl', _('LGPL')),
    ('bsd', _('BSD')),
)

class Work(schema.Document):
    licence = schema.StringProperty(_('Licence'),
            required=True, default='gpl', choices=LICENCE_CHOICES)

# forms.py

from couchdbkit.ext.django.forms import DocumentForm

from .models import Work

class WorkForm(DocumentForm):
    class Meta:
        document = Work

When I try to render this form, I get this error::
Error when calling the metaclass bases
    cannot concatenate 'str' and 'list' objects

Exception Location: .../couchdbkit/ext/django/forms.py in
                                fields_for_document, line 160

This error is caused by this code::
if prop.choices:
    if prop.default:
        defaults['choices'] = prop.default_value() + list(
                        prop.choices)
        defaults['coerce'] = prop.to_python

My default value is 'gpl', why default value is concatenated with choices? Is
this an error or a feature which I don't know how to use?

+1
Is there any news on this?


Add filter "in  CAP" to source datasets

Add a field to source dataset in the build called CAPLink. Make it always null for now.
Add CAP link as a column on source datasets,
Add a filter "in CAP" with yes/ no values depending on if the source dataset has a cap link.
Group this with the "in cellxgene " filter.

Complete


upload_async fails with large files

I was using the proposed solution in #51 for uploading large files (> 100MB).
The upload_async method is working well for files which do not require chunking and therefore don't require an upload session. However when trying to upload a file which requires an upload session an OneDriveError is raised with invalidRequest - API not found.
The line which triggered the upload was:
client.item(drive='me', id='ID').children['testfile.bin'].upload_async('largeLocalFile.bin')
This issue might possibly be related to API changes (namespace changes) mentioned here. Are there any plans to adapt the current python code to the changed API specifications?

I have the same issue. Any solution?

This issue might possibly related to #104
Additional information: Checked with Python version 3.4.2 and 3.6.0

I also tried with 3.6.3 on Ubuntu 16.04 and still have : API not Found
Do you have any update or workaround as from my point of view without clear solution this API is unusable as you cannot upload "large" file ... ?
Python 3.6.3 (default, Oct  6 2017, 08:44:35)
Thank you !
Traceback (most recent call last):
File "./TEST.py", line 214, in upload_file
returned_item = CLIENT.item(drive='me', id='root').children[file_name].upload_async(source_file)
File "/home/papou/.local/lib/python3.5/site-packages/onedrivesdk/version_bridge/fragment_upload.py", line 160, in fragment_upload_async
session = self.create_session(item).post()
File "/home/papou/.local/lib/python3.5/site-packages/onedrivesdk/request/item_create_session.py", line 106, in post
return self.request().post()
File "/home/papou/.local/lib/python3.5/site-packages/onedrivesdk/request/item_create_session.py", line 60, in post
entity = UploadSession(json.loads(self.send(self.body_options).content))
File "/home/papou/.local/lib/python3.5/site-packages/onedrivesdk/request_base.py", line 163, in send
content=content_dict)
File "/home/papou/.local/lib/python3.5/site-packages/onedrivesdk/http_provider.py", line 71, in send
custom_response = HttpResponse(response.status_code, response.headers, response.text)
File "/home/papou/.local/lib/python3.5/site-packages/onedrivesdk/http_response.py", line 59, in init
raise OneDriveError(message["error"], self.status)
onedrivesdk.error.OneDriveError: invalidRequest - API not found

@papou-github @edgaru @oleo65 I don't have this issue when uploading 4.62 GB files. Try upgrading onedrive-sdk and regenerating your client_id and client_secret.

Thank you for reaching out and for your patience. This SDK is being officially deprecated. See #209 for more information


feat(HACBS-682): only create release if releaselink set to auto-release

This commit adds functionality to the integration_adapter to only retrieve the ReleaseLinks
for an application if the ReleaseLink does not have the release.appstudio.openshift.io/auto-release
label set to false. A missing label is considered the same as it being there and set to true.
Signed-off-by: Johnny Bieren<EMAIL_ADDRESS>

@davidmogar untested so it is marked as draft, but FYI. I am going to open a PR for the ReleaseLink webhook to disallow setting the auto-release label to anything but true/false. Otherwise this code breaks if we set it to foo or something.

https://github.com/redhat-appstudio/release-service/pull/63 forces updates to the release link value to be only true or false

@dirgim I don't see any integration controller stuff in https://github.com/redhat-appstudio/infra-deployments/blob/main/hack/preview-template.env
How do y'all normally test out code changes?

@dirgim I don't see any integration controller stuff in https://github.com/redhat-appstudio/infra-deployments/blob/main/hack/preview-template.env
How do y'all normally test out code changes?

I added this https://github.com/redhat-appstudio/infra-deployments/pull/425. Just rebase it on top of your fork main and you are good to go.

@dirgim I don't see any integration controller stuff in https://github.com/redhat-appstudio/infra-deployments/blob/main/hack/preview-template.env
How do y'all normally test out code changes?

I added this redhat-appstudio/infra-deployments#425. Just rebase it on top of your fork main and you are good to go.

Thank you!

I tested this with three scenarios

releaselink has auto-release label set to true -> release is created -> worked properly
releaselink has auto-release label set to false -> release is not created -> worked properly
releaselink is missing the auto-release label -> release is created -> worked properly

None of this looks at the releaselink in the managed workspace, but that is m7 stuff afaik

I tested this with three scenarios

releaselink has auto-release label set to true -> release is created -> worked properly
releaselink has auto-release label set to false -> release is not created -> worked properly
releaselink is missing the auto-release label -> release is created -> worked properly

None of this looks at the releaselink in the managed workspace, but that is m7 stuff afaik

@johnbieren Could you share how you tested your scenarios? I would like to learn. Thank you!

I deployed infra-deployments with a custom integration-controller specific to my work here (We recorded how to do this. If you don't have the recording I can share it with you). I then just created a bunch of ReleaseLinks to fit the scenarios I wanted (over a full screen of yaml so not pasting it here unless you want me to). Then I just created dummy pipeline runs in my cluster to see what would happen. The release pipeline failed for all since I was just using dummy things, but I was only interested in seeing if the integration controller created a release or not for each pipeline run

@dirgim got some approvals, can we merge this?

@johnbieren yes, thanks for putting this together!


Preview doesn't work on FreeBSD

I've already pasted the following settings (copy from repo README page) to ~/.config/lf/lfrc:
set previewer ctpv
set cleaner ctpvclear
&ctpv -s $id
&ctpvquit $id

But when I open lf (many times to confirm), no image preview:

So, first thing first, I need to make sure that ueberzug works or not, then I tried to make a draw-image.sh that uses ueberzug to draw an image in the terminal. Here is the script content:
#!/usr/local/bin/bash

[ -z "$5" ] && echo "Usage: $0 <image> <x> <y> <max height> <max width>" && exit

source "`ueberzug library`"

ImageLayer 0< <(
    ImageLayer::add [identifier]="example0" [x]="$2" [y]="$3" [max_width]="$5" [max_height]="$4" [path]="$1"
    read
)

Then run it to see if it works or not:
draw-image.sh ~/Photos/wallpaper/11.jpg 0 0 100 100

And it works perfectly:

So, next try is ctpv, here is some commands and output:
ctpv -m ~/Photos/wallpaper/rust_old.png
# .png image/png

# Based on the man page info: ` ctpv file [w] [h] [x] [y] [id]`, I tried to run this command,
# but it prints out the image binary content instead of drawing an image:
ctpv  ~/Photos/wallpaper/rust_old.png 100 100 0 0

Anything I'm missing?:)

Hello! This is weird, it looks like ctpv cannot find ueberzug program installen on the system, so it falls back to the most basic preview, which is plain cat.
What is your /bin/sh shell? Could you please try running  command -v "ueberzug" >/dev/null; echo $??

Hello! This is weird, it looks like ctpv cannot find ueberzug program installen on the system, so it falls back to the most basic preview, which is plain cat.
What is your /bin/sh shell? Could you please try running  command -v "ueberzug" >/dev/null; echo $??

Hello! This is weird, it looks like ctpv cannot find ueberzug program installen on the system, so it falls back to the most basic preview, which is plain cat.
What is your /bin/sh shell? Could you please try running  command -v "ueberzug" >/dev/null; echo $??

Hey, sorry for late reply, mmh, I use fish shell and installed uebuerzug via
FreeBSD pkg (the standard normal way to install anything in FreeBSD).
And ueberzug is in my $PATH, so I think ctpv should be able to find it:
N  wison | /usr/home/wison   which ueberzug
/usr/local/bin/ueberzug

N  wison | /usr/home/wison   ls -lht /usr/local/bin/ueberzug
lrwxr-xr-x  1 root  wheel    12B Dec 11 08:18 /usr/local/bin/ueberzug@ -> ueberzug-3.9

I  wison | /usr/home/wison   ls -lht /usr/local/bin/ueberzug-3.9
-rwxr-xr-x  1 root  wheel   974B Dec 11 08:18 /usr/local/bin/ueberzug-3.9*

I  wison | /usr/home/wison   ueberzug version
18.1.8

And here is the info of the installed ueberzug:
I  wison | /usr/home/wison   pkg info --all | rg ueberzug
py39-ueberzug-18.1.8_1         Draw images on terminals with X11 child windows

I  wison | /usr/home/wison   pkg info py39-ueberzug
py39-ueberzug-18.1.8_1
Name           : py39-ueberzug
Version        : 18.1.8_1
Installed on   : Fri Dec 16 18:33:10 2022 NZDT
Origin         : graphics/py-ueberzug
Architecture   : FreeBSD:13:amd64
Prefix         : /usr/local
Categories     : python graphics
Licenses       : GPLv3+
Maintainer<EMAIL_ADDRESS>WWW            : https://github.com/seebye/ueberzug
Comment        : Draw images on terminals with X11 child windows
Options        :
        EXAMPLES       : on
Shared Libs required:
        libXext.so.6
        libX11.so.6
Annotations    :
        FreeBSD_version: 1301000
        flavor         : py39
        repo_type      : binary
        repository     : FreeBSD
Flat size      : 374KiB
Description    :
Überzug is a command line util which allows to draw images on terminals by
using child windows.

Advantages to w3mimgdisplay:
- no race conditions as a new window is created to display images
- expose events will be processed,
- so images will be redrawn on switch workspaces
- tmux support (excluding multi pane windows)
- terminals without the WINDOWID environment variable are supported
- chars are used as position - and size unit
- no memory leak (/ unlimited cache)

WWW: https://github.com/seebye/ueberzug

The command you asked me to run, fail in fish:
I  wison | /usr/home/wison   command -v "ueberzug" >/dev/null; echo "$?"
fish: $? is not the exit status. In fish, please use $status.
command -v "ueberzug" >/dev/null; echo "$?"
                                         ^
I  wison | /usr/home/wison   command -v "ueberzug" >/dev/null; echo $status
0

Then I gave it a try in bash shell as well:
[wison@my-bsd /usr/home/wison]$ command -v "ueberzug" >/dev/null; echo $?
0
[wison@my-bsd /usr/home/wison]$ which ueberzug
/usr/local/bin/ueberzug

Plz let me know you still need anything from me:)

Could you please try running ls -l /bin/sh and `/bin/sh -c 'command -v "ueberzug"' >/dev/null; echo $?

Could you please try running ls -l /bin/sh and /bin/sh -c 'command -v "ueberzug"' >/dev/null; echo $?

Sure, here it is:
I  wison | /usr/home/wison   ls -l /bin/sh
-r-xr-xr-x  1 root  wheel  169816 May 12  2022 /bin/sh*

I  wison | /usr/home/wison   /bin/sh -c 'command -v "ueberzug"' >/dev/null; echo $?
fish: $? is not the exit status. In fish, please use $status.
/bin/sh -c 'command -v "ueberzug"' >/dev/null; echo $?
                                                     ^
I  wison | /usr/home/wison   /bin/sh -c 'command -v "ueberzug"' >/dev/null; echo $status
0

# Then run that in `/bin/sh`:

I  wison | /usr/home/wison   sh
$ /bin/sh -c 'command -v "ueberzug"' >/dev/null; echo $?
0

How did you make fish your default shell?

I'm pretty sure it has something to do with fish being the default shell on your system. Although I might be wrong since /bin/sh seems to be working as expected...

How did you make fish your default shell?

Fish is not a POSIX shell, while ctpv expects a POSIX shell to be running because all its internal preview scripts are written in POSIX shell syntax. Do you have bash installed on your system?

Fish is not a POSIX shell, while ctpv expects a POSIX shell to be running because all its internal preview scripts are written in POSIX shell syntax. Do you have bash installed on your system?

Sorry for late reply, yes I understand and yes I got Bash installed. If I insist to stay with Fish (as that's my favourite shell), is there any handy and easy way that I can run your plugin in bash session? (I mean how to use a script command to replace the default settings in lfrc?)☺

I can add a config option to specify shell path. So in your case you could specify a path to bash.

Just added shell option (6f364cf383e87d2ab51bee307bbd149c2fb252db). Try adding set shell "/usr/bin/bash" in your ctpv config.

Just added shell option (6f364cf). Try adding set shell "/usr/bin/bash" in your ctpv config.

I  git clone the latest version and confirmed that with your last commit, but it can't compile :(
Does anything change in the Makefile (as I remember I can compile before)....
doas make install
Password:
cc -o ctpv   -O2 -pipe
cc: error: no input files
*** Error code 1

Stop.
make: stopped in /usr/home/wison/temp/ctpv
 I  wison | /usr/home/wison/temp/ctpv   cc --version
FreeBSD clang version 14.0.5 (https://github.com/llvm/llvm-project.git llvmorg-14.0.5-0-gc12386ae247c)
Target: x86_64-unknown-freebsd14.0
Thread model: posix
InstalledDir: /usr/bin

Last time I changed the Makefile was on October 10, So it's probably unrelated to that. It looks like Makefile does not have a list of source files. What kind of make utility do you use? Is it GNU Make? I think you can check with make --version.

Last time I changed the Makefile was on October 10, So it's probably unrelated to that. It looks like Makefile does not have a list of source files. What kind of make utility do you use? Is it GNU Make? I think you can check with make --version.

Ok, I fixed the make issue by installing gmake and doas gmake install works, but it seems still not solve the problem:)
I think you need to know the following information (re-run the previous commands you wanted me to do):
I  wison | /usr/home/wison   /usr/local/bin/bash --version
GNU bash, version 5.2.15(0)-release (amd64-portbld-freebsd14.0)
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
 I  wison | /usr/home/wison 
 I  wison | /usr/home/wison   bash
[wison@my-bsd /usr/home/wison]$
[wison@my-bsd /usr/home/wison]$ command -v "ueberzug" >/dev/null; echo "$?"
0
[wison@my-bsd /usr/home/wison]$ which ueberzug
/usr/local/bin/ueberzug
[wison@my-bsd /usr/home/wison]$ ueberzug version
18.1.8
[wison@my-bsd /usr/home/wison]$ bat ~/.config/ctpv/config
───────┬─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
       │ File: /home/wison/.config/ctpv/config
───────┼─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
   1   │ set shell "/usr/local/bin/bash"
───────┴─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
[wison@my-bsd /usr/home/wison]$ ctpv -m ~/Photos/wallpaper/rust_old.png
.png image/png

But when I run ctpv  ~/Photos/wallpaper/rust_old.png 100 100 0 0, it still print out the image data to the console which means not ok:)

Could you please send your ctpv config here?

Could you please send your ctpv config here?

Sure, it just one line:
set shell "/usr/local/bin/bash"

I've added -d option for debug messages. Could you please try running ctpv on an image and print the output here?

ctpv ~/Photos/wallpaper/rust_old.png 100 100 0 0

Ok, I pull and recompiled and reinstalled, here is what you want I think:

Try to preview a file:
I  wison | /usr/home/wison/temp/ctpv   ctpv -d ~/Photos/wallpaper/rust_old.png 100 100 0 0 > ~/temp/ctpv_debug.log
# Running preview: image
# Preview image failed
# Running preview: any

#
# Compare the log file size and original image size,
# I opened the log file, it seems just the image binary data.
#
I  wison | /usr/home/wison/temp/ctpv   ls -lht ~/temp/ctpv_debug.log
# -rw-r--r--  1 wison  wison   8.8M Apr 11 11:04 /home/wison/temp/ctpv_debug.log
I  wison | /usr/home/wison/temp/ctpv   ls -lht ~/Photos/wallpaper/rust_color.png
# -rwx------  1 wison  wison   1.1M Jan  6 18:04 /home/wison/Photos/wallpaper/rust_color.png*

Run in lf:

I changed my lf config:
# Add debug flag and output to log file
&ctpv -d -s $id >> ~/temp/lf_ctpv.log
&ctpvquit $id >> ~/temp/lf_ctpvquit.log

Then run lf and navigate to a few image files, nothing happen and there is no log content:
 N  wison | /home/wison/temp   /bin/ps aux | rg ctpv

# wison   23037    0.0  0.0      16484   5588  2  S    11:09     0:00.01 ctpv -s 22342
# wison   92911    0.0  0.0      16484   5592  2  S    11:10     0:00.01 ctpv -d -s 92010
# wison   38032    0.0  0.0      18176   6472  3  R+   11:11     0:00.00 rg ctpv

 I  wison | /home/wison/temp   ls -lht ~/temp/lf*.log

# -rw-r--r--  1 wison  wison     0B Apr 11 11:10 /home/wison/temp/lf_ctpvquit.log
# -rw-r--r--  1 wison  wison     0B Apr 11 11:10 /home/wison/temp/lf_ctpv.log

And it seems to treat the image file as a binary file type or maybe fallback to bat/cat?


Improve UI and Function

I dont know how to open two pull requests with one repostory.
Sorry for that.

@zeteticl, as @joesinghaus said, please create two separate branches on your fork and then submit them as separate Pull Requests.  If you are using Github Desktop for Windows, there is a guide here: https://services.github.com/on-demand/github-desktop/create-branches-github-desktop
If you're using the command line, there are numerous guides to branching online; just create the branch with a single command (git checkout -b whatever-you-want) and switch between existing branches with (git checkout whatever-you-want), pushing to said branches with (git push remotename whatever-you-want) (usually your remotename will be origin, if it is a direct clone of your fork; this is how git sets it up by default).
In any case, I can merge this as a new sheet for the inSANe system and updates to Shinobi_Gami.  And also, you do not need to add empty translation files as stated above.  The translation system will auto-populate them based on the translation.json file in the base directory.
Jeff


Handle JUCE 8.0.2 deprecating Font::getStringWidth()

JUCE deprecated Font::getStringWidth() in v8.0.2, which was used in a few places across the inspector.
This adds a new getStringWidth() static method to InspectorLookAndFeel which uses juce::GlyphArrangement to calculate the string width in JUCE 8.0.2 or newer, keeping backwards-compatibility for older versions of JUCE.

Thanks! I'll take a look tomorrow and merge.

The CI errors are fixed in #125, which needs this merged as well, so will merge this first.