Possible CMS 5 regression with global cache key

This was reported to us by @chrispenny
Is this potentially a regression? The issue is visible to me because I'm looping through Locales, but it's potentially a more generic issue of the global_key and/or <% cached %> wrapper behaviour when using SSViewer to render templates(?).
I have a template with a <% cached .. %> wrapper:

Debug CurrentLocale value: $CurrentLocale

<% cached $SiteConfig.CacheKey, 'Header' %>
    ... some localised links
<% end_cached %>

I have a global_key configuration defined that should mean the current locale is added to any <% cached %> wrappers by default:
SilverStripe\View\SSViewer:
  global_key: '$CurrentReadingMode, $CurrentUser.ID, $CurrentLocale'

There are 2 Locale in my application (Locale, URLSegment):
- Default: en_NZ, nz
- International: en_001, int

I then have a job that is looping through Locales and saving some HTML output to a file (cache related). Effectively:
foreach (Locale::get() as $locale) {
    FluentState::singleton()->withState(function (FluentState $state) use ($locale): void {
        $state->setLocale($locale->Locale);

        $viewable = ViewableData::create();
        $template = SSViewer::create(['Includes\Header']);
        $html = (string) $template->process($viewable);

        Debug::dump($html);
    });
}

First output:

en_001

  Contact Us

...

Second output:

en_NZ

  Contact Us

...

So, the $CurrentLocale (that is not cached) shows the correct/active Locale, but the cached content displays whatever was generated first.

Removing the <% cached %> wrapper results in the correct output for each iteration.
Flipping the iteration order (en_NZ first) results in both output having the en_NZ content.

I tried to look for where SSViewer::$global_key was used, and I found the following locations:

FileShortcodeProvider::getCacheKey()
SSTemplateParser::CacheBlock_CacheBlockTemplate()

I then added a bunch of var_dump()s in there to try and see what the value of global_key was, but I didn't get any output displayed when running my Job (but they are visible if I, say, just load a page regularly).
Before refining this

Validate if it breaks in CMS4 as well.
Validate if this is a fluent problem only, or if it affect framework caching
This is not a blocker for CMS5, but we probably want to fix it pretty quickly any way.

@maxime-rainville apologies, this didn't end up being quite as my original Slack message thought.
The issue ended up not being with the cached wrapper, but was actually related to some caching that seems to be happening within the request.
foreach (Locale::get() as $locale) {
    FluentState::singleton()->withState(function (FluentState $state) use ($locale): void {
        $state->setLocale($locale->Locale);

        // This line here seemed to solve the issue, but I don't really know why
        SiteConfig::flush_and_destroy_cache();

        $viewable = ViewableData::create();
        $template = SSViewer::create(['Includes\Header']);
        $html = (string) $template->process($viewable);

        Debug::dump($html);
    });
}

I don't reaaally understand why that works though, because the links that are being output are from things like $Menu(1), and other related Children() type links.


Update bundle annotations to include must-gather image

Since we have a must-gather image, we should advertise that information
through the bundle. We typically do this using RELATED_IMAGES, which
the operator uses to find container images it needs to do things like
profile parsing or scanning.
While we can use RELATED_IMAGES for the must-gather image, the
Compliance Operator doesn't use the must-gather image directly. Instead,
we can put it in the annotation of the bundle CSV, so it's still
discoverable to users, while not polluting the operator environment with
variables it doesn't need.

/test e2e-aws-parallel
We have some flakiness in our metrics tests that are causing failures, which has cropped up else where - https://github.com/ComplianceAsCode/compliance-operator/issues/302


Gene causal/non-causal info missing in response

Need to update the pydantic models to return it. Actually I will add a "metadata" field to several models to support this info rather than making a gene-association specific addition, that can also hold phenotype frequency info etc.

done via #47


feat(modal): modal header accessibility

This PR add accessibility for Modal header.
Description

Related Issue

Motivation and Context

How Has This Been Tested?

Screenshots:
Before (If applicable):

After:

Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] Documentation update
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] CI related changes
[ ] Other... Please describe:

Checklist:

[ ] My code follows the code style of this project.
[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[ ] I have read the CONTRIBUTING document.
[ ] I have added tests to cover my changes.
[ ] All new and existing tests passed.

opened another PR for same.


is_odd fails for negative numbers

The output of /version on my server is: This server is running Paper version git-Paper-65 (MC: 1.15.2) (Implementing API version 1.15.2-R0.1-SNAPSHOT)
The output of /version denizen on my server is: Denizen version 1.1.4-SNAPSHOT (build 4645-DEV)
(If relevant) A link to a paste of a script demonstrating the issue: https://one.denizenscript.com/paste/66175
https://one.denizenscript.com/haste/66176
The issue is:
The is_odd tag isn't evaluating locationtag.z tags correctly.

That title is ridiculous, I corrected it to be the actual issue title per looking at Discord discussion from the time when you posted this.


Implement stability indicators for PeerDetail to be appended to Peers.json

This should help with picking more stable peers over others, leading to better communication faster transaction forwarding, block mining, etc.

ALSO DOCUMENT THE PEER DISCOVERY STRATEGY

Documentation for peer discovery in progress : #20

Documentation for peer discovery completed as of #20


Corrupt zip archive created when album size is >4GB

Detailed description of the problem
The zip archive created using the download album button is corrupt when the (compressed) size of the album is >4GB.
Steps to reproduce the issue

Go into an album which is >4GB
Click on 'Download Album'
Try to extract the downloaded zip archive

Output when trying to unzip archive (on a 64bit Arch Linux machine):
$ unzip --help
UnZip 6.00 of 20 April 2009, by Info-ZIP.
$ unzip album.zip
Archive:  album.zip
warning [album.zip]:<PHONE_NUMBER> extra bytes at beginning or within zipfile
  (attempting to process anyway)
file #1:  bad zipfile offset (local header sig):<PHONE_NUMBER>
  (attempting to re-compensate)
checkdir error:  album.zip exists but is not directory
                 unable to process album.zip/DSC_6733.jpg.
...
checkdir error:  album.zip exists but is not directory
                 unable to process album.zip/DSC_8335.jpg.
file #381:  bad zipfile offset (local header sig):  3957486
  (attempting to re-compensate)
checkdir error:  album.zip exists but is not directory
                 unable to process album.zip/DSC_8336.jpg.
...

The exit status of unzip is 2.
I was able to recover the archive with (credits here):
$ zip -FF album.zip --out album_repaired.zip -fz

Output of the diagnostics
I know the version is moderately old, but I prefer not to update the running instance to test if the issue is still current.
    Diagnostics
    -----------
    Warning: Dropbox import not working. No property for dropboxKey.

    System Information
    ------------------
    Lychee-front Version:    3.2.14
    Lychee Version (git):    262dc31 (master) - Probably more than 30 commits behind master
    DB Version:              040000
    System:                  Linux
    PHP Version:             7.3
    MySQL Version:           8.0.16
    Imagick:                 1
    Imagick Active:          1
    Imagick Version:         1690
    GD Version:              2.2.5

    Config Information
    ------------------
    version:                 040000
    checkForUpdates:         0
    sortingPhotos_col:       takestamp
    sortingPhotos_order:     ASC
    sortingAlbums_col:       description
    sortingAlbums_order:     DESC
    imagick:                 1
    skipDuplicates:          0
    small_max_width:         0
    small_max_height:        360
    medium_max_width:        1920
    medium_max_height:       1080
    lang:                    en
    layout:                  1
    image_overlay:           1
    image_overlay_type:      exif
    default_license:         none
    compression_quality:     90
    full_photo:              1
    deleteImported:          1
    Mod_Frame:               0
    Mod_Frame_refresh:       30000
    landing_page_enable:     0
    landing_owner:           ---
    landing_title:           ---
    landing_subtitle:
    landing_facebook:
    landing_flickr:
    landing_twitter:
    landing_instagram:
    landing_youtube:
    landing_background:
    thumb_2x:                1
    small_2x:                0
    medium_2x:               0
    site_title:              ---
    site_copyright_enable:   0
    site_copyright_begin:    2019
    site_copyright_end:      2019
    additional_footer_text:
    display_social_in_gallery: 0

Browser and system

Lychee-Laravel-Docker at commit a300383f
Docker image bigrob8181/lychee-laravel dev (at 262dc31)
Docker image mysql v8.0

An album with >4GB of photos? You don't mess around. :wink:
The whole download feature went through an overhaul in commit 7ccd77f379be461d88b7c64a9047d865396f7628 (merged on July 11). Given that, it would be good to know if the problem is still present, though to be perfectly honest, I expect that it's still there.
We use a third party package for generating zip files and I expect the bug to be with them; I'll see if a newer version than the one we use mentions fixing such a problem...

Huh... By the look of it, upstream has it fixed at the price of losing compatibility with MacOS:
https://github.com/maennchen/ZipStream-PHP/commit/6cdd417699fe89cdc4925f4d6fd811f30b1628fd
We should probably upgrade but we'll need to add a config to either support 64bit zips or the native MacOS unarchiver...


Improve zenodo

The current zenodo record is automatically generated - it should be adjusted to show correct contributors, ...
https://zenodo.org/record/1283345#.WxpFIWMzY18

@cecileherr can you check this is correct?

Yep, allright!


Random reads on temps

I have exactly the same problem from "https://github.com/RobTillaart/MAX31855_RT/issues/19". All random readings from internal temp and thermocouple temp BUT ok with bitflags control.

NOTE: On this image, there is a flag, but when i say it give random temp data all flags is 0.
NodeMCU ESP32 <SPI(sw) 8cm wire lenght> MAX31855 (clone from ebay and cut T- and GND)
Arduino UNO <SPI(sw) 8cm wire lenght> MAX31855 (clone from ebay and cut T- and GND)
I have oscilloscope to check SPI readings (software) and i see good comms. I have tested ok bit flags from erros from the thermocouple (SHORT to GND, SHORT to VCC, no thermocouple). When i see the bits from rawdata and check with oscilloscope, the data match.
ESP32 dont work for me with SPI HW on VSPI nor HSPI.
Oh, i have tested with 3 clones from ebay, and 1 from aliexpress. All same problem.
I have questions:

I see on the oscilloscope the CLK inverted (VCC at start) and on the datasheet i see its GND at start. Anyway it take good data when fall CLK.
I see on oscilloscope that freq is 2Mhz with sw, and i dont know if it is need to reach 5Mhz.
Without thermocouple connected, the internal temp still works?

Thank you for your time :)

