Need to add image registration methodologies

There are currently no methods to perform image registration / estimate relative offsets between images.
Options include:

Example code provided by Jason Wang (see slack)
The jwst pipeline Stage 3 process (very memory intensive for a large number of integrations)
Using gaia sources within images / subarrays to track relative offsets.

Could also look at reducing computational intensity for these by average subsets of integrations (or all of them), or reducing the precision of values in the data arrays.

@AarynnCarter Since this is handled by the JWST module of pyKLIP now, shall we close this issue?

Sounds good!


fix(release): try to fix release config

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 90.942%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
251

Relevant Lines:
276

💛  - Coveralls


fix(ctranslate2): Add missing cuda & cudnn deps

Hi,
Just adding the missing cuda & cudnn deps which I found missing and breaking the ctranslate2 build.
Best,
M

Thanks @ms1design , hadn't build this one myself 🙏


[HUDI-5594] Add metaserver bundle validation

Change Logs
Add metaserver bundle validation
Impact
check the metaserver bundle jar
Risk level (write none, low medium or high below)
medium
Documentation Update
Describe any necessary documentation update if there is any new feature, config, or user-facing change

The config description must be updated if new configs are added or the default value of the configs are changed
Any new feature or user-facing change requires updating the Hudi website. Please create a Jira ticket, attach the
ticket number here and follow the instruction to make
changes to the website.

Contributor's checklist

[ ] Read through contributor's guide
[ ] Change Logs and Impact were stated clearly
[ ] Adequate tests were added if applicable
[ ] CI passed

this commit passed. the last commit has no impact. we should be able to land

last commit passed after rerun


luaPackages.luv: cleanup build

Motivation for this change

Fix ~~https://github.com/NixOS/nixpkgs/issues/79870~~ ~~https://github.com/NixOS/nixpkgs/issues/80704~~ https://github.com/NixOS/nixpkgs/issues/81206.
Make luv's build less hacky, clearer and more maintainable.

Things done

Remove passthru of libluv which was always too confusing IMO - I think I understand the original motivation behind that but I don't think it's worth the maintenance / confusion burden it introduced.
Make luaPackages.compat53 install it's c-api files luv needs in order to build cleanly.
Tested Neovim builds and runs.

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

[X] NixOS
[ ] macOS - Darwin users please see the TODOs I've left.
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[X] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[X] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[X] Ensured that relevant documentation is up to date
[X] Fits CONTRIBUTING.md.

ccing people involved in https://github.com/NixOS/nixpkgs/issues/79870 :

@manveru, @rvolosatovs and @Ma27 (Neovim maintainers)
@teto
@bjornfor
@ArdaXi
@mjlbach
@jokogr
@chkno

@GrahamcOfBorg build neovim

Note: Although https://github.com/NixOS/nixpkgs/issues/79870 was closed by @bjornfor , I doubt that it builds on Darwin as expected. nix-build -A luajit.pkgs.luv.libluv still fails for me on latest master:
these derivations will be built:
  /nix/store/9snxwz16ahc0rbdw4xkwhncgs3cgxv4a-luajit-2.1.0-beta3-luv-1.34.1-1.drv
building '/nix/store/9snxwz16ahc0rbdw4xkwhncgs3cgxv4a-luajit-2.1.0-beta3-luv-1.34.1-1.drv'...
unpacking sources
unpacking source archive /nix/store/f0az73f8fi7fp7cz55iapzwr0wh1kd93-luv-1.34.1-1.src.rock

Done. You may now enter directory
luv-1.34.1-1/luv-1.34.1-1
and type 'luarocks make' to build.
source root is ./luv-1.34.1-1/luv-1.34.1-1
setting SOURCE_DATE_EPOCH to timestamp<PHONE_NUMBER> of file ./luv-1.34.1-1/luv-1.34.1-1/src/work.c
patching sources
configuring
building
patching script interpreter paths in .
./deps/lua-compat-5.3/tests/test.lua: interpreter directive changed from "/usr/bin/env lua" to "/nix/store/1m8vh1byjnjmjkpdidcqc37cykgsqjap-luajit-2.1.0-beta3/bin/lua"
installing

luv 1.34.1-1 depends on lua >= 5.1 (5.1-1 provided by VM)
Warning: unmatched variable LUA_LIBDIR
-- The C compiler identification is GNU 9.2.0
-- The ASM compiler identification is GNU
-- Found assembler: /nix/store/1kn7fi3hhi33jms3113riyzwyn2yqpqd-gcc-wrapper-9.2.0/bin/gcc
-- Check for working C compiler: /nix/store/1kn7fi3hhi33jms3113riyzwyn2yqpqd-gcc-wrapper-9.2.0/bin/gcc
-- Check for working C compiler: /nix/store/1kn7fi3hhi33jms3113riyzwyn2yqpqd-gcc-wrapper-9.2.0/bin/gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Found LIBUV: /nix/store/w89ndqsb7ig22mw5hk7k7zfvxmhx44xb-libuv-1.34.2/lib/libuv.so
-- Lua: using information from luarocks
-- LUA_LIBDIR:
-- LUA_INCDIR: /nix/store/1m8vh1byjnjmjkpdidcqc37cykgsqjap-luajit-2.1.0-beta3/include/luajit-2.1
-- LUA: /nix/store/1m8vh1byjnjmjkpdidcqc37cykgsqjap-luajit-2.1.0-beta3/bin/luajit
-- Lua library: LUA_LIBRARIES-NOTFOUND
-- Configuring done
-- Generating done
-- Build files have been written to: /build/luv-1.34.1-1/luv-1.34.1-1/build.luarocks
Scanning dependencies of target luv
[ 50%] Building C object CMakeFiles/luv.dir/src/luv.c.o
[100%] Linking C shared library libluv.so
[100%] Built target luv
[100%] Built target luv
Install the project...
-- Install configuration: ""
-- Installing: /nix/store/f0a65c2fw8l24yb7y21h0bizzlq4iww7-luajit-2.1.0-beta3-luv-1.34.1-1/luv-1.34.1-1-rocks/luv/1.34.1-1/lib/libluv.so.1.34.1
-- Installing: /nix/store/f0a65c2fw8l24yb7y21h0bizzlq4iww7-luajit-2.1.0-beta3-luv-1.34.1-1/luv-1.34.1-1-rocks/luv/1.34.1-1/lib/libluv.so.1
-- Installing: /nix/store/f0a65c2fw8l24yb7y21h0bizzlq4iww7-luajit-2.1.0-beta3-luv-1.34.1-1/luv-1.34.1-1-rocks/luv/1.34.1-1/lib/libluv.so
-- Installing: /nix/store/f0a65c2fw8l24yb7y21h0bizzlq4iww7-luajit-2.1.0-beta3-luv-1.34.1-1/luv-1.34.1-1-rocks/luv/1.34.1-1/lib/pkgconfig/libluv.pc
-- Installing: /nix/store/f0a65c2fw8l24yb7y21h0bizzlq4iww7-luajit-2.1.0-beta3-luv-1.34.1-1/include/luv/luv.h
-- Installing: /nix/store/f0a65c2fw8l24yb7y21h0bizzlq4iww7-luajit-2.1.0-beta3-luv-1.34.1-1/include/luv/util.h
-- Installing: /nix/store/f0a65c2fw8l24yb7y21h0bizzlq4iww7-luajit-2.1.0-beta3-luv-1.34.1-1/include/luv/lhandle.h
-- Installing: /nix/store/f0a65c2fw8l24yb7y21h0bizzlq4iww7-luajit-2.1.0-beta3-luv-1.34.1-1/include/luv/lreq.h
cp: cannot stat '/nix/store/f0a65c2fw8l24yb7y21h0bizzlq4iww7-luajit-2.1.0-beta3-luv-1.34.1-1/luv-1.34.1-1-rocks/luv/1.34.1-1/lib/libluv.so': No such file or directory

Error: Failed copying /nix/store/f0a65c2fw8l24yb7y21h0bizzlq4iww7-luajit-2.1.0-beta3-luv-1.34.1-1/luv-1.34.1-1-rocks/luv/1.34.1-1/lib/libluv.so to /nix/store/f0a65c2fw8l24yb7y21h0bizzlq4iww7-luajit-2.1.0-beta3-luv-1.34.1-1/lib/lua/5.1/libluv.so
builder for '/nix/store/9snxwz16ahc0rbdw4xkwhncgs3cgxv4a-luajit-2.1.0-beta3-luv-1.34.1-1.drv' failed with exit code 1
error: build of '/nix/store/9snxwz16ahc0rbdw4xkwhncgs3cgxv4a-luajit-2.1.0-beta3-luv-1.34.1-1.drv' failed

Just as before. Hence I think this PR is still relevant. It's just that I can't fiddle around with the darwin specific build changes we need to set in order for Neovim to build on Darwin. Help will be appreciated.

This PR fixed the build for me on NixOS using latest nixos-unstable. I ran into https://github.com/NixOS/nixpkgs/issues/79870

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/why-does-gconf-depends-on-python2/5995/5

@thefloweringash Thanks a lot for your help!
Everything should be ready now for a Darwin build test by @GrahamcOfBorg .

Just to sum up the bigpicture issues:

luv either installs the module or the include directory but not both (which in my tests seem to be problematic here). Would be nice to have someone send a PR upstream (like a new target rather than have all checks depend on BUILD_MODULE).
the lua infrastructure doesn't play well with cmake build based packages. It seemed possible to pass flags to cmake via luarocks but in the end it isn't thus I've opened https://github.com/luarocks/luarocks/issues/1160

Previously we had a luv lua module that contained an alternative luv built via cmake, here we just have a luv.

@GrahamcOfBorg build neovim

@doronbehar what’s the status on this? Is it ready to merge?

Not really @lovesegfault . If you'd like to merge it on your own branch it should make both nvim-client and neovim compile succesfully, but @teto and I still have an unresolved issue, see https://github.com/NixOS/nixpkgs/pull/80528#pullrequestreview-364539332
I'm not sure myself what would be the best way to go. Here's my summarize of the conclusions from the discussion:

