[BUG] RichHandler(show_path=False) emits trailing whitespace up to terminal width

Describe the bug
When show_path=False is passed to RichHandler, it does not need to emit any content beyond the end of the log message, but it still pads out the content with spaces up to the console's width. This (a) makes it annoying to copy/paste as an end user, (b) means that resizing ones terminal/font size results in "blank" whitespace-only lines appearing in already-emitted log output, and (c) means that setting an explicitly high console width to avoid wrapping (which our CLI's integration tests do) results in huge amounts of whitespace in the output.
With the below script and sed, we can demonstrate this:
$ python reproducer.py | sed 's/ /_/g'
2022-11-15_10:33:11_INFO_____Logging_initialised_____________________________________________________________________________________________________________________________

import logging

from rich.logging import RichHandler

def init_logging() -> logging.Logger:
    handler = RichHandler(show_path=False)

    logging.basicConfig(
        datefmt="%Y-%m-%d %H:%M:%S",
        format="%(message)s",
        handlers=[handler],
        level=logging.INFO,
    )
    logging.info("Logging initialised")

init_logging()

Platform

Click to expand
What platform (Win/Linux/Mac) are you running on? What terminal software are you using?
Ubuntu 20.04, GNOME Terminal
$ python -m rich.diagnose
╭───────────────────────── <class 'rich.console.Console'> ─────────────────────────╮
│ A high level console interface.                                                  │
│                                                                                │
│ ╭──────────────────────────────────────────────────────────────────────────────╮ │
│ │ <console width=173 ColorSystem.TRUECOLOR>                                    │ │
│ ╰──────────────────────────────────────────────────────────────────────────────╯ │
│                                                                                │
│     color_system = 'truecolor'                                                   │
│         encoding = 'utf-8'                                                       │
│             file = <_io.TextIOWrapper name='<stdout>' mode='w' encoding='utf-8'> │
│           height = 43                                                            │
│    is_alt_screen = False                                                         │
│ is_dumb_terminal = False                                                         │
│   is_interactive = True                                                          │
│       is_jupyter = False                                                         │
│      is_terminal = True                                                          │
│   legacy_windows = False                                                         │
│         no_color = False                                                         │
│          options = ConsoleOptions(                                               │
│                        size=ConsoleDimensions(width=173, height=43),             │
│                        legacy_windows=False,                                     │
│                        min_width=1,                                              │
│                        max_width=173,                                            │
│                        is_terminal=True,                                         │
│                        encoding='utf-8',                                         │
│                        max_height=43,                                            │
│                        justify=None,                                             │
│                        overflow=None,                                            │
│                        no_wrap=False,                                            │
│                        highlight=None,                                           │
│                        markup=None,                                              │
│                        height=None                                               │
│                    )                                                             │
│            quiet = False                                                         │
│           record = False                                                         │
│         safe_box = True                                                          │
│             size = ConsoleDimensions(width=173, height=43)                       │
│        soft_wrap = False                                                         │
│           stderr = False                                                         │
│            style = None                                                          │
│         tab_size = 8                                                             │
│            width = 173                                                           │
╰──────────────────────────────────────────────────────────────────────────────────╯
╭─── <class 'rich._windows.WindowsConsoleFeatures'> ────╮
│ Windows features available.                           │
│                                                       │
│ ╭───────────────────────────────────────────────────╮ │
│ │ WindowsConsoleFeatures(vt=False, truecolor=False) │ │
│ ╰───────────────────────────────────────────────────╯ │
│                                                       │
│ truecolor = False                                     │
│        vt = False                                     │
╰───────────────────────────────────────────────────────╯
╭────── Environment Variables ───────╮
│ {                                  │
│     'TERM': 'xterm-256color',      │
│     'COLORTERM': 'truecolor',      │
│     'CLICOLOR': None,              │
│     'NO_COLOR': None,              │
│     'TERM_PROGRAM': None,          │
│     'COLUMNS': None,               │
│     'LINES': None,                 │
│     'JUPYTER_COLUMNS': None,       │
│     'JUPYTER_LINES': None,         │
│     'JPY_PARENT_PID': None,        │
│     'VSCODE_VERBOSE_LOGGING': None │
│ }                                  │
╰────────────────────────────────────╯
platform="Linux"

$ pip freeze | grep rich
rich==12.6.0

RichHandler is designed with one goal in mind: to look nice in the terminal.
If you don't want the path. And you want it to soft wrap. Then you don't want RichHandler. Best roll your own logging handler using just the features you want.

RichHandler is designed with one goal in mind: to look nice in the terminal.
If you don't want the path. And you want it to soft wrap. Then you don't want RichHandler. Best roll your own logging handler using just the features you want.

Hi @willmcgugan, I'm a little confused by this response. RichHandler explicitly has support for excluding the path with show_path=False. I'm reporting that using this documented option means that log output does not "look nice in the terminal" if that terminal is resized to be smaller (e.g. by increasing its font size) after the log lines are emitted: the trailing whitespace causes every line to wrap.
For avoidance of doubt, here is the same log output before and after incrementing my terminal's font size:

(It sounds like passing Console(..., soft_wrap=True) might be the solution for (c) our CI output issues: thanks for the pointer!)

I am also experiencing the same issue. There is no reason for trailing spaces to be printed when nothing is being right-aligned, i.e. when RichLogger(show_paths=False). @willmcgugan

I'm experiencing the same issue, are you planing to fix this ? :)

I also ran into this bug when transitioning a CLI to use rich. in the integration tests I inspect what is being output to stderr/stdout and found a bunch of white space being added to the end of each line. a fix for this would be greatly appreciated.

Also would be useful for GitLab CI usage as show_path needs to be disabled for that: https://github.com/Textualize/rich/issues/2551

I have the same issue with Syntax()
I print YAML from teh data I receive from an API, the user can redirect it to a file to use as a template, put it's padded with trailling white space.
Wish there was an argument to suppress trailling whitespace


[Request - Product] IBM AIX Server

IBM AIX Server - https://www.ibm.com/products/aix
AIX 7.3 TL1 - End of Support: 31 December 2025
AIX 7.3 TL0 - End of Support: 31 December 2024
AIX 7.2 TL5 - End of Support: To be determined
AIX 7.2 TL4 - End of Support: 30 November 2022
AIX 7.2 TL3 - End of Support: 30 September 2021
AIX 7.2 TL2 - End of Support: 31 October 2020
AIX 7.2 TL1 - End of Support: 30 November 2019
AIX 7.2 TL0 - End of Support: 31 December 2018
AIX 7.1 TL5 - End of Support: 30 April 2023
AIX 6.1 TL9 - End of Support: 30 April 2017
Note: (Paid) Extended Support is available for AIX 7.1 TL5, up to 30 April 2026

https://www.ibm.com/support/pages/aix-support-lifecycle-information
Thanks!

I created a PR #3053 that adds IBM AIX to endoflife.date - if you may @firewavemtl, please check if the dates are valid.

Reviewed and all good. Thanks!

I guess it can be closed now with #3053 now in place - fyi @captn3m0, @marcwrobel.

You are right, thanks !


Load FixtureBooster only in test environment

It was causing a problem with %database_path% parameter not found in prod.
Since this is only useful in test environment, but is called from console with dev, add to bundle list only in needed environments.

Closed in favor of https://github.com/elcodi/bamboo/pull/353


VSCode Exten login failed

When I login in VSCode, get fellowing error:
Request $/handleOAuthCallbackUri failed with message: Minified error #8:  See https://developer.grammarly.com/docs/error-explainer?code=8&args=vscode%3A%2F%2Fznck.grammarly%2Fauth%2Fcallback%3FwindowId%3D1&trace=Error
++++at+https%3A%2F%2Fjs.grammarly.com%2Fgrammarly-sdk%401.7%3A17%3A60282
++++at+Generator.next+(<anonymous>)
++++at+bt+(https%3A%2F%2Fjs.grammarly.com%2Fgrammarly-sdk%401.7%3A17%3A26642)
++++at+o+(https%3A%2F%2Fjs.grammarly.com%2Fgrammarly-sdk%401.7%3A17%3A26846)
++++at+https%3A%2F%2Fjs.grammarly.com%2Fgrammarly-sdk%401.7%3A17%3A26907
++++at+new+Promise+(<anonymous>)
++++at+https%3A%2F%2Fjs.grammarly.com%2Fgrammarly-sdk%401.7%3A17%3A26786
++++at+Ve+(https%3A%2F%2Fjs.grammarly.com%2Fgrammarly-sdk%401.7%3A17%3A60396)
++++at+https%3A%2F%2Fjs.grammarly.com%2Fgrammarly-sdk%401.7%3A17%3A90543
++++at+t.SDK.handleOAuthCallback+(https%3A%2F%2Fjs.grammarly.com%2Fgrammarly-sdk%401.7%3A17%3A90565) for details.

I had the same issue when tried to install the extension for VS Code Insiders. It works fine for the stable version of VS Code.


GH-15 Trigger database initialization on embedded ones by default

Done for jdbc module.
Mongo and JPA modules are already working out of the box.
Closes #15

@odrotbohm my tests are failing, but not sure why is that.
For example "mysql init disabled" fails, if I add "debug: true" to mysql yaml files then I can see:
`Unconditional classes:
org.springframework.boot.test.autoconfigure.jdbc.TestDatabaseAutoConfiguration
org.springframework.modulith.events.jdbc.JdbcEventPublicationAutoConfiguration`

It looks like conditional annotation was never evaluated:
@Bean @Conditional(DatabaseSchemaInitializerCondition.class) DatabaseSchemaInitializer
Not sure what I'm doing wrong here.

Redone, added additional tests + classpath resource for getSchemaResourceFilename in DatabaseType

Thanks, Nikola. I'll have a look ASAP.


Development of common tools for data format validation