@jpsminix
I see only one explicit question Without thermocouple connected, the internal temp still works?
The answer is I never tried, as I have no hardware setup / time, I cannot test it.
From your description I understand that
software SPI is working for UNO
software SPI is working for ESP32
hardware SPI is working for UNO
hardware SPI is failing for ESP32 (both HSPI and VSPI)
Can you confirm?
(it will be at least the weekend before I have time to dive into this.

Hi, thank you to much for helping me
software SPI is working for UNO
software SPI is working for ESP32
hardware SPI is failing for UNO  (sorry for not write this before)
hardware SPI is failing for ESP32 (both HSPI and VSPI)
I have same setup on arduino for sw and hw SPI:
const int csPin   = 10;
const int clkPin  = 13;
const int dataPin = 12;

uint32_t start, stop;

MAX31855 tc(csPin);
//MAX31855 tc(clkPin, csPin, dataPin);  // sw SPI

And only change the last line to this to make sw SPI working:
//MAX31855 tc(csPin);
MAX31855 tc(clkPin, csPin, dataPin);  // sw SPI

I put some log with hw SPI:
16:51:59.675 -> time:		480
16:51:59.675 -> stat:		129
16:51:59.675 -> raw:		1111 1111 1111 1111 1111 1111 1111 1111
16:51:59.721 -> internal:	0.000
16:51:59.721 -> temperature:	nan
16:52:00.691 ->
16:52:00.691 -> time:		484
16:52:00.691 -> stat:		129
16:52:00.691 -> raw:		1111 1111 1111 1111 1111 1111 1111 1111
16:52:00.691 -> internal:	0.000
16:52:00.691 -> temperature:	nan
16:52:01.705 ->
I put some log with sw SPI:
16:52:42.680 -> time:		508
16:52:42.680 -> stat:		0
16:52:42.680 -> raw:		0111 1000 0011 1000 1001 1101 1101 0000
16:52:42.726 -> internal:	-98.188
16:52:42.726 -> temperature:	1923.500
16:52:43.699 ->
16:52:43.699 -> time:		508
16:52:43.699 -> stat:		0
16:52:43.699 -> raw:		0111 1100 0011 1100 1001 1101 1100 0000
16:52:43.699 -> internal:	-98.250
16:52:43.699 -> temperature:	1987.750
I have a pull up resistor ~2k between 5V and DO (MISO).
MAX31855 is connected to 5V (has a regulator to 3.3v the board).
This is a capture of oscilloscope of Arduino UNO, sw SPI, (pull up resistor 2k only on MISO) and MAX31855 (with LDO to 3.3v):

OK,  which time zone are you in EU  or USA?
Helps to know the moments we are both online, I am from the Netherlands (EU).
the first raw: 1111 1111 1111 1111 1111 1111 1111 1111   is definitely wrong
The SW SPI values are correct ? (just asking as 1923° seems quite high and -98° seems very low.
16:52:42.680 -> raw: 0111 1000 0011 1000 1001 1101 1101 0000
16:52:42.726 -> internal: -98.188
16:52:42.726 -> temperature: 1923.500

I am from Spain (EU).
The first raw it is beacuse hw SPI its not working (i dont see anything on the pins, CS/CLK/DO).
The SW SPI the values ar not correct, the are completely random. Internal temp can jump from -98 to 127 and then go to -127. Same with thermocouple. BUT the flags bits are correct. If i short the pins near GND to T- and VCC to T+, the flags are correct.
There is a big posibility that 4 MAX31855 that i have with same results maybe are faulty (all clones). But i would like to make it work with hw SPI.. maybe sw SPI is slow... (i dont think so because with sw SPI and ESP32 its pretty fast)... but i dont know what to check.

Have you tried e.g. Adafruits library?
Might help to check if it is in the hardware / wiring  or in the software.
If I find some time tomorrow I will setup a test environment, I hope I have all the HW needed.

I just installed now the adafruit MAX31855 v1.3 and configured for HW SPI with CS=10 with all same wires (nothing changed)
// Example creating a thermocouple instance with software SPI on any three
// digital IO pins.
//#define MAXDO   3
//#define MAXCS   4
//#define MAXCLK  5

// initialize the Thermocouple
//Adafruit_MAX31855 thermocouple(MAXCLK, MAXCS, MAXDO);

// Example creating a thermocouple instance with hardware SPI
// on a given CS pin.
#define MAXCS   10
Adafruit_MAX31855 thermocouple(MAXCS);

// Example creating a thermocouple instance with hardware SPI
// on SPI1 using specified CS pin.
//#define MAXCS   10
//Adafruit_MAX31855 thermocouple(MAXCS, SPI1);

The logs:
12:18:31.024 -> Internal Temp = 127.94
12:18:31.024 -> C = 639.00
12:18:31.992 -> Internal Temp = 127.94
12:18:32.038 -> C = 639.00
12:18:33.009 -> Internal Temp = 127.94
12:18:33.055 -> C = 642.25
12:18:34.024 -> Internal Temp = 127.94
12:18:34.024 -> C = 580.50
12:18:34.997 -> Internal Temp = 127.94
12:18:35.043 -> C = 646.50
12:18:36.013 -> Internal Temp = 127.94
12:18:36.059 -> C = 646.50
The oscilloscope view.. this confuse me a little (so much space on end of DO)

This is the same situation as before but with short T- to GND.

I think internal temp is broken on all my chips and its impossible to calculate the external temp without the reference of internal.
Thank you so much!

Is it correct that I to see that the clock is 5V and the dataline is 3V3 ?

I think internal temp is broken on all my chips and its impossible to calculate the external temp without the reference of internal.

I need to dive into the datasheet / code to confirm that

Maybe your sensor batch does not work at full frequency. I've heard such stories for other sensors before, that 2nd choice batches are sold cheaply.
(thinking out loud)
In my library you can patch the software timing by adding delayMicroseconds
search for     // delayMicroseconds(1);  // DUE
and in a similar way you can patch the hardware handshake too.  try e.g. 10 us per pulse.
Absolutely no guarantee it will work, at least it could be tested in a few minutes if the sensor works on lower frequency.

The gap in the scope picture might be an artefact of the library used. Then you should see it after every data exchange.

Is it correct that I to see that the clock is 5V and the dataline is 3V3 ?

Yes, you are correct but i dont know why, the pull up resistor is on the pin of the DO.

.
Another difference is that CLK line start from LOW with adafruit (hw SPI)

Im gonna test it. I will update with news.

I have changed the file MAX31855.cpp with this modification:
  else  // Software SPI
  {
    digitalWrite(_select, LOW);
    for (int8_t i = 31; i >= 0; i--)
    {
      _rawData <<= 1;
      digitalWrite(_clock, LOW);
      delayMicroseconds(10);   // DUE MODIFIED
      if ( digitalRead(_miso) ) _rawData++;
      digitalWrite(_clock, HIGH);
      delayMicroseconds(10);  // DUE MODIFIED
    }
    digitalWrite(_select, HIGH);
  }

With this modification i see that the Freq with sw SPI has changed from ~70khz to ~32Khz with same result.
Data log is a little more stable on external temp but internal temp is off:
14:27:32.386 -> time:		1056
14:27:32.386 -> stat:		0
14:27:32.386 -> raw:		0011 0100 0100 0000 1000 0000 0000 0000
14:27:32.386 -> internal:	-128.000
14:27:32.386 -> temperature:	836.000
14:27:33.360 ->
14:27:33.360 -> time:		1056
14:27:33.360 -> stat:		0
14:27:33.360 -> raw:		0011 0100 0010 1000 1000 0000 0000 0000
14:27:33.360 -> internal:	-128.000
14:27:33.360 -> temperature:	834.500

My ambiental temp is about 19~24º and all test is on ambiental temp.

Found a problem when testing with UNO.
I noticed that the constructor that sets the hardware flag does not get executed (anymore?).
When moving the code from the constructor to begin HW SPI starts to work again at least on UNO.
todo

check if ESP32 HW has the same problem.
fix the code

ESP32 shows same problem
see on the scope that the ESP32 definitely needs pull-up resistors on the clock, and data line.

Fix needs a rewrite of the constructor and begin() function and will be a breaking change.
Might take some days to fix.

@jpsminix
Created a branch https://github.com/RobTillaart/MAX31855_RT/tree/fix21 that should solve the issue.
Can you please test if this works with UNO SW HW and ESP32 SW and HW?
Note: In your sketch you need to move the parameters from the constructor to the begin().

ESP32 via VSPI  (240MHz)
time:		15
stat:		0
raw:		0000 0001 0100 1000 0001 0011 1101 0000
internal:	19.812
temperature:	20.500

note that SW SPI is almost equally fast 17 vs 15 us. - that is ~2 bits / usec

@jpsminix Created a branch https://github.com/RobTillaart/MAX31855_RT/tree/fix21 that should solve the issue. Can you please test if this works with UNO SW HW and ESP32 SW and HW?
Note: In your sketch you need to move the parameters from the constructor to the begin().
update: unit tests needs investigation update 2: unit tests fixed, pull request is ready for merging.

I have tested Arduino UNO HW and ok. Tomorrow i will test the rest:

ESP32 HW and SW
Arduino UNO SW again.

update on an open question:

I think internal temp is broken on all my chips and its impossible to calculate the external temp without the reference of internal.

I need to dive into the datasheet / code to confirm that

From datasheet:
The device senses and corrects for the changes in
the reference junction temperature with cold-junction
compensation. It does this by first measuring its internal
die temperature, which should be held at the same temperature
as the reference junction. It then measures the
voltage from the thermocouple’s output at the reference
junction and converts this to the noncompensated thermocouple
temperature value. This value is then added
to the device’s die temperature to calculate the thermocouple’s
“hot junction” temperature. Note that the “hot
junction” temperature can be lower than the cold junction
(or reference junction) temperature.
So yes, the internal temperature is needed as a reference. What I understand from the above is that the external sensor follows the internal sensor (as the external is added). So in theory the two temperatures should follow same pattern ?
However if internal is broken anything is possible in practice.

Sorry, bad wiring on esp32 testing. I have corrected the pinout wiring and ESP32 with sw SPI -> OK. Im gonna test ESP32 hw SPI now.

Sorry, bad wiring on esp32 testing. I have corrected the pinout wiring and ESP32 with sw SPI -> OK. Im gonna test ESP32 hw SPI now.

happens to me daily :)

No data with ESP 32 hw SPI and 2 resistor pull up (~2k) on CLK and DO lines. I dont see anything on the scope. Log output:
17:18:30.257 -> time:		51
17:18:30.257 -> stat:		0
17:18:30.257 -> raw:		0000 0000 0000 0000 0000 0000 0000 0000
17:18:30.303 -> internal:	0.000
17:18:30.303 -> temperature:	0.000
17:18:31.272 ->
17:18:31.272 -> time:		51
17:18:31.272 -> stat:		0
17:18:31.272 -> raw:		0000 0000 0000 0000 0000 0000 0000 0000
17:18:31.272 -> internal:	0.000
17:18:31.272 -> temperature:	0.000

Wops, i dont have choose demo VPSI. i am gonna check.

Yep, that was de VPSI command. My bad.
Ok ESP32 hw SPI working (with and without resistor pullup). Logs:
17:23:49.640 -> time:		16
17:23:49.640 -> stat:		0
17:23:49.640 -> raw:		0101 0100 1001 1000 1011 0011 1101 0000
17:23:49.640 -> internal:	-76.188
17:23:49.640 -> temperature:	1353.500
17:23:50.660 ->
17:23:50.660 -> time:		16
17:23:50.660 -> stat:		0
17:23:50.660 -> raw:		0100 1111 1111 1000 1011 0110 0001 0000
17:23:50.660 -> internal:	-73.938
17:23:50.660 -> temperature:	1279.500
The scope its a little strange, but works:

ESP32 via VSPI (240MHz)
time:		15
stat:		0
raw:		0000 0001 0100 1000 0001 0011 1101 0000
internal:	19.812
temperature:	20.500

note that SW SPI is almost equally fast 17 vs 15 us. - that is ~2 bits / usec
good moment to stop :)