Using cmake (mkDerivation) build for luv makes lua.pkgs.nvim-client fail to build because it doesn't detect luv.
Using buildLuarocksPackage would make nvim-client detect luv and use it but then luarocks make is used instead of what stdenv does and then cmake is called by luarocks with different flags and it results in a configuration error, see https://github.com/NixOS/nixpkgs/pull/80528#pullrequestreview-364539332
Using buildLuaPackage or toLuaModule for the mkDerivation version of luv, builds luv and neovim OK but nvim-client still fails to detect luv if it was built that way.

If you ask me, Upstream does has some room for improvements with the way it handles luarocks make's cmake call. But in anycase, we need to fix (3) which is completely under our responsibility, and we'll be able to get away with upstream's lack of support for luarocks make. I tried exploring deeply our Lua build system and I couldn't figure out why do toLuaModule and buildLuaPackage don't work when they wrap mkDerivation.

Done in #81483

@teto I tried to debug why when luv is built with toLuaModule, nvim-client complains with:
error: attribute 'rocksSubdir' missing, at /var/src/nixpkgs/pkgs/development/interpreters/lua-5/build-lua-package.nix:124:86
(use '--show-trace' to show detailed location information)

I tried adding that manually to luv's derivation after comparing it with the value of the buildLuarocksPackage generated luv derivation. Here are the missing files luarocks install creates and cmake && make don't:
├── luv-1.34.2-0-rocks
│   ├── luv
│   │   └── 1.34.2-0
│   │       ├── doc
│   │       │   ├── docs.md
│   │       │   ├── LICENSE.txt
│   │       │   └── README.md
│   │       ├── luv-1.34.2-0.rockspec
│   │       └── rock_manifest
│   └── manifest

luv-1.34.2-0.rockspec and what's in docs/ can easily  be retrieved or superficially created, but the file rock_manifest contains:
rock_manifest = {
   doc = {
      ["LICENSE.txt"] = "3b83ef96387f14655fc854ddc3c6bd57",
      ["README.md"] = "0f18a578793f7eaf68f827dc5d9a187e",
      ["docs.md"] = "4622f9c76688774e9bb31a7e588034fa"
   },
   lib = {
      ["luv.so"] = "baff2d4777e17bd03a41172e0188e88d"
   },
   ["luv-1.34.2-0.rockspec"] = "66b6a8b3b69205b104767b5f1fa5ea4e"
}

Which seem to me like hashes of the resulting files. I can't imagine we can reproduce this file without luarocks make or luarocks install. I edited some of my previous comments to reflect this new revelation.
This new finding definitly points out beyond all doubt that upstream (luarocks and / or luv) need to be further patched in order to finally fix this. I'll put my further efforts on this once again I'll have time. If anyone else wants to help on this, please refer to https://github.com/luvit/luv/pull/459#issuecomment-592950786 for more info.

Unless, we'll decide we don't mind having both a libluv derivation built using mkDerivation (used only by neovim) and another, (completely) automatically generated luv derivation built using buildLuarocksPackage (which will be used by nvim-client). This is the current state of this PR.
Please forgive me @teto for insistingly stating this is good enough, considering upstream's complicated flaws no body seems to care besides us.

Hey, I'd like just to report that neovim from unstable (13e7a3e1127) seems to be broken on macOS. Patching this version with this PR fixes this.

note https://github.com/luvit/luv/pull/464. I've been looking into a broader fix for lua + cmake. The best fix is adding cmake variables to the generated luarocks, which suggests either parsing "$cmakeFlags" to remove the -D prefixes or relying on structured attributes https://discourse.nixos.org/t/structured-cmakeflags-attrs/6261 which may take some time. Meanwhile we need some faster fix if the build is broken on macos. I am not sure this makes things simpler (+87 −32) I would rather see a one-liner but I dont use mac so if that works... xD

With their latest version and this preBuild:
     sed -i 's,\(option(WITH_SHARED_LIBUV.*\)OFF,\1ON,' CMakeLists.txt
     sed -i 's,\(option(BUILD_MODULE.*\)ON,\1OFF,' CMakeLists.txt
     sed -i 's,\(option(BUILD_SHARED_LIBS.*\)OFF,\1ON,' CMakeLists.txt
     sed -i 's,\(option(BUILD_STATIC_LIBS.*\)OFF,\1ON,' CMakeLists.txt

The only error I get is:
CMake Error at cmake_install.cmake:61 (file):
  file cannot create directory: /var/empty/local/include/luv.  Maybe need
  administrative privileges.

Meaning the missing piece as of now is Luarocks support for cmake flags. I tried adding this ugly sed command to preBuild:
     sed -i 's,^option(BUILD_MODULE.*),\0\nset(CMAKE_INSTALL_PREFIX\, "${placeholder "out"}"),' CMakeLists.txt

So it'll result in an additional line in CMakeLists.txt with:
set(CMAKE_INSTALL_PREFIX, "/nix/store/12628ckdlcspf945vyj3ah9zpjadv19v-luajit-2.1.0-beta3-luv-1.34.2-2")

But that didn't change that default prefix error.

@doronbehar are you still investigating the cmake error?

HI, I just tried to install neovim with nix-darwin and I am getting the same build error:
...
[100%] Building C object src/nvim/CMakeFiles/nvim.dir/xdiff/xprepare.c.o
make[2]: *** No rule to make target '/nix/store/nyf0qhx47vad558rcv8bskfkdvs9wwav-luajit-2.1.0-beta3-luv-1.34.1-1/lib/lua/5.1/libluv.dylib', needed by 'bin/nvim'.  Stop.
make[2]: *** Waiting for unfinished jobs....
[100%] Building C object src/nvim/CMakeFiles/nvim.dir/xdiff/xutils.c.o
make[1]: *** [CMakeFiles/Makefile2:5012: src/nvim/CMakeFiles/nvim.dir/all] Error 2
make: *** [Makefile:152: all] Error 2
builder for '/nix/store/bpxyw4r1h2wklcwc6kiisq2n9cps67k9-neovim-unwrapped-0.4.3.drv' failed with exit code 2
cannot build derivation '/nix/store/84wks6big9cg91xw8pym4j6kbig22i5s-neovim-0.4.3.drv': 1 dependencies couldn't be built
error: build of '/nix/store/84wks6big9cg91xw8pym4j6kbig22i5s-neovim-0.4.3.drv' failed

As neovim is one of the first packages a user might install after installing nix, shouldn't this be fixed ASAP?

That has been fixed quite some time ago by the reverts.

That has been fixed quite some time ago by the reverts.

Though this is evidence that a Darwin user is still encountering this which is troubling but I have no idea why is that.
@amckinlay I'm sorry to hear about your experience, but unfortunately this issue is a nasty one which I think most of the involved consider it "upstream's fault". The discussions and comments above should explain it more thoroughly, but basically, we are stuck because of: https://github.com/luarocks/luarocks/issues/509 and/or https://github.com/luarocks/luarocks/issues/339 . Note that we are also stuck with Luarocks 3.2.1 because updating it will break Neovim for all of us. See https://github.com/luarocks/luarocks/issues/1155 .
Even if we'd try to solve this without waiting for upstream, a cleaner fix (then this PR) is orthogonal to some other big changes to Nixpkgs:

https://github.com/NixOS/nixpkgs/pull/85103
https://discourse.nixos.org/t/structured-cmakeflags-attrs/6261
https://github.com/NixOS/rfcs/pull/13

And more... :disappointed:

This is evidence that a Darwin user is still encountering this issue, which is troubling but I have no idea why is that.

@doronbehar No my revert was for the darwin side. https://hydra.nixos.org/job/nixpkgs/trunk/neovim.x86_64-darwin
As I mentioned in the pr, currently we can't update luv or luarocks, updating either will break one of the platforms.
@amckinlay I would suggest ask a question on irc or discourse, I suspect you've not updated your channel (eg. multi-user) but this is not the right place for debugging that.

@LnL7 @doronbehar Okay, it was fixed. For some reason all my channels were missing so my sudo nix-channel --updates haven't been doing anything for a while. :(


It crashes.....

I click the teleplot button, and it opens teleplot.  I then choose /dev/ttyACM0 on the serial menu.  When I click open, nothing happens until I get a window saying it clashed.  It asked if I wanted to submit a report about VScode crashing, so I did, but it seems to be a problem with teleplot.  I was sending serial data using the USB ACM-CDC model from a raspberry pi pico using Earl Philhower's Arduino Pico library at about 3 Mbit/s or so.  The serial monitor works fine, but of course does not plot.  I am new to this so I'm not sure my code has the teleplot initialization.  If I leave it like I would with the the Arduino IDE it just crashes.  If I add a Serial.print(">Left: "); ahead of the Serial.println() statement it runs a while plotting, but then crashes.  I think it may be slowing down or missing my data while it is briefly running.    I'm tryinig to plot I2S data from a PCM1808.  It works from the Arduino IDE fine.  I'll paste it here since github doesn't seem to allow pasting a .cpp file.
`/*
I2S stereo microphone (input) example
Run using the Arduino Serial Plotter to see waveform.
Released to the Public Domain by Earle F. Philhower, III
For the Google AIY Voice Hat Microphone daughterboard, part
of the Raspberry Pi AIY cardboard box, the I2S stereo pinout
looking at the board top with the RPI logo on the left hand
side:
+--   ------------------------------------  --+
left RPI | (1) GND (2) DIN (3) BCLK (4) LRCLK (5) 3.3V | AIY right
logo +---------------------------------------------+ logo
For an Adfruit I2S MEMS microphone (https://www.adafruit.com/product/3421),
connect the pins as follows:
  DOUT -> GPIO0
  BCLK <- GPIO1
  LRCL <- GPIO2  # LRCLK = BCLK + 1
  GND <-> GND
  3V  <-> 3V3OUT

The other idiosyncrasy of most modern MEMS microphones is that they
require a minimum clock rate to wake up. For example, the SPH0645
microphone needs at least 1MHz.
*/
#include <I2S.h>
#define RATE 16000
#define MCLK_MULT 256  // 384 for 48 BCK per framme,  256 for 64 BCK per frame
I2S i2s(INPUT);
void setup() {
Serial.begin();
i2s.setDATA(2);
i2s.setBCLK(0);
i2s.setMCLK(3);
// Note: LRCK pin is BCK pin plus 1 (1 in this case).
i2s.setBitsPerSample(24);
i2s.setFrequency(RATE);
i2s.setMCLKmult(MCLK_MULT);
i2s.setSysClk(RATE);
i2s.setBuffers(32,0,0);
i2s.begin();
}
void loop() {
static int32_t r, l;
i2s.read32(&l, &r);
Serial.print(">left:");
Serial.printf("%d \r\n", l<<9);  // This only works up 16 kHz.
}
`