Hi all,
As we discussed in the telcon, we should define a couple of methods for DL3 data format validation. Apart from the use cases that the format will need to cover, we should have methods to estimate the systematic uncertainty we are adding by using certain approximations.
Also, the current generation of IACTs will dedicate some effort to validate their own DL3 products, so there is a nice synergy on this task from which we could profit.
I guess, an obvious example is to fit the measured spectrum of a known source (CrabNebula for MAGIC) with different assumptions considered (adding or removing some IRF dependencies, for example).
In the case of CTA, we could generate event lists from several IRFs with small differences (for example, zenith angle variation expected in ~30') and measure the effect on the calculated spectrum using an averaged IRF.
@cdeil Were similar validations done for HESS? Or just comparison between standard analysis tools and DL3 analysis products?

Hi Tarek,
as a first approach, the check on spectra that you're suggesting sounds good to me.
However, I am not sure that the feedbacks coming from tests based on simulation only (e.g. CTA) can be as effective as the ones coming from real data (e.g. HESS, MAGIC, VERITAS). For this reason, I would concentrate first on tests performed on real data.

Hi @SaverioLombardi ,
Indeed. Real data will be key here. The experience of HESS and VERITAS will be essential. You know how much I love MC... :blush:
Although we must also validate the DL3 format for CTA, and that requires to run some tests also without real data. It could be relevant to define the length of CTA DL3 bunches (key, for example, to estimate the computing resources for the run-wise MC), to understand how complex will IRF3 be, and things like that... Current generation of IACTs do not have such tight requirements, so we will probably need both.

Well, in HESS, 100 people have done all kinds of studies for over a decade, so I'm sure many studies and attempts to quantify IRF and high-level analysis result precision have been done.
But when it comes to concrete methods or scripts to check the DL3 data and IRFs we produce, there's almost nothing there yet!
At the moment we're comparing high-level source results (position, extension, spectral parameters) for a handful of test sources between different chains / configs / tools.
@joleroi has a script that does these batch analyses for target lists with Gammapy, @mimayer has one that does them with ctools, both haven't landed in the public Gammapy or ctools repo yet I think.
I once started a EventListDatasetChecker in Gammapy where I started to compare times and coordinates (RA / DEC / ALT / AZ / DETX / DETY) obtained via Astropy / Gammapy against the HESS software. This is old and outdated, I'm just mentioning as an example of how we could implement common tools to check IACT DL3 data. Both for format and for content, I think Python scripts are the way to go. They should be open-source to be re-usable for all IACTs. I don't care much at the moment if this development happens in Gammapy, ctapipe, Gammalib or in this spec repo or yet another repo. For personal reasons I have a slight preference for Gammapy and pull request there for an IRFChecker (anything, both format and content) are welcome. It should be exposed as a command-line tool also, e.g. called gamma-dl3-police or something.
As I've mentioned at the Meudon meeting, in HESS we have these index files for each "FITS production", so really what I'm looking for is something that takes such a production (DataStore in Gammapy) and runs a series of checks, producing a text or HTML report about issues.
I think the needs for CTA at the moment are different. There it's more about developing tools that compute required MC statistics and good binnings in parameters to obtain a given precision. Some of the code will be useful for existing IACTs also, but it's also kind of a different study.
So I don't know what this means for us here. Either we continue to chat a bit about it here and we all do our own stuff more or less. Or someone (probably from CTA) sets up a task group on this and tries to organise the work (kick-off f2f meeting, then monthly telcons) ... if you can get enough contributions.
In my opinion we can cover format validation in the monthly calls we have now, but when it comes to content validation and IRF checks and data quality, that's a large separate task that we can't cover in one telcon a month.

Also -- every IACT, chain, config and IRF is different. See the backup slides 12 and 13 with examples of IRF issues from HESS here. Some chains in HESS do MC simulations at fixed energies, other continuous. Some configs have gamma-hadron separate in energy and offset bands and then the responses have steps. This is a long-time known issue (well, internally) for HESS spectra without a good solution.
So what I'm saying is: yes, we should develop some methods and tooling to check IRFs. But the re-use factor will be limited, large time investments are needed to produce good, well-understood  IRFs for every IACT / chain / config. Is there a task group in CTA to work on this?

Thanks @cdeil !

Also -- every IACT, chain, config and IRF is different. See the backup slides 12 and 13 with examples of IRF issues from HESS here. Some chains in HESS do MC simulations at fixed energies, other continuous. Some configs have gamma-hadron separate in energy and offset bands and then the responses have steps. This is a long-time known issue (well, internally) for HESS spectra without a good solution.

I'm thinking exclusively about validating the format. Different analysis chains would produce different DL3 datasets, and could be compared and cross-validated. But to validate the format itself you probably need methods that proof that you are actually not loosing information in the process.

At the moment we're comparing high-level source results (position, extension, spectral parameters) for a handful of test sources between different chains / configs / tools.
@joleroi has a script that does these batch analyses for target lists with Gammapy, @mimayer has one that does them with ctools, both haven't landed in the public Gammapy or ctools repo yet I think.

I was thinking about something like this.

So what I'm saying is: yes, we should develop some methods and tooling to check IRFs. But the re-use factor will be limited, large time investments are needed to produce good, well-understood IRFs for every IACT / chain / config. Is there a task group in CTA to work on this?

Definitely not. And it may be unrealistic to think people will devote their efforts on it. And also the scope of such common tools may be simply too wide.
But, thinking about CTA, the fact that we need to validate the format itself worries me. I guess it may be validated together with the methods that will, in the future, validate the CTA "blessed" science tools.

But, thinking about CTA, the fact that we need to validate the format itself worries me. I guess it may be validated together with the methods that will, in the future, validate the CTA "blessed" science tools.

It's my fault, but we're talking about very different things in this one thread and it's getting confusing.

Format validation
Content validation

for DL3 (EVENTS, IRFs)
for derived DL4 or DL5 (measured source parameters)

Should we focus on 1 for now and leave 2 to the future and some other thread?
@TarekHC - You say "the fact that we need to validate the format itself worries me".
I think it's completely normal and a need for any format as soon as you have several producers.
When HESS or MAGIC or CTA or ... produces FITS data that is supposed to match this DL3 spec, it's nice if we have a validation tool that checks that the format is OK.
By format I just mean to check that all required header keywords and columns are present.
This could then be extended to simple data type and value checks, like livetime should be a positive floating point number, even if those simple value checks are already moving a little bit towards content validation.
The other tool that would be nice to have would be to throw a FITS file or list of FITS files at it, and it lists or summarises as text on the console what they contain (i.e. which HDUs are of formats describe in this spec and what they contains which aren't).
In Gammapy we have started to implement the gammapy-data-show command line tool (mainly used so far to debug exported HESS IRFs). It's not implemented well ... as soon as we have the declarative scheme here with the HDUCLASS2 required, it should go via a registry. At the moment the user has to say what format a given HDU is in (see here).
Also, before we keep discussing further: @jknodlseder - do you think it's useful to talk about "Development of common tools for data format validation" in the issue tracker of this repo? Or do you think we should limit the scope here to format discussions, and move tool discussions over to the Gammalib or Gammapy trackers?


Wrong id text was fixed at waist trackers

last 2 are back (3, 4) was changed to:
last 2 are back (2, 3)

Thank you!


Inline feature

Is there any inline feature planned?
I mean how can I answer to an InlineQuery with this python-based bot?
Would appreciate any help!

Yeah I'd like to use such a feature too. Right now I'm trying to add this to answer inline queries. Not sure if it's going to work.


Update full-distance-fix with consistent field names

This PR updates:

the sample point indicators field names in setup_config.py and aggr.py so that they are consistent across the workflow.

update the full nodes functions so that it produces distance measures, then run convert to binary measures as a separate step.

I test the workflow using Vic and Olomouc, both sample point and aggregation scripts are run successfully.
Before merging into the upstream, there is a minor issue:
Whenever coverting the origional node subgraph to gdf:
# convert subgraph into edge GeoDataFrame
subgraph_gdf = ox.graph_to_gdfs(subgraph_proj,
                                nodes=False,
                                edges=True,
                                node_geometry=False,
                                fill_edge_geometry=True)

It gives the warning message:
/opt/conda/lib/python3.7/site-packages/pyproj/crs/crs.py:53: FutureWarning: '+init=<authority>:<code>' syntax is deprecated. '<authority>:<code>' is the preferred initialization method. When making the change, be mindful of axis order changes: https://pyproj4.github.io/pyproj/stable/gotchas.html#axis-order-changes-in-proj-6
  return _prepare_from_string(" ".join(pjargs))

So we have 14087 nodes for Vic, when running the sp.py in the terminal, it shows this warning message 14087 times. But it does not seem to affect the workflow and the results.
Is there something that I should be aware of with this message? Anything we should do to address this?

@shiqin-liu yes we should update all of our CRS definitions as that warning suggests. The old style is not compatible with future versions of the proj library.

@shiqin-liu yes we should update all of our CRS definitions as that warning suggests. The old style is not compatible with future versions of the proj library.

@gboeing any suggestion on how to make this update?
Our current CRS in config json for example is:
       "to_crs": {         "init": "epsg:7845"     }
I make the change to "to_crs": "epsg:7845", but the warning does not seem to go away, is that's something related to the input data source?

Yeah updating them like "epsg:7845" should fix it... if you still get warnings there are probably still some old-style "init" CRS definitions somewhere in the code or data.

Thanks! I guess it is something related to the data, but I will double-check the workflow to make sure.

I have posted the CRS format issue in #58.  I think this should be ready to be merged into the master, if @gboeing and @carlhiggs you both think this looks OK.

@shiqin-liu sounds good. If we have all the CRS's in our codebase here formatted correctly, then we should be ready to merge. If I don't hear otherwise from @carlhiggs I can do the merge tomorrow.


Can not create new user or change password in 0.94.0

Home Assistant release with the issue:
0.94.0
Description of problem:
Trying to change password on admin and create a new not admin user and gets this error:
2019-06-06 19:05:34 ERROR (MainThread) [homeassistant.components.websocket_api.http.connection.2905382032] Error handling message: Unknown error
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/components/websocket_api/decorators.py", line 17, in _handle_async_response
await func(hass, connection, msg)
File "/usr/src/homeassistant/homeassistant/components/config/auth_provider_homeassistant.py", line 60, in websocket_create
provider = _get_provider(hass)
File "/usr/src/homeassistant/homeassistant/components/config/auth_provider_homeassistant.py", line 53, in _get_provider
raise RuntimeError('Provider not found')
RuntimeError: Provider not found
2019-06-06 19:05:36 ERROR (MainThread) [homeassistant.components.websocket_api.http.connection.2905382032] Error handling message: Unknown error
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/components/websocket_api/decorators.py", line 17, in _handle_async_response
await func(hass, connection, msg)
File "/usr/src/homeassistant/homeassistant/components/config/auth_provider_homeassistant.py", line 60, in websocket_create
provider = _get_provider(hass)
File "/usr/src/homeassistant/homeassistant/components/config/auth_provider_homeassistant.py", line 53, in _get_provider
raise RuntimeError('Provider not found')
RuntimeError: Provider not found

Please provide your configuration (http, core and anything related to auth) - and post if you have used any additional auth provider.

I'm using Nginx 2.1 and Duckdns 1.6.
My configuration.yaml:
homeassistant:
auth_providers:
- type: trusted_networks
trusted_networks:
- <IP_ADDRESS>
- ::1
- <IP_ADDRESS>/24
- <IP_ADDRESS>/24
- <IP_ADDRESS>/24
- <IP_ADDRESS>/24
- fd00::/8
http:
use_x_forwarded_for: true
trusted_proxies:
- <IP_ADDRESS>
- ::1
cors_allowed_origins:
- https://xxxxxx.duckdns.org
- http://hassio.local
ip_ban_enabled: true
login_attempts_threshold: 5

Sorry, user error deleted a line by misstake.


How must the satellite images look like?

Dear Wang Zhecheng,
I would like to run DeepSolar for Central Europe, especially Germany.
The 5 GB of https://s3-us-west-1.amazonaws.com/roofsolar/SPI_eval.tar.gz is too much to download it for fun.
May you please tell me how the satellite images must be formatted? Is a TMS (tiled map service) sufficient?

The satellite images are 320*320px PNG files. They are from Google Maps (Google Static Map API), so I believe images in Europe should be similar to those in our dataset.

The satellite images are 320*320px PNG files. They are from Google Maps (Google Static Map API), so I believe images in Europe should be similar to those in our dataset.

Hi ZheCheng,
Great work! What is the zoom level of the satellite images? Estimated like around 16, I think the zoom level may affect the final ap.

Hi Wang ZheCheng,
I got "access denied" to the SPI_train.tar.gz and SPI_eval.tar.gz files.
Is there something I need to be doing to get access?
The SPI_val.tar.gz file is ok
Thanks

Hi @wangzhecheng
Can you get the files available to download?
Perhaps do you have the files yet, @Spike774 ?
Thanks

Hi @wangzhecheng
Can you get the files available to download?
Perhaps do you have the files yet, @Spike774 ?
Thanks

The Author had removed the source files due to privacy issue before I found this repo.

@Spike774
Do you know how to execute this script without the files then?
I hope you would like to help me with this.

@Spike774
Do you know how to execute this script without the files then?
I hope you would like to help me with this.

Check #8 : the files are available as torrents.


FW-234  SCons build for Atmel SAMR21-XPlained Pro

Re-implemented from latest version of master repo.

@mikehaben , there is nothing changes in this PR, wrong operation?

Sorry Tengfei, I'm really not having much luck with the GitHub Windows
client.  I thought I'd re-synchronised my fork with the master repo, and
then applied the FW-234 changes - clearly not!  I'll try again tomorrow.
Mike Haben
------ Original Message ------
From: "Tengfei.Chang"<EMAIL_ADDRESS>To: "openwsn-berkeley/openwsn-fw"<EMAIL_ADDRESS>Cc: "mikehaben"<EMAIL_ADDRESS>"Mention"
<EMAIL_ADDRESS>Sent: 17/10/2016 15:08:52
Subject: Re: [openwsn-berkeley/openwsn-fw] FW-234 SCons build for Atmel
SAMR21-XPlained Pro (#308)

@mikehaben , there is nothing changes in this PR, wrong operation?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

@mikehaben ,no probably :-)


Default to MockDirectoryFactory in test configs

Description
IDE's like IntelliJ and Eclipse have internal test-runners that can often run tests faster than using the project's gradle build.  But many tests cannot use these IDE-internal runners because they rely on values set by the gradle build (particularly system properties set in 'randomization.gradle').
The primary offender here is the directory factory setting, which is set as RAMDirectoryFactory in test configs, but is then  overridden by randomization.gradle to be 'MockDirectoryFactory' instead.
Solution
This commit pushes the randomization.gradle override into individual test-config files, so that tests will see the same "effective default" regardless of whether they're run by an IDE's runner or using the gradle build.
Tests
N/A - existing tests continue to pass
Checklist
Please review the following and check all that apply:

[x] I have reviewed the guidelines for How to Contribute and my code conforms to the standards described there to the best of my ability.
[x] I have given Solr maintainers access to contribute to my PR branch. (optional but recommended)
[x] I have developed this patch against the main branch.
[x] I have run ./gradlew check.

See this dev list thread for more context

I did a search for RAMDirectoryFactory in source code to look for other possible issues, and I see what may be a bigger challenge in org.apache.solr.SolrTestCaseJ4#initCore().
factoryProp = System.getProperty("solr.directoryFactory");
    if (factoryProp == null) {
      System.setProperty("solr.directoryFactory", "solr.RAMDirectoryFactory");
    }

Your change means that factoryProp is going to be null when previously it would not have been.  I suppose we can simply remove this?  I like that... but admittedly it means that tests that do not use the test files you refer to would previously have used MockDirectoryFactory but now will get RAMDirectoryFactory.  I suppose you'll just have to triage any failures with this in mind.

Since the issue I refer to is "initCore()"; it's old tests that extend STCJ4, most new ones don't (or shouldn't) use initCore().

As I read things the factoryProp == null branch is dead code on main/branch_9x, since randomization.gradle sets that prop on all builds?
I think you're right that with the PR as it stands, any tests that don't use the configsets would now be getting RAMDirectoryFactory, when they didn't previously.  In that case maybe the thing to do here isn't to delete the conditional outright but to tweak it so that it sets the same default (i.e. MockDirectoryFactory) as the configs.

Agreed Jason.

In that case maybe the thing to do here isn't to delete the conditional outright but to tweak it so that it sets the same default (i.e. MockDirectoryFactory) as the configs

Actually, let's simply delete this; one less potential moving part / layer for where this might be set.  It should be enough to ensure all our test configs refer to MockDirectoryFactory.
I suppose there's a case for RAMDirectoryFactory, which is performance (faster running tests; less disk thrashing).  Albeit some tests need persistence, obviously.  But I'm unsure how to balance that with MockDirectoryFactory.  The safe bet is certainly MockDirectoryFactory.

Actually it looks like removing the check in SolrTestCaseJ4.initCore() causes a number of tests to fail, mostly with SecurityManager-related exceptions.
Taking SolrCoreTest.testCoreInitDeadlockMetrics as an example, it uses core/src/test-files/configsets/minimal/ to create a core.  The relevant directoryFactory config there is:
  <directoryFactory name="DirectoryFactory"
                    class="${solr.directoryFactory:solr.NRTCachingDirectoryFactory}"/>

As things stand on 'main'/'branch_9x' currently, the gradle randomization ensures that solr.directoryFactory is always set to be MockDF, so the "default" value in this snippet doesn't ever come into play.  But in the most recent iteration of this PR neither randomization.gradle nor SolrTestCaseJ4.initCore() set a default dirFactory, so the test will start using NRTCachingDirectoryFactory and fail as a result.
I'm gonna try to go through and update the dirFactory default to MockDF in 'minimal' and some of these other lingering configsets, in the knowledge that these solrconfig.xml defaults were all being overridden by the randomization.gradle logic anyways.  But if I run into any issues I might rollback and put the SolrTestCaseJ4.initCore() back in place...

Nevermind; all is well.
I looked closer at MockDirectoryFactory, which calls LuceneTestCase.newDirectory which usually uses a memory based directory (ByteBuffersDirectory) and sometimes wraps with NRTCachingDirectory, albeit "rarely".  And we have lots of SolrCloud tests using NRTCachingDirectoryFactory so even the factory is getting tested.


Missing equality comparisons in Errors.swift for ProcedureKitError.Context?

Some of the Context enum cases are not currently handled explicitly in
public static func == (lhs: Context, rhs: Context) -> Bool

I haven't yet figured out exactly what to change - but before v4 is final, there needs to be a bit of an overhaul/refactor of ProcedureKitError.


16-puzzle added

PR Description 📜
i have added 16_puzzle game added
i have added html,cs,js file and added game entry in readme,json,images
Fixes #3878

Mark the task you have completed ✅

[x] I follow CONTRIBUTING GUIDELINE & CODE OF CONDUCT of this project.
[x] I have performed a self-review of my own code or work.
[x] I have commented my code, particularly in hard-to-understand areas.
[x] My changes generates no new warnings.
[x] I have followed proper naming convention showed in CONTRIBUTING GUIDELINE
[x] I have added screenshot for website preview in assets/images
[x] I have added entries for my game in main README.md
[x] I have added README.md in my folder
[x] I have added working video of the game in README.md (optional)
[x] I have specified the respective issue number for which I have requested the new game.

Add your screenshots(Optional) 📸

Thank you soo much for contributing to our repository 💗

@kunjgit  please review it
if everything is well,
and make sure you assign me this PR and add labels so that no conflict occure in future
thank you

/assign

Thank you  @Yashgabani845 , for your valuable time and contribution in our GameZone 💗.
It’s our GameZone, so Let’s build this GameZone altogether !!🤝
Hoping to see you soon with another PR again 😇
Wishing you all the best for your journey into Open Source🚀


Be able to remove contact

Recommendation from user

Might be time to give some love to user screen.


Registry Contract

Problem
The Registry contract should be implemented to spec: https://spec.projectliberty.io/Identity/Registry
link to Pivotal Tracker #12345678
Solution
We implemented the registry contract. In order to test authorization we also added a TestDelegation contract. This may eventually be replaced with an Identity contract.
This does not yet contain EIP 712 methods.
Change summary:

Introduce IRegistry interface.
Implement IRegistry.registermethod.
Implement IRegistry.changeAddressmethod.
Implement IRegistry.changeHandlemethod.
Introduce IDelegate interface (required to authorize)
Introduce BasicDelegate contract just for testing.
Test all methods.

Steps to Verify:

Run tests and ensure they pass.
Inspect code?

beautiful 👍


fixing typo

there are still typos in the files in the parser/output... I am not sure how to add commits to here(commit+PR from the web)

Ok, I will send a PR soon

https://github.com/raysan5/raylib/pull/2749


getting simulation warning with xrun

UVM_INFO ./src/riscv_asm_program_gen.sv(275) @ 0: reporter [asm_gen] Randomizing call stack..done
instr_list = {instr_list[0:idx-1], new_instr, instr_list[idx:current_instr_cnt-1]};
|
xmsim: *W,RTSVQR (./src/riscv_instr_stream.sv,100|29): improper part-select index expression ordering for queues.

won't
instr_list.insert(idx, new_instr);
work as a fix for this problem?

and for 1st case just
if (replace)
...
instr_list[idx] = new_instr;
else
instr_list.insert( ...

new_instr is a dynamic array, cannot use insert for this.


Intermittent "H5Fget_obj_count(): not a file id" - finalizer bug?

The shortest code to trigger this would be to have
using HDF5, JLD
file = jldopen("/tmp/mydata.jld", "w")

in a file and run julia on it. Easier to try/reproduce is via:
julia -e "using HDF5, JLD; jldopen(\"/tmp/test.jld\",\"w\")"

In about every second invokation it yields
HDF5-DIAG: Error detected in HDF5 (1.8.13) thread 0:
  #000: H5F.c line 442 in H5Fget_obj_count(): not a file id
    major: Invalid arguments to routine
    minor: Bad value

Tested on OSX, julia 0.3.4 with HDF5 1.8.13 from Homebrew.jl
From what I found in the issues it looks similar to  #95?

Wow, this was impressively fast! Thanks a lot!


Don't start another daemon process from launcher when the first one is not accessible

Partial fix for #12232
In some network configurations, it can happen that the daemon client can start a new daemon, but the new process cannot be connected. The client, however, does not distinguish between new and existing daemon connections and performs retries. Since the retry limit is set to 100, the result is that the client spams the entire memory with inaccessible Gradle daemons.
The solution is to make the client know if a new daemon was started. If the connection fails in that case then the client does not do further retries. This is also the behavior of the single-use daemons.

@bot-gradle  test rFM

OK, I've already triggered ReadyForMerge build for you.

@bot-gradle help

@bot-gradle test QF

OK, I've already triggered QuickFeedback build for you.

@big-guy PTAL

@bot-gradle test QF

OK, I've already triggered QuickFeedback build for you.

@bot-gradle test rFM

OK, I've already triggered ReadyForMerge build for you.

@bot-gradle test rFM

OK, I've already triggered ReadyForMerge build for you.

@bot-gradle test rFM

OK, I've already triggered ReadyForMerge build for you.

@bot-gradle test and merge

Your PR is queued. See the queue page for details.

OK, I've already triggered a build for you.


Allow recommenders to submit decision for stage 2 (RR)

 Add option for recommender to issue a decision prior to in-depth review for Stage 2 submissions submitted for the first time


Add application tests

Q
A

Is bugfix?
❌

New feature?
❌

Breaks BC?
✔

Tests pass?
✔

Fixed issues
#105

Fixed phpunit config - remove filter section.
https://github.com/sebastianbergmann/phpunit/blob/master/ChangeLog-9.3.md#changed

👍


Fdem dcr dom

@sgkang I uploaded two scripts for you. Works from my SimPEG\Mag_Amplitude branch. There are few Static\Utils that needed and update.

Cool. Thx Dom! I'll try to run


My first pull request

Try out my first pull request back to the original forked repo :)

Hey @scisteffan —congrats on submitting your first ever PR, and for completing the beginning git course. I hope you found the course useful, and enjoyable.
If you weren't already using git for your code, hopefully this has inspired you to do so. I hope that you enjoy the "Mastering Git" video course as well—you'll soon be able to get git to bend to your will :)
You can now wear this #GitWarrior badge with pride—and Tweet your historic victory!

sam


Reporting bonus for Bug: not able to select text

Please pay @gadhiyamanan for reporting this bug. The bug was already fixed by reverting a PR.

Triggered auto assignment to @kevinksullivan (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details.

Bug0 Triage Checklist (Main S/O)

[ ] This "bug" occurs on a supported platform (ensure Platforms in OP are ✅)
[ ] This bug is not a duplicate report (check E/App issues and #expensify-bugs)

If it is, comment with a link to the original report, close the issue and add any novel details to the original issue instead

[ ] This bug is reproducible using the reproduction steps in the OP. S/O

If the reproduction steps are clear and you're unable to reproduce the bug, check with the reporter and QA first, then close the issue.
If the reproduction steps aren't clear and you determine the correct steps, please update the OP.

[ ] This issue is filled out as thoroughly and clearly as possible

Pay special attention to the title, results, platforms where the bug occurs, and if the bug happens on staging/production.

[ ] I have reviewed and subscribed to the linked Slack conversation to ensure Slack/Github stay in sync

@kevinksullivan Whoops! This issue is 2 days overdue. Let's get this updated quick!

Constant errors from upwork right now. Will try again tomorrow.

Sorry @gadhiyamanan just sent you an offer
https://www.upwork.com/jobs/~010c71b53924a0686b
Let me know when you accept


Add CSharp gitignore

Current dependencies on/for this PR:

main

PR #1   👈

PR #2

This stack of pull requests is managed by Graphite.


Patch all style errors in updateReadme.py

Just ran the following commands:
pip install flake8
flake8 updateReadme.py

There should be no output from this command if all style checks are fixed.
xref #298

Beauty.


[DOCFIX] Journal doc fix

alluxio-bot, merge this please

alluxio-bot, cherry-pick this to branch-2.5 please


Will nodeos main process ever be multithreaded?

I have tuned and tuned and tuned. It takes me 8+ hours to sync from the freshest snapshot I can get my hands on and 30min-1hr if I restart the server (less than 5 min down time). While the plugins are gloriously multithreaded, it seems to all pipe back in to the parent nodeos process and that becomes a bottleneck. Number of cores for syncing (and when live in production) obviously doesn't matter, so it's down to clock speed (and IPC?). I only have access to a Zen 2 AMD Epyc @ 3.3 GHz at the moment, so I am neutered. I have played with nearly all of the config options. I noticed increasing the fetch from 100 blocks to 500 actually decreases performance. It becomes bursty, but overall lower avg throughput. I have seen one config with 50 blocks per fetch, does that help? I am basically looking for the ultimate config ini for p2p syncing. I am not doing full history, yet, and cannot see that even being possible at this rate. When my server is behind the current head block I am only seeing 100-200 kibps, when I am fully synced it shoots up to 500 kibps. It seemed like the p2p nodes were just rate limiting me or saturated, but then it became clear it is probably my CPU.
I saw one comment on my deep dive through the issues that the main process will never be multithreaded, but I would like to know if that is true.

I am basically looking for the ultimate config ini for p2p syncing

A few I would recommend:

2.0.x: make sure you're set to wasm-runtime = eos-vm-jit, this is default in 2.1.x
use eos-vm-oc-enable = true, at least while syncing/catchup and maybe always depending on your node type
if you've got 8+ cores set eos-vm-oc-compile-threads = to something greater than 1, like maybe 2 or 3. This setting has diminishing returns but if you have a lot of free cores dial it up higher.
set chain-state-db-size-mb =  to something larger than the state of the chain you're following, but no more than 4GB of physical RAM, and make sure it's a multiple of 1024MB. I realize this is a tough number to dial in, and this will hopefully be improved in future versions.
Reserve enough 1GB hugepages to match the setting you gave to chain-state-db-size-mb. This might be something like echo -n 32 > /sys/kernel/mm/hugepages/hugepages-1048576kB/nr_hugepages but you'll need to confirm the kernel was able to reserve so much continuous memory by reading the value back. Set it on boot command line for highest success rate.

2.0.x: set database-hugepage-path = to a 1GB hugetlbfs mount and then set database-map-mode = locked
2.1.x: set database-map-mode = heap (no need for hugetlbfs any longer)

Reduce the number of peers you're connected to. Particularly for syncing/catchup IMO it's better to be connected to a couple good peers vs. having 1 or 2 slow peers out of 10 connections.

I saw one comment on my deep dive through the issues that the main process will never be multithreaded, but I would like to know if that is true.

2.1 is leaps and bounds faster than 1.0, and we haven't exhausted our list of potential performance improvements yet.

Thank you so much. This was exactly the info I was looking for. I will try these settings and report back.

Syncing like an absolute beast now! But also I upgraded to a Zen 3 @ 4.7 GHz. Only take minutes instead of hours. Thanks!


Change file extension when converting format

Currently, file extension stays the same on conversion to a different format. This is a bad behavior and should be fixed.

Hi @Razunter. What do you mean by file extension? I believe handler sends the right meme and we are not sending any other header about file name or extension.

Hm… I've meant generation urls always end in the original file extension, and it causes confusion: avif-wepb etc. still end up with urls looking like they are wrong extension. Like in the docs: http://localhost:3000/embed,f_webp,s_200x200/static/buffalo.png. It's webp, but it looks like png since url ends with png.

I can understand DX issues but we cannot change the last part as it has to directly map to the source id. Without the extension, we don't know what is an original file path. I'm closing this issue as cannot think of an easy possible solution but please ping to reopen if you have an idea without changing signature and dropping source extension.

Though it may not be a clever solution, how about appending the converted file extension so that we can both keep mapping relation while still having the browser to pick up the right file extension.
Example:
Original file @/static/buffalo.png becomes /f_webp/static/buffalo.png.webp


Add broadcasting for rank 6 Tensors

As per @aselle's comment in #14924, this bumps up the broadcasting dimension limit of Tensors from 5 to 6.
I'm making this pull request to make it easy to merge this change if it is wanted; perhaps it is not wanted.

Can one of the admins verify this patch?

I signed the CLA.

@aselle can you check whether we want this? I assume yes, but you may have more context.

@aselle WDYT?

Nagging Reviewer @aselle: It has been 41 days with no activity and the awaiting review label was assigned. Can you please take a look?

Should we close this just to get the notifications to go away? It's probably a design choice that tensors sometimes only broadcast until 5 dimensions.
I'm going to close this, and if you disagree just open it again.


Reuse LocalAlluxioCluster to speedup CLI tests

This speeds up the cli integration tests, by reusing the LocalAlluxioCluster throughout each test class. This avoids tearing down and recreating the cluster between each individual test case. When a new cluster configuration was required, a new test class was created and those test cases were moved into the new file.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/7392/
Test FAILed.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/7395/
Test FAILed.

Jenkins, test this please

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/7432/
Test FAILed.

Jenkins, test this please

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/7433/
Test FAILed.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/7437/
Test FAILed.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/7441/
Test FAILed.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/7459/
Test FAILed.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/7460/
Test FAILed.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/7461/
Test FAILed.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/7464/
Test PASSed.

Jenkins, test this please

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/7467/
Test FAILed.

Jenkins, test this please

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/7475/
Test PASSed.

Jenkins, test this please

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/7476/
Test PASSed.

Jenkins, test this please

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/7478/
Test FAILed.

Jenkins, test this please

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/7480/
Test PASSed.

Jenkins, test this please

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/7483/
Test PASSed.

Jenkins, test this please

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/7485/
Test FAILed.

Jenkins, test this please

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/7489/
Test PASSed.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/7490/
Test PASSed.

Jenkins, test this please

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/7492/
Test PASSed.

Jenkins, test this please

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/7495/
Test PASSed.

Jenkins, test this please

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/7497/
Test PASSed.

Jenkins, test this please

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/7501/
Test PASSed.

Jenkins, test this please

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/7503/
Test FAILed.

Jenkins, test this please

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/7504/
Test PASSed.

Jenkins, test this please

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/7509/
Test FAILed.

Jenkins, test this please

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/7510/
Test PASSed.

Jenkins, test this please

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/7511/
Test FAILed.

Jenkins, test this please

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/7512/
Test PASSed.

Jenkins, test this please

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/7546/
Test PASSed.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/8219/
Test PASSed.

flaked tests:
Flaked tests:
alluxio.client.cli.fs.JobServiceFaultToleranceShellTest.distributedMv(alluxio.client.cli.fs.JobServiceFaultToleranceShellTest)
  Run 1: JobServiceFaultToleranceShellTest.before:52 » IO java.util.concurrent.TimeoutE...
  Run 2: PASS

alluxio.server.ft.journal.JournalBackupIntegrationTest.backupRestoreMetastore_Rocks(alluxio.server.ft.journal.JournalBackupIntegrationTest)
  Run 1: JournalBackupIntegrationTest.backupRestoreMetastore_Rocks:127->backupRestoreMetaStoreTest:519 » Alluxio
  Run 2: PASS

alluxio.server.tieredstore.SpecificTierWriteIntegrationTest.midTierWrite(alluxio.server.tieredstore.SpecificTierWriteIntegrationTest)
  Run 1: SpecificTierWriteIntegrationTest.midTierWrite:166->writeFileAndCheckUsage:117 » IO
  Run 2: PASS

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/8514/
Test PASSed.

@ZacBlanco

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/8573/
Test FAILed.

jenkins, test this please

Test failure is unrelated to any of the CLI tests being modified

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/8590/
Test PASSed.

alluxio-bot, merge this please


History.isTraditionalAnchor does not work properly

Hello guys.
I have an issue with latest History.js 1.8b2. The problem is with URLs with params. For example if we push /catalog, then everything works find, but if we push /catalog?title=Apple' then History.isTraditionalAnchorreturnsfalseand inHistory.getShortUrl ./` is not added to the start of the URL.
After this you got an URL like this http://<IP_ADDRESS>:3000/#catalog?brand=Cheetah instead of http://<IP_ADDRESS>:3000/#./catalog?brand=Cheetah. All seems to continue to work right, but URL is confusing.
In previous versions of History.js there was no History.isTraditionalAnchor. Why do we need it?
Thanks.

Any news on this issue ?


Set timeout for http.Client

Used a default of 100 seconds for the timeout.  This is the same value
as what c# uses by default. I didn't find any other good default.
Make annotation_tasks_install.go use the common function instead of
defining it's own.
Fixes #1514
Changes

Submitter Checklist

[ ] 📝 A good commit message is important for other reviewers to understand the context of your change. Please refer to How to Write a Git Commit Message for more details how to write beautiful commit messages. We rather have the commit message in the PR body and the commit message instead of an external website.
[ ] ♽ Run make test before submitting a PR (ie: with pre-commit, no need to waste CPU cycle on CI. (or even better install pre-commit and do pre-commit install in the root of this repo).
[ ] ✨ We heavily rely on linters to get our code clean and consistent, please ensure that you have run make lint before submitting a PR. The markdownlint error can get usually fixed by running make fix-markdownlint (make sure it's installed first)
[ ] 📖 If you are adding a user facing feature or make a change of the behavior, please verify that you have documented it
[ ] 🧪 100% coverage is not a target but most of the time we would rather have a unit test if you make a code change.
[ ] 🎁 If that's something that is possible to do please ensure to check if we can add a e2e test.
[ ] 🔎 If there is a flakiness in the CI tests then don't necessary ignore it, better get the flakyness fixed before merging or if that's not possible there is a good reason to bypass it. (token rate limitation may be a good reason to skip).

Why do you not use http.Client Timeout?
Also this case would not be covered by this PR?

We used to do this but we have this linter now:
https://github.com/sonatard/noctx
they have reasoning why ctx timeout is better... (but i am not a total expert on that so would not be able to argue)
the code in there https://github.com/openshift-pipelines/pipelines-as-code/blob)/a43138b10818661de41550fcd71aa24c165cfafd/pkg/matcher/annotation_tasks_install.go#L109-L120
is using the Clients.HTTP as defined with timeout

Using both http.Client Timeout and ctx in the request is also good.
https://github.com/openshift-pipelines/pipelines-as-code/blob/0971fd894f3edc1f3658d89e3cd90e6d976caf4f/pkg/matcher/annotation_tasks_install.go#L110C32-L110C32
But this does not handle timeout on http request? only on dial defined in the http.Client or does this ctx have a timeout that i'm missing passed to it?

lgtm


Loading screen - fix the text "estimated time"

Please fix the text.
It should be Estimated time, not estimate (this screenshot from design)

To define UI for loading screen we use "loading.qml" file. You can find it in "[your path]\beam-ui\ui\view\loading.qml".
Firs step is to find "broken" string. Search in "loading.qml" was unsuccesfull.
But we see that "broken" string betwen "Loading wallet..." text label and progress bar.
After serching for "Loading wallet..." we found a code that responsible for this message

Text for this message provided by "viewModel.progressMessage".
Id "viewModel" defined at this file as instance of "LoadingViewModel".
In "[your path]\beam-ui\ui\ui.cpp" registered all custom qml types that Beam use.
And "LoadingViewModel" registered as
qmlRegisterType<LoadingViewModel>("Beam.Wallet", 1, 0, "LoadingViewModel");
C++ class LoadingViewModel defined in "[your path]\beam-ui\ui\viewmodel.loading_viewh" and implemented in "[your path]\beam-ui\ui\viewmodel\loading_view.cpp"
"viewModel.progressMessage" defined as:
Q_PROPERTY(QString progressMessage READ getProgressMessage WRITE setProgressMessage NOTIFY progressMessageChanged)
Implementation for setter and getter:
const QString& LoadingViewModel::getProgressMessage() const
{
    return m_progressMessage;
}

void LoadingViewModel::setProgressMessage(const QString& value)
{
    if (m_progressMessage != value)
    {
        m_progressMessage = value;
        emit progressMessageChanged();
    }
}

"setProgressMessage" called from "void LoadingViewModel::updateProgress()" method
And we see that this method responsible for generation progress message string.
By this 2 lines generates translated string with placeholder.
//% "Estimate time: %s"
QString estimateStr = qtTrId("loading-view-estimate-time");

You can read about function "qtTrId" in official qt documentation.
https://doc.qt.io/qt-5/qtglobal.html#qtTrId
To fix this issue we nead just edit comment
before:
"//% "Estimate time: %s""
after:
"//% "Estimated time: %s""
After cmake configuring and generating done all translation files will updates.
You can find translation files in:
"[your path]\beam-ui\ui\i18n"
In localized files you must find message with id "loading-view-estimate-time" and edit translation for your languages.
And delete property 'type="unfinished"', also you can remove tag "oldsource".
Enjoy.

'type="unfinished"' and "oldsource". I didnt see that for "ID "loading_view_estimate_time" when i searched

'type="unfinished"' and "oldsource". I didnt see that for "ID "loading_view_estimate_time" when i searched

Not related to this task, it is general recommendation.

Checked


video_player plugin: Update exoplayer to 2.14 for RTSP support

It would be great if the video_player plugin could upgrade exoplayer so that RTSP is supported.

See here for relevant info: https://exoplayer.dev/rtsp.html

flutter/plugins#3933

Closing as a duplicate of https://github.com/flutter/flutter/issues/18061


Bug in ResultListDo

There is a bug in s:ResultListDo:  exe .a:command -> exe a:command

Thanks for pointing this out! It's fixed in the master branch, now.


Please consider releasing source code to pypi

cfn-lint version: (cfn-lint --version)
0.7.3
Description of issue.
I am using a tool that requires the sources to be deployed to pypi along with the binaries

First time we've had this request, but not unreasonable.  I'm going to mark it as an enhancement while we look into it.

Thanks, much appreciated.

Should be covered with the new release (v0.8.3).  Let me know if you are still having issues.


Annotation Problems with release 2.0.1

Hello,
I tried the 2.0.1 version but it breaks with strictdi enabled. It seems that the js is no longer correctly annotated.
I tried to annotate it with the last release of ng-annotate but it didnt' work.
Has anyone experienced the same problem ?
Thanks

Hmm. You're the first one to report it, but I'm not sure how many people have upgrade to the 2.x or 3.x builds yet. They're still new.
At a glance, I'm not sure what's wrong. The built dist seems to have the correct bracket syntax.
Any ideas?

We have occurrences of
controller: function($scope) ...

and it should be
controller: ["$scope", function($scope) ...

like we had in 1.x.x
I'm not sure why ng-annotate doesn't work in this case. Maybe adding @ngInject comments can help

I've got a handle on this. Seems like I need to give ngAnnotate a bit of a nudge for some of my TypeScript classes, by way of an /* @ngInject */ comment. I'll try to get a release built and pushed out this evening for you.
By chance, do you need 2.x to be updated? Or would you be willing to upgrade to 3.x? (3.x is backwards compatible except for the change to radio fields.)

3.x should be good for me
Thanks for your reactivity !

Fantastic. :)
I'm still looking into it. Thought I'd fixed it but then some of my regressions failed and it had gotten late. I'll try to get a release out tonight or tomorrow. :)

I'm pleased to inform you that release 3.0.1 is out and should resolve your strict-di issues. :)
Thanks for reporting this. Please let me know if you encounter any other issues while upgrading.

Re-opening this issue because I may have noticed a problem with field-label, post release. Will report back with more soon.

Ok. My apologies for that. Resolved a minor fieldLabel issue with 3.0.2. You should now be good to go. I've updated the documentation site to also run with strict-di so that I'll notice this before releasing next time. :)


cannot download dataset by running script

Hi,
I would like to download the dataset by running the script. I followed the instruction and run the script as below.

./bin/run_hb.sh MRCPATH

But I didn't successfully download it.
I checked the data folder and found that there should be a script download_hpatches.sh, but I can not find it. Could you please help me this?

Hi, please find the updated instructions on the main hpatches-benchmark repository.


Source from GitHub tarball (from #105)

Checklist

[x] Used a personal fork of the feedstock to propose changes
[x] Bumped the build number (if the version is unchanged)
[ ] Reset the build number to 0 (if the version changed)
[x] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[x] Ensured the license file is being packaged.

Is this PR actually using go at all? I don't see anything in the logs.

Is this PR actually using go at all? I don't see anything in the logs.

I found out that it is not required for this W&B version, sorry.
Ready for review

Shouldn't this stay noarch? Isn't any compilation coming in in the next version?

At this point yes, you're right!

Thank you so much for your work on this @flferretti 🙏🏽!  This will unblock a bunch of our open-source projects that rely on a conda package of W&B.

Can I please request the code owners to approve and merge this MR, assuming all the issues are resolved?

@xhochy @synapticarbors friendly ping. Thanks!

I believe setuptools is correct for 0.16.6.


Feature Request: Obey MaxDepth in SerializeObject()

It would be helpful if MaxDepth worked on SerializeObject() as well, not just Deserialize().
Currently, you can use MaxDepth to stop the serializer from deserializing anything past a given depth on the initial object(s). But, you can't currently tell it to only serialize down to a certain depth.
Additionally, it appears that the normal behavior of MaxDepth is to throw an exception, which is not desirable. It would help if there was a way to tell it to simply serialize/deserialize down to MaxDepth and stop. An exception is undesirable behavior in many circumstances.
A good example of where this is useful is on an Entity Framework database with LazyLoading enabled and virtual properties throughout. SerializeObject(user, new JsonSerializerSettings { MaxDepth = 0 }); would be useful for containing JSON serialization to just the user and their FK Ids. Without MaxDepth, JsonConvert is going to dutifully serialize most or all of the entire database.
I'm happy to write this feature if people are interested in it.

Hi, does json.net support this feature now?

I'd be interested in MaxDepth setting (on JsonSerializerSettings and JsonSerializer)  working for JsonConvert.SerializeObject(). Ideally it would work for all overloads (The initial overload I'm specifically interested in using it for is: JsonConvert.SerializeObject(object?, JsonSerializerSettings).
A starting point would be to have the serialization behavior mirror existing deserialization behavior (i.e. throwing exception if that's correct per @b9chris observation).
A second level of enhancement could have both serialization and serialization that respects MaxDepth with options on what to do when MaxDepth is exceeded. It could be similar to ReferenceLoopHandling setting,but in this case with just Error (default/existing) or Ignore options.

I've same problem, when serializing at 2nd depth i get error. Any workaround to solve this problem?
Found an old solution but not sure if can be done in another way
https://stackoverflow.com/questions/10453127/how-to-serialize-or-deserialize-a-json-object-to-a-certain-depth-in-c

I really need this too for logging purposes. My log messages are huge :/

How is this not fixed? Everyone who has set this expects a certain behavior and isn't getting it.

@b9chris we (The World) are very interested! Please go ahead! Thanks for your contribution.

I really need this too for logging purposes. My log messages are huge :/

did you find any work around for this issue. I'm logging all updates (CUD) and navigation properties are also getting serialized making the log size huge.

did you find any work around for this issue.

Yes but it's not pretty. I had to create my own JsonConverter and pass it to JsonConvert.SerializeObject.
For my use case, I wanted to log the contents of an object that contained data for executing a command or query, which I called the "Request" object:
var rawRequest = JsonConvert.SerializeObject(request, Formatting.None, new RequestJsonConverter(2));

And this is my RequestJsonConverter class:
/// <summary>
/// Converts the request object without any complex class property values included
/// </summary>
private class RequestJsonConverter : JsonConverter
{
    private readonly int _depth;

    public RequestJsonConverter(int depth)
    {
        _depth = depth;
    }

    public override bool CanRead => false;

    public override bool CanConvert(Type objectType) => true;

    public override void WriteJson(JsonWriter writer, object value, JsonSerializer serializer)
    {
        var jObject = new JObject();
        var requestProperties = value.GetType().GetProperties();
        RequestJsonConverter nextConverter = null;

        foreach (var prop in requestProperties)
        {
            if (_depth <= 0)
            {
                continue;
            }

            try
            {
                var propValue = prop.GetValue(value);
                if (!prop.PropertyType.IsPrimitive &&
                    !prop.PropertyType.IsValueType &&
                    prop.PropertyType != typeof(string))
                {
                    if (propValue is null || _depth <= 1)
                    {
                        continue;
                    }

                    nextConverter ??= new RequestJsonConverter(_depth - 1);
                    var serializedPropValue = JsonConvert.SerializeObject(propValue, Formatting.None, nextConverter);
                    jObject.Add(prop.Name, serializedPropValue);
                }
                else
                {
                    jObject.Add(prop.Name, propValue.ToSafeString());
                }
            }
            catch
            {
                // ignored - property getter might have thrown an exception so skip it.
            }
        }

        jObject.WriteTo(writer);
    }

    public override object ReadJson(JsonReader reader, Type objectType, object existingValue, JsonSerializer serializer)
        => throw new NotImplementedException("Unsupported");
}


Feature request: config which items should be sent to mqtt

Describe the solution you'd like
Should be possible to choose which items mqtt exposes

Any particular reason why you need that? Do you want to disable existing topics or expose new topics?

Expose new topics :-)

Ok. It'd be easier If you could explicitly name the topics you need here: #182

ok. I do that


Make sure decode_pushnum is private (pub(crate))

In #2989 we made decode_pushnum public while moved stuff to primitives - make sure it is private before releasing primitives v0.100.0.

Turns out this wasn't possible. We still use decode_psuhnum in rust-bitcoin.


Support basic version control

This patch adds the ability to go back to previous versions of a document. As we start working on a solid foundation for storing changes to markdown files we want to ensure that users don't loose any data. This simple feature allows to store multiple versions of a document and load it back at any point in time.
Demo:

Possible improvements:

rather than connecting the document to the local file system path we can also use Git information to make it even more flexible and allow reviving content made on other machines but on the same project in the same file

@sourishkrout I update the code to reflect the following behavior:

if file is version controlled by git the save operation is executed based on implementation of #57
if file is not version controlled and runme.feature.versionHistory setting is disabled, it throws an error message
if file is not version controlled but runme.feature.versionHistory is enabled, save operation is executed

See example here:

As version controlled I consider:

workspace directory has a .git folder
git ls-files --error-unmatch ./path/to/file is not failing

I'm getting this with an untracked test.md. Why not use the builtin git extension?

I'm getting this with an untracked test.md

As this file is not tracked into the repo, the error is expected. If our save mechanism fails, the user would loose their data.

OK I think I'm following... but shouldn't the error message be the same as in your screenshot?

Why not use the builtin git extension?

IMO too much overhead for a simple check like this.

👌
PS: Can we also remove the recommendation to change the setting from the message and say "please git track" it?

PS: Can we also remove the recommendation to change the setting from the message and say "please git track" it?

What is the point of having the work around then if we mention it no where? Shall we remove it?

but shouldn't the error message be the same as in your screenshot?

Good catch, fixed it.


More option for "az storage blob list --container-name "

az storage blob list --container-name
This command only shows item from oldest to newest. Please add option to get the list from newest to oldest. If my container has too many items, it will create a huge string of json in my code. The option --num-results also only returns string from oldest to newest. Meanwhile, I only needs few recently items and those are only at the end of the list. Please note that --prefix doesn't help at all.

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

ID: 472d5f5f-3ce0-1220-3058-4b27068f512b
Version Independent ID: 76e1699e-e6ba-c0dd-aad4-c5a7ab58260d
Content: az storage blob
Content Source: src/azure-cli/azure/cli/command_modules/storage/_help.py
Service: storage
GitHub Login: @rloutlaw
Microsoft Alias: routlaw

add to S170

add to S172


ENH - (Windows) Support aas_expandpathbyvars for Windows

Currently aas_expandpathbyvars does nothing on Windows. Thus paths in the xml cannot use environment variables like %APPDATA%.
Should path expansion also be supported on Windows? Does need to take into account also #288
The subfunction expandind would change from
ind = sort([strfind(x,'$'),strfind(x,'`')]);

to e.g.
if ispc()
    % Even more unsafe than on non-pc, since % is likely to be found in formatting expressions
    ind = sort(strfind(x,'%'));
else
    ind = sort([strfind(x,'$'),strfind(x,'`')]);
end

It is not a core goal but is worth noting as a TODO for later.
However, it seems you, @AljenU,  have already found a clever solution. :)

It basically works indeed. However, because the % is also used a lot in printf formatting statements, there is even more chance of accidental replacements (#288). Thus i would be more comfortable if there were some improvements for #288

How about using $ for Windows, as well. I know it is not a direct mapping and might be a little confusing for the users, but some explicit documetation would help for sure.

On windows, there needs to be a % at the start and at the end of the environment variable that is to be replaced. So the analogy with the unix case would get even more confusing.
And to deviate from standard conventions should have a really good reason, since it is easy to accidentally fall back to default behaviour, which would then lead to errors.
I did just add some idea for fixing #288, in which case it would also be ok to enable this one with the easy change from the starting comment.


It seems use command line client will cost more time than curl mode.

It seems use command line client will wait more time than curl mode. For example:
cht.sh java :learn

vs
curl cht.sh/java/:learn

How can I reprodruce it?
Do you have this problem still?
$ time cht.sh java :learn > /dev/null

real    0m0.100s
user    0m0.004s
sys     0m0.004s
$ time curl -ks https://cht.sh/java/:learn > /dev/null

real    0m0.099s
user    0m0.004s
sys     0m0.004s

I cannot reproduce it. Close it.


Let instrumenting transformer use the cross version file locking protocol

As most (if not all) flaky test failures seem to happen when running the cross version tests.

@bot-gradle test and merge

Your PR is queued because #16810 is being built.

OK, I've already triggered a build for you.

Pre-tested commit build failed.


Sacred not compatible with ptvsd (the debugger used in VS Code)

When debugging a sacred experiment with Visual Studio Code, which uses the ptvsd debugger, the debugger crashes at the first breakpoint inside the experiment.
So everything before the ex.automain decorated function works fine and breakpoints work. However, as soon as reaching a breakpoint inside the main function, the debugger crashes.
Specifying the -d flag doesn't make a difference.
Example code:
from sacred import Experiment

ex = Experiment("test") # Breakpoint here works fine

@ex.automain
def main_function():
    print(1)
    print(2) # Breakpoint here crashes
    print(3)

Leads to following output with breakpoint at print(2)
env "PYTHONIOENCODING=UTF-8" "PYTHONUNBUFFERED=1" "PYTHONPATH=<home>/.vscode/extensions/ms-python.python-2018.8.0/pythonFiles/experimental/ptvsd" <home>/.pyenv/versions/anaconda3-4.3.0/bin/python -m ptvsd --host localhost --port 59042 <path_to_file>/test.py -d
cd <path_to_file> ; env "PYTHONIOENCODING=UTF-8" "PYTHONUNBUFFERED=1" "PYTHONPATH=<home>/.vscode/extensions/ms-python.python-2018.8.0/pythonFiles/experimental/ptvsd" <home>/.pyenv/versions/anaconda3-4.3.0/bin/python -m ptvsd --host localhost --port 59042 <path_to_file>/test.py -d
Backend TkAgg is interactive backend. Turning interactive mode on.
INFO - test - Running command 'main_function'
INFO - test - Started
1
Tcl_WaitForEvent: Notifier not initialized
[1]    45315 abort      env "PYTHONIOENCODING=UTF-8" "PYTHONUNBUFFERED=1"   -m ptvsd --host localhost

(where I shortened file paths with <...>)
On MacOS Sierra with the newest Visual Studio Code.
Edit: Python 3.6 (Anaconda)

This is troubling, and I currently don't have any idea what could cause this behavior. If you find any further hints, please let me know.


New animated logo performance regression

The zowe.org logo update in https://github.com/zowe/zowe.github.io/pull/873 caused a performance regression, because it is the second biggest asset loaded, slowing the page load down on slow connections.
Slow connection performance is important. You may view zowe.org on a hotel or conference wifi that is unbearably slow. You do not want to make the experience worse for first-time viewers.

You can simulate the performance in dev tools by selecting "3G", as I did.
You will notice that the animation doesn't even animate well, due to its slow load.
This can be solved by optimization.
There is no reason to use an unoptimized GIF.
A simple fix is to convert it to APNG, a format supported by all browsers which is much more efficient. Example:

This could be mitigated by https://github.com/zowe/zowe.github.io/pull/874

note: to a lesser extent, medium.com gifs are also large so people should avoid them too, but they only show up when scrolling further down the page.

The medium.com needs to be done differently. I intend to get to it at some point, but otherwise closing as the PR is merged.


Forward HBase testcontainer's log to stdout to see whether #2458 is o…

…ccurring

Looks like this PR is triggering another issue in hase tests. Or maybe, it's part of the investigation ?

Looks like this PR is triggering another issue in hase tests. Or maybe, it's part of the investigation ?

Yes, see the last attempt


UI fixes for new ISM UI

Description

Adds isValid method to actions, implements logic, and sets on UI to show error state and disable buttons
Fixes update/create not showing error toaster when there is a failure
Fixes a bunch of the number type inputs from setting the value as NaN
Fixes the timeout/retry settings turning into uncontrolled inputs
Fixes allocation and rollup actions not being able to correctly save when edited and not edited.
A bunch of the UI inputs had text transform capitalize on them for some reason, probably from copy pasting from other components, removed them.
Adds default no conditions option in transition conditions
Fixes editing an action bug that instead adding a new action when switching the action type
Blocks creating a state if a state with that name already exists on UI
Removes unused rollover keys if they are not used
We were missing the UI for Allocation action, considering time just added simple JSON editor and we can go back and add a more friendly UI.
Removes X from top right of flyout
Removes flyout overlay and makes outside clicks not close flyout
Changes state flyout button from "X Close" to "Cancel"
Removes X icon from action/transition cancel button
Adds toolips for edit/delete icons for states, transitions, and actions
Removes underline when hovering states

Check List

[x] Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Codecov Report

Merging #84 (46dfbaa) into main (5f3b941) will decrease coverage by 0.41%.
The diff coverage is n/a.

:exclamation: Current head 46dfbaa differs from pull request most recent head 295b0b1. Consider uploading reports for the commit 295b0b1 to get more accurate results

@@            Coverage Diff             @@
##             main      #84      +/-   ##
==========================================
- Coverage   50.24%   49.83%   -0.42%
==========================================
  Files         154      154
  Lines        4221     4328     +107
  Branches      625      662      +37
==========================================
+ Hits         2121     2157      +36
- Misses       1950     2014      +64
- Partials      150      157       +7

Impacted Files
Coverage Δ

...mponents/EuiFormCustomLabel/EuiFormCustomLabel.tsx
85.71% <0.00%> (-14.29%)
:arrow_down:

...licy/components/UIActions/ReplicaCountUIAction.tsx
57.89% <0.00%> (-8.78%)
:arrow_down:

...reatePolicy/containers/CreateState/CreateState.tsx
50.53% <0.00%> (-1.79%)
:arrow_down:

...licy/components/UIActions/NotificationUIAction.tsx
3.44% <0.00%> (-0.90%)
:arrow_down:

...ntainers/VisualCreatePolicy/VisualCreatePolicy.tsx
13.27% <0.00%> (-0.62%)
:arrow_down:

...ges/VisualCreatePolicy/components/States/State.tsx
94.44% <0.00%> (ø)

...ualCreatePolicy/containers/CreateState/Actions.tsx
75.00% <0.00%> (ø)

...reatePolicy/containers/CreateState/Transitions.tsx
75.00% <0.00%> (ø)

...tePolicy/components/UIActions/ReadOnlyUIAction.tsx
0.00% <0.00%> (ø)

...tePolicy/components/UIActions/RolloverUIAction.tsx
50.00% <0.00%> (ø)

... and 14 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 5f3b941...295b0b1. Read the comment docs.


Fix printBackgrounds option name inconsistency

printBackgrounds was sometimes written with an s and sometimes not.

Was crashing electron when setting printBackounds to true.

Take a look at PR #2515. It seems it fixes the same problem.

@etiktin Indeed, but the documentation need to be updated as well then.

@nekuz0r
Looks like your PR only renames the JS option printBackground to printBackgrounds, which will make a breaking change.

printBackgrounds was sometimes written with an s and sometimes not.

Both the print and printToPDF API have a consistent printBackground option name, and the document are all mentioned the printBackground instead of printBackgrounds.

@hokein, there's one place in browser-window.md that does need fixing (notice the 's'):

By default, an empty options will be regarded as {marginsType:0, printBackgrounds:false, printSelectionOnly:false, landscape:false}.

The docs are inconsistent as they speak in one place about printBackground and in another about printBackgrounds so whatever you do to fix this bug is backwards incompatible for someone. I'd use printBackgrounds as it expresses the intent better and is in line with the original Chromium API:
https://github.com/atom/electron/search?utf8=✓&q=printBackground&type=Code
https://github.com/atom/electron/search?utf8=✓&q=printBackgrounds&type=Code

@hokein
https://github.com/atom/electron/blob/d455232eb14882a944b42c9ea6c93bd11becfdfe/atom/browser/api/lib/web-contents.coffee#L100
Condition uses printBackgrounds, assignation printBackground looks pretty inconsistent to me.
And more, this code can't work, if you set printBackground to true it will have not effect and if you set printBackgrounds to true then printingSetting.shouldPrintBackgrounds is undefined.

@etiktin @Janpot  @nekuz0r

https://github.com/atom/electron/blob/d455232eb14882a944b42c9ea6c93bd11becfdfe/atom/browser/api/lib/web-contents.coffee#L100
Condition uses printBackgrounds, assignation printBackground looks pretty inconsistent to me.
And more, this code can't work, if you set printBackground to true it will have not effect and if you set printBackgrounds to true then printingSetting.shouldPrintBackgrounds is undefined.

Indeed, it's a bug.
The printBackgrounds found in https://github.com/atom/electron/search?utf8=✓&q=printBackgrounds&type=Code is a typing error, and is fixed in #2515.
Officially, the APIs are required to use printBackground. No printBackgrounds is used.

Closing in favor of #2515, and thanks for finding this out!


Create code of conduct

Hello, I would like to work on this issue, could you assign it to me under LGMSOC21?


[Feature][Hotfix] Add observedGeneration to the status of CRDs

Why are these changes needed?
observedGeneration is a common pattern in Kubernetes to determine whether the current status is out-of-date or not.

Good article: Kubernetes operator best practices: Implementing observedGeneration

StatefulSet uses ObservedGeneration to determine whether update status or not.
// inconsistentStatus returns true if the ObservedGeneration of status is greater than set's
// Generation or if any of the status's fields do not match those of set's status.
func inconsistentStatus(set *apps.StatefulSet, status *apps.StatefulSetStatus) bool {
    return status.ObservedGeneration > set.Status.ObservedGeneration ||
  	  status.Replicas != set.Status.Replicas ||
  	  status.CurrentReplicas != set.Status.CurrentReplicas ||
  	  status.ReadyReplicas != set.Status.ReadyReplicas ||
  	  status.UpdatedReplicas != set.Status.UpdatedReplicas ||
  	  status.CurrentRevision != set.Status.CurrentRevision ||
  	  status.AvailableReplicas != set.Status.AvailableReplicas ||
  	  status.UpdateRevision != set.Status.UpdateRevision
}

However, this PR does not use observedGeneration to do anything because:

Currently, KubeRay lacks a well-defined strategy for updating the status of its resources. Furthermore, it's possible for multiple status updates to occur within a single reconciliation loop, which can lead to problematic patterns and outcomes.
As a result, merging a pull request that includes any changes related to status updates shortly before the release of v0.5.0 is very risky.

The main motivation for this PR is to unblock Shopify. Other works will be included in the release v0.6.0.
ObservedGeneration definition at this moment

ObservedGeneration in this PR only promises that ObservedGeneration <= Generation.
I did not promise any other behavior in this PR because there are a lot of code paths that will update the status and I do not check every path.

Test

We currently only have a test for RayCluster because we do not have tests with fake clients for RayJob and RayService at this moment. These should be done in the next release which we plan to focus on the stability of RayJob and RayService.

Related issue number
Hotfix for #916
Checks

[ ] I've made sure the tests are passing.
Testing Strategy

[x] Unit tests
[x] Manual tests
[ ] This PR is not tested :(

RayCluster

RayJob

RayService

cc @gariepyalex

Out of curiosity, is the ObjectMeta.Generation set by the user or is it autogenerated by the controller?

ObjectMeta.Generation is maintained by Kubernetes's APIServer. The field is a sequence number representing a specific generation of the desired state. Set by the system and monotonically increasing, per-resource. See this for more details.


DNM: debug extensions build

The extensions build that is run in the SCOS base container fails with:
[cosa-build : fetch-and-build] (rpm-ostree compose extensions:1): libdnf-WARNING **: 04:28:55.246: failed to setup monitor: Operation not supported
[cosa-build : fetch-and-build] error: Unknown rpm-md repository: baseos

This seems to come from:
https://github.com/GNOME/glib/blob/main/gio/gfile.c#L5680
via
https://github.com/rpm-software-management/libdnf/blob/dnf-4-master/libdnf/dnf-repo-loader.cpp#L553
The c9s.repo is indeed present and contains the baseos repo.
Note that this still pulls in rpm-ostree 2022.12, as 2022.13 is still gated behind c9s-gate, not sure how long packages have to wait there.

Filed https://github.com/coreos/rpm-ostree/issues/4029 for the monitor thing but that's just cosmetic, it's not the real issue.
The real issue is:

error: Unknown rpm-md repository: baseos

@cgwalters hm, is this not the monitor looking for *.repo files in the compose dir? How else would rpm-ostree know about the yum repos? As the logs show, the c9s.repo is present and defines the baseos repo. If the failed monitor is not the reason, why is it not picked up and what can we do to fix this?

What's the mounted filesystem here? Can you add a stat -f . here e.g.?  Are there any strict seccomp policies in play here?
Looking at the code it doesn't seem like inotify failing should be fatal, but maybe.
I think it's more likely that the .repo file isn't being found at all for some reason.  We could try to add some more debugging info to print out which repo files we loaded.

What's the mounted filesystem here? Can you add a stat -f . here e.g.? Are there any strict seccomp policies in play here?

Running a new build now, will post logs here

We could try to add some more debugging info to print out which repo files we loaded.

That would be very helpful indeed!

It's an OverlayFS
[1/3] STEP 7/7: RUN stat -f . && ls -al && cat c9s.repo && rpm-ostree compose extensions --rootfs=/ --output-dir=/usr/share/rpm-ostree/extensions/ {manifest,extensions}.yaml
  File: "."
    ID: f0528d92d52841ea Namelen: 255     Type: overlayfs
Block size: 4096       Fundamental block size: 4096
Blocks: Total: 2574551    Free: 1876684    Available: 1745612
Inodes: Total: 655360     Free: 584536

Full logs:
cosa-build.log

Somewhat related to this...I personally consider the extensions container stuff as a short term crutch specifically for RHEL/OCP.  The most load-bearing extension by far is kernel-rt but I want to do https://issues.redhat.com/browse/MCO-378 and then we could probably just disable extensions support via MachineConfig for OKD - anyone who wants to add custom content (usbgaurd, etc.) can build their own images in a fully supported and sane way.

That makes a lot of sense to me! Maybe in SCOS, instead of jumping through these hoops now, we could simply never ship the extensions image then. As of today we're not able to build it here anyway, and would thus have to disable it for the MVP release next week.

The pipeline will continue to attempt extension builds, but won't fail if unsuccessful. I've opened https://github.com/openshift/machine-config-operator/pull/3356 to remove the ext image ref from MCO for the time being.
I'm closing this PR. This work can be picked up elsewhere.

So we just now hit this in https://issues.redhat.com/browse/COS-2000 ...should have debugged it fully at the time :frowning:
Current status quo is that OKD/SCOS is still not shipping the extensions container?

Yes, unfortunately :(

We likely need https://github.com/coreos/coreos-assembler/blob/main/src/build-extensions-container.sh#L18 to copy the in-tree c9s.repo file too


Where is unity.h?

My project build and test without issue. But VS Code complain about cannot open source file "unity.h" What should I add to my include path so that VS Code can find it and give me IntelliSense for unity.h?

Hi, @rickymohk. Which version of Ceedling are you using—0.31.1 or 1.0.0-prerelease? We can guide you specifically knowing that.
The former tucks unity.h away in Ceedling's installation directory. The latter copies it into your build directory. If you increase verbosity in your build you can see unity.c's source path in the compilation. unity.h is in the same path.

I am using 0.31.1

First run ceedling clobber. Then ceedling verbosity[4] test:<one of your tests>. In the compilation output, look for unity.c being compiled. The path to unity.c is the same as to unity.h.

Got it. Thank you.


Change help url

URL displayed in help window now reflects the team's UserGuide instead of AB3 Default

PR didn't pass the checks (TIMEOUT error), but only made the url change as showed, so merged and closed PR anyway.


Add tags to all metrics

Logging this as a reopening of #67 -- I noticed the solution for that issue (examples/tag-view.rs) was removed in #133, is it no longer supported/doesn't work?
If so, is there another means of accomplishing this?

Hi,
It should still work. It was removed because I was feeling lazy and didn't want to update it along side changes to the Cadence API. I'd expect it's still a perfectly reasonable approach to add a common set of tags to metrics.

I guess one option that might make this easier is adding a new method to MetricBuilder that accepts a slice or hashmap of tags instead of just methods that require adding tags one-by-one. That would still require a wrapper ala examples/tag-view.rs in order to "stack" them but would cut down on the code required.

I'd like to add this functionality because my project is using cadence and it would be nice to add global tags. I was thinking of adding a with_tags option to StatsdClientBuilder, similar to how the Datadog Go library works.
Does that sound good @56quarters?

I'd like to add this functionality because my project is using cadence and it would be nice to add global tags. I was thinking of adding a with_tags option to StatsdClientBuilder, similar to how the Datadog Go library works.
Does that sound good @56quarters?

That sounds like a really elegant way to do it. Want to throw a draft PR up with a rough idea of what you're thinking of?

@56quarters yup, working on it!


Play 2.8 and @this

Hi.
I tried to inject
@import play.api.Play

@this(configuration: com.typesafe.config.Config)
@(error: Boolean)

<!DOCTYPE html>

into template to use it to obtain some information for footer. Problem is that compiled code results looks like
class login @javax.inject.Inject()@javax.inject.Inject() /*3.6*/(configuration: com.typesafe.config.Config) extends ...
@javax.inject.Inject()@javax.inject.Inject() is inserted twice - and I have no idea why. Could any one have idea what might cause it ?

@Finu I am pretty sure that is because you set
TwirlKeys.constructorAnnotations += "@javax.inject.Inject()"

in your build.sbt. Just remove that from your build.sbt.
You don't have to set this yourself when using Play. That's because Play sets it for you already. Only when using twirl without Play you have to set this yourself.

@Finu could you solve your problem?

@Finu closing for now. Feel free to re-open if you think you still ran into a bug.