If you disconnect the thermocouple wiring, is the MAX31855 still gives you the readings of internal temp?

it looks like you got it working!

If you disconnect the thermocouple wiring, is the MAX31855 still gives you the readings of internal temp?

I will try, will take few minutes

I removed the wire and immediately
time:           15
stat:           1
raw:            0111 1111 1111 1101 0001 0111 0001 0001
internal:       0.000
temperature:    0.000

So it looks like the raw data is not completely "crap"
I need to check if the read "returns" prematurely.

made a patch in the .cpp and it shows a nice internal and a faulty external  ==> bit 18 -31 are all 1
time:		16
stat:		1
raw:		0111 1111 1111 1101 0001 0011 1011 0001
internal:	19.687
temperature:	2047.750

(thinkin out loud)
That implies including this patch in the Pull Request gives better information in case of an STATUS_OPEN_CIRCUIT  (1) error.
Agree?

@jpsminix
I removed the "premature" return from read() so it now it will always fill internal and temperature from the raw data.
Can you verify?

The scope its a little strange, but works (15.6Mhz):

looks similar to what I saw on my scope yesterday.  The ESP32 the SW SPI had no time between the bytes, while HW SPI had faster bursts like your picture shows. So hardware SPI is in theory maybe twice as fast, but the overhead of transaction exists. In practice that means pulses are shorter and probably not a nice square ware, but more a "rounded shark fin". So for stability SW SPI should be preferred.

(thinkin out loud) That implies including this patch in the Pull Request gives better information in case of an STATUS_OPEN_CIRCUIT (1) error. Agree?

Complety agree!

@jpsminix I removed the "premature" return from read() so it now it will always fill internal and temperature from the raw data. Can you verify?

I will try on a while. I will tell you.

Ok, its working (my chip is giving random numbers but works your code).

The scope its a little strange, but works (15.6Mhz):

looks similar to what I saw on my scope yesterday. The ESP32 the SW SPI had no time between the bytes, while HW SPI had faster bursts like your picture shows. So hardware SPI is in theory maybe twice(++) as fast, but the overhead of transaction exists. In practice that means pulses are shorter and probably not a nice square ware, but more a "rounded shark fin". So for stability SW SPI should be preferred.

Correct!

I'm going to merge the Pull Request, thank  you for the issue and your testing

Issue is automatically closed by PR, so if there are new problems please open a new issue (or reopen if related)

@jpsminix
I am thinking about adding a configurable delay in the SW SPI loop so the timing can be adjusted.
  else  // Software SPI
  {
    digitalWrite(_select, LOW);
    for (int8_t i = 31; i >= 0; i--)
    {
      _rawData <<= 1;
      digitalWrite(_clock, LOW);
      if (del > 0 )  delayMicroseconds(del / 2 );         <<<<<<<<<
      if ( digitalRead(_miso) ) _rawData++;
      digitalWrite(_clock, HIGH);
       if (del > 0 ) delayMicroseconds(del - del / 2 );     <<<<<<<<<<<
    }
    digitalWrite(_select, HIGH);
  }

and then add  void setSWSPIdelay(uint16_t del)  and a uint16_t getSWSPIdelay()
this would allow adjusting timing when needed e.g. when long wires are used.


python310Packages.yalexs-ble: 2.1.12 -> 2.1.14

Changelog: https://github.com/bdraco/yalexs-ble/blob/v2.1.14/CHANGELOG.md
Description of changes