I found vscode crashing is an issue if you send data at a too high rate indeed. Serial prints worked reliable for me up to 1Khz without vscode crashing


List position based formatting

Fixes #5830, fixes #5890, fixes #6252, fixes #6320, fixes #6451, fixes #10681, fixes #13688, and maybe more.
Previous behavior:
foo.then
  <
  void // list does not add indentation
  >();

foo
  .then(
  () => {}
  );

function foo(
  param1: number,
  param2: number
): {
    attribute: number // incorrectly double indented
  } {
}

New behavior:
foo.then
  <
    void // every list adds indentation
  >();

foo
  .then( // list starts on single-indented line
    () => {} // new formatter is list-position-sensitive, its children are now double indented
  );

function foo(
  param1: number,
  param2: number
): { // list starts on non-indented line
  attribute: number // correctly single indented
} {
}

Test fails on codeFixClassImplementInterfaceComputedPropertyNameWellKnownSymbols because of a strange list object with the form { pos: undefined, end: undefined, hasTrailingComma: undefined}. Need some bisecting to resolve this.

BTW I think the fix for codeFixClassImplementInterfaceComputedPropertyNameWellKnownSymbols is out of scope of this PR, a simple workaround may be enough?

Rebased and squashed for easier review. Sorry for previous mess 😅

What is the status of this PR?

I think it's mature enough, time to merge conflicts anyway...

@andy-ms can you refresh this PR

Note for myself: downgrade to TS 2.4.x, gulp-typescript 3.0.x, and mocha 3.5.x to build this.

Test fails on codeFixClassImplementInterfaceComputedPropertyNameWellKnownSymbols

Solved by #18284


feat(datepicker) New input pickerInitialDate

New input (optional) that sets the intial date to display (null = today)
Updated demo page

Partially addresses #165
Before submitting a pull request, please make sure you have at least performed the following:

[X] read and followed the CONTRIBUTING.md guide.
[X] linted, built and tested the changes locally.
[X] added/updated any applicable API documentation.
[X] added/updated any applicable demos.

Thanks @harogaston, will get this looked at and merged hopefully tomorrow 😄

Some thoughts.
Regarding new Date() as the defaultValue and considering what I mentioned before: Maybe the intended behavior it was not clear. As I implemented it, there is a difference between

[pickerInitialDate]="null" means: initial date is today
[pickerInitialDate] not present or undefined means: do nothing (same old behavior)
[pickerInitialDate]="dateObject" means: set dateObject as the selected date (the input will be populated!)

That was my idea. Maybe we should get to an agreement before we do anything else.

On those bullets:
1 & 2: the old behavior is new Date() but bounded to possible values, i.e. inside the min & max date range. This means that you don't get the datepicker into a ridiculous range if your min & max are waaaay in the past / future, but also you don't need to configure it.
3: In that case, why not just use pickerSelectedDate? Having this initial date property set a selected date is very confusing - do we then emit that date in ngModel? I don't like the idea of two separate properties essentially conflicting with eachother.
Do you see what I mean?

I'm sorry, you are absolutely right. I was confused. I'll get onto it this weekend!

Just did what you suggested. Sorry about the confusion.


Use Gyroscope when available

This is more of an enhancement request :) It would be nice if somebody could
work on improving tracking by using the gyroscope in devices where it's
available or a more complicated predictive filter (Kalman?)

Original issue reported on code.google.com by<EMAIL_ADDRESS>on 24 Jan 2012 at 4:40

FWIW, here's what I consider to be a fairly solid implementation of the ROTATION_VECTOR sensor licensed under Apache 2.0 - full disclosure, I implemented it.
The onSensorChanged() method:
https://github.com/barbeau/gpstest/blob/master/GPSTest/src/main/java/com/android/gpstest/GpsTestActivity.java#L561
Here's the initial setup in onResume():
https://github.com/barbeau/gpstest/blob/master/GPSTest/src/main/java/com/android/gpstest/GpsTestActivity.java#L229
...and teardown in onPause():
https://github.com/barbeau/gpstest/blob/master/GPSTest/src/main/java/com/android/gpstest/GpsTestActivity.java#L264
It supports:

Back to API level 8 (Froyo) - uses Sensor.TYPE_ORIENTATION on devices that don't support Sensor.TYPE_ROTATION_VECTOR
Orientation changes - remaps the coordinate system accordingly
Correction for magnetic north
A workaround for a Samsung-specific bug that causes a crash on certain Samsung devices (see  https://github.com/barbeau/gpstest/issues/39 for details)

Implemented in the latest version (1.9.0b).


release v0.1

@JuliaRegistrator register

Registration pull request created: JuliaRegistries/General/18216
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v0.1.0 -m "<description of version>" 3a4a0fa09281deca3df8a3ae94c6c8c9c594092e
git push origin v0.1.0

@JuliaRegistrator register

Registration pull request updated: JuliaRegistries/General/18216
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v0.1.0 -m "<description of version>" a4d0467d2760e3b38f57675ee5ea1b4666e35d18
git push origin v0.1.0

closed since we are not using Ion CLI to release the packages.


Void variable from "org-journal-previous-entry"

Describe the bug
I've enabled the org-journal Doom module with (org +journal) but trying to do org-journal-previous-entry (or next-entry) results in Lisp error: (void-variable displayed-month). Navigating via M-x calendar and i j over some date opens that journal entry, so the calendar package is alright...
I asked on the Doom discord for help and Henrik suggested that it appears to be a bug in org-journal using an uninitialized variable.
To Reproduce
Steps to reproduce the behavior:

Latest Doom with (org +journal) in init.el
Create 2 journal entries, and try to navigate to one from the other with org-journal-<previous/next>-entry

Expected behavior
Navigate to the previous/next entry.
Screenshots
Desktop (please complete the following information):

OS: [e.g. iOS] OSX
Emacs Version [e.g. 25]: 26.3

Your Emacs Configuration
The part relevant to org-journal.
(setq org-directory "~/org/"
      org-journal-dir "~/Dropbox/org/journal"
      org-roam-directory "~/Dropbox/org/zettels"
      org-roam-db-location "~/org-roam.db"
      org-journal-file-format "%Y-%m-%d.org"
      org-journal-date-prefix "* "  ;; No title, print heading straightaway.
      ;; Heading example: `Friday, 12 June 2020'
      org-journal-date-format "%A, %d %B %Y"
      org-ellipsis " ▼ "
      ;; Automatically add journal TODO's to agenda.
      org-journal-enable-agenda-integration t
      )

(use-package! org-journal
  :config
  (map!
   "s-j" #'org-journal-new-entry
   "C-M-S-s-j" #'org-journal-new-entry
   "C-M-S-s-k" #'org-journal-new-entry  ;; Today, or Kyō (今日)
   "s-J" #'org-journal-open-current-journal-file))

Hey @christabella, org-journal-previous-entry and org-journal-next-entry are supposed to be used only inside the calendar.
There are two other functions, org-journal-open-next-entry and org-journal-open-previous-entry which can be used inside an org-journal buffer the navigate.
But thinking about this, I think having two types of next/previous function is bad. There should be only one next/previous function, which work inside the calendar, and an org-journal buffer.

OMG! That is such an incredibly facepalm moment for me, I was using that in a previous config but forgot about its existence. Ahhhh.... Thank you!!

That makes a lot of sense. Well I don't know about having two types of functions, not familiar with designing Emacs packages... Whatever makes the most sense to you :) For now I'm very happy with just using org-journal-open-next-entry!

OMG! That is such an incredibly facepalm moment for me, I was using that in a previous config but forgot about its existence. Ahhhh.... Thank you!!

Such things happen :-D.

That makes a lot of sense. Well I don't know about having two types of functions, not familiar with designing Emacs packages... Whatever makes the most sense to you :) For now I'm very happy with just using org-journal-open-next-entry!

A next/prev functions which are context aware. When the cursor is inside the calendar do the calendar part, when in an org-journal buffer do the other part, for all other cases print a message that the function is used in the wrong context.
It would a) improve the usability, and b) is easier to maintain.


TF Hub Tests by QA/Dev Team

Situation

The TFHub procedure is most done but we'd need the QA/Dev team to test it further
@coesensbert tested it to some extent.

Bert please add info here if possible/needed.

TODO

Test the TFHub

@xmonader or @sabrinasadik  can you check on your end who could test the TFHub? Thanks!
Related Issue

https://github.com/threefoldtech/tf_operations/issues/2754

environment to test grid stack

@A-Harby in relation with issue #2754, can you provide an update of the Hub testing? Lmk if you need anything to move this forward. Thanks!

@A-Harby is still testing the tfchain backend part , and still facing some issues there , so please Ahmed put your update here once you reach the hub setup section in testing.

@A-Harby @hossnys
In relation with issue #2754, can you provide an update of the Hub testing? Lmk if you need anything to move this forward. Thanks!

I'm just lost in the naming, but the TF Hub should be what?

The Hub is what serves the flists and it's data for the grid: https://hub.grid.tf/
It can be deployed with this: https://github.com/threefoldtech/grid_deployment/tree/development/grid-hub
The hub is one part of the guardian stack. It works as it is now, we need to find out someone else can also set it up. We have this code running here for example: https://hub.de.grid.tf/ / https://bootstrap.de.grid.tf/

I keep getting this error when trying to run the script.
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ModuleNotFoundError: No module named 'nacl'

seems to go wrong here https://github.com/threefoldtech/grid_deployment/blob/development/grid-hub/install-hub.sh#L31
because of the flag --break-system-packages, @maxux prolly different python version? Can we safely remove this flag?
script does not seem to stop at this error, so it then complains about the missing nacl python module

@maxux any idea on this?
Let's see if we can get this tests done. Thanks!

Which version of Ubuntu are you running ?
You can give a try to: apt-get install python3-nacl python3-redis
And comment the two pip line on the script.

Which version of Ubuntu are you running ?

Ubuntu 22.04.5 LTS

It worked fine, and Docker ran with no issue.

And the sites were reachable.

I created a PR for the fix too: https://github.com/threefoldtech/grid_deployment/pull/95

Well done @A-Harby thanks for this.

done, thanks!

Thanks Bert. I merged the PR.
@A-Harby do QA/Dev teams have anything else to test or we can close this issue?
Thanks.

It's done for us now


[add-resource] New Hereditor theme

Greetings,
I would like to submit my theme (Hereditor) to the Grav repository (it's a detached fork of the getgrav/grav-theme-mediator theme initially developed by Grav team and contributors).
The project details and source code is available at gizmecano/grav-theme-hereditor.
The related skeleton package is available at gizmecano/grav-skeleton-hereditor-site.
In addition, a demonstration implementation of this theme based on the skeleton has been published online.

Just a quick note to inform that I have just improved a bit the theme pre-release for submission to the Grav repository.

Added.


Dev to Master for Debugging

@ayush9pandey @zoltuz following up from my slack message the build seems to fail even on Dev (which successfully built before). This means some version of some software (probably jupyter?) got upgraded and no longer works the way we expected. Any thoughts on how to fix this?


add PT unit

linux done

windows done, macosx done

ios done

TODO: add more clever PT size determination based on screen resolution and screen size, somewhere 1px somewhere 1.5px etc.

draft done. closing issue for now.


Bug: shapely.strtree.STRtree returns false positives

Expected behavior and actual behavior.
Expected: "The query method on STRtree returns a list of all geometries in the tree that intersect the provided geometry argument." as documented: https://shapely.readthedocs.io/en/latest/manual.html#str-packed-r-tree
Reality: STRtree.query(x) sometimes returns objects that don't intersect x. Worse yet, it always returns a non-empty list when certain rectangle-shaped regions of the search space are queried.
Steps to reproduce the problem.

Create STRtree  from buffered random lines
Query STRtree  with another buffered line and assert result[0].intersects(queried_line)
Wait for assertion to fail

I'll code a minimum repro later if there is interest. For now, here's my workaround that first queries the R-tree and then double-checks the R-tree query results by brute forcing intersects to test if a line segment intersects any obstacles. This solved my problem for now, but kills the log(n) time complexity that I'll need later
def drc_check(self, a :Tuple, b :Tuple, obstacles :STRtree) -> bool:
  """
  Returns True if the (a,b) trace is far enough from obstacles to
  meet design rules
  """
  new_trace_string = LineString([a,b]).buffer(self.trace_width/2 + self.trace_spacing/2)
  intersecting_obstacles = obstacles.query(new_trace_string)
  for o in intersecting_obstacles:
    if o.intersects(new_trace_string):
      return False
    else:
      pass #False positive in STRtree :(
  return True

Operating system
Linux
Shapely version and provenance
1.7.0 installed from PyPI using pip on Python 3.6

This is a documentation bug. The query method returns objects which have extents that intersect with the extent of the given geometry. So, yes, there will be false positives of this kind. We will fix the documentation.

Ah, thanks for confirming. Lemme tack on a performance bug/note to this.
I profiled one run of my program and found that checking for false positives with intersects takes 318 seconds whereas all 354836 calls to strtree.py:50(query) take 9.2 seconds.
Oddly enough, some instances of STRtree only return a non-empty list when the query is close to the obstacles. In those cases, double-checking R-tree queries is quick and acceptable.
Other instances of STRtree consistently return a non-empty list if i query anywhere inside large rectangles covering 1/4 of my search space even though the obstacles (buffered LineString) cover a minuscule area of the search space.
Seems like chopping up large LineStrings into smaller ones reduces the size of the extents and prevents a diagonal  line from blocking off a huge bounding box that covers the entire geom. But that increases memory usage.
I wonder if I can tune the R-tree construction to limit the maximum size of leaf nodes (rectangles) and allow a single extent to span many of those small rectangles.
Or perhaps there is a better way to approach this problem?
Example of a bad R-tree that degrades to O(n) inside the large white rectangles:

Resolved by #857.


Serialization error: cannot represent an object with type Section

currently if you have a component with a parameter of type CrossSection, it cannot be serialized.
simple example:
try serializing the settings for the following component, i.e. by generating a regression test for it
@gf.cell
def demonstrate_bad_cross_section_setting(cross_section=strip()) -> gf.Component:
    c = gf.components.straight(cross_section=cross_section)
    return c

i think this used to work, but maybe this code was removed when handling of cross_sections was refactored?

Hi Troy,
i added this test and it worked great on my side

import gdsfactory as gf
from gdsfactory.cross_section import strip

@gf.cell
def demo_cross_section_setting(cross_section=strip()) -> gf.Component:
    c = gf.components.straight(cross_section=cross_section)
    return c

def test_settings(data_regression, check: bool = True) -> None:
    """Avoid regressions when exporting settings."""
    component = demo_cross_section_setting()
    data_regression.check(component.to_dict())

if __name__ == "__main__":
    # c = demo_cross_section_setting()
    # d = c.to_dict()
    # c.show()
    test_settings()

see https://github.com/gdsfactory/gdsfactory/blob/master/gdsfactory/tests/test_serialize.py


chore: updates README to not include no longer needed instructions

what

Removes the instructions regarding manually configuring datadog + adds mention of how the integration is wired up.

why

Seems that these instructions are no longer relevant. The DataDog provider automates these steps and no manual steps are needed from what I have seen.

references

closes #7

/test all


A crash

The List

iroh get CID/does/not/exist results in a weird error message
connection issues #345

Connection problems ugly output:
Error: status: Unavailable, message: "error trying to connect: tcp connect error: Connection refused (os error 111)", details: [], metadata: MetadataMap { headers: {} }

Caused by:
    0: transport error
    1: error trying to connect: tcp connect error: Connection refused (os error 111)
    2: tcp connect error: Connection refused (os error 111)
    3: Connection refused (os error 111)

part of the issue surrounds RPC error handling, which is nontrivial. Errors should be better with the switch to tarpc (see #459).
Let's repurpose this issue to be specifically about errors stemming from RPC connections, and making them not gross


Adding a properties file for HeatingDevice configuration

In order to avoid command line parameters for now, we could use a properties file for configuring the HeatingDevice. @lulf wdyt ?

Closed by 20330a72f8a026b9a520eaa79970642ca84f23da


Break out tests that require sequencing into separate test suite

We have a set of tests (e.g. all the integration tests that require restart) that must be run sequentially.
I think these are disabled right now, but we should use them if we have them. After #1050 is done, this will be easy to do. This will be the only suite that will be run as a separate make task, to guarantee that they're run in sequence. (Additionally we'll set the right go test flags)

I think we can just get rid of those tests instead. Given that the server is stateless now testing restarts doesn't really do much for us and it seems like a bit of a pain. If we wanted to have meaningful restart tests it would be a lot more meaningful to restart the database than pachd itself.

no longer relevant ... all integration tests are run in sequence now


Update REadme.md for npm

Description
Set a new version to update README.md on npm.
Type of change

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update

Checklist:

[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my own code
[x] I have commented my code, particularly in hard-to-understand areas
[x] I have made corresponding changes to the documentation
[x] I have added tests that prove my fix is effective or that my feature works
[x] New and existing unit tests pass locally with my changes
[x] Any dependent changes have been merged and published in downstream modules
[x] I have checked my code and corrected any misspellings

Codecov Report

Merging #5 (37a0648) into main (04ad3bc) will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##              main        #5   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files           27        27
  Lines          213       213
  Branches        50        50
=========================================
  Hits           213       213

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 04ad3bc...37a0648. Read the comment docs.


feat: command orchestration

Implements https://github.com/algorandfoundation/algokit-cli/issues/417
Proposed Changes

Adding new project command group consolidating bootstrap, deploy and run.
Adding deprecation notes and hiding bootstrap and deploy from the root until next major release.
Adding orchestration logic that allows execution of multiple standalone commands sequentially (per configuration) or concurrently by default. Adding options to list commands from the workspace root as well as filter execution in specific project
Adding documentation
Adding snapshot and unit tests
Minor structural refinements, consolidating bootstrap and deploy under project folder - following convention established with tasks
Minor structural refinements, consolidating [algokit.deploy] settings under [algokit.project.deploy]. Old syntax is also supported until next major release.

TODO

[ ] - DO NOT MERGE until this pr is merged https://github.com/algorandfoundation/algokit-cli/pull/450
[ ] - Update template repos to support orchestration features

@neilcampbell after some further usage i ended up adding a run command group to isolate static deploy and bootstrap from custom user commands. Initial idea with making deploy and bootstrap wasn't working out too well and was breaking the conventions we used so far with config files where toml sections are mirroring the command group hierarchy in algokit cli. Let me know what you think

Old syntax is also supported until next major release.

We need to figure out a non-painful deprecation plan for this. e.g. if you have team members who have multiple versions of the CLI then they will get inconsistent experiences, which isn't great. Can we just explicitly support those keys as aliases of the project. ones?

@robdmoore thats already the case, cli parses both old
[deploy]

and
[project.deploy]

syntaxes when parsing .algokit.toml file. If a team has multiple people relying on multiple cli verisons they just need to agree whether they stick to new section declaration in toml files or the old [deploy]. Unless you were referring to some other feature?

@neilcampbell feel free to check again, haven't smoke tested manually on windows yet


nixos/soft-serve: init

Description of changes
This adds a NixOS module for Soft Serve, a tasty, self-hostable Git server for the command line.
The module has a test that checks some basic things like creating users, creating a repo and cloning it. Bash is required for running the hook scripts (e.g., on push), so I added it to the path of the wrapper.
Things done

Built on platform(s)

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

[x] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[x] 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

[x] 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
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
23.11 Release Notes (or backporting 23.05 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
[x] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/prs-ready-for-review/3032/2420

Hi, how can we proceed with this? I think I have addressed all change requests and the branch still has no conflicts. Can this be merged?

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

1 package blacklisted:

nixos-install-tools

1 package built:

soft-serve


NGram index dropped & created on every startup - 7.0.0 - beta 4

A small repro using Marten 7.0.0 beta 4
using Marten;
using Microsoft.Extensions.Hosting;

var host = Host.CreateDefaultBuilder()
   .ConfigureServices((ctx, services) =>
    {
        services.AddMarten(opts =>
        {
            opts.Connection("xxx");
            opts.Schema.For<NGramDoc>().NgramIndex(x => x.NGramString);
        })
       .ApplyAllDatabaseChangesOnStartup()
       .UseLightweightSessions();
    })
   .Build();

await host.StartAsync();

public class NGramDoc
{
    public Guid Id { get; set; }
    public string NGramString { get; set; } = "";
}

This might have been fixed by other changes, but "works on my box"

Using the same setup as earlier I still see this issue on beta 5.
      drop index if exists public.mt_doc_ngramdoc_idx_ngram_ngramstring;
      CREATE INDEX mt_doc_ngramdoc_idx_ngram_ngramstring ON public.mt_doc_ngramdoc USING gin (public.mt_grams_vector( data ->> 'NGramString'));

@arildboifot Thanks for reporting that the issue still persists. We will have a look at it.
@jeremydmiller I will have a look at this.

Trying it again this evening, and "it works on my box" again. I can't reproduce this at all with V7. There is some Weasel changes coming that were part of fixing #2983, maybe those changes will help whatever is happening here. What I am seeing in that other issue is that some other configuration of PostgreSQL makes yet more changes to the DDL that we weren't yet accounting for in our comparison.
But for right now, with no workable reproduction, this has to be closed because nothing is actionable.


Chore/dependencies 2024 05 29

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 96.40%.

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #5445      +/-   ##
==========================================
- Coverage   96.41%   96.40%   -0.01%
==========================================
  Files         946      946
  Lines       22428    22428
  Branches     2016     2016
==========================================
- Hits        21623    21621       -2
- Misses        657      658       +1
- Partials      148      149       +1

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Adding option to allow __partial in URLs.

See https://github.com/realm/realm-studio/issues/658

The disallow_partial_urls member variable is never used outside of the constructor and thus doesn't need to exist. The new constructor doesn't particularly need to exist either; you could instead bypass the validation by just setting the url afterwards rather than passing it to the constructor.

@tgoyne Thanks for the advice.


Move link out of object space.

The link object was previously stored in a disused object.  This is
good for reducing meta-data, but if we want to reduce the meta-data
corruption potential, then this is not a good design choice.
This commit moves it into the Metaslab.
The overall change improves performance slightly in a couple of cases.

@nwf this might make the CHERI changes slightly easier as it is one less bit to store in an exposed location.

Seems reasonable. If I have it right, this replaces a uint16_t in each Metaslab with a two void*, but padding rules mean that it's probably just the two new void* and some more internal padding now.

Yep, I think it goes from 16 bytes on 64bit non-CHERI architectures to 32 bytes per slab, so still a very small overhead.


Update zh_CN translation

Update panels, tables package zh_CN translation files.
Add infolists, notifications, support package zh_CN translation files.

Thanks!


Various edits throughout the manuscript

Sorry... pushed the wrong button. This PR is open.
I'm going to open a couple of issues to highlight outstanding issues with the manuscript.


Multiple ubuntu kernel headers cannot be found

Describe the bug
As title says; some examples:
{
      "kernelversion": "2",
      "kernelrelease": "5.18.0-1002-oracle",
      "target": "ubuntu"
}
{
      "kernelversion": "1",
      "kernelrelease": "5.19.0-1001-lowlatency",
      "target": "ubuntu"
}
{
      "kernelversion": "24~20.04.3",
      "kernelrelease": "5.15.0-24-lowlatency-hwe-5.15",
      "target": "ubuntu"
}

These all lead to
FATA exiting                                       error="kernel headers not found"

I think there is some sort of issue with current fetchUbuntuKernelURL (possibly some patterns are missing).
@EXONER4TED @dwindsor

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Provide feedback via https://github.com/falcosecurity/community.
/lifecycle stale

/remove-lifecycle stale

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Provide feedback via https://github.com/falcosecurity/community.
/lifecycle stale

/remove-lifecycle stale

I promise I will get to looking at this 😅 I've been on family leave, and now am moving houses, but that wraps up this week. I should actually be back in some capacity here in the next couple weeks 😄

No problem sir :house: :rocket:

I'm looking into this now. For the first example, it looks like mirrors.edge.kernels.org doesn't have oracle-5.18 :/
From their site:
linux-oracle/                                      21-Mar-2023 17:01       -
linux-oracle-5.0/                                  18-Mar-2020 11:13       -
linux-oracle-5.11/                                 08-Feb-2022 12:07       -
linux-oracle-5.13/                                 15-Jun-2022 11:43       -
linux-oracle-5.15/                                 15-Mar-2023 23:44       -
linux-oracle-5.3/                                  27-Jul-2020 18:23       -
linux-oracle-5.4/                                  18-Feb-2023 23:34       -
linux-oracle-5.8/                                  06-Aug-2021 18:15       -
... and linux-oracle doesn't have any 5.18
Will keep looking into the others.

Yea... kernel-crawler is unable to crawl for these either. My gut says pulled kernels...
╰─❯ cat ubuntu.json | grep 5.18.0-1002-oracle

╰─❯ cat ubuntu.json | grep 5.19.0-1001-lowlatency

╰─❯ cat ubuntu.json | grep 5.15.0-24-lowlatency-hwe-5.15

I can confirm this is not missing headers patterns though. Taking the ubuntu-oracle example above, here are all of the URL subpaths it attempts to crawl:
[https://mirrors.edge.kernel.org/ubuntu/pool/main/l/linux/linux-headers-5.18.0-1002-oracle_5.18.0-1002.2_amd64_all.deb https://mirrors.edge.kernel.org/ubuntu/pool/main/l/linux/linux-headers-5.18.0-1002-oracle_5.18.0-1002.2_amd64.deb https://mirrors.edge.kernel.org/ubuntu/pool/main/l/linux/linux-oracle-headers-5.18.0-1002_5.18.0-1002.2_all.deb https://mirrors.edge.kernel.org/ubuntu/pool/main/l/linux-oracle/linux-headers-5.18.0-1002-oracle_5.18.0-1002.2_amd64_all.deb https://mirrors.edge.kernel.org/ubuntu/pool/main/l/linux-oracle/linux-headers-5.18.0-1002-oracle_5.18.0-1002.2_amd64.deb https://mirrors.edge.kernel.org/ubuntu/pool/main/l/linux-oracle/linux-oracle-headers-5.18.0-1002_5.18.0-1002.2_all.deb https://mirrors.edge.kernel.org/ubuntu/pool/main/l/linux-oracle-5.18/linux-headers-5.18.0-1002-oracle_5.18.0-1002.2_amd64_all.deb https://mirrors.edge.kernel.org/ubuntu/pool/main/l/linux-oracle-5.18/linux-headers-5.18.0-1002-oracle_5.18.0-1002.2_amd64.deb https://mirrors.edge.kernel.org/ubuntu/pool/main/l/linux-oracle-5.18/linux-oracle-headers-5.18.0-1002_5.18.0-1002.2_all.deb]

The URL subpaths look like:
main/l/linux/
main/l/linux-oracle/
main/l/linux-oracle-5.18

Which are the correct paths to go down, but the hosting site just literally doesn't have linux-oracle-5.18 and doesn't have that specific kernel under linux-oracle... So the headers patterns are correct, but the kernel just doesn't exist anymore.

So, it seems like i was actually testing against pulled kernels?
Fact is, today crawler is unable to crawl for them, but the test was made ~20th August :laughing: who knows!
I think we can close this one and reopen it eventually if anyone comes up with issues!
Thank you for your investigation @EXONER4TED !
/close


Allow to change showInlayHints during runtime

It would be helpful if one could toggle showInlayHints during runtime, as I don't want to see inlay hints all the time due to the clutter, but sometimes they are helpful.
In VSCode there even is an extra shortcut, where you can hold Ctrl+Alt to temporarily show inlay hints.
Is there some way to make this work with this plugin? If I don't enable them before starting the LSP server, then they will never show, i.e. even calling the following function during runtime will not make them show up:
:call LspOptionsSet(#{showInlayHints: 1})

It would be nice if this plugin could toggle them, if I set the option during runtime.

that may depend on lsp server, e.g rust analyser, it would not init give inlay hints.
// or it was a its bug? or it just did like your demand.

I have committed e5b32d6549c43e0dfa777b5a2ddb288e612e78a3 to add support for enabling/disabling inlay hints.  Can you try the latest plugin?  The command :LspInlayHints enable enables inlay hints and the command :LspInlayHints disable disables inlay hints for the current Vim session.  You can also use the showInlayHints option to enable or disable inlay hints across Vim sessions.

seems good, thanks.
// a little different is clangd maybe/canbe init enabled by default, but rust would/can not.
// but so far, that's a knew issue, or rust-analyser's feat, maybe.

Thanks it works perfectly.

// a little different is clangd maybe/canbe init enabled by default, but rust would/can not.
// but so far, that's a knew issue, or rust-analyser's feat, maybe.

@yegappan i opened PR #357 trying to correct it.


Latest TypeScript and Javascript Grammar: Some closing elements are being colored as attributes in Typescript React

VS Code
Version 1.5.3
Commit 5be4091987a98e3870d89d630eb87be6d9bafd27
Date 2016-09-22T08:50:42.185Z
Shell 0.37.6
Renderer 49.0.2623.75
Node 5.10.0
Latest TypeScript and Javascript Grammar 0.0.2
Windows 7 SP1 x64

@emzero Thanks for reporting the issue. Can you please paste your code here so that we can investigate this.

import * as React from 'react';

export default class Home extends React.Component<any, void> {
    public render() {
        return

Hello, world!

Welcome to your new single-page application, built with:

ASP.NET Core and C# for cross-platform server-side code

React, Redux, and TypeScript for client-side code

Webpack for building and bundling client-side resources

Bootstrap for layout and styling

To help you get started, we've also set up:

Client-side navigation. For example, click Counter then Back to return here.

Webpack dev middleware. In development mode, there's no need to run the webpack build tool. Your client-side resources are dynamically built on demand. Updates are available as soon as you modify any file.

Hot module replacement. In development mode, you don't even need to reload the page after making most changes. Within seconds of saving changes to files, rebuilt React components will be injected directly into your running application, preserving its live state.

Efficient production builds. In production mode, development-time features are disabled, and the webpack build tool produces minified static CSS and JavaScript files.

Server-side prerendering. To optimize startup time, your React application is first rendered on the server. The initial HTML and state is then transferred to the browser, where client-side code picks up where the server left off.

;
    }
}


fix list pull refresh invalid sometimes

 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.斗破 seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.


adjust feature to right link

The url to feature.rst should be adjust.

 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.

The real file link was: https://github.com/alibaba/EasyRec/edit/master/docs/source/feature/feature.rst
Not feature.md

ping @0xflotus @lgqfhwy @cosmozhang1995 @chengmengli06

@chengmengli06  CI run failed due to:Error: Unhandled error: HttpError: Resource not accessible by integration


[SPARK-32897][PYTHON] Don't show a deprecation warning at SparkSession.builder.getOrCreate

What changes were proposed in this pull request?
In PySpark shell, if you call SparkSession.builder.getOrCreate as below:
import warnings
from pyspark.sql import SparkSession, SQLContext
warnings.simplefilter('always', DeprecationWarning)
spark.stop()
SparkSession.builder.getOrCreate()

it shows the deprecation warning as below:
/.../spark/python/pyspark/sql/context.py:72: DeprecationWarning: Deprecated in 3.0.0. Use SparkSession.builder.getOrCreate() instead.
  DeprecationWarning)

via https://github.com/apache/spark/blob/d3304268d3046116d39ec3d54a8e319dce188f36/python/pyspark/sql/session.py#L222
We shouldn't print the deprecation warning from it. This is the only place ^.
Why are the changes needed?
To prevent to inform users that SparkSession.builder.getOrCreate is deprecated mistakenly.
Does this PR introduce any user-facing change?
Yes, it won't show a deprecation warning to end users for calling SparkSession.builder.getOrCreate.
How was this patch tested?
Manually tested as above.

Test build #128737 has started for PR 29768 at commit 8d1fcd1.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/33361/
Test PASSed.

Test build #128737 has finished for PR 29768 at commit 8d1fcd1.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/128737/
Test PASSed.

Thanks! merging to master/3.0


New author page should save the author

Scenario
When a user visits the new author page
And fills in 'Alan', 'Turing', and 'http://wikipedia.org/Alan_Turing', respectively
And submits the form
Then Alan Turing should be found in the database
Hints
Write a test that visits the new-author page, fills in the 'new author' form and submits it.
Use fill_in to enter data into input fields.
Submit the form using the find and click methods.
Try a new it block in new_author_spec.rb.
visit new_author_path
page.fill_in 'author[last_name]', with: 'Dijkstra'
# ...
find('input[type="submit"]').click

Here is the relevant section (5.6) in the Rails Guide.
Make the failing test pass by saving the POSTed form data in a new Author database object.
This is the task of a create action in authors_controller.rb.
Make sure to set the :url option of the form_with, to control where the data will be POSTed to. Read up on "strong parameters" and whitelisting of required parameters.
Do not issue a redirect_to @author, as this will error (there is no code for showing authors yet). Instead you can redirect_to root_path, notice: 'Success!'.
Tips:

Your browser's dev tools are helpful in debugging and inspecting HTML.
rails console allows you to interact with stored object in an interactive shell, e.g. Author.count shows the amount of stored authors.

Error

Got ActiveRecord::RecordNotFound: Couldn't find Author with [WHERE "authors"."last_name" = ?]

6 exercise tests have passed. There are 44 in total. You will solve multiple at once towards the end.

Sorry, it's not working for me yet:
Scenario
When a user visits the new author page
And fills in 'Alan', 'Turing', and 'http://wikipedia.org/Alan_Turing', respectively
And submits the form
Then Alan Turing should be found in the database
Error

Got ActiveRecord::RecordNotFound: Couldn't find Author with [WHERE "authors"."last_name" = ?]

If you have problems solving this task, please don't hesitate to contact the teaching team!


Fix AD check unscheduling

What does this PR do?
Fix check unscheduling
Motivation
Right now both configresolver & autoconfig can schedule checks, but the level of information is not the same & one of the path was breaking the unscheduling.
The PR add maps to make bridges to have the same level of info & unify a bit the flow but this is not ideal.

@xvello I agree for the need of lifecycle tests.
Let's quick-fix it for rc2, and take more time to rethink & test the AD flow for 6.1


Does this work with Laravel breeze?

Hello, I'm interested in implementing your laravel package into my project, and I was wondering if your package works with Laravel Breeze? It's using it as a base, so I would like to know if I can use your package for my setup wizard that I am planning to add.

Yes you can implement this


Allow to unsubscribe from subscriptions/callbacks.

MessageTemplate.subscribe should return a unique value that can be used as an argument to MessageTemplate.unsubscribe to stop the subscription.
Possibly also send

I thought it already did...

...Nope, EventStream already does, nevermind


sample logseq-slash-commands: the slash command doesn't work

I tried the sample logseq-slash-commands in logseq version 0.6.2. Type slash command /Big in a block. The slash command didn't show in the slash command list.

A known issue of Logseq. It fixed in this PR https://github.com/logseq/logseq/pull/4828


(maint) Refactor export to run in fewer queries and remove acceptance tests

@senior Refactored this in such a way that we can and should merge this part of things before 4.0, I think we can also add the anonymization functionality to the export tool in 3.2 as well, but that'll go in the next PR.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://jenkins.puppetlabs.com/job/platform_puppetdb_intn-sys_pr/1882/

looks good to me

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://jenkins.puppetlabs.com/job/platform_puppetdb_intn-sys_pr/1891/

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://jenkins.puppetlabs.com/job/platform_puppetdb_intn-sys_pr/1890/

@pljenkinsro retest this please

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://jenkins.puppetlabs.com/job/platform_puppetdb_intn-sys_pr/1892/

Refer to this link for build results (access rights to CI server needed):
http://jenkins-enterprise.delivery.puppetlabs.net/job/enterprise_puppetdb_init-multijob_githubpr-master/1/
Test FAILed.

Refer to this link for build results (access rights to CI server needed):
http://jenkins-enterprise.delivery.puppetlabs.net/job/enterprise_puppetdb_init-multijob_githubpr-stable/2/
Test FAILed.

Refer to this link for build results (access rights to CI server needed):
http://jenkins-enterprise.delivery.puppetlabs.net/job/enterprise_puppetdb_init-multijob_githubpr-master/9/
Test PASSed.


add http request logging in exposure service

Proposed Changes

When running on kubernetes, lack of request logs joined with application logs makes troubleshooting very difficult

Release Note
Standard HTTP request logs for exposure service.

/retest

/retest


add no-color option and use strip-ansi v6

👋 small change to add --no-color
I am also submitting a follow up PR that moves to minimist for arg parsing that refactors this a bit, so we might want to just breeze past this PR

superseded by #14


can't get this resource

when I run ./deps.sh, I can't get the resource called"stuffit520.611linux-i386.tar.gz", and the link is disabled!!!!

http://mirror.sobukus.de/files/grimoire/z-archive/stuffit520.611linux-i386.tar.gz


Should we have a play method on Player to play animations?     This is a code structure question related to teaching/making tutorials.

As in OpenRPG, I've opted for a Skin node for the characters' skin, so we can replace the animated characters, so an animator or artist can work on animations without messing with the code/git history, and so we can mix-and-match animation techniques without other bits of code breaking.
This makes it so to start an animation from a state, we have to use player.skin.play(animation_name). So this makes the skin property a dependency for each state that accesses it. This is +/- fine as they're all part of the same scene. But I'd like your thoughts on using this kind of code vs adding public methods on Player.gd to encapsulate functionality. In the states, this would result in having
player.skin.play(animation_name)

vs
player.play(animation_name)

And adding an extra play method on Player:
func play(animation_name: String) -> void:
    skin.play(animation_name)

Which one should we teach or recommend? I'd use player.skin.play() as it makes it clear that you're giving work to the skin node. And I think that both approaches have downsides. I wouldn't want to clutter Player.gd, the Player node being a KinematicBody2D node.
Yes, our lives as developers is complicated

Ping @razcore-art

I think it is better to use Player.play().

encapsulate what changes

If we decide to change anything in the Skin or related to it, the interface provided to the states will stay the same and we would only have to change the content of the Player.play() method.

As for cluttering the Player class, maybe it is better to decouple the two responsibilities, the change in state from the animation being played. This will also avoid this problem.
We can have the player sending signals about its current state and let the Skin decide what to do with this information.

Unfortunately it's not that simple since the player shouldn't do anything while the animation plays so it's not just a matter of letting Skin do it's own work. At this time I can't think of anything that would possibly decouple the Skin animation from the player state change.
As far as using Player.play() instead of Player.skin.play() or similar I'd opt for Player.skin.play() as it is indeed more clear about what's happening plus the other mentioned advantages - no cluttering of Player etc. We wouldn't run in the API/Interface issue since, if we do the stuff right, play would be a public method that shouldn't rely on the private implementation so it's just like Player.play() in this sense. We can still explain the API/Interface concept just as well, that's basically the public/pseudo-private methods/variables issue.

We can have the player sending signals about its current state and let the Skin decide what to do with this information.

Although that makes it so when the state machine changes state, you have to figure out where the code to change the animation is. I think it complicates the code.

We wouldn't run in the API/Interface issue since, if we do the stuff right, play would be a public method that shouldn't rely on the private implementation

Makes sense, keeping it like that for now then


how to use the pred_light in the rel

hi @stevewongv, this is a very meaningful job. I have a question to ask. Is 'pred_light' a quaternion? Is it in the order of 'wxyz'? What kind of coordinate system is the result in?

@xuheny , did you solve this issue? Do you know how they should be constructed?


Ignoring the settings in the support folder

As described here https://on.cypress.io/uncaught-exception-from-application I have added the e2e.js inside the support folder. But the test is ignoring it completely. Please see the screenshot below.

Not related to preprocessing.

@badeball I checked this without cucumber-preprocess on the latest cypress version 12.4.0 and it is working as expected. I am almost certain this is related to preprocessing. Could you please check by adding it?

This works fine, as far as I know.

Can you pls include it in the sample?

forgot to mention that I am keen on browserify-esm exmaple

I tried adding it to the broserify-esm example and it is working. When it cannot locate an element, I can see it is printing AssertionError: Timed out retrying after 4000ms: Expected to find element:#sample, but never found it. However, when I have the similar situation in my application (due to any cosole error / API error in the console) it is failing. However, with the normal cypress I am able to execute the similar steps.

There is nothing I can do for you unless you can provide me with a clear example that illustrates the issue. Vague descriptions such as the last scenario you're description isn't going to make me investigate.


enable '@V' rolling to horizontal 3D rendering command/module

In Honda's example model (pg 68 of PARAMETRIC L-SYSTEMS AND THEIR APPLICATION TO THE MODELLING AND VISUALIZATION
OF PLANTS), uses the L+C module @V, which is described as maintaining the current axis of "growth", but rolling on that axis so that branching to the left or right results in a horizontal (from the world perspective) divergence.
I haven't sorted out the relevant math to enable that within the 3D visualizations currently, but I'd like to be able to showcase that model as an example.

resolved with https://github.com/heckj/Lindenmayer/commit/c8999bcf68848c8ddb09bf8191f6512a40ac9b0c


Delta SDS incorrectly sends an error response for an empty response

Title: Delta SDS incorrectly sends an error response for an empty response
Description:
Control plan sends resources:[], removed:[some resource]. Envoy rejects with 2024-03-11T23:35:13.641010Z     warning envoy config external/envoy/source/extensions/config_subscription/grpc/grpc_subscription_impl.cc:138    gRPC config for type.googleapis.com/envoy.extensions.transport_sockets.tls.v3.Secret rejected: Missing SDS resources for kubernetes://sds-credential in onConfigUpdate()      thread=25
This comes from https://github.com/envoyproxy/envoy/blob/708fa7b4d8269372fdac39b11caf2a3bf7b18d53/source/common/secret/sds_api.cc#L157 which only considers SotW
Repro steps:
I don't have a trivial Envoy SDS setup for this in pure envoy, but its pretty simple in Istio. Just create something like
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: echo
spec:
  selector:
    istio: ingressgateway
  servers:
  - port:
      number: 443
      name: https
      protocol: HTTPS
    hosts:
    - "*"
    tls:
      credentialName: sds-credential
      mode: SIMPLE

With istio latest (which uses delta xds now)

cc @adisuissa @htuch

This seems to be a dup of #24373.

I can try to take this if it's not claimed

@keithmattix I'll close this as dupe and assign you https://github.com/envoyproxy/envoy/issues/24373

@howardjohn  I think the Istio repro in the original description is expected. If the secret is not supplied by the SDS server, then the client should indeed error, no?

a NACK from lack of resource is not expected. it should stay warming.
but even if we had previously sent it, any removal is just entirely rejected

but even if we had previously sent it, any removal is just entirely rejected

Right, I've confirmed this and am iterating on the linked PR; I'm looking to verify the repro behavior with Istio

a NACK from lack of resource is not expected. it should stay warming.

Ah I see; from the spec (emphasis mine):

Resources names of resources that have be deleted and to be removed from the xDS Client. Removed resources for missing resources can be ignored.

So you're saying the desired behavior is:

if cluster is still warming and secret is removed, the SDS subscription should ignore the removal (NOT NACK)
If cluster is already ready (and serving traffic), the SDS subscription should also ignore that removal because the owning listener/cluster should be updated as well

I agree with 1 but on 2, how can the SDS subscription guarantee that the cluster/listener are being updated? What if the server is saying "this secret no longer exists" (e.g. a cert rotation failed); what should that do to the owning cluster/listener? Does the SDS subscription need to do anything at all (I think this is current behavior)?

IMO I think the delete should be ignored entirely -- will try to explain
more in a bit or you can look at the recent ecds issue
On Wed, Mar 20, 2024, 8:54 PM Keith Mattix II @.***>
wrote:

but even if we had previously sent it, any removal is just entirely
rejected
Right, I've confirmed this and am iterating on the linked PR; I'm looking
to verify the repro behavior with Istio
a NACK from lack of resource is not expected. it should stay warming.
Ah I see; from the spec
https://www.envoyproxy.io/docs/envoy/latest/api-v3/service/discovery/v3/discovery.proto#envoy-v3-api-field-service-discovery-v3-deltadiscoveryresponse-removed-resources
(emphasis mine):
Resources names of resources that have be deleted and to be removed from
the xDS Client. Removed resources for missing resources can be ignored.
So you're saying the desired behavior is:

if cluster is still warming and secret is removed, the SDS
subscription should ignore the removal (NOT NACK)
If cluster is already ready (and serving traffic), the SDS
subscription should also ignore that removal because the owning
listener/cluster should be updated as well

I agree with 1 but on 2, how can the SDS subscription guarantee that the
cluster/listener are being updated? What if the server is saying "this
secret no longer exists" (e.g. a cert rotation failed); what should that do
to the owning cluster/listener? Does the SDS subscription need to do
anything at all (I think this is current behavior)?
—
Reply to this email directly, view it on GitHub
https://github.com/envoyproxy/envoy/issues/32832#issuecomment-2010505469,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAEYGXIM7SHLFUTTAPOOBW3YZHSOPAVCNFSM6AAAAABERG5OGWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMJQGUYDKNBWHE
.
You are receiving this because you were mentioned.Message ID:
@.***>

I'm familiar with the ecds issue; I'm just not sure which is the more "correct" approach from a protocol perspective. What you're suggesting would mean any removal that isn't LDS or CDS essentially has no effect. From a pure protocol perspective, I would think that an xDS server should be able to indicate that dependent resources are missing/removed and have that mean somethign

@keithmattix IMO there are 2 usable implementations:

There is update and remove semantics (as today), and remove of dependent resources is ignored
There is update, remove, and "requested thing not present" semantics. Remove dependant resource is respected

In (2), we would just never send Remove for dependent types. But if we just do that today, then we cannot tell Envoy a resource it requested is not available, which means it will be warming instead of just failing which is unexpected.

Ah I see; unless we xDS adopted (2)'s semantics, we wouldn't be able to express "not available". Fair point; I ended up coding up "delete ignored" in my PR, so I think this will solve Istio's issue

Wouldn't that require an update instead of a removal though? Of the cluster is not supposed to use a secret in the interim period before a new secret is available, modify the cluster right?

@keithmattix I think it depends. I am mostly dis-agreeing with the base assumption that traffic must not be disrupted at all costs. Sometimes, you do want to break traffic to mitigate an ongoing attack.

Sure, but IIUC, not ignoring removal leaves control planes in a tough spot because they can't signal to the data plane that a requested secret is not/available without breaking traffic. If the CP wants to break traffic, it can just remove the secret from the cluster right?

My take here is that semantics today are as pointed out above, we don't support removal of singleton subscriptions (SDS, EDS, etc.)  independent of the referencing resource (cluster, listener). To @kyessenov point about dangers, we can either rely on the control plane to enforce the correct behavior during secret removal or make a change in semantics as suggested by @howardjohn. It seems reasoable to rely on control plane updating cluster/listener in these cases? Reopening as this is not resolved.


Fix pythonPackages.moviepy

Motivation for this change
The package was updated in #55757 but the list of dependencies was not.
Now it build again and I can import it in python3.
Things done

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

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nix-review --run "nix-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[x] Determined the impact on package closure size (by running nix path-info -S before and after)
[x] Assured whether relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

@GrahamcOfBorg build python37Packages.moviepy
@GrahamcOfBorg build python27Packages.moviepy

Needs backport to 19.03

It looks like python-2.7 is not supported anymore. Can you please mark it broken for python-2.7?

It looks like python-2.7 is not supported anymore. Can you please mark it broken for python-2.7?

Thanks! Wasn't aware we had the capability to do that :)


False positives on export (destructuring) missing key object with default value

// constants.js
export const {
  a: {
    // `b` would have been undefined, but we will default the value with a string
    b = 'default value',
  },
} = {
  a: {
    // `b` doesn't exist here
    c: 'test',
  },
};

...

// foo.js
import {b} from './constants';

// And it results in
 error  b not found in './constants'  import/named

It shouldn't throw an error because we have a default value for the key there.

I'm not actually sure how that named export works with destructuring - that seems like something you shouldn't be able to do.
is that exporting just a "b"?

It's just exporting b.
Code and my app run just fine because it's valid destructuring (with export).
It's just lint complaining about that.

This appears to be fixed already. Happy to reopen if the current and also next release doesn't solve it.


rename CommonMark to commonmark

Fixes "ImportError: No module named CommonMark" as proposed in rtfd/recommonmark#116

Looks like we need to rename more imports

Change the test import too and I think you're golden:
https://github.com/zachmccormick/recommonmark/blob/master/tests/test_basic.py#L11

can someone please merge this? We have a pending we have the  CI error due to this


Add note about online schema changes

(Related to #4601) As a stop gap for now,  add a note that clarifies that schema changes consume additional resources and that you should have overhead available in your cluster. See #4601 for more details

Additional note from DT: "Client was trying to run 4 big schema changes at once and it isn’t clear to me they understood that that was too much, and maybe we want to include somewhere — i’m not sure where — a warning that a) any schema changes adding and removing columns are potentially expensive and b) best practice is don’t do more than one at once in production"


Automatically create a tag after release PR was merged

Implement this (or similar) flow:

Creating a PR that bumps project version in Cargo.toml triggers a workflow
New tag is automatically created
Build is started
After build is finished, create a new release on GH with changelog generated automatically from CHANGELOG.md file

CHANGELOG.md should be updated at some step so that "Unreleased" section is converted to a new version and a new "Unreleased" section is created. Ideally this modification to changelog should be contained both on the master branch and newly created tag.

Duplicate of #859


BCI-2646 - Adding zkSync tests

BCI-2646 - Adding zkSync tests

closing due to staleness; we have also decided to use another approach, when deploying to zksync


Notification: don't show it on Project.default_version

Don't show the notification "This may be an old version of this documentation" if the reader is currently reading the Project.default_version.
I'm on the fence about doing this part of the default logic or a config on its own. I'll probably change it to a config after thinking a little more, but pushing these changes for now.
Closes #406

I really don't like having so many configuration options. I already feel like the Addons config is overwhelming, and "just add another setting" feels like the wrong solution.
I think users almost certainly don't want a warning on their default version, at least in the current UX of the warning, so I'm :+1: on this being part of the default logic.

Cool! I updated the PR and I'm marking it ready to review.


[FLINK-29198][test] Fail after maximum RetryOnException

What is the purpose of the change
This pull request causes tests annotated with @RetryOnException to fail after the given number of retries when used with the JUnit5 RetryExtension.  This is the old behaviour we saw with the JUnit4 RetryRule.
Currently, the test is retried for the maximum number of executions, but the "expected" exception is never thrown even on the last try.  This causes the test to appear skipped instead of failed.
Brief change log

If the test doesn't succeed on the last possible retry, the exception is propagated as a test failure.
I reverted some overeager JUnit5 migration on test cases for the JUnit4 RetryRule.  This code is appropriately duplicated for RetryExtension.

Verifying this change
This change is already covered by existing tests, such as RetryOnExceptionExtensionTest.
I've manually tested that the following test now fails after the expected number of retries (instead of being skipped):
    @TestTemplate
    @RetryOnException(times = NUMBER_OF_RUNS, exception = IllegalArgumentException.class)
    void testThrowExceptionForever() {
        throw new IllegalArgumentException();
    }

In JUnit5, it's very tricky to specify that a test is supposed to fail, but it's possible.  I started down this route with a technique similar to ExpectToFail but it ends up needing to be very aware of the internals of our RetryExtension.  I'm not sure it's worth adding test extension code to test extension code, but I can continue down that route!
Does this pull request potentially affect one of the following parts:

Dependencies (does it add or upgrade a dependency): no
The public API, i.e., is any changed class annotated with @Public(Evolving): no
The serializers: no
The runtime per-record code paths (performance sensitive): no
Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Kubernetes/Yarn, ZooKeeper: no
The S3 file system connector: no

Documentation

Does this pull request introduce a new feature? no
If yes, how is the feature documented? not applicable

Thanks for the contribution.
I think it would be great to have a test here confirming that the change fixes the issue

Thanks for the contribution. I think it would be great to have a test here confirming that the change fixes the issue

Thanks Sergey, especially for the collaboration!  This was a tricky thing to test; it gets a bit unclear about how far to go when testing test code :D  But since this is such a widely used TestExtension, it's good to have extra coverage -- especially when the symptom is otherwise silently skipping tests that should have failed.

@flinkbot run azure

lgtm from my side
//cc @XComp

Rebased again and edited the commit messages!

Rebased again and moved some modifications to their own separate commit

Rebased and changed the commit messages to the suggested text.  Thanks for your attention!
In fact, for testing correctness, I would suggest that all three commits be cherry-picked back into branch-1.16

@flinkbot run azure

Failure caused by FLINK-24119

@flinkbot run azure

@flinkbot run azure


reject messages with a timestamp < the prev timestamp

pfraze
domanic: we should refine the order. a feed's internal seq should be respected with higher priority than timestamp

domanic
pfraze, if it doesn't have an increasing timestamp, with respect to itself, that should be invalid

pfraze
domanic: i agree, that should cause feed rejection

pfraze
it should be invalidated locally when `add` is called, so unexpected incidents of non-monotonic growth should be blocked from occuring

pfraze
if it is allowed, it would have to be due to some data corruption or from intentionally trying to break the constraint

pfraze
both are good grounds to invalidate the feed

domanic
pfraze, agree

I traveled back in time and implemented it like that in the first place.

https://github.com/ssbc/secure-scuttlebutt/blob/master/validation.js#L76-L83

just occured to me that it would be cool if github links to code where transcludes, and actually displayed those lines on this page. oh well.

I traveled back in time and implemented it like that in the first place.

haha, though actually i dont think that's it. we need
if(prev && prev.timestamp > msg.timestamp) {
  validateSync.reason = 'timestamp shows after prev msgs' timestamp'
  return false
}

is that in there and i dont see?

just occured to me that it would be cool if github links to code where transcludes, and actually displayed those lines on this page. oh well.

agree

!!???! I linked you to the wrong code block:
I meant this:
https://github.com/ssbc/secure-scuttlebutt/blob/master/validation.js#L68-L74
it checks the sequence, and then checks the timestamp. maybe we should make it use a <= instead of just < though.

aha, there it is! yeah, i think <= would be right

okay this is implemented in 8.1.1

:+1:


⚠ Bofrost.be has degraded performance

In eae1190, Bofrost.be (https://www.bofrost.be) experienced degraded performance:

HTTP code: 200
Response time: 1006 ms

Resolved: Bofrost.be performance has improved in 7d21e7b.


Simply Self.

When the normal name of the template (i.e., the name from the enclosing scope, not the injected-class-name) is used, it always refers to the class template itself and not a specialization of the template

http://eel.is/c++draft/temp.local
I hereby agree to the terms of the CLA available at: https://yandex.ru/legal/cla/?lang=en

Ok.


GitHub & npm mismatch

In NPM latest version is 5.21.4 and was published 4 days ago: https://www.npmjs.com/package/react-tooltip?activeTab=versions
However in GitHub the latest commit is from 2 weeks ago and it's a chore for version 5.21.3: https://github.com/ReactTooltip/react-tooltip/commits/master
There's also no mention of 5.21.4 in the releases: https://github.com/ReactTooltip/react-tooltip/releases
I hope you weren't hacked and a rouge package was published under your name.
I think other maintainers have processes in place to keep these in sync.

Hey @targumon,
I just checked, and the last publish was by @gabrieljablonski:

we probably forgot to update the release notes, but our last releases have no code changes, only adjusting the sponsoring banner.
I'll confirm with Gabriel and we will update the release notes.
Thank you so much for checking and letting us know!

Hi @targumon.
Thanks for letting us know, but no need to worry. Sometimes we do minor releases related to some tests we do, and end up not updating the release notes. Though we'll make sure this doesn't happen again so it doesn't cause any confusion.
Thanks again.


dataset with spaces in column names breaks dashboard due to unescaped queries

It doesn't appear we're escaping column names in the analytical queries.
Steps to reproduce:

add the following source to RIll Developer
auto-generate dashboard

I get a number of 400 errors along these lines:
"Parser Error: syntax error at or near "posted"
LINE 1: ...M UFO_Reports_model WHERE 1=1 AND date posted >= ? AND date posted < ?  GROUP ...
                                                  ^"

@egor-ryashin : Can you help with this one?

I've fixed it here https://github.com/rilldata/rill-developer/pull/1490


Toolbar in panel header story is broken

closes : https://github.com/zakodium-oss/react-science/issues/627

Codecov Report
Attention: 58 lines in your changes are missing coverage. Please review.

Comparison is base (ebf6eb7) 24.32% compared to head (2cbbdf3) 24.25%.

Files
Patch %
Lines

stories/components/panel-header.stories.tsx
0.00%
31 Missing :warning:

src/components/toolbar/PanelPreferencesToolbar.tsx
5.88%
16 Missing :warning:

src/components/toolbar/Toolbar.tsx
8.33%
11 Missing :warning:

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@            Coverage Diff             @@
##             main     #629      +/-   ##
==========================================
- Coverage   24.32%   24.25%   -0.08%
==========================================
  Files         223      223
  Lines       12869    12911      +42
  Branches      234      234
==========================================
+ Hits         3130     3131       +1
- Misses       9651     9692      +41
  Partials       88       88

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


DOCS-8702: Please add configuration example for MuleSoft’s Enterprise Repositories

Mule 3.9 doc has it at https://docs.mulesoft.com/mule-runtime/3.9/configuring-maven-to-work-with-mule-esb#referencing-mulesofts-enterprise-repositories
It works with Mule 4.2.2, but I want to have it in the official 4.2 doc.

https://www.mulesoft.org/jira/browse/DOCS-8702

This issue is addressed and closed via https://www.mulesoft.org/jira/browse/DOCS-8702


[ci:component:github.com/gardener/logging:v0.49.0->v0.51.0]

Release Notes:
Build an image containing the bare minimum of libs for `tunef2s` to work alongside `lsblk` and `awk`.

/close in favor of #7650

/close


moved the test config to manifests folder

Yes
Fixes https://github.com/numaproj-labs/numaplane/issues/101
Modifications
Modified the config.yaml file  in tests/manifests folder with the latest fields
Modified config tests and the controller tests to use the config file from tests/manifests folder
Verification
As no new feature has been added ,only the existing tests cases have been checked if they run properly

Sorry, I think this Issue maybe wasn't clear. I was specifically hoping our tests could no longer reference repos like:

https://github.com/numaproj-labs/numaplane-control-manifests
https://github.com/numaproj/numaflow
And we could just put all of the files that we need for these tests within this repo instead, in tests/manifests.

Sorry, I think this Issue maybe wasn't clear. I was specifically hoping our tests could no longer reference repos like:

https://github.com/numaproj-labs/numaplane-control-manifests

https://github.com/numaproj/numaflow

And we could just put all of the files that we need for these tests within this repo instead, in tests/manifests.

ok i will modify that .

@juliev0 i have checked we are not using any resources  as of now from these git urls ,we are just using these urls for performing gitsync  tests in util_test.go . So I believe we dont have any dependency on these external repos

@juliev0 i have checked we are not using any resources as of now from these git urls ,we are just using these urls for performing gitsync tests in util_test.go . So I believe we dont have any dependency on these external repos

This is an example of a dependency on the numaflow repo: https://github.com/numaproj-labs/numaplane/blob/main/internal/git/util_test.go#L279 Let's say that config/namespace-install directory changes...

No longer needed


Switch over to HTML5 navigation

GitHub doesn't support HTML5 navigation very well, but with a workaround
it's possible to use it. If the user loads the index then navigation
works as normal, but if the user loads another path the 404 page kicks
in to redirect back to the index without losing the route.
Also add a default handler with 404 content.

Running on my site, you may need to refresh a few times:
https://kfarnung.github.io/puzztool/