Things done

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
23.05 Release Notes (or backporting 22.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[ ] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 223799 run on x86_64-linux 1

4 packages built:

home-assistant-component-tests.august
home-assistant-component-tests.yalexs_ble
python310Packages.yalexs-ble
python311Packages.yalexs-ble


Delete unnecessary files like *.iml, *.DS_Store, etc.

Deleted files that match the patterns:
*.DS_Store # Hide files made by MacOS
*.iml # Hide files made by IntelliJ IDE
*.project # Hide files made by Eclipse IDE

and added these patterns to .gitignore.
I also fixed a small typo in the file extension of one file. The extension was .javaa so I renamed it to .java

I could squash the commits into one if you wish


remove producer-by-consumer metric reporting

These metrics are not in use and thus should be removed until they
are ready for use.
 Last update 51e31a8...9c5c6f9

LGTM


[FEATURE] Inline Blame View

#94

Done, I've modified it as you asked!
and also I fixed some lint errors

Thank you for the quick turn-around. There are a few auto-fixable lint errors left and then I'll merge.

That test failure is due to an issue in the test itself. I'll merge this now. I'll also add a setting to disable this for those who want to keep the old behavior.

Thank you!


Enhance password field

[ ] bug
[x] feature request
[ ] enhancement

Password input field should have an attribute using which developers can show/hide a see password icon. This is a common design in modern password fields and also helps in improving the security of application.

A eye-show/eye-hide toggle at the end of a password field would ideal. Clicking the control would swap the view of the input field from one to another and the icon toggle would swap as well.
'eye-hide' icon showing: text field state (alphanumeric)```

@mathisscott mentioned that we would need to be conscious of native browser controls that do this for the user (Edge?)

need to know what this will look like. where it sits in reference to the text field. also how it conflicts with existing functionality across OSes.

This has been completed in new forms.


Release eo-math

Release is required to apply syntax changes

@yegor256 please release

Duplicate of #99

@mximp we just did


Fix handling of entity length in HTTP/2.

Re-enable grpc tests.
First part of #5418 & #5323

Tests are still technically disabled, is this on purpose?
https://github.com/tomas-langer/helidon/blob/0d614aff5dd99e33e18c39f43fb01c938cc98c5e/nima/pom.xml#L38-L53

Tests are still technically disabled, is this on purpose?
https://github.com/tomas-langer/helidon/blob/0d614aff5dd99e33e18c39f43fb01c938cc98c5e/nima/pom.xml#L38-L53

Tests are running in profile test and are part of pipeline testing.


feat: read HTTP cookies as a map string to string

slightly improve performance and avoid mapping errors now that we started indexing it with dynamic mapping.

@kruskall Is there anything I can help to move this forward?


Documenting research links in main README

Dumping most everything I've looked into so far into the README so others can see. Maybe it can go somewhere else later?

Yeah will take a look. I'm not sure how to link docs in GH, but will figure it out and update. Thanks!
------- Original Message -------
On Friday, June 3rd, 2022 at 8:47 AM, nbpion @.***> wrote:

@nbpion requested changes on this pull request.
Can we rename the file too? README.md can be a jumping-off point to the various topic-specific docs like this one.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.Message ID: @.***>

@nbpion I actually tried adding this content the the repo's wiki. Do you prefer that or creating a separate .md file in the main repo? I'm guessing since this entire repo is docs, we may want to check all files into the repo instead of using the wiki. Especially since ACLs/approvals on adding to the wiki seem pretty light. WDYT?

@nbpion I actually tried adding this content the the repo's wiki. Do you prefer that or creating a separate .md file in the main repo? I'm guessing since this entire repo is docs, we may want to check all files into the repo instead of using the wiki. Especially since ACLs/approvals on adding to the wiki seem pretty light. WDYT?

Yep I think separate Markdown files are the way to go for now. I think Wiki will be more useful for end-user documentation when we get to that stage.

@nbpion I actually tried adding this content the the repo's wiki. Do you prefer that or creating a separate .md file in the main repo? I'm guessing since this entire repo is docs, we may want to check all files into the repo instead of using the wiki. Especially since ACLs/approvals on adding to the wiki seem pretty light. WDYT?

Yep I think separate Markdown files are the way to go for now. I think Wiki will be more useful for end-user documentation when we get to that stage.

Ok, created new "Research" file with these links. I think we can rename/move it further once we narrow things down a bit.


Notifier is broken

Mobx is providing a strange issue now (78fbc622e9aec558f11131625909918ddca59134) that it has been hooked up to Create React App 2. I think its related to MobX 5 being more strict and requiring a schema for multi-level data, such as an object. Notifier.jsx has always been hacky, but I don't have time to fix it properly, so I am just looking for a quick fix to that we have notifications working for the mvp release. This is really the only thing holding us up at this point from having a 'usable' product.

[mobx] Encountered an uncaught exception that was thrown by a reaction or observer component, in: 'Reaction[Reaction@201]' Error: [serializr] this value is not primitive: [object Object]

Fixed Notifier by rewriting the Notistack implementation in 5ef8c7a645c2f08167d65f00efda3cf017a5df47.


prometheus_remote_storage_pending_samples are drastically increasing over time.

What did you do?
Using 3 standalone victoria-metrics as LTS storage for prometheus.
What did you expect to see?
prometheus_remote_storage_pending_samples should not increase over time.
What did you see instead? Under which circumstances?
Increase on prometheus_remote_storage_pending_samples metric.
It does not look that there is a metric lag on victoria-metrics site though.
Environment
Centos 7. Prometheus 2.16.0 (same issue on older versions). Victoria-metrics 1.32.6
About 1.5k scrape targets.

System information:
Linux 3.10.0-957.21.3.el7.x86_64 x86_64

Prometheus version:

prometheus, version 2.16.0 (branch: HEAD, revision: b90be6f32a33c03163d700e1452b54454ddce0ec)
  build user:       root@7ea0ae865f12
  build date:       20200213-23:50:02
  go version:       go1.13.8

Prometheus configuration file:

---
global:
  scrape_interval: 30s
  scrape_timeout: 5s
rule_files:
- "/etc/prometheus/rules/*"
remote_write:
- url: http://victoria-metrics1:8428/api/v1/write
  queue_config:
    max_shards: 50
    min_shards: 2
    capacity: 1500000
    max_samples_per_send: 150000
    batch_send_deadline: 2s
- url: http://victoria-metrics2:8428/api/v1/write
  queue_config:
    max_shards: 50
    min_shards: 2
    capacity: 1500000
    max_samples_per_send: 150000
    batch_send_deadline: 2s
- url: http://victoria-metrics3:8428/api/v1/write
  queue_config:
    max_shards: 50
    min_shards: 2
    capacity: 1500000
    max_samples_per_send: 150000
    batch_send_deadline: 2s

Prometheus seems to work fine for some time, but then it will start drastically increse prometheus_remote_storage_pending_samples metrics. It does not seem, that there's any lag in metrics, which are written to remote storage.
It also appears, that prometheus_remote_storage_pending_samples begins to increase right after WAL checkpoint.  You can see that during checkpoint, prometheus begins increasing shard count and  also pending_samples begins to grow:
prometheus_remote_storage_shards:

prometheus_remote_storage_pending_samples:

What could be causing this?
Thank you.

Thanks for the report.
cc @tomwilkie & @cstyan

cc @valyala FYI

https://github.com/prometheus/prometheus/blob/261cbab8e9fa470b72693c984cc25e9be6e33e83/storage/remote/queue_manager.go#L816-L818
We probably want s.qm.pendingSamplesMetric.Sub(float64(len(pendingSamples))) in case we are in the case where  nPending > max

We cannot set it to 0 as there are many shards sharing the same pendingSamplesMetric. That metric is for the queue, but is adjusted on a per shard basis.
It should not actually be possible for nPending > max to ever happen as we process samples one at a time. I would be fine using nPending or len(pendingSamples) though I very much doubt that is the bug.

@csmarchbanks, thats the problem - i get all the data in time - there are no lagging metrics in graphs. It's just the pending samples that increase.
You can see from the graphs, that after checkpoint, prometheus increases shard count for a short period of time to upload all the data, that was was not sent during snapshot creation. After that shard count returns to normal, but pending samples remain at high level.
I reconfigured prometheus remote_write to:
    max_shards: 50
    capacity: 1500000
    max_samples_per_send: 150000
    batch_send_deadline: 5s

Seing no increase on pendingSamples for about 3hours now. But the problem is, tat at some point they will jump up in number again. Ant only thing that i can correlate is that WAL checkpoint happens at the same time. After checkpoint is created you can get an increase on pendingSamples

I agree there is a bug here, I am seeing it in some of my instances as well that are not behind. I am just not convinced the nPending > max case is the cause of it.
It could be related to resharding, but some of my instances are not resharding but still have this metric increasing forever at a relatively consistent rate.

We should be selecting pendingSamples[:max] here: https://github.com/prometheus/prometheus/blob/261cbab8e9fa470b72693c984cc25e9be6e33e83/storage/remote/queue_manager.go#L816
Still looking at what might actually cause this though.

I had a slightly different pattern: the two jumps are when the back-end had an outage so the queue did build up.  But after the queue cleared the metric stayed high.

@bboreham which metric is each screenshot showing?

From the legend at the bottom (two traces are selected):
"queue length" is sum(prometheus_remote_storage_pending_samples) by (url)
"shards" is max(prometheus_remote_storage_shards) by (url)
Top one is just queue length.

I think somehow this might be related to the shards timing out, which happens when they haven't reached max_shards_per_send within 5s by default.
I just spent some time looking through debug logs on one of our instances, in the few seconds right before we had a pending shards jump we had 90 shards time out and sending the samples they had queued. Those 90 shards flushed 4678 samples. At t0 we had 8282326 samples pending, at t1 we had 8278810 samples pending, and at t2 we had 828689 samples pending. The flush happened right before t0, but I have another example where we flush between t0 and t1 and again there's  more pending samples at t2 than t0.
@bboreham @csmarchbanks @Seitanas can you turn on debug logging and confirm whether you're seeing the same?

That does not seem to be the case for me. I have a queue with increasing samples pending that has never ran into the runShard timer ticked message.

Just to be clear, you have debug logging on, or off? That log line is level.Debug.

Debug logging is on. I also have a queue that is constantly hitting the per message timeout but does not exhibit continual increases in pending samples.

Hmmm... on a different instance I just had the same thing happen as you, large spike in runShard timer ticked messages alongside a large increase in pending samples. It also corresponded with a reshard event and an increase in latency to the destination.

Honestly I think all we can do right now is change some of the code in runShard to always use the same var when selecting samples to send and how many to remove from the pending samples metric: https://github.com/prometheus/prometheus/issues/6952#issuecomment-597265658
And we could also add more debug logging to see if shards are exiting with samples in their buffer (samples being enqueued to the shard after it's marked for shutdown). I only see the pending samples start to go up on our instances after they've been running for quite some time (multiple days) so this is hard to track down without some more data.

exiting with samples in their buffer (samples being enqueued to the shard after it's marked for shutdown)

Samples being enqueued to the shard after it is marked for shutdown is not the only way for there to be samples in the buffer. If waiting on a request to go out there can be up to the shard capacity samples already there before being marked for shutdown.
Most of the graphs in this issue point to some correlation between resharding and this issue, it could easily be caused by taking too long to flush the samples already queued during a reshard and hitting the hard shutdown case where we don't do any handling of pending samples. Why not add some handling in that case to subtract all the pending samples from the metric, and add nPending + len(queue) as failed samples? This case is what I was trying to explain in https://github.com/prometheus/prometheus/pull/6960#pullrequestreview-372426783.

@csmarchbanks right I understand now. Yes, we should also ensure we're removing any pending samples in the <- ctx.Done() case. But if that was the cause I'd expect to be seeing the log line level.Error(s.qm.logger).Log("msg", "Failed to flush all samples on shutdown") which I haven't. The default for the flush deadline is also 1m or higher iirc, so if that was the cause of pending samples growing we should also see succesful send time graphs flatten for periods of time.

Hello, any update on this?


Move default remote options out of library

This is causing melange to pull in a bunch of deps it doesn't need.

If we bump this dep in melange after this change:
diff --git a/go.mod b/go.mod
index d8d768a..ed50e1d 100644
--- a/go.mod
+++ b/go.mod
@@ -41,15 +41,6 @@ require (
        cloud.google.com/go/compute v1.19.3 // indirect
        cloud.google.com/go/compute/metadata v0.2.3 // indirect
        cloud.google.com/go/iam v0.13.0 // indirect
-       github.com/Azure/azure-sdk-for-go v68.0.0+incompatible // indirect
-       github.com/Azure/go-autorest v14.2.0+incompatible // indirect
-       github.com/Azure/go-autorest/autorest v0.11.29 // indirect
-       github.com/Azure/go-autorest/autorest/adal v0.9.23 // indirect
-       github.com/Azure/go-autorest/autorest/azure/auth v0.5.12 // indirect
-       github.com/Azure/go-autorest/autorest/azure/cli v0.4.6 // indirect
-       github.com/Azure/go-autorest/autorest/date v0.3.0 // indirect
-       github.com/Azure/go-autorest/logger v0.2.1 // indirect
-       github.com/Azure/go-autorest/tracing v0.6.0 // indirect
        github.com/MakeNowJust/heredoc v1.0.0 // indirect
        github.com/Microsoft/go-winio v0.6.1 // indirect
        github.com/ProtonMail/go-crypto v0.0.0-20230528122434-6f98819771a1 // indirect
@@ -57,22 +48,6 @@ require (
        github.com/apparentlymart/go-cidr v1.1.0 // indirect
        github.com/asaskevich/govalidator v0.0.0-20230301143203-a9d515a09cc2 // indirect
        github.com/avast/retry-go v3.0.0+incompatible // indirect
-       github.com/aws/aws-sdk-go-v2 v1.18.0 // indirect
-       github.com/aws/aws-sdk-go-v2/config v1.18.25 // indirect
-       github.com/aws/aws-sdk-go-v2/credentials v1.13.24 // indirect
-       github.com/aws/aws-sdk-go-v2/feature/ec2/imds v1.13.3 // indirect
-       github.com/aws/aws-sdk-go-v2/internal/configsources v1.1.33 // indirect
-       github.com/aws/aws-sdk-go-v2/internal/endpoints/v2 v2.4.27 // indirect
-       github.com/aws/aws-sdk-go-v2/internal/ini v1.3.34 // indirect
-       github.com/aws/aws-sdk-go-v2/service/ecr v1.18.11 // indirect
-       github.com/aws/aws-sdk-go-v2/service/ecrpublic v1.16.2 // indirect
-       github.com/aws/aws-sdk-go-v2/service/internal/presigned-url v1.9.27 // indirect
-       github.com/aws/aws-sdk-go-v2/service/sso v1.12.10 // indirect
-       github.com/aws/aws-sdk-go-v2/service/ssooidc v1.14.10 // indirect
-       github.com/aws/aws-sdk-go-v2/service/sts v1.19.0 // indirect
-       github.com/aws/smithy-go v1.13.5 // indirect
-       github.com/awslabs/amazon-ecr-credential-helper/ecr-login v0.0.0-20230519004202-7f2db5bd753e // indirect
-       github.com/chrismellard/docker-credential-acr-env v0.0.0-20230304212654-82a0ddb27589 // indirect
        github.com/cloudflare/circl v1.3.3 // indirect
        github.com/common-nighthawk/go-figure v0.0.0-20210622060536-734e95fb86be // indirect
        github.com/containerd/containerd v1.6.15 // indirect
@@ -80,7 +55,6 @@ require (
        github.com/containers/gvisor-tap-vsock v0.5.0 // indirect
        github.com/cpuguy83/go-md2man/v2 v2.0.2 // indirect
        github.com/davecgh/go-spew v1.1.1 // indirect
-       github.com/dimchansky/utfbom v1.1.1 // indirect
        github.com/docker/cli v24.0.2+incompatible // indirect
        github.com/docker/distribution v2.8.2+incompatible // indirect
        github.com/docker/docker-credential-helpers v0.7.0 // indirect
@@ -103,7 +77,6 @@ require (
        github.com/go-openapi/validate v0.22.1 // indirect
        github.com/goccy/go-yaml v1.9.8 // indirect
        github.com/gogo/protobuf v1.3.2 // indirect
-       github.com/golang-jwt/jwt/v4 v4.5.0 // indirect
        github.com/golang/groupcache v0.0.0-20210331224755-41bb18bfe9da // indirect
        github.com/golang/protobuf v1.5.3 // indirect
        github.com/google/btree v1.1.2 // indirect
@@ -120,7 +93,6 @@ require (
        github.com/insomniacslk/dhcp v0.0.0-20221215072855-de60144f33f8 // indirect
        github.com/jbenet/go-context v0.0.0-20150711004518-d14ea06fba99 // indirect
        github.com/jinzhu/copier v0.3.5 // indirect
-       github.com/jmespath/go-jmespath v0.4.0 // indirect
        github.com/josharian/intern v1.0.0 // indirect
        github.com/josharian/native v1.1.0 // indirect
        github.com/kevinburke/ssh_config v1.2.0 // indirect
@@ -177,3 +149,5 @@ require (
        inet.af/tcpproxy v0.0.0-20221017015627-91f861402626 // indirect
        mvdan.cc/sh/v3 v3.5.1 // indirect
 )
+

I don't get it. All this seems to do is move some of the configuration out of oci.go and into publish.go. What does that buy us?

I don't get it. All this seems to do is move some of the configuration out of oci.go and into publish.go. What does that buy us?

Clients that only depend on pkg/build/oci don't pick up an implicit dependency on AWS/ACR/GCR cred helpers, which bring in a bunch of cloud client library deps. If those clients want to pass those cred helpers and their deps in, they can, but if they just want to use authn.DefaultKeychain which consults ~/.docker/config.json they can do that too, and avoid a lot of big dependencies.

Ah it doesn't change apko, but makes life easier for downstream dependencies. Makes sense.


Update React code snippets to use useState instead of using ref to set open

What component is this related to?
IcDialog, IcPopover
Why do we need it?
The React code snippets for Dialog need to be updated so they are idiomatic to React. For example, the following code snippet
const dialogEl = useRef(null);
const showDialog = () => {
  dialogEl.current.open = true;
};
const confirmDialog = (ev) => {
  alert("Added to basket");
  ev.target.open = false;
};
return (
  <>
    <IcButton onClick={showDialog}>Launch dialog</IcButton>
    <IcDialog ref={dialogEl} heading="Are you sure?" label="Coffee order"
      onIcDialogConfirmed={confirmDialog}
    >
      <IcTypography>
        You are about to add 'Americano' to your basket. Are you sure you want to continue?
      </IcTypography>
    </IcDialog>
  </>
);

..should be changed to....
const [open, setOpen] = useState(false);

const showDialog = () => {
  setOpen(true);
};
const confirmDialog = (ev) => {
  alert("Added to basket");
  setOpen(false);
};
return (
  <>
    <IcButton onClick={showDialog}>Launch dialog</IcButton>
    <IcDialog open={open} heading="Are you sure?" label="Coffee order"
      onIcDialogConfirmed={confirmDialog}
    >
      <IcTypography>
        You are about to add 'Americano' to your basket. Are you sure you want to continue?
      </IcTypography>
    </IcDialog>
  </>
);

For Toast too

Make the change on the actual site, not just the snippet


pairs observable static function does not infers correctly

Bug Report
Current Behavior
pairs observable is incorrectly inferred. With the example below the type infers as Observable<[string, {}]>
var obj = {
  foo: 1,
  bar: 2,
  baz: 3
};

var source = pairs(obj);

Expected behavior
It should infer `Observable<[string, number]>
Environment

RxJS version: Latest (6.3.3)

@cartant Is this now with Typescript 3+ possible?
If yes let's comment the next steps. If no let's close this issue

Closing this because the types in v7 infer correctly:
var obj = {
  foo: 1,
  bar: 2,
  baz: 3
};
var source = pairs(obj); // Observable<["foo" | "bar" | "baz", number]>

And because pairs is now deprecated:
https://github.com/ReactiveX/rxjs/blob/4805a7fecfa5d9732e0329fb463e11d62c219238/src/internal/observable/pairs.ts#L9-L12


chore: add silverstripe framework to integration tests

See: #178 (https://github.com/php-rust-tools/parser/pull/178#discussion_r1044242481)

Ha !
This found an interesting case:
https://github.com/silverstripe/silverstripe-framework/blob/4/src/ORM/Map.php#L15


Remove kafka generator support

What does this PR do?
This commit removes kafka generator support from lading. We believe it it unused and its maintenance burden is non-trivial, especially with consideration to the kafka crate's unstable interface.
Additional Notes
This is a break changing and so lading's version is now bumped to 0.12.
Signed-off-by: Brian L. Troutwine<EMAIL_ADDRESS>

The release workflow needs some adjustment for this change: https://github.com/DataDog/lading/blob/main/.github/workflows/release.yml#L31-L33

Good catch.

The release workflow needs some adjustment for this change: https://github.com/DataDog/lading/blob/main/.github/workflows/release.yml#L31-L33

Good catch.

Addressed in 6d9ce2c.


Go binary cannot be found on macOS 13 and macOS 14 runner images

Description
With the recent switch from macos-12 to macos-14 when using the macos-latest tag, it appears the Go binary cannot longer be found. The macos-13 image also appears to be affected. The docs (e.g. macos-13, macos-14-arm64) still suggest multiple versions of Go should be preinstalled.
NB: the code has not been tested with the macOS large runners due to account / billing limitations.
Platforms affected

[ ] Azure DevOps
[X] GitHub Actions - Standard Runners
[ ] GitHub Actions - Larger Runners

Runner images affected

[ ] Ubuntu 20.04
[ ] Ubuntu 22.04
[ ] macOS 11
[ ] macOS 12
[X] macOS 13
[ ] macOS 13 Arm64
[ ] macOS 14
[X] macOS 14 Arm64
[ ] Windows Server 2019
[ ] Windows Server 2022

Image version and build link
2.316.0, see https://github.com/markdumay/gha-hugo-macos/actions/runs/8865382577
Is it regression?
No
Expected behavior
Running go version from within the workflow should return a valid Go version, e.g. go version go1.21.9 darwin/amd64.
Actual behavior
On macos-13 and macos-14, running go version returns an error:
/Users/runner/work/_temp/xxx-xxx-xxx-xxx-xxx.sh: line 1: go: command not found
Error: Process completed with exit code 127.

Repro steps

Create a new workflow file in any repository, e.g. .github/workflows/fail.yml and copy the following code:

name: Go installation check (fail)
on:
  workflow_dispatch:

jobs:
  check:
    strategy:
      matrix:
        os:
          - macos-14
          - macos-13

    runs-on: ${{ matrix.os }}

    steps:
    - run: go version

Manually run the workflow Go installation check (fail) in the actions overview.

not listed in the 13 and 14 readmes as "installed"
using setup-go will succeed and report 1.22.2 for all versions
name: Go installation check (fail)
on:
  workflow_dispatch:

jobs:
  check:
    strategy:
      matrix:
        os:
          - macos-14
          - macos-13
          - macos-12

    runs-on: ${{ matrix.os }}

    steps:
      - name: Install Go
        uses: actions/setup-go@v5
        with:
          go-version: ">1.0.0"
      - name: RUN Go
        run: go version

Thanks @irkode, you're right. After some more careful reading, the Go binary is indeed only available as precached tool in both runner images. I'll close this issue as solved.


Allow data generators as input sources

Currently, we're using intake to provide data to scivision, but we should also allow the possibility of using data generators as input sources. This could include:

Synthetic data, created on-the-fly by, for example, deep generative models or
Data streaming directly from instruments

@quantumjot it occurs to me that @mooniean @ots22 work involved a synthetic generator, but it used intake - does that example satisfy closing this issue or did you have something else in mind?

I think we can close this for now.


Stopped working after upgrading to HOOBS v4

Hi, could you please advice me on whether the fact that this plugin doesn't seem to work on HOOBS v4 is currently known? I've tried pretty much everything to make it work on the HOOBS Version: 4.0.92 without any success. Had no issues running it on the v3. Some indication whether it's just me or this is a wider compatibility issue would be appreciated (have been going a bit crazy trying to make the plugin work again).
Thanks

@Maikysupra
I've never tested the plugin on HOOBS v4 yet. It might be a compatibility issue.

Thanks from coming back so promptly. I really appreciate it! I'm no developer, but it does look like a compatibility issue to me. The plugin just doesn't seem to communicate with the Raspberry Pi's GPIO interface (on the HOOBS v4). Don't mean to put pressure by any means as I understand you must be very busy, but would you happen to know when you might be likely to look into this (ballpark)? Just to help me make a decision whether I should downgrade back to v3 for the time being (as I rely on your plugin quite heavily) or I might just wait a bit. Kind Regards and thank you very much for making such an awesome plugin! It's been the main reason for me to run Homebridge on Raspberry Pi. Peter

@Maikysupra
I need to investigate the compatibility issue on HOOBS v4.
Please feel free to post an issue here if the plugin is not working properly on Pi.

Hi Team,
I just updated my Hoobs for Version 4.0.31 and the Relay Lapo didn't work any more, baucause one of the library in the new Hoobs environment was updated. Please can you help here on the update or to certificate this plug in for Hoobs. I use the relays for the Jalousie to manage via Homebridge. Thanks for your help.
BR André


ModuleNotFoundError: No module named 'absl'

Hello, after updating to the last commit I get this error when running the program:
Traceback (most recent call last):
File "/usr/local/alphafold/alphafold/docker/run_docker.py", line 21, in
from absl import app
ModuleNotFoundError: No module named 'absl'
which I never encountered before. Any idea of how to solve this? Thanks!

Actually, I could fix this with the following:
pip install absl-py
which then led to a similar issue with the docker module:
Traceback (most recent call last):
File "/usr/local/alphafold/alphafold/docker/run_docker.py", line 24, in
import docker
ModuleNotFoundError: No module named 'docker'
that could also be fixed with:
pip install docker
...after which the programs ran as before. But I suppose I should still report this because, as I wrote in my original message, it did not seem to happen with previous commits.


Get-WordDocument causes Powershell 5.1 window to exit

Hi there,
First time trying to use your module and test some basic functionality. I was expecting that using
Get-WordDocument -filepath .\test.docx
would return an object containing details about the file, but actual behaviour seems to just exit the console.
Powershell 5.1
Windows 10 Pro vers  10.0.19042 (Build 19042)

It's my mistake, there were Exit commands when something went wrong in those cmdlets. I don't know what I was thinking when I wrote it.

This is now fixed, a new version was released. Thank you for reporting.


Charge results

Describe the bug
Only q(Cxx) results work, but q(Sxx), q(Vxx) don't.
Wrong results:
{
'q(V1)': [q(V1)_1, q(V1)_2],
'q(S1)': [q(S1)_1, q(S1)_2],
'q(S2)': [q(S2)_1, q(S2)_2]
}

To Reproduce
# SC1
from symcirc import *

netlist = """

V1 node1 0 DC 1 AC 1 0
S1 node1 node2 1
C1 node2 0 6.2n
S2 node2 node3 2
C2 node3 0 10n
"""

circuit = AnalyseCircuit(netlist, "TF", symbolic=False, method="two_graph_node", scsi="scideal", phases="P=2")

results = circuit.node_voltages()
results.update(circuit.component_values("all"))
print(results)

This issue is rooted in the Two Graph Method used for the circuit analysis. It is common for both standard and SCSI analysis.
It can be fixed by not reducing the equation matrix when writing voltage sources (both V and S use the same model).
I will try to implement this during the upcoming month (it might take some time).


Use event delegation to reduce number of event listeners

@beru can you rebase to main and resolve the build issues?


Force UTF-8 encoding on task results

Since task results are stored as binary blobs, they can be set as
strings in whatever encoding you like. This can create problems for
the API, which blindly tries to convert all attributes to JSON - any
value containing ASCII with ansi escape codes will fail with a
conversion error.
It seems reasonable to expect that all string values should be encoded
as UTF-8 - the alternative is for the API to have to force the
encoding on every single string that comes its way.
This change forces incoming values to be converted to UTF-8 prior to
being stored. It will also convert outgoing values in the case that
they have already been persisted prior to this change - though this
extra check I'm sure could eventually be removed.
Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1557731

@imtayadeway gaprindashvili/yes ?

Gaprindashvili backport details:
$ git log -1
commit abe1095c02d8032ab9cbac777ba1d32c8815838d
Author: Gregg Tanzillo<EMAIL_ADDRESS>Date:   Fri Apr 6 08:18:44 2018 -0400

    Merge pull request #17252 from imtayadeway/force-task-results-encoding

    Force UTF-8 encoding on task results
    (cherry picked from commit c7d158064e5241e03a98a69cf53f01dae753a70b)

    Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1566572


proxyd batches

Codecov Report

Merging #165 (71240ad) into develop (bf65167) will increase coverage by 17.79%.
The diff coverage is n/a.

@@             Coverage Diff              @@
##           develop     #165       +/-   ##
============================================
+ Coverage    71.73%   89.52%   +17.79%
============================================
  Files           68       33       -35
  Lines         2257     1079     -1178
  Branches       335      150      -185
============================================
- Hits          1619      966      -653
+ Misses         638      113      -525

Flag
Coverage Δ

batch-submitter
?

contracts
89.52% <ø> (ø)

core-utils
?

data-transport-layer
?

message-relayer
?

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

Impacted Files
Coverage Δ

packages/core-utils/src/common/test-utils.ts

packages/core-utils/src/common/hex-strings.ts

packages/message-relayer/hardhat.config.ts

packages/data-transport-layer/src/utils/eth-tx.ts

packages/core-utils/src/batches.ts

.../batch-submitter/src/transaction-chain-contract.ts

packages/core-utils/src/common/misc.ts

...ackages/batch-submitter/src/utils/tx-submission.ts

.../l1-ingestion/handlers/sequencer-batch-appended.ts

packages/core-utils/src/watcher.ts

... and 25 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 bf65167...71240ad. Read the comment docs.


Redis test

Title of this pull request?
Small Description?
Pull Request Checklist:

[ ] Please make sure all jobs pass before requesting a review.
[ ] Put closes #XXXX in your comment to auto-close the issue that your PR fixes (if such).
[ ] Have you lint your code locally before submission?
[ ] Did you write tests where appropriate?

Related Issue?
Screenshots (if appropriate):

@Kashalls I have these logs from dashboard-api conatiner.

oneuptime-dashboard-api-1  | [ioredis] Unhandled error event: Error: connect ETIMEDOUT
oneuptime-dashboard-api-1  |     at TLSSocket.<anonymous> (/usr/src/CommonServer/node_modules/ioredis/built/Redis.js:170:41)
oneuptime-dashboard-api-1  |     at Object.onceWrapper (node:events:627:28)
oneuptime-dashboard-api-1  |     at TLSSocket.emit (node:events:513:28)
oneuptime-dashboard-api-1  |     at TLSSocket.emit (node:domain:489:12)
oneuptime-dashboard-api-1  |     at TLSSocket.Socket._onTimeout (node:net:568:8)
oneuptime-dashboard-api-1  |     at listOnTimeout (node:internal/timers:564:17)
oneuptime-dashboard-api-1  |     at processTimers (node:internal/timers:507:7)
oneuptime-dashboard-api-1  | {
oneuptime-dashboard-api-1  |   message: 'Cannot connect to Redis. Retrying again in 5 seconds',
oneuptime-dashboard-api-1  |   level: 'info',
oneuptime-dashboard-api-1  |   timestamp: '2023-08-02T14:23:20.230Z'
oneuptime-dashboard-api-1  | }
oneuptime-dashboard-api-1  | {
oneuptime-dashboard-api-1  |   message: 'Cannot connect to Redis. Retrying again in 5 seconds',
oneuptime-dashboard-api-1  |   level: 'info',
oneuptime-dashboard-api-1  |   timestamp: '2023-08-02T14:23:25.238Z'
oneuptime-dashboard-api-1  | }


Chaotic Feat: Footer

Describe your chaotic idea
There will be customised footer at the end of page
It will be aligned horizontally with the website
Add Screenshots or Sketches
NA
Confirm

[X] I understand that my idea will add to the chaos and I'm okay with it
[X] I agree to follow this project's Code of Conduct
[X] I want to work on this feature
[X] I'm GSSOC'24 Extd registered Contributor
[X] I'm Hacktoberfest registered Contributor

Go ahead 🚀
Note:

provide a sketch/design for your task
try to make it responsive for all screens

You can start working!

Are you working on this??

@vansh-codes i would like to contribute to this issue . Can u assign me this issue?

@coding-geek-nm Explain your idea to make the footer chaotic in brief

Describe your chaotic idea:

A dynamic footer will be implemented at the bottom of the website, aligned horizontally with the overall layout.(and responsive too).
Footer will include links to essential contact information, such as email, social media profiles, and GitHub repositories, ensuring easy communication.
A dedicated section for copyright information will also be displayed, updating automatically to reflect the most current terms and licenses associated with the project.
Also would wish to style it by adding some transitions or animations accordingly.

Thank you

Go ahead!
Make something appealing as well as chaotic

yep sure , Thank you .

@vansh-codes i am pinning the design of the footer . do let me know if any changes .
https://github.com/user-attachments/assets/50c910b2-bf48-414c-b91f-ffc0bdc52421

sorry This is the revised version. Do let me the changes in the design , so that i can start the implementation.
https://github.com/user-attachments/assets/bfbe7002-b740-435a-a80d-2071fe204d8c

Great work! Is it responsive?

i will make it responsive

Sure! Create a PR once its completed

okay will be done by Tuesday.


add zoom link, fix UTC time for DST

If we update the template in this repo, will the deployed bot use the updated version?

Not quit. @lgierth needs to ssh into the server, pull down the branch, and copy the template to the live instance, and then restart forever.
LMK if you need help with that, @lgierth.

also removed the sync-between-sprints meeting, since we haven't needed it for over a month.

Should be updated now


[WIP]  PP-4277 🔪connector tests

WHAT
A brief description of the pull request:
HOW
Steps to test or reproduce:

re c3907d5 it is actually quite useful to have these in the codebase, esp. when doing a new integration. It means you can have a quick local way of figuring out it what you are doing works. They are not intended to be run as part of CI pipeline.


Fix if condition in ESP Event Linker fragment

The if condition should not be part of the entries, but not
surrounding the fragment itself.
This got introduced in merge https://github.com/espressif/esp-idf/commit/0b59b6069e764b3c063047b5a18149b3ba3245bb - specifically https://github.com/espressif/esp-idf/commit/2b914f2d2222b507bed0db65e1cdced13ee02589
Previously this would result in:
Scanning dependencies of target ldgen_esp32.project.ld_script [ 98%] Generating esp32.project.ld linker script generation failed for /Users/sieren/Documents/Development/esp-idf/components/esp32/ld/esp32.project.ld.in ERROR: failed to parse /Users/sieren/Documents/Development/esp-idf/components/esp_event/linker.lf fragment requires at least 1 values for key 'entries' (at char 44), (line:3, col:1) make[3]: *** [esp-idf/esp32/esp32.project.ld] Error 1 make[2]: *** [esp-idf/esp32/CMakeFiles/ldgen_esp32.project.ld_script.dir/all] Error 2

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


[Feature] Add toggle to catch all downloads, and skip choosing file extension

I'd like to advise to take a look at XDM's implementation to take inspiration from, because from my experience this feature is very hit or miss. Specifically I had the need to download huge files from sharepoint.com (OneDrive), and so far only IDM and XDM worked to catch the download AND not fail with an error, while being able to resume the download (worth noting that on sharepoint.com to be able to resume the download, you need to download the files 1 by 1).


component_function does not accept vim9 function

how to reproduce:
vim9script

g:lightline = {
  active: {
    left: [
      [ 'mode', 'paste' ],
      [ 'readonly', 'filename', 'modified' ],
    ],
    right: [
      [ 'position', ],
      [ 'hello', ],
    ],
  },
  component: {
    position: '%P:%L',
  },
  component_function: {
    hello: 'Hello',
  },
}

def Hello(): string
  return 'hello'
enddef

I have defined Hello() function just return 'hello' for test, but it not show up in statusline after reopen vim.
Does component_function can accept a vim9 function or not?

You need to declare as a global function like def g:Hello().


Automation Send F5 with VNC Viewer

Hello,
With your addon, can we do automation to connect in a Magic Mirror and do F5 and next disconnect ?
I need to do F5 in 2 Magic Mirror to refresh it when i want.
Thank you.
PS: Sorry for my bad english, i'm french

The addon only allows to interact with an vnc server manually. An automation with it is not possible (my current state of knowledge), sry.

is there an addon allowing it ?

@JeedHome44 Not that I know of. I also don't know a VNC client which can transmit keystrokes.
Maybe you have other options like http requests or mqtt commands to refresh the screen.


Fedora-IOT image type isn't supported on aarch64

Description of problem
In image-builder's cockpit interface, on the create image modal, type dropdown does not show "Fedora IoT Commit (.tar)" on aarch64 images.
Version or commit hash (if applicable)
Fails on fedora33-server-aarch64 and fedora33-workstation-aarch64.
Works on fedora33-workstation x86 iso install.
How often reproducible
Always
Steps to Reproduce

start the image in virt-manager on a aarch64 host
update the system and install components as per this guide
go to the cockpit interface, create a blueprint, click create image, select the type dropdown

Actual results
"Fedora IoT Commit (.tar)" is not shown
Expected results
"Fedora IoT Commit (.tar)" should be shown
Additional info
after checking the repo sources composer-cli presents the same behavior
$ composer-cli compose types
ami
openstack
qcow2

Hello! Thanks for this issue! Building Fedora IOT images isn't currently supported by osbuild-composer.
It shouldn't be that hard to introduce the support: Mainly, it's needed to compare the package lists for x86_64 and aarch64.
The hard part might be to test this: Our ostree.sh test currently runs a VM but our team currently doesn't have any aarch64 machines that can run KVM VMs. FTR, I tried modifying ostree.sh to use an emulated machine (using qemu) but IRC Anaconda got stuck.

Hello! Thanks for this issue! Building Fedora IOT images isn't currently supported by osbuild-composer.
It shouldn't be that hard to introduce the support: Mainly, it's needed to compare the package lists for x86_64 and aarch64.
The hard part might be to test this: Our ostree.sh test currently runs a VM but our team currently doesn't have any aarch64 machines that can run KVM VMs. FTR, I tried modifying ostree.sh to use an emulated machine (using qemu) but IRC Anaconda got stuck.

Hi @ondrejbudai thank you for your fast answer !
I'm not sure that I understand what you mean by Building Fedora IOT images isn't currently supported by osbuild-composer as it does work on my machine running fedora33-workstation-x86 (maybe it shouldn't by the way, see at bottom), and is also demonstrated to work on a supposedly aarch64 machine in this tutorial.
About virtualization:
I started fedora33-server-aarch64 without issue in qemu emulating aarch64 on x86 but it was painfully slow on a decent machine, I wouldn't recommend it (10+min boot time, good luck for the build :joy: ).
However i'm currently running 2 kvm VMs on my centos8 rpi4 including fedora33-server-aarch64 (in order to build the image I need, which I did not success yet because the Fedora IoT type is not present).
I'm also currently deploying a new rpi4 with fedora33-server-aarch64 as host instead of VM, because I initially thought that the type Fedora IoT Commit was maybe not available because osbuild can't run kvm in kvm on rpi4, so i will enable kvm on this host. I can provide it for your tests if that is something you would see fit.
I'm currently stuck by this issue, could you help me by providing the way to enable manually this option so I can test the build on the new host ? I'm currently building an ostree OS for a commercial device we're going to release quite soon.
Bottom: Writing these lines I realized I actually successfully built a Fedora IOT image without additional packages on the x86 machine, I wonder what is the state of this image. As far as I understand it should not be functional as it must contain x86 packages in an aarch64 image ?

Hi @ondrejbudai thank you for your fast answer !
I'm not sure that I understand what you mean by Building Fedora IOT images isn't currently supported by osbuild-composer as it does work on my machine running fedora33-workstation-x86 (maybe it shouldn't by the way, see at bottom), and is also demonstrated to work on a supposedly aarch64 machine in this tutorial.
About virtualization:
I started fedora33-server-aarch64 without issue in qemu emulating aarch64 on x86 but it was painfully slow on a decent machine, I wouldn't recommend it (10+min boot time, good luck for the build :joy: ).
However i'm currently running 2 kvm VMs on my centos8 rpi4 including fedora33-server-aarch64 (in order to build the image I need, which I did not success yet because the Fedora IoT type is not present).
I'm also currently deploying a new rpi4 with fedora33-server-aarch64 as host instead of VM, because I initially thought that the type Fedora IoT Commit was maybe not available because osbuild can't run kvm in kvm on rpi4, so i will enable kvm on this host. I can provide it for your tests if that is something you would see fit.
I'm currently stuck by this issue, could you help me by providing the way to enable manually this option so I can test the build on the new host ? I'm currently building an ostree OS for a commercial device we're going to release quite soon.
Bottom: Writing these lines I realized I actually successfully built a Fedora IOT image without additional packages on the x86 machine, I wonder what is the state of this image. As far as I understand it should not be functional as it must contain x86 packages in an aarch64 image ?

I'm sorry, I missed one word: Building Fedora IoT images for aarch64 isn't currently implemented. Building IoT images is available only for x86_64.

I'm sorry, I missed one word: Building Fedora IoT images for aarch64 isn't currently implemented. Building IoT images is available only for x86_64.

Hi @ondrejbudai thank you for your answer.
Is it on the roadmap though ? To me IoT sounds more like arm than x86. I'm willing to help implementing and testing if you can guide me a little on what's to be done.
Are there alternatives to building our own OS using ostree for aarch64 rpi ?

Hi @ondrejbudai thank you for your answer.
Is it on the roadmap though ? To me IoT sounds more like arm than x86. I'm willing to help implementing and testing if you can guide me a little on what's to be done.
Are there alternatives to building our own OS using ostree for aarch64 rpi ?

Hi @pciavald! Thanks for your interest! Fedora IoT support for aarch64 is definitely something we would like to have, and it should not be a lot of work, I think.
This is what we'll need to do:
Definition
Each image type is defined for each distro and architecture in internal/distro/*/distro.go. We'd need to add an entry here for Fedora/aarch64. Take inspiration from RHEL for Edge as well as Fedora/x86_64.
As we are not the single source of truth for what makes Fedora IoT, we will need to look at the official definitions / .ks / commits to make our definition as close as possible to that. We don't want just a Fedora-based ostree image type, but actually Fedora IoT (or we would have to name it something else). @nullr0ute is the authority on Fedora IoT, so he would hopefully be happy to review/ack whatever we come up with, and @gicmo has done this in the past so might also have some insight.
Testing
All image types need to be tested in our CI. For this, look in test/cases, and take inspiration from the current RHEL for Edge tests there.

Here is the official kickstart mentioned above: https://pagure.io/fedora-kickstarts/blob/main/f/fedora-iot.ks

RHEL for Edge would be part of this issue, as ARM is a key target platform for edge devices.

We do support aarch64 for RHEL for Edge.

I think the definition of Fedora-IoT is here: https://pagure.io/fedora-iot/ostree/blob/f34/f/fedora-iot-base.json.
To support building Fedora-IoT type image on aarch64, all that's left is testing?

fedora-iot-commit as supported on aarch64 since https://github.com/osbuild/osbuild-composer/pull/2461


Extended hurricane model

Added STORM database filetype to the hurricane_models. Requires some attention in usage due to arbitrary selected starting year (Starting year in input files is 0.00 even for historic events)

ok, its a bit messy to see now what the changes are..let me try to merge master into mosaic first..

hmm it still thinks it changing 25 files..

its probably ok, (and the hurricane model changes look fine) but I am going to make a new clean PR...

close in favour of #35


query_job_list bug

System information

Have I written custom code (no):
OS Platform and Distribution (Mac 14.2.1 (23C71) ):
FATE Flow version (v2.1.0):
Python version (use command: python --version):

Describe the current behavior
当数据库表 t_job 中有记录的 f_parties 字段的值有多种格式，而flow中只考虑了一种形式引起的。
我现在表中f_parties 的值如：["JG0100001100000010", "JG0100001100000000"]，flow对应的代码解析时就会出错，造成query_job_list返回为空了。
问题代码：fate_flow/python/fate_flow/controller/job.py的 224行
具体代码：
    @classmethod
    def query_job_list(cls, limit, page, job_id, description, partner, party_id, role, status, order_by, order,
                       user_name):
        # Provided to the job display page
        offset = limit * (page - 1)
        query = {'tag': ('!=', 'submit_failed')}
        if job_id:
            query["job_id"] = ('contains', job_id)
        if description:
            query["description"] = ('contains', description)
        if party_id:
            query["party_id"] = ('contains', party_id)
        # if partner:
        #     query["parties"] = ('contains', partner)
        if role:
            query["role"] = ('in_', set(role))
        if status:
            query["status"] = ('in_', set(status))
        by = []
        if order_by:
            by.append(order_by)
        if order:
            by.append(order)
        if not by:
            by = ['create_time', 'desc']
        if user_name:
            query["user_name"] = ("==", user_name)
        jobs, count = JobSaver.list_job(limit, offset, query, by)
        jobs = [job.to_human_model_dict() for job in jobs]
        lst_job = []
        for job in jobs:
            job['partners'] = set()
            for _r in job['parties']:  # job['parties']返回的数据有可能为：[{"role": "local", "party_id": ["0"]}]，也有可能为["JG0100001100000000"]
                if isinstance(_r, dict):
                    job['partners'].update(_r.get("party_id"))  # 原代码中没有经过类型判断，这里是有bug的
                elif isinstance(_r, str):
                    job['partners'].update(_r)
                else:
                    continue
            job['partners'].discard(job['party_id'])
            job['partners'] = sorted(job['partners'])
            if partner and str(partner) not in job['partners']:
                continue
            lst_job.append(job)
        return count, lst_job

Describe the expected behavior
Other info / logs Include any logs or source code that would be helpful to
diagnose the problem. If including tracebacks, please include the full
traceback. Large logs and files should be attached.

fateflow/logs/$job_id/fate_flow_schedule.log: scheduling log for a job
fateflow/logs/$job_id/* : all logs for a job
fateflow/logs/fate_flow/fate_flow_stat.log: a log of server stat
fateflow/logs/fate_flow/fate_flow_schedule.log: the starting scheduling log for all jobs
fateflow/logs/fate_flow/fate_flow_detect.log: the starting detecting log for all jobs

Contributing

Do you want to contribute a PR? (yes/no):
Briefly describe your candidate solution(if contributing):

感谢您的反馈，后续版本我们会跟进这个问题并优化


[WIP] API definition.

Added a swagger API definition for UI purposes.
A couple of notes:

Username will be set in the UI not the API
Local/static file requests are handled primitively, however I assumed its not necessary to rework, since the API will only ever receive requests for 3 known files.
The API has the following capabilities:

Get/Update a user ConfigMap (GPU, and EnvVar reading is included in this, will split if necessary)
Remove a value from a user ConfigMap (with path)
Get Sizes (Both full json readout of just the names), Also get a single size
Get Images (Names only)

I just realised it was neccessary to "hack" the service.py file, what should be done about that?

Can you add a route to the openshift directory as well?
It is also missing serviceaccount, role and rolebinding to be able to access and modify ConfigMaps

It would be also good to add example profiles ConfigMap so that someone trying this out does not get "ConfigMap not found error"

Removed the ClusterIP, added Route, Service Account, custom Role and Rolebinding, and an example ConfigMap for testing. The API should be easier to test now.


Cannot read properties of null (reading 'offset') on custom handler getSelection()

I was trying to implement a custom handler for image loading, which gave me the following error:
quill.js?v=ad3ea11b:12611 Uncaught TypeError: Cannot read properties of null (reading 'offset')
at quill.js?v=ad3ea11b:12611:26
at Array.map ()
at Proxy.normalizedToRange (quill.js?v=ad3ea11b:12608:31)
at Proxy.getRange (quill.js?v=ad3ea11b:12597:25)
at Proxy.update (quill.js?v=ad3ea11b:12734:43)
at Proxy.update (quill.js?v=ad3ea11b:13811:20)
at Proxy.getSelection (quill.js?v=ad3ea11b:13705:10)
at Toolbar.imageHandler (EditPublicationPage.vue:42:31)
at HTMLButtonElement. (quill.js?v=ad3ea11b:17165:31)
I downgraded to 1.3.7 from 2.0.2 (also tested 2.0.1 and 2.0.0 with no success) and the same code now works flawlessly.
The Handler:
function imageHandler () {
if (quill.value) {
quill.value.focus()
const range = quill.value.getSelection() // this line throws error
const value = prompt('please copy paste the image url here.')
if (value) {
quill.value.insertEmbed(range.index, 'image', value, Quill.sources.USER)
}
}
}
all source code of my component:
``

``

I ran into a similar issue using vue with refs, also described here: https://github.com/slab/quill/issues/4293
Changing to a plain variable resolved things for me.
//  ❌ doesn't work with Quill2 for me
const quillRef = ref<Quill | null>(null)
...
onMounted(() => {
  quillRef.value = new Quill(...)
});

// ✅  works with quill2
let quill: Quill | null = null

onMounted(() => {
   quill = new Quill(...)
})

thanks @jxjj , that worked

thanks!! it works

thanks!! and there is another way
// ✅
const quillRef = ref<Quill | null>(null)

onMounted(() => {
  quillRef.value = markRaw(new Quill(...))
});


Add Gaussian smoothing before undersampling

Status
READY
Description
Gaussian smoothing is performed previous to the scaling operation if
zoom factor < 1. This reduces the aliasing introduced by the
undersampling operation.
Choice of sigma according to:
Cardoso et al., "Scale factor point spread function matching:
beyond aliasing in image resampling", MICCAI 2015
Currently, labels are also smoothed. I wonder if there are disadvantages to this.
Types of changes

[x] New feature (non-breaking change which adds functionality)
[x] My code follows the code style of this project.
[x] All new and existing tests passed.

Todos

[ ] Tests
[ ] Documentation

Impacted Areas in Application

Spatial scaling

Closes #242

When it is used as a trainable layer, smoothing may not be needed.

Hi @YipengHu, I'm not sure what you mean. Can you give an example?

@fepegar sorry - wasn't very clear. If the re-sampling code is used in data processing, pre- or post-, then yes, smoothing prevents aliasing. If this code is used after a learnable layer, e.g. a convolution, in training, the smoothing could be redundant. Although I don't see any serious harm in doing so apart from small increase of computation, I think an option to turn smoothing off plus a comment perhaps are enough here.

Data distribution should be the same for both training and testing, so I would argue that it should be always on. But I guess having a flag would not hurt!

Agree with @YipengHu: if scaling is used inside a network, it might be beneficial to let the network learn how to "smooth" rather than handcraft it. As such an option to turn it off would make sense to me. The default can be to apply smoothing to try and respect Nyquist.

This code is for augmentation, so it would be prior to inputting data into the network. I don’t see a situation where you might want to downsample data without respecting nyquist.

Makes sense. I didn't realise it was in an augmentation-specific context.

fine, although not sure you can stop users to insert it in networks - then again, at that level they can do whatever they want...


Make the @required_version decorator a built-in

The @required_version decorator is an interesting tool to have ReFrame skip incompatible tests. Although we currently don't use it so much, it will become more relevant when we start creating test libraries and tests may be run by different ReFrame versions that may or may not support some features that the test require. The problem with the decorator now is that it is executed too late, i.e., after the class creation, so we couldn't capture features like the pipeline hooks when they were added. Therefore, I suggest making a  built-in, such as the variable() and parameter(), which execute even before the class body is executed.

Would it make sense to set this through the __init_subclass__ hook instead?
class Foo(rfm.RegressionTest, required_version=[x.x.x, y.y.y]):
   ...

To me, this feels more natural than having something in the class body like
class Bar(Foo):
    required_version(x.x.x, y.y.y)
    def __init__(self):
        ...

That way we can leave the class body for more common python-like assignments as done with the variable or parameter built-ins.

I've no problem where it fits best. The current problem is that the decorator can only cover a small set of features. Also we are free to choose a better name.


[Question]: Faiss Vector Store adding and updating new data

Question Validation

[X] I have searched both the documentation and discord for an answer.

Question
I am using Faiss vector store and created it using the following code.
    embed_dim = 768
    faiss_index = faiss.IndexFlatL2(embed_dim)
    vector_store = FaissVectorStore(faiss_index=faiss_index)
    storage_context = StorageContext.from_defaults(
        vector_store=vector_store)

    index = VectorStoreIndex(
        nodes=all_nodes,
        storage_context=storage_context,
        use_async=True,
        show_progress=True,
        insert_batch_size=4096
    )
        index.storage_context.persist(
        persist_dir="index")

I have created the nodes manually and also assigned relationship between them.
Now what I want is how can I load this current indexes and  add, update and delete data from it and save it again.
I think right now the delete functionality is not support but how can I add data to it.
Currently, I am loading the index and extracting nodes from it and then recreating index but since the embedding is None, the code generated embeddings for all the data which is not very efficient.
Does Faiss not store the embeddings which can be looked into?

FAISS does not support deleting. Otherwise though, dosu is correct

One more questions, since Faiss store embeddings and not the text. How can I access embeddings of each node from faiss vector store.


Fix numerical comparison error of test_patternfit_stats

What does the code in this PR do / what does it improve?
An error is seen in test: https://github.com/XENONnT/straxen/actions/runs/7918467685/job/21616952222, from a numerical comparison assert (1.0000000000000002 >= 0 & 1.0000000000000002 <= 1).
Can you briefly describe how it works?
This PR uses math.isclose in the test to solve the error. When 1.0000000000000002 is close to 1.0, the argument of assert is still true.
Can you give a minimal working example (or illustrate with a figure)?
Please include the following if applicable:

[ ] Update the docstring(s)
[ ] Update the documentation
[ ] Tests to check the (new) code is working as desired.
[ ] Does it solve one of the open issues on github?

coverage: 91.269% (-0.06%) from 91.327%
when pulling 27feb4fcc79c5ba9b5b799a8364ea7ccbb11b895 on fix_binom_test
into 2cc3473957a2875653a3fc5f73b643d55033c1d4 on master.

Hey Dacheng, thank you for fixing the test! I am surprised, though; I never see it fail

Hey Dacheng, thank you for fixing the test! I am surprised, though; I never see it fail

It is a very rare comer case. :)


WIP: get ready for rever tag

Codecov Report

Merging #104 into master will decrease coverage by 0.21%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master     #104      +/-   ##
==========================================
- Coverage   97.14%   96.92%   -0.22%
==========================================
  Files           6        7       +1
  Lines        2275     2276       +1
  Branches      514      514
==========================================
- Hits         2210     2206       -4
- Misses         33       37       +4
- Partials       32       33       +1

Impacted Files
Coverage Δ

shed/event_streams.py
92.27% <0%> (-0.61%)
:arrow_down:

shed/tests/test_streams.py
98.92% <0%> (-0.07%)
:arrow_down:

shed/tests/__init__.py
100% <0%> (ø)

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 6f3ff7f...27623a3. Read the comment docs.

The test coverage will be fixed in the test overhall.


[FancyZones] Keep more than one zone in the app history

The "move newly opened windows to last known zone" option remembers only the last zone for each monitor.
Probably would be better to have a queue of possible zones (instead of one zone) for each app and if the highest priority zone doesn't contain an app window, place the window in that zone. If all zones contain the app, place all other windows in the zone with the highest priority. In case the app is unsnapped from the zone (manually moved outside the zone, including using keyboard shortcuts), the zone is removed from the history.
Example: if you snap explorer windows to zones 1, 2, 3, after you close and reopen them, the first will be automatically snapped to the 3rd zone, 2nd window to the 2nd zone, and the 3rd window to the 1st zone.
Originally posted by @SeraphimaZ in https://github.com/microsoft/PowerToys/issues/16328#issuecomment-1046839021

You closed #18907 as a duplicate but it doesn't seem correct (unless there is some other side effects in action). Issue #18907 is about the window being moved to the wrong monitor after a manual sleep of the PC. It has nothing to do with the number of app windows since none of the windows are in the correct zone.

@SeraphimaZykova, I tend to agree with @Nahor here. Without understanding greater context and implications of the original issue described here as #16659, the issue described under #19193 appears unrelated since it's more specific to a daily issue each morning after waking the laptop/PC from sleep.
This issue occurs even when you have a single app (and single window instance of an app) distinctly snapped to a particular zone on the monitor extension without any other apps sharing that same zone.  I, too, opted for PowerToys/FancyZones because I was informed and read that this problem with awake from sleep does not exist like it does with other zone partition apps. Sadly, it does happen exactly the same way as with other apps.  If I leave my laptop during the workday for a few hours and monitor goes into standby mode, the problem does not occur.  It's only overnight when the laptop eventually goes to sleep when this happens.  You can imagine the frustration of starting each workday having to face this recurring problem.
Please double check you have not dismissed the reported issue prematurely and unintentionally/incorrectly lumped it in under an unrelated issue.  Thank you.

Hello
Is a fix for this bug still in the works or is it not being fixed?


goreleaser: 0.166.0 -> 0.166.2

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://github.com/goreleaser/goreleaser/releases.
meta.description for goreleaser is: "Deliver Go binaries as fast and easily as possible"
meta.homepage for goreleaser is: "https://goreleaser.com"
meta.changelog for goreleaser is: ""
Updates performed

Golang update

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact

Checks done (click to expand)

built on NixOS

The tests defined in passthru.tests, if any, passed

/nix/store/23qjik48f5dyn9qmn15vddfgikjabbi0-goreleaser-0.166.2/bin/goreleaser passed the binary check.

1 of 1 passed binary check by having a zero exit code.

1 of 1 passed binary check by having the new version present in output.

found 0.166.2 with grep in /nix/store/23qjik48f5dyn9qmn15vddfgikjabbi0-goreleaser-0.166.2

found 0.166.2 in filename of file in /nix/store/23qjik48f5dyn9qmn15vddfgikjabbi0-goreleaser-0.166.2

directory tree listing: https://gist.github.com/c9c076a2c7aef945963075076aa5fb9c

du listing: https://gist.github.com/f2c2961d2b89d004cb5c4f92aa2c8253

Rebuild report (if merged into master) (click to expand)

4 total rebuild path(s)

1 package rebuild(s)

1 x86_64-linux rebuild(s)
1 i686-linux rebuild(s)
1 x86_64-darwin rebuild(s)
1 aarch64-linux rebuild(s)

First fifty rebuilds by attrpath
goreleaser

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/23qjik48f5dyn9qmn15vddfgikjabbi0-goreleaser-0.166.2 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A goreleaser https://github.com/r-ryantm/nixpkgs/archive/5d64abee44f4b7b13e16ea910eadcb79c998c2e7.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/23qjik48f5dyn9qmn15vddfgikjabbi0-goreleaser-0.166.2
ls -la /nix/store/23qjik48f5dyn9qmn15vddfgikjabbi0-goreleaser-0.166.2/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

1 package built:

goreleaser

Maintainer pings
cc @c0deaddict @endocrimes @sarcasticadmin @kalbasit for testing.

Result of nixpkgs-review pr 125035 1

1 package built:

goreleaser


Unchecking a required  does not make the form $invalid

Plunkr: http://plnkr.co/edit/NZAg38SAjgSQzbRTl9WY?p=preview
I'm using Angular form validation. An unchecked <ion-checkbox> with required attribute correctly makes the form $invalid. However, if I check it then uncheck it, the form does not become $invalid again.
This problem does not happen with a plain <input type="checkbox">, as demonstrated in the plunkr.

Greetings @imgx64!
I've closed this issue because my sensors indicated it was old and inactive, and may have already been fixed in recent versions of Ionic. However, if you are still experiencing this issue, please feel free to reopen this issue by creating a new one, and include any examples and other necessary information, so that we can look into it further.
Thank you for allowing me to assist you.

I got the same problem. What should I do?

+1

I got the same problem =/


Decouple MQTT and USB code

Hey,
So if we want to create an API for xcomfortd and then create a proper HA integration, we somehow need to be able to send data from the USB stick to either MQTT part or the API part of the code, or maybe both.
I suggest that we create a interface that the USB part sends data to. Then MQTT and API part implement that interface.
An added benefit to this is that testing for MQTT and the API would be easier since it does not require the USB stick plugged in while developing.

FYI: I cloned your addon code to https://github.com/karloygard/hassio-addons and expanded the HA discovery code a little. It seems to work reasonably well and has received some testing by another user as well.
I agree that making a proper HA integration would be preferable, have you thought any further about how to do that? You appear to be more knowledgeable about those things than me.

Yeah, we need to make an API in xComfortd that uses websockets to push events back and fourth. I will try to take some time to describe what I think we need to do soon :)
When that is done we can make an integration in Home Assistant and make a pull request to the HA repo so it a seemless part of Home Assistant in the future.

As far as I can tell, the Eaton xComfort Bridge is a completely different device from those supported by this code.

As far as I can tell, the Eaton xComfort Bridge is a completely different device from those supported by this code.

And I think you are right. My understanding is that Eatons marketing announcements now indicates that their Bridge is the future and that Home Controller is likely to be phased out at some point. How about considering rewriting your code to support the Bridge?  Regretfully I'm not a programmer myself, otherwise I would have done it. 🙄
Do you think it is realistic to make the CKOZ-00/14 coexist with the Bridge using your HA Add-on code as-is, assuming it is possible to generate a correct Datapoint-list file?