Explore Improvements to DT Training Procedure

/Just wanted to have meta card to track progress on these things with links:

[x] LayerNorm (I'll probably only try layernorm pre) (https://github.com/jbloomAus/DecisionTransformerInterpretability/issues/52)
[x] AdamW Optimizer
[x] Adding a warmup stage with LambdaLR scheduler or cosine annealing
[x] Implement gated MLP's (https://arxiv.org/pdf/2002.05202.pdf). Might need to be done in TransformerLens.
[x] Make it possible to use GeLU not ReLU (try that out as well).
[ ] Better encode state.
[ ] Implement wandb sweeps for DT training (likely already exists a card for this so I should find it)

If we've implemented all of those and still no success with the memory env training, possibly try either much longer training runs, more variable sampling methods, or ask for advice (or go bug hunting)

LN and Adam done. No clear benefit on smaller model. I think I'll get everything implemented then set off some sweeps tomorrow/the next day with the memory env environment.

done lr scheduling stuff: https://github.com/users/jbloomAus/projects/1/views/1?pane=issue&itemId=27012682

I'm going to add a task here for setting up wandb sweeps. I think given the stuff I've added, it's important to just get a better sense of the right hyperparameters I need.

[ ] Implement wandb sweeps for DT training (likely already exists a card for this so I should find it)

I just had a lightbulb moment relating to #61 so I'm going to do that really quick before I attempt wandb sweeps.

converting "Implement masking rather than just having different tokens during padding" to it's own card.

Closing this. Got working agents!


enum type is always string

Describe the bug
Numeric enum generates type as string
To Reproduce
Have given ApiProperty:
@ApiPropertyOptional({
        enum: [0, 1, 2],
        example: 1,
        name: "sex",
        enumName: "sex",
        description: "..."
    })

In generated schema there is type as string, even if all values, are numbers:

Expected behavior
type of enum should be same, as values types (if all values are same type) or from implicit given type from ApiProperty decorator. If I put type: number the result is always string.
Environment
Nest version: 8.0.4

@pavlikm hey, enum can't have numeric keys.
TS2452: An enum member cannot have a numeric name.


How do you force prebuild-install to NOT compile from source/ALWAYS download prebuild binaries?

Really, I'd just like to force prebuild-install to NEVER skip the prebuilt option (they exist for a reason, after all!)

If a binary is available ´prebuild-install´ will always use it. Compiling from source is fallback only on user side. Do you have an example?

Sorry, yes. To clarify, I am attempting to use prebuild while installing a node module from a Git(Hub) repository instead of NPM. If I do not install the module directly from NPM (the original module does not provide prebuilt binaries) then I receive a line like the following:
> prebuild-install || node-gyp rebuild

prebuild-install info begin Prebuild-install version 2.3.0
prebuild-install info install installing from git repository, skipping download.

I have not found any way to force the use of prebuilt binaries, despite both trying with binaries commited in prebuilds and with prebuild's native prebuild -u <token> GitHub release upload. If there is a way to do so already, we can update the documentation to make this clearer.
Just to clarify, the module is included as a dependency under git+<repository>/file:<path>, but both methods cause it to skip retrieval of the (most certainly available) prebuilt binaries.

I think I know what you mean now. The "skipping download" thing is a feature used for when developing modules. But in your case this feature gets in your way since you are actually using git: or file: based dependencies and you will basically never get the any prebuilts. Correct?

Why don't you make a PR to make https://github.com/santigimeno/node-pcsclite prebuild ready? Maybe you can convince him that using prebuild is a cool thing? :)

The "skipping download" thing is a feature used for when developing modules. But in your case this feature gets in your way since you are actually using git: or file: based dependencies and you will basically never get any prebuilts.

This case also falls under "development". A git based dependency is mutable, so it can't have prebuilds.

Why don't you make a PR to make https://github.com/santigimeno/node-pcsclite prebuild ready? Maybe you can convince him that using prebuild is a cool thing? :)

👍

This case also falls under "development". A git based dependency is mutable, so it can't have prebuilds.

True.. The only thing we could do is to check if the github url is a tagged one and search the releases for that tagged version?!

I think I know what you mean now. The "skipping download" thing is a feature used for when developing modules. But in your case this feature gets in your way since you are actually using git: or file: based dependencies and you will basically never get any prebuilts. Correct?

This is correct.

Why don't you make a PR to make https://github.com/santigimeno/node-pcsclite prebuild ready? Maybe you can convince him that using prebuild is a cool thing? :)

Strange, I don't recall mentioning that module? ;)
Unfortunately, that would only solve our most obvious issue: getting the module itself loaded. We have a multi-stage build process for a cross-platform app that, ideally, should only have to be run on a Linux machine. Amongst various other issues, we want to make certain we're using our QA-tested binaries.

This case also falls under "development". A git based dependency is mutable, so it can't have prebuilds.

True.. The only thing we could do is to check if the github url is a tagged one and search the releases for that tagged version?!

I don't think changing the default behavior here is worth the effort; instead, I would propose a new flag that forces prebuild-install to ignore those checks. If accidental developer misuse is a worry, we could add warnings to alert the developer.
The code looks simple enough to modify. If there's not an existing method to do this, then I'll work on a pull request to add this functionality? :)

The code looks simple enough to modify. If there's not an existing method to do this, then I'll work on a pull request to add this functionality? :)

:+1:

@ralphtheninja The PR has been made when you have the chance to review it.

@ian-axiadids Yep, just noticed it! Fixing borked travis first.


GH-149 Swagger API to get account balance

Depends on #168

superseded by https://github.com/aeternity/epoch/pull/170


OpenCV/GStreamer/ Rk3399

NanoPi M4(Rk3399) have stability issues with V4L with CSI cameras(with USB everything is OK), so gstreamer with specific rkisp required

Hi !
Could you elaborate on the specific rkisp please ?
I have been testing the ov4689 on the Nano Pi M4 today using gstreamer just to display the video, and I could saw those stability issues in the dmesg. I was using FriendlyElec Desktop.
Have you been using it with FriendElec kernel too ? I am trying to get armbian to work with the camera... without much luck so far.

Good day!
I had stability issues with FriendlyElec Desktop(2018/12/18) too (dmseg issue, including Error, which stop display\record - below).
Armbian kernel(4.4) include all code for camera - only need to switch it on in config, but I didn't manage to control ISP from system - look like it should be /dev/media device for it, but it missed. Also I didn't manage to build RockChip gstreamer plugins. I will try again next week ;)
[91151.283111] cif_isp10_mipi_isr WARN: CIF_MIPI_ERR_CSI: 0x1100001 [91151.283134] cif_isp10_mipi_isr WARN: CIF_MIPI_SYNC_FIFO_OVFLW: 0x1100001 [91151.316596] cif_isp10_mipi_isr WARN: CIF_MIPI_ERR_CSI: 0x1100001 [91151.316617] cif_isp10_mipi_isr WARN: CIF_MIPI_SYNC_FIFO_OVFLW: 0x1100001 [91151.349906] cif_isp10_mipi_isr WARN: CIF_MIPI_SYNC_FIFO_OVFLW: 0x1 [91151.349943] cif_isp10_mipi_isr WARN: CIF_MIPI_ERR_CSI: 0x1100000 [91151.383399] cif_isp10_mipi_isr WARN: CIF_MIPI_SYNC_FIFO_OVFLW: 0x1 [91151.383419] cif_isp10_mipi_isr(6810) ERR: mipi_mis icr err: 0x1100000 [91151.384026] cif_isp10_mipi_isr WARN: CIF_MIPI_ERR_CSI: 0x1100000 [91151.416829] cif_isp10_mipi_isr WARN: CIF_MIPI_SYNC_FIFO_OVFLW: 0x1 [91151.416880] cif_isp10_mipi_isr WARN: CIF_MIPI_ERR_CSI: 0x1100000 [91151.450278] cif_isp10_mipi_isr WARN: CIF_MIPI_SYNC_FIFO_OVFLW: 0x1 [91151.450331] cif_isp10_mipi_isr WARN: CIF_MIPI_ERR_CSI: 0x1100000

maybe it's a good place to leave some more info:

ov4689 use 4 line CSI;
Nano Pi M/T4 use dual MIPI intefrace with 4 lines each;
Rk3399 have only 6 CSI lines, so for dual-camera mode ov4689 sensor should be configurated with 2 lines (in fact, it's similar to Raspberry PI Compute/dual-camera mode, but RPI cameras originally use 2 line design, so don't required reconfiguration);
this also means, that outstanding video performance of ov4689 cannot be achieved in dual-camera mode too

kernel 5.1 merge for nanoMpi T/M 4 support
https://github.com/torvalds/linux/commit/6ad63dec9c2c80710896edd1996e56c54a230870

Hi ! Thanks for the help !
I am stumbling on the exact same issues here. I tried to build Armbian with different config all day to get the new isp driver to work (rockchip-isp1 instead of the old rkisp10), but I can't get to see the /dev/media device to control the ISP...
I'll share the info here when I get it to work :)
And great found on the merge notes, 2 days old only :o

btw, it's no /dev/media in friendlyelec build too.

well, good news is - I manage to get camera working with Armbian
key point - need to use https://github.com/rockchip-linux/gstreamer-camera instead of other gsteramer-plugin/plugin-extra repositories.
I will continue my evaluation - since now looks like something with a color, but it works ;) https://github.com/ayaromenok/test/commit/b5b5c0770ac31d65052dce3e0aef174d6c5ac127

dmesg show same errors. but looks like camera work a bit more stable (OpenCV camera app not freezing)
[ 9081.826426] cif_isp10_mipi_isr(6810) ERR: mipi_mis icr err: 0x2
[ 9081.826443] cif_isp10_mipi_isr WARN: CIF_MIPI_SYNC_FIFO_OVFLW: 0x2
[ 9081.826454] cif_isp10_mipi_isr(6810) ERR: mipi_mis icr err: 0x2
[ 9081.826468] cif_isp10_mipi_isr WARN: CIF_MIPI_SYNC_FIFO_OVFLW: 0x2
[ 9081.826492] cif_isp10_mipi_isr WARN: CIF_MIPI_SYNC_FIFO_OVFLW: 0x2
[ 9081.826494] systemd-journald[312]: /dev/kmsg buffer overrun, some messages lost.
[ 9081.826512] cif_isp10_mipi_isr(6810) ERR: mipi_mis icr err: 0x2
[ 9081.826530] cif_isp10_mipi_isr WARN: CIF_MIPI_SYNC_FIFO_OVFLW: 0x2
[ 9081.826540] cif_isp10_mipi_isr(6810) ERR: mipi_mis icr err: 0x2
[ 9081.826554] cif_isp10_mipi_isr WARN: CIF_MIPI_SYNC_FIFO_OVFLW: 0x2
[ 9081.826578] cif_isp10_mipi_isr WARN: CIF_MIPI_SYNC_FIFO_OVFLW: 0x2
[ 9081.826580] systemd-journald[312]: /dev/kmsg buffer overrun, some messages lost.

@ayaromenok Can I ask you what pipeline do you use from opencv to capture camera input? I have a NanoPi NEO4 and i'm struggling to get the ov13850 camera working. I'm attempting to open the VideoCapture with the folloging pipeline passed to VideoCapture:
rkisp device=/dev/video0 sensor-id=1 io-mode=4 path-iqf=/etc/cam_iq/rk-ov13850.xml ! video/x-raw,format=NV12,width=640,height=480,framerate=30/1 ! appsink

But the isOpened always returns false. Any help would be appreciated!

@hosaka
I don't have ov13850 camera (only ov46xx), so it's only theoretical ideas:

try to get picture from camera via streamer without OpenCV: gst-launch-1.0 rkisp device=/dev/video0 sensor-id=1 io-mode=4 path-iqf=/etc/cam_iq/rk-ov13850.xml ! video/x-raw,format=NV12,width=4224,height=3136,framerate=30/1 ! rkximagesink
try to use full sensor resolution - 4224,3136

PS: I use OpenCV 4.0.x, built with gstreamer support and not a FriendlyElec prebuild OpenCV 3.4.x

@ayaromenok Hi, thank you for your reply! I'm also using OpenCV 4.0.1 built with gstreamer. I've got this simple pipeline working:
rkisp device=/dev/video0 sensor-id=1 io-mode=4 path-iqf=/etc/cam_iq/rk-ov13850.xml ! video/x-raw,format=NV12,width=640,height=480,framerate=30/1 ! videoconvert ! appsink

However this doesn't use the rockchip mpp encoder/decoder. And thus opencv performance suffers between frames, USB camera works much better. Also, I need smaller images on the receiving end, since I'm feeding them into a neural network at the end, so the full resolution is not necessary.
 Would you happen to have some suggestions on how to use the hardware encoder/decoder to feed compressed data into OpenCv? I'm guessing that this will help with performance.
Cheers!

@hosaka - in general - you don't need to use h264 encoder in ISP and than a h264 decoder in OpenCV to get a data, so first option with RAW data(in NV12 format) is correct - no intermediate conversion, except from NV12 to BGR (one more idea - use may Video4Linux directly - and converts to BGR in CV).
The problem is in camera config\software support - while your 13MP sensor support a smaller native resolution (2112x1568 at 60fps), looks like it's always used a full 13MP resolution, and this board just not fast enough for this. Plus, in camera config you may find something like a 7.5 and 15fps for some resolution - this may affect too.
PS: ov46xx sensor (which I have) is looks more suitable for NN - at least it can handle stable 30fps(plus, have wider FOV)

@ayaromenok Thank you for your suggestions! I'll look into purchasing an OV4689 camera and give that a try as well. If I try to use v4l2 directly, I don't need to compile opencv with gstreamer libs right? That would be ideal if I can drop the gstreamer dependencies, convert to BGR and resize in opencv directly from the camera.

@hosaka it's a example of image from V4L2 in OpenCV - https://github.com/ayaromenok/test/blob/master/09_CvGStreamerCam/res/yuv1280x720.png - you may try to use it, but I found it useless.
ov4689 sensor can be better for CV type of application (due to high-speed video mode), but again - software support is terrible as for ov13850 :(

hey, I've been attempting to get opencv to stream from the ov4689 that I have connected to my nanopi m4. However, I get gstreamer errors when trying to open the camera. Attempting to open using gstreamer throws
`GStreamer: Error opening bin: no element "rkisp"
(python:7788): GStreamer-CRITICAL **: gst_element_get_state: assertion 'GST_IS_ELEMENT (element)' failedeven though I can preview just fine using the gst-launch-1.0 bash command.  Any help would be appreciated.

@pfarrel84 Looks like you don't have rkisp gstreamer module for some reason.
What OS do you use on M4 board? This module exist in FriendlyDesktop/Core since 201812xx version, while missing in Armbian for NanoPi M4/avafinder own Ubuntu build.
You can check presence of this gstreamer module by gst-inspect-1.0  | grep rk (you may need to install gstreamer1.0-tools)
PS: native proportion of ov4689 sensor is 16:9, so resolutions like 672x380, 1280x720, 1920x1080 can provide less distortion in input image (can be critical for OpenCV)

rkisp is detected when I run gst-inspect-1.0
rkisp:  rkisp: Gstreamer Plugin For Rockchip ISP Source
rkisp works properly when I launch it as
gst-launch-1.0 rkisp device=/dev/video0 sensor-id=1 io-mode=4 path-iqf=/etc/cam_iq/rk-ov4689.xml ! video/x-raw,format=NV12,width=1280,height=720,framerate=30/1 ! rkximagesink
I'm running lubuntu 16.04 on the 4.4 Kernal.

@pfarrel84
It's really strange than.
Did you build OpenCV by yourself? is it include gstreamer support for camera? python bindings for all modules?

Yeah, I compiled OpenCV 3.4.5 from source. Build information says that gstreamer 0.10.36 is supported
 GStreamer:       base:                      YES (ver 0.10.36)       video:                     YES (ver 0.10.36)       app:                       YES (ver 0.10.36)       riff:                      YES (ver 0.10.36)       pbutils:                   YES (ver 0.10.36)
I have opencv built for both python 2 and 3, I don't know a way of checking to make sure all the modules have python bindings though.
I'm suspecting the issue is that gstreamer 0.10 is being used instead of 1.0, I'll probably try recompiling with gstreamer 1.0 later today and see if that fixes it.

@pfarrel84

I'm suspecting the issue is that gstreamer 0.10 is being used instead of 1.0, I'll probably try recompiling with gstreamer 1.0 later today and see if that fixes it.

it's possible.
just in case - my working configuration include OpenCV 4.0.x with GStreamer 1.0, build in Ubuntu 18.04

Hey, I got busy yesterday but here's an update:
I got opencv to work with one ov4689 camera using gstreamer 1.0 instead of 0.10, there are no longer any errors. So that's resolved now!
I was able to get your test code to work for one camera, however i cannot get the dual camera setup working. Is there changes to the xml I need to make or other configurations to be made to resolve this? I saw above that the ov4689 uses 4 CSI lines out of 6 so I'm assuming that's the problem. Anyway, I really appreciate your help with getting this working!

@pfarrel84
It's great to know that camera working!
regarding dual-camera - up-to-date info: it will not work with FriendlyElec distro.
Technically - it's 2 different driver for RK3399 in kernel: older(~2017) isp10 and more recent(since 2018) isp1.
Older driver (that what you can find in FirendlyElec Ubuntu 16.04 and 18.04) support only one device in time - controlled via Video4Linux or gstreamer. Newest driver use kernel Media API and support multiply devices, but it's work-in-progress and not correctly integrated with drivers for ov4689/ov13xxx - cameras for NanoPi M4. May be one day drivers will start to work (I know, that it was done some work on armbian\thinkerboard, which use similar ISP, but different CPU - but can't check right now since I am in vacation ;) ) and than it will be possible to evaluate a dual-cam mode\number of CSI line issue.

ah, that's a shame honestly. Oh well, thank you for your help!

Oops.  I bought two ov13850's in the hope of running dual cameras with opencv on the NanoPC-T4 FirendlyElec Ubuntu 18.04:
gst-launch-1.0 rkisp sensor-id=1 io-mode=4 path-iqf=/etc/cam_iq/rk-ov13850.xml device=/dev/video4
! video/x-raw,format=NV12,width=720,height=480,framerate=10/1
! videoconvert ! autovideosink
With both cameras connected, but running one at a time, /dev/video0 works, but /dev/video4 is flakey.  (One bright frame then dim)

@cafrank
Dual-camera mode not working with T/M4 with FriendlyElec Unbuntu due to usage of old isp10 driver.
Rockchip create a new driver, called isp1, but as I know, at present moment it's used only on Asus TinkerBoard(201902 build from asus and, possible, armbian too).
I write some result of my driver investigation here

Thank you for the quick info.  I will keep the second camera, and try more stuff in the hope of getting to isp1. I initially had Armbrin on the board, but it did not load the drivers (no /dev/video?), so I moved to Friendly-Ununtu 18.04.

@cafrank In Armbian you need to rebuild kernel with isp10 enabled and build gstreamer rksip - but I don't find/made correct IQ driver for camera - so AWB is not working.
Armbian maintener - IgorP already switch on isp10 in his branch, so soon it will work out-of-the-box (at least, with V4L2)

Even by enabling ISP10 when building Armbian kernel I was never able to make the driver work or even see the /dev/video or /dev/media. It's like the option did not do anything (I tried about a month ago)

@JulesThuillier  you need to enable isp1 to have chance to see /dev/media (as I remember, you need to use patches from asus tinkerboard kernel first just to build it).
isp10 use old V4L2 only driver, so only /dev/video will appear (but you need to build sensor drives too).

@ayaromenok I had enabled it in Armbian (for nanopi M4), but I couldn't see or use it (it wasn't even detected as "installed").
The IQ settings files are the XML files right ?
I'll be looking into latest Armbian and Tinkerboard updates, maybe I'll find a solution there.

@JulesThuillier I can send you working kernel config in two weeks, when I will back home.
Bun as I remember, I manually switch everything on with rkisp (or rockchip ) and sensor driver (ov4* and ov13*) in .config and build in drivers(using =y inf config instead of modules =m).
yes, IQ settings is XML, but it support own versioning (see code_xml_parse_version on top of XML file).
FriendlyElec distro use version 0.18, while gstreamer driver from rockchip repo( which I manage to build) - 0.17 and they not backward-compatible (at least in AWB section). many more version can exist ;)

@JulesThuillier @pfarrel84 @cafrank @hosaka
Good news first: FriendlyElec publish a new OS image from 20190511, which include "new" RKISP and \dev\media0 & \dev\media1 devices.
Bad news for me personally: CSI1 connection don't work anymore on my board for some reason (while CSI2 is OK), so I can't test stereo-mode.
Please, if you manage to make stereo-mode working - let me know - I am thinking about buying a new one, but need to be sure, that's stereo working well )

for "old" rkisp10 driver is
for CSI1 error is follow
cif_isp10_mipi_isr WARN: CIF_MIPI_ERR_CSI: 0x100001
cif_isp10_mipi_isr WARN: CIF_MIPI_SYNC_FIFO_OVFLW: 0x100001
cif_isp10_mipi_isr(6867) ERR: mipi_mis icr err: 0x1

for CSI2 error the same, as above
[ 9081.826512] cif_isp10_mipi_isr(6810) ERR: mipi_mis icr err: 0x2
[ 9081.826530] cif_isp10_mipi_isr WARN: CIF_MIPI_SYNC_FIFO_OVFLW: 0x2
[ 9081.826540] cif_isp10_mipi_isr(6810) ERR: mipi_mis icr err: 0x2
[ 9081.826554] cif_isp10_mipi_isr WARN: CIF_MIPI_SYNC_FIFO_OVFLW: 0x2
[ 9081.826578] cif_isp10_mipi_isr WARN: CIF_MIPI_SYNC_FIFO_OVFLW: 0x2

FriendlyElec from 20190511 - new rkisp1 log
[    0.240594] iommu: Adding device ff910000.rkisp1 to group 4
[    0.241176] iommu: Adding device ff920000.rkisp1 to group 5
[    1.383363] rkisp1 ff910000.rkisp1: rkisp1 driver version: v00.01.00
[    1.383941] rkisp1 ff910000.rkisp1: Missing rockchip,grf property
[    1.385698] rkisp1 ff910000.rkisp1: GPIO lookup for consumer vsirq
[    1.385707] rkisp1 ff910000.rkisp1: using device tree for GPIO lookup
[    1.385716] of_get_named_gpiod_flags: can't parse 'vsirq-gpios' property of node '/rkisp1@ff910000[0]'
[    1.385725] of_get_named_gpiod_flags: can't parse 'vsirq-gpio' property of node '/rkisp1@ff910000[0]'
[    1.385731] rkisp1 ff910000.rkisp1: using lookup tables for GPIO lookup
[    1.385739] rkisp1 ff910000.rkisp1: lookup for GPIO vsirq failed
[    1.386026] rkisp1 ff920000.rkisp1: rkisp1 driver version: v00.01.00
[    1.386622] rkisp1 ff920000.rkisp1: Missing rockchip,grf property
[    1.388305] rkisp1 ff920000.rkisp1: GPIO lookup for consumer vsirq
[    1.388313] rkisp1 ff920000.rkisp1: using device tree for GPIO lookup
[    1.388322] of_get_named_gpiod_flags: can't parse 'vsirq-gpios' property of node '/rkisp1@ff920000[0]'
[    1.388330] of_get_named_gpiod_flags: can't parse 'vsirq-gpio' property of node '/rkisp1@ff920000[0]'
[    1.388337] rkisp1 ff920000.rkisp1: using lookup tables for GPIO lookup
[    1.388344] rkisp1 ff920000.rkisp1: lookup for GPIO vsirq failed

CSI1:
rkisp1: MIPI mis error 0x0000001
rkisp1: MIPI mis error 0x0000001
rkisp1: MIPI mis error 0x0001001 << not sure about this

CSI2:
rkisp1: MIPI mis error 0x0000002
rkisp1: MIPI mis error 0x0000002
rkisp1: MIPI mis error 0x0000002
rkisp1: MIPI mis error 0x0100002

I tried the latest image, but the following pipeline does not Work:
`gst-launch-1.0 rkisp num-buffers=20 dev
ice=/dev/video0 io-mode=1 path-iqf=/etc/cam_iq/ov4689.xml !
video/x-raw,format=NV12,width=640,height=480,framerate=10/1
!  jpegenc ! multifilesink location=/tmp/test.jpg|

plz, check dual-camera.sh script with FriendlyElec image from 201905XX or later.

@ayaromenok dual-camera.sh assumes a FriendlyDesktop with an lxsession.

@harandK yes. Something with X11 session - since you will have 2 windows from both cameras ;)

@ayaromenok basically, I would like to use both cameras in a headless mode with opencv, applying stereomatching etc.

@harandK it's up to you. But maybe it's a good idea to develop and debug with X11 and multiply windows/using IDE an than switch to console only/headless mode.
Just don't forget to change last parameter to appsink in openCV

@ayaromenok The camera which is connected to the MIPI CSI1 connector, provides a distorted image. Even when I switch the cameras. Also the performance is really bad in dual mode. Thanks for your help so far.

@harandK I had similar issue with one of MIPI CSI1 - screenshot - and now it even worse - hang up almost immediately. So, I return to Raspberry Pi Compute/IO Board with dual camera setup and sent stereo-pair via network stream to target(more powerful, than RPi) board.


Discord Error occurred forever

every time i press authorize, my keyboard and mouse slowly turn red and it will ask me to authorize multiple times. there are no troubleshooting pages to help why I'm getting errors at all. not really sure what to do right now.

Same issue for me. It dont register that i approve the authorization

Same exact issue. The second I check the Connect to Discord checkbox it just keeps asking for permissions inside discord and then showing the error animation/lighting after granting them.

Same issue here. Hope this gets updated because its an amazing app.

Same Issue here... Is this App dead?

Same... And the app hasn't been updated in over a year so I'm fearing it's dead.

This was tied to the scope issue and has been fixed.


Create a decorator that caps the range of allocation (for allocations.py)

In PR #97, ta-oliver commented:

(...) We could consider allowing short selling by default as it is easy for user to trivially truncate results if needed? We could create a decorator for example that capped the range of allocation between a and b that users could apply to constain any allocation algorithm.

and

We could use a decorator to enforce maximum allocation ranges (short selling and max leverage/upper allocation) as it is simple to wrap and doesn't need any other information.

This decorator could deal with:
(a) short selling and usage of leverage;
(b) handling "allocators" that don't return values in [-1, 1].
Although with (b) there's obviously an issue with knowing how to normalize the series.
(edited: changed as per the comments below)
This could be worth looking into soon-ish (implemeting the decorator should be straightforward), so I'm not adding the icebox label for now.

a) is a very simple and formulaic constraint decorator.
b) would be potentially quite complicated, depending on what level of complexity was acceptable.
It might be worth splitting off a) as that will be 6 lines of code whereas b) may be a mini-research project given different possible considerations (e.g. if bid-offer is high you may want stable allocations).

@fernando-az-infertrade - I think a) will be very fast, as limited code. Happy to undertake?

@fernando-az-infertrade - I think a) will be very fast, as limited code. Happy to undertake?

Yes.

@holderfolyf - this could be extended to include a daily stop loss? And eventually dynamic stop losses?

Potential PRs for this:
https://github.com/ta-oliver/infertrade/compare/main...modified_decorator_branch
https://github.com/ta-oliver/infertrade/compare/main...decorator_for_allocations_py

I am working on a solution for stop-loss however facing some issues with computing entry price. Shall i commit work in progress code to this branch or a separate one?

I am working on a solution for stop-loss however facing some issues with computing entry price. Shall i commit work in progress code to this branch or a separate one? @ta-oliver

We want to merge improvements to dev whenever they are complete, starting further work as fresh feature branches.
I would suggest us first reviewing and merging in @fernando-az-infertrade 's improvements and then you could create a new feature branch to work on adding the stop loss?

@bi-kash - this is the allocations restriction issue we discussed.

@bi-kash - this is the allocations restriction issue we discussed.

I'll start addressing this issue ASAP.

Also see discussions here and here.

Essentially @fernando-az-infertrade created a better format that I had initially envisioned and we could make a @apply_restrictions decorator of similar format.

@bi-kash , @holderfolyf  - we could incorporate the stop loss into this format too.

Many thanks @bi-kash , @fernando-az-infertrade and @holderfolyf .


Early allocation of the Chef::RunContext

Allow for allocation of the Chef::RunContext without its arguments and
use that to allocate it early.  The APIs are kept backcompatible since
otherwise this has a decent chance of blowing up something like
chefspec.

Is the idea of this so that we can log earlier and have earlier event handlers?

it ultimately gets the run_context created earlier and gets setup_run_context out of the business of creating it, and that allows event handlers to get ahold of that object earlier
and then the point is more to the hang the rest client(s) off of the run_context for reuse.  that has broader benefits, but one goal is to get all the ResourceReporter + DataCollector crap out of the Chef::Client.

also "do less work in initializers" and now you can create a Chef::RunContext without passing a node + cookbook_collection + event handler, which it doesn't always need (noting how often we pass {} in for the cookbook_collection), etc.
not that i'm certain how much i want to push that, since there's about a billion run_context objects created in the unit tests and i don't really want to go through and 'fix' every single one just for philosophical reasons -- hence why this change is all backcompat and not breaking...


Update README to have known issues

Fix #6 - other sections of the README could use fleshing out, particularly the usage (once #9 is resolved).

Err looks like there's a ton of other stuff on this branch - I'll just add straight to master.


How to specify export bundle fields in HISTORY.rc

I have a general MAPL history question. I have code below that creates an ‘MSA’ field in the ‘AEROSOLS’ bundle within the ‘AERO’ export.
In SetServices:
call MAPL_AddExportSpec(GC,                    &
       SHORT_NAME = 'AERO',                        &
       LONG_NAME  = 'aerosol_mass_mixing_ratios',  &
       UNITS      = 'kg kg-1',                     &
       DIMS       = MAPL_DimsHorzVert,             &
       VLOCATION  = MAPL_VLocationCenter,          &
       DATATYPE   = MAPL_StateItem, __RC__)

In Initialize:
call ESMF_StateGet(expChem, 'AERO', aero, __RC__)
aero_state_aerosols = ESMF_FieldBundleCreate(name='AEROSOLS', __RC__)
call MAPL_StateAdd(aero, aero_state_aerosols, __RC__)
call ESMF_StateGet(INTERNAL,’GOCART::MSA_ForBundle', FIELD, __RC__ )
fld = MAPL_FieldCreate(FIELD, name=’MSA’, __RC__)
call MAPL_FieldBundleAdd(aero_state_aerosols, fld, __RC__)

My question is how do I output the ‘MSA’ field via History? Is there syntax for specifying export/bundle/field? I realize perhaps outputting the internal state here is a better option, but I would like to know how to get at the AERO export contents directly.

@bena-nasa Following our discussion last week I tried adding each of these to HISTORY.rc, specifying gridcomp 'GOCART':
'AEROSOLS%MSA'
'AERO%AEROSOLS%MSA'
'AERO%MSA'
'MSA'
'AERO'
All of these combinations failed with MAPL_StateGet errors in History. Do you know for certain that export bundle fields can be output via MAPL History?

call MAPL_AddExportSpec(GC,                    &
SHORT_NAME = 'AERO',                        &
LONG_NAME  = 'aerosol_mass_mixing_ratios',  &
UNITS      = 'kg kg-1',                     &
DIMS       = MAPL_DimsHorzVert,             &
VLOCATION  = MAPL_VLocationCenter,          &
DATATYPE   = MAPL_StateItem, RC)

Lizzie,
First, we never add states to state like that in the addexport, importspec
In SetServices you create the bundle in the export state:
call MAPL_AddExportSpec(GC,                    &
       SHORT_NAME = 'AERO',                        &
       LONG_NAME  = 'aerosol_mass_mixing_ratios',  &
       UNITS      = 'kg kg-1',                     &
       DIMS       = MAPL_DimsHorzVert,             &
       VLOCATION  = MAPL_VLocationCenter,          &
       DATATYPE   = MAPL_BundleItem, __RC__)

@bena-nasa My example code is cut and pasted from GOCART in a fairly recent version of GEOSgcm. I did not edit it beyond omitting non-relevant lines of code. It seems to work okay for exporting the aerosol bundle from GOCART to Radiation since it has been in place for a while.  I believe Elliot Sherman is working to rewrite GOCART to clean up the code. Perhaps this is an area that could be made more standard?
I am going to close this issue since it is no longer a problem for me. I am getting the array values I want to History via other means.


conifg(engine): refine storeConfig to support new isolation schema

Is your feature request related to a problem?
No
Describe the feature you'd like
Refine storeConfig to support new isolation schema
Describe alternatives you've considered
No response
Teachability, Documentation, Adoption, Migration Strategy
No response

/area engine

/assign @maxshuang


[FLINK-9941][ScalaAPI] Flush in ScalaCsvOutputFormat before close

What is the purpose of the change
This pull request update scala api ScalaCsvOutputFormat to increase continuous integration stability.
Brief change log
Add flush method before close method in ScalaCsvOutputFormat for scala API.
Verifying this change
Add ScalaCsvOutputFormatTest and test passed.
Does this pull request potentially affect one of the following parts:

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

Documentation
Does this pull request introduce a new feature? (yes / no)
If yes, how is the feature documented? (not applicable / docs / JavaDocs / not documented)

+1

+1

@aljoscha u are original author of this class. mind help to review it?

@rmetzger I noticed that the problem is still unresolved, can u help to review it?

because this pr code is too late from master (fork a year go, flink 1.5) , it can't pass ci.  So I pull the latest flink project and create a new pr.  https://github.com/apache/flink/pull/9467


Update library release.

Hello, thanks for making this handy library, its possible to make a new release for this? given that there are several bugs and fixes that were fixed and merged already and the latest release was on Jan 31.

@mattapperson ping

Update 1.1.0

Yes please. I'm running on master now.

I am a little slammed this week, ill try to cut a new release on Tuesday

@mattapperson Need help with this lib? If you're too slammed for a release, your release procedure might be suboptimal. I'll be using this library a lot, so perhaps I can assist.

@mattapperson   ping?

@mattapperson  ping?  Thank you

We need more contributors and administrators for this repo. This is an amazing library, arguably the best react-native library and thus the high number of issues which can be overwhelming for any one person to handle.
@mattapperson and other admins, can we come up with a strategy to bring about more leadership and pace here?
Thank you!

Hey sorry, I’ll be cutting a build tomorrow.
I’ll also be talking with the other admins/collaborators about the issue/pr/responsiveness issues

@mattapperson

@iamronsuez sorry... updated!


Invariant culture parsing

Eliminates problems with parsing ints and doubles on localization-specific OSs

Thanks for updating.


The predicate.buildType syntax not in compliance with SLSA v0.2

Expected Behavior
The predicate.buildType in SLSA v0.2 is of type string with TypeURI format, which is defined in RFC 3986.
Actual Behavior
The current predicate.buildType is not a valid RFC 3986 URI because it's missing the scheme component.
Steps to Reproduce the Problem

Create a Tekton TaskRun or a PipelineRun
Notice that the Chains controller generates the attestation JSON with predicate.buildType not in RFC 3986 syntax

Additional Info
A common prefix, such as https:// could be added to TaskRun or PipelineRun attestations.

Thanks @zregvart for filing this ticket. Concur with that. I think there are 2 changes we need to make.

to make sure the buildType field is fully in-spec with SLSA 0.2.
@chitrangpatel may have more knowledge about this. Essentially, we might need to create documentations and the buildType is the uri pointing to the docs because based on the slsa definition: buildType should be "URI indicating what type of build was performed. It determines the meaning of invocation, buildConfig and materials." .

I think we would also add a new configmap field to make the field is configurable.
Reasoning: The cloud builders that uses tekon as the infrastructure may need the field to point to their own flavoured documentations. Therefore, making it configurable would be beneficial to those users.

/remove-lifecycle stale

The new slsa/v2alpha1 provenance format that's currently WIP changes this to:
https://github.com/tektoncd/chains/blob/ad16eb4661d7634567e97aa1754ecd23c19b8626/pkg/chains/formats/slsa/v2/taskrun/taskrun.go#L58
Which should cover this.
I know we've made changes to this before, but I'm a bit hesitant to make additional changes to the slsa/v1 buildType after seeing the challenges that popped up after making a similar change in cosign - https://github.com/sigstore/cosign/pull/2737. We ended up having to walk it back because users were keying on the predicateType and broke downstream tools / policies.


Crash on S2Geometry lsb() -> UInt64

A crash occurs when executing this function inside S2Geometry.swift
    func lsb() -> UInt64 {         return UInt64(Int64(id) & -Int64(id))     }

What's the value of id for the cell you're testing with?

Id "9263822755068982677"
Luke, do you think it is wise/safe to publish an app on the App Store containing this unofficial API? The app would be free with in-app purchases.

@lsapan Link to SO where @lucamegh asked this question:
http://stackoverflow.com/questions/38623251/crash-on-uint64-bitwise-operation-in-swift
that will help solve the crash, but we still can't find useful map objects (expected since you said there's still some things to be done.)

This should be all set now, let me know if you're still running into any issues.


Fix a link to pretrained model.

In the implementation of resnet, I found a wrong link to a pretrained model.
The following link must be to resnet-50 pretrained model.
https://github.com/chainer/chainercv/blob/6a0ccda66125985f8a2453995c73fe31e1cccf31/chainercv/links/model/resnet/resnet.py#L112
I believe 'resnet50_imagenet_trained_2018_11_26.npz' should be the correct link, but I haven't checked yet.

Thank you for reporting the issue. I made PR for this #751.


Nice to have - Clickup api url

Is it possible to pass a parameter to the clickup_api constructor to change the clickup api url used ?
I need to change it to catch request in my proxy (to avoid CORS issue).
Thanks.

Hi,
Alright, i'm gonna release this change on next update.
Tks for the feedback.

Thanks !

Hello i've done the modification locally, do you allow me to submit the modifications ?

Hi,
Open a merge request to dev branch, so I can check the changes.
Tks.

Changes published on version 1.4.0.
https://www.npmjs.com/package/clickup_api/v/1.4.0


Air Race Speed [PCSE00980]

App summary

App name: Air Race Speed
App serial: PCSE00980
App version: 1.00

Vita3K summary

Version: v0.1.6 3002-4dfc3911
Build number: 3002-4dfc3911
Commit hash: https://github.com/vita3k/vita3k/commit/4dfc3911
CPU backend: Dynarmic
GPU backend: OpenGL

Test environment summary

Tested by: Computerdude77
OS: Windows 10
CPU: Intel Core i3-4130
GPU: NVIDIA GeForce GTX 1050 Ti/PCIe/SSE2
RAM: 16 GB

Issues
Texture issues with the jet boosters. An error message occurs sometimes when crashing/finishing a level PSVitaBasicSoundSource::pause: sceNgsVoicePause failed: 804a0010
Screenshots

Log
vita3k.log
Recommended labels

Playable
Graphics bug
Crash

I was doing some further testing and did not realize that on the Vulkan render, there are different texture issues, where the jets and level tunnel do not render correctly, along with the booster issues. Here are some screenshots showing that off, tested on the https://github.com/Vita3K/Vita3K/commit/97f8bb0d commit:


MM-43215: Fixes typo.

Summary
Fixes typo.
Ticket Link
https://mattermost.atlassian.net/browse/MM-43215
Release Note
NONE

/update-branch

/cherry-pick release-6.6

Cherry pick is scheduled.

Error trying doing the automated Cherry picking. Please do this manually
+++ Updating remotes...
Fetching upstream
Failed to add the RSA host key for IP address '<IP_ADDRESS>' to the list of known hosts (/app/.ssh/known_hosts).
From github.com:mattermost/mattermost-webapp
   f1954e4b2..fcbdcdb3d  MM-37714_Unread-section-in-channel-switcher -> upstream/MM-37714_Unread-section-in-channel-switcher
   ff681f6d2..8c02491e7  MM-41211_session-expiry-hours -> upstream/MM-41211_session-expiry-hours
 + fdb50e4f3...30ebae198 MM-41347_advance-text-editor -> upstream/MM-41347_advance-text-editor  (forced update)
 * [new branch]          MM-41565_fixes-minus-one-thread-count -> upstream/MM-41565_fixes-minus-one-thread-count
 * [new branch]          MM-41981_marketplace-latest-install -> upstream/MM-41981_marketplace-latest-install
 * [new branch]          MM-42023-add-task-list-to-end-users -> upstream/MM-42023-add-task-list-to-end-users
   3aa8742a9..75bed3b33  MM-42391-a         -> upstream/MM-42391-a
 * [new branch]          MM-42585-actions-cypress-tests -> upstream/MM-42585-actions-cypress-tests
   49dcbb1dd..d82dbeb77  MM-42891-hide-healthdashboard-not-valid-cloud-options -> upstream/MM-42891-hide-healthdashboard-not-valid-cloud-options
 * [new branch]          MM-42970-plugin-usage-stats-api -> upstream/MM-42970-plugin-usage-stats-api
 * [new branch]          MM-43075           -> upstream/MM-43075
 * [new branch]          MM-43079           -> upstream/MM-43079
 * [new branch]          MM-43084           -> upstream/MM-43084
 * [new branch]          MM-43328/show-channel-admins -> upstream/MM-43328/show-channel-admins
 * [new branch]          MM-43345-actions-menu-unit-tests -> upstream/MM-43345-actions-menu-unit-tests
 * [new branch]          MM-43350-change-actions-text -> upstream/MM-43350-change-actions-text
 * [new branch]          command-pal-poc    -> upstream/command-pal-poc
 * [new branch]          command-palette-modal-and-feature-flag -> upstream/command-palette-modal-and-feature-flag
 + 15f8bd19c...fad4f2e90 hh_ship-types-and-client -> upstream/hh_ship-types-and-client  (forced update)
   fa09b711e..e8d9c4e71  master             -> upstream/master
   c264149ee..660a89322  release-6.6        -> upstream/release-6.6
 * [new branch]          update-link-tooltip-docs -> upstream/update-link-tooltip-docs
 * [new tag]             cloud-2022-04-12-1 -> cloud-2022-04-12-1
 * [new tag]             v6.3.7             -> v6.3.7
 * [new tag]             v6.6.0             -> v6.6.0
Fetching origin
Failed to add the RSA host key for IP address '<IP_ADDRESS>' to the list of known hosts (/app/.ssh/known_hosts).
+++ Updating remotes done...
+++ Creating local branch automated-cherry-pick-of-mattermost-webapp-#10173-upstream-release-6.6-1650286246
Switched to a new branch 'automated-cherry-pick-of-mattermost-webapp-#10173-upstream-release-6.6-1650286246'
Branch 'automated-cherry-pick-of-mattermost-webapp-#10173-upstream-release-6.6-1650286246' set up to track remote branch 'release-6.6' from 'upstream'.

+++ About to attempt cherry pick of PR #10173 with merge commit 2b1f19b408c401de12eb25f0332c15062a598bd2.

The previous cherry-pick is now empty, possibly due to conflict resolution.


Add affinity rules to the istio-cni helm chart

There are a few situations where Istio CNI should not be deployed to every node, namely virtual nodes from systems like admiralty. I propose the addition of affinity rules to the istio-cni helm chart to allow the configuration of anti-affinity rules for these situations.
Forking the chart myself, generating k8s artifacts and then applying manual changes
Affected product area (please put an X in all that apply)
[ ] Ambient
[ ] Docs
[X] Installation
[X] Networking
[ ] Performance and Scalability
[ ] Extensions and Telemetry
[ ] Security
[ ] Test and Release
[X] User Experience
[ ] Developer Infrastructure
Affected features (please put an X in all that apply)
[ ] Multi Cluster
[ ] Virtual Machine
[ ] Multi Control Plane
I'd be happy to make the contribution myself, but I'm not really sure how to get involved.

Fixed by $42038


async-h1 error

async-h1 error(version :  0.11.0)
when i use command test
\Apache24\bin\ab.exe -c1000 -n10000 http://localhost:8080/test

2020-06-19T20:48:35.284913500+08:00 ERROR tide::server - async-h1 error  (C:\Users\mayn\.cargo\registry\src\github.com-1ecc6299db9ec823\tide-0.11.0\src\server.rs:309)
2020-06-19T20:48:35.286893200+08:00 ERROR tide::server - async-h1 error  (C:\Users\mayn\.cargo\registry\src\github.com-1ecc6299db9ec823\tide-0.11.0\src\server.rs:309)
2020-06-19T20:48:35.288917700+08:00 ERROR tide::server - async-h1 error  (C:\Users\mayn\.cargo\registry\src\github.com-1ecc6299db9ec823\tide-0.11.0\src\server.rs:309)
2020-06-19T20:48:35.291918100+08:00 ERROR tide::server - async-h1 error  (C:\Users\mayn\.cargo\registry\src\github.com-1ecc6299db9ec823\tide-0.11.0\src\server.rs:309)
2020-06-19T20:48:35.293902200+08:00 ERROR tide::server - async-h1 error  (C:\Users\mayn\.cargo\registry\src\github.com-1ecc6299db9ec823\tide-0.11.0\src\server.rs:309)
2020-06-19T20:48:35.295916700+08:00 ERROR tide::server - async-h1 error  (C:\Users\mayn\.cargo\registry\src\github.com-1ecc6299db9ec823\tide-0.11.0\src\server.rs:309)

Does this happen on master as well?

Does this happen on master as well?

yes

Maybe this error message is caused a client sending HTTP/1.0 requests:
[2020-09-21 23:34:32][ERROR] async-h1 error
    error: Unsupported HTTP version 1.0
(C:\Users\fw\.cargo\registry\src\mirrors.ustc.edu.cn-61ef6e0cd06fb9b8\tide-0.13.0\src\listener\tcp_listener.rs:66)

This error message can be caused by haproxy too.
for example
haproxy.cfg file:
global
    maxconn         10000

defaults
    timeout client          30s
    timeout server          30s
    timeout connect         30s

frontend my-frontend
    bind <IP_ADDRESS>:8100
    default_backend my-backend

backend my-backend
    server s1 <IP_ADDRESS>:8080 check

run the hello example, and run haproxy to backend :8080
$ cargo run --example hello
$ haproxy -f haproxy.cfg

error log is
tide::listener::tcp_listener async-h1 error
    error Connection reset by peer (os error 54)

async-h1 does not support HTTP 1.0
$ cargo run --example hello
$ curl --http1.0 http://<IP_ADDRESS>:8080/
tide::listener::tcp_listener async-h1 error
    error Unsupported HTTP version 1.0

Support for HTTP/1.0 was added to async-h1 in https://github.com/http-rs/async-h1/pull/170. However I'm not sure how to enable it, perhaps we're missing a release?
cc/ @jbr do you know what the story here is right now?

Tide isn't set up for 1.0 yet. We'd need to be able to configure a default host. That might be another listener configuration?

I think we might also need an async-h1 release. It's on the 3.0 branch because I've been considering it experimental

Also this issue from Nginx proxy requests, Nginx proxy_pass default uses HTTP/1.0

I'm also seeing this async-h1 error without details.
With trace enabled (RUST_LOG=trace cargo run), here is some of the events before/after.
[2022-12-20T19:42:18Z INFO  tide::log::middleware] --> Response sent
[2022-12-20T19:42:18Z TRACE async_h1::server] wrote 117 response bytes
[2022-12-20T19:42:18Z TRACE async_h1::server] discarded 0 unread request body bytes
[2022-12-20T19:42:18Z TRACE polling::kqueue] add: kqueue_fd=11, fd=15, ev=Event { key: 1, readable: true, writable: false }
[2022-12-20T19:42:18Z TRACE polling] Poller::notify()
[2022-12-20T19:42:18Z TRACE polling::kqueue] notify: kqueue_fd=11
[2022-12-20T19:42:18Z TRACE async_io::driver] block_on: sleep until notification
[2022-12-20T19:42:18Z TRACE polling::kqueue] new events: kqueue_fd=11, res=1
[2022-12-20T19:42:18Z TRACE async_io::reactor] process_timers: 0 ready wakers
[2022-12-20T19:42:18Z TRACE async_io::reactor] react: 0 ready wakers
[2022-12-20T19:42:18Z TRACE async_io::driver] block_on: waiting on I/O
[2022-12-20T19:42:18Z TRACE async_io::reactor] process_timers: 0 ready wakers
[2022-12-20T19:42:18Z TRACE polling] Poller::wait(_, Some(59.999926166s))
[2022-12-20T19:42:18Z TRACE polling::kqueue] wait: kqueue_fd=11, timeout=Some(59.999926166s)
[2022-12-20T19:42:18Z TRACE polling::kqueue] new events: kqueue_fd=11, res=1
[2022-12-20T19:42:18Z TRACE async_io::reactor] react: 1 ready wakers
[2022-12-20T19:42:18Z TRACE async_io::driver] block_on: stops hogging the reactor
[2022-12-20T19:42:18Z TRACE async_io::driver] main_loop: notified
[2022-12-20T19:42:18Z TRACE polling] Poller::notify()
[2022-12-20T19:42:18Z TRACE async_io::driver] main_loop: waiting on I/O
[2022-12-20T19:42:18Z TRACE polling::kqueue] notify: kqueue_fd=11
[2022-12-20T19:42:18Z TRACE async_io::reactor] process_timers: 0 ready wakers
[2022-12-20T19:42:18Z TRACE polling] Poller::wait(_, Some(59.999855416s))
[2022-12-20T19:42:18Z TRACE polling::kqueue] add: kqueue_fd=11, fd=15, ev=Event { key: 0, readable: false, writable: false }
[2022-12-20T19:42:18Z TRACE polling::kqueue] wait: kqueue_fd=11, timeout=Some(59.999855416s)
[2022-12-20T19:42:18Z TRACE async_io::driver] block_on: sleep until notification
[2022-12-20T19:42:18Z TRACE polling::kqueue] new events: kqueue_fd=11, res=1
[2022-12-20T19:42:18Z ERROR tide::listener::tcp_listener] async-h1 error
[2022-12-20T19:42:18Z TRACE async_io::reactor] process_timers: 0 ready wakers
[2022-12-20T19:42:18Z TRACE async_io::reactor] react: 0 ready wakers
[2022-12-20T19:42:18Z TRACE async_io::driver] main_loop: sleeping for 50 us
[2022-12-20T19:42:18Z TRACE async_io::driver] block_on: waiting on I/O
[2022-12-20T19:42:18Z TRACE async_io::reactor] process_timers: 0 ready wakers
[2022-12-20T19:42:18Z TRACE polling] Poller::wait(_, None)
[2022-12-20T19:42:18Z TRACE polling::kqueue] wait: kqueue_fd=11, timeout=None
[2022-12-20T19:42:18Z TRACE async_io::driver] main_loop: sleeping for 75 us
[2022-12-20T19:42:18Z TRACE async_io::driver] main_loop: sleeping for 100 us
[2022-12-20T19:42:18Z TRACE async_io::driver] main_loop: sleeping for 250 us
[2022-12-20T19:42:18Z TRACE polling::kqueue] new events: kqueue_fd=11, res=1

I use tide for handling incoming POST requests containing json.
The server runs on localhost:9000.
The server is not running on <IP_ADDRESS>:9000.
I don't use nginx.
The POST requests are being made by separate Rust process that uses reqwest to perform the POST requests.


Pass the current filename to F*

Hey Clément,
Do you mind merging this? This is the first time in my life I'm writing elisp so I'm happy to be told if there's a better way of doing this!
Cheers,
Jonathan

Thanks! Looks good.

It would be nice to have a check in fstar-subp-start that the current buffer is indeed attached to a file.  This would give a nicer error message when pressing C-c C-RET in a temporary fstar buffer.

Thanks Clément!


Issue 9

Pull Request Test Coverage Report for Build 83

3 of 3 (100.0%) changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.06%) to 93.333%

Totals

Change from base Build 79:
0.06%

Covered Lines:
82

Relevant Lines:
84

💛  - Coveralls


Use tooltips to show the area name on the homepage

Not sure why we didn't do this originally, but it's much easier than glancing over to the side to the see the name.
https://github.com/acteng/atip/assets/1664407/1f1fcc3e-25f1-443d-a567-2030ddea1229

Async feedback welcome


How to get instagram pictures?

Hi, how can I get regular photos from a user using his name?

Solved via discord.
_- use UsersUsernameInfo request

get the user PK
use feeduserrequest to get photos_


go get as mod failed

<((("> go get github.com/dapr/cli@latest
go get<EMAIL_ADDRESS>updating to
<EMAIL_ADDRESS>requires
<EMAIL_ADDRESS>requires
<EMAIL_ADDRESS>requires
<EMAIL_ADDRESS>requires
<EMAIL_ADDRESS>requires
<EMAIL_ADDRESS>invalid version: git fetch -f origin refs/heads/:refs/heads/ refs/tags/:refs/tags/ in /Users/majik/go/pkg/mod/cache/vcs/1873572271fcf325ad32062ccf6aee165fdb6b2229b714b40050d6bf3d599824: exit status 128:
remote: Repository not found.
fatal: repository 'https://github.com/kubernetes/client/' not found
<((("> go version
go version go1.16.2 darwin/amd64

@yaron2 Can you take a look at this?


Issues with Terminal Shell Integration on Windows with Zsh

Does this issue occur when all extensions are disabled?: Yes/No

VS Code Version:  1.95.2 (user setup)
OS Version:  Windows_NT x64 10.0.22631

I have installed zsh, oh-my-zsh through msys2.
Steps to Reproduce:

I cannot directly use [[ "$TERM_PROGRAM" == "vscode" ]] && . "$(code --locate-shell-integration-path zsh)" in my .zshrc, it returns a Windows-formatted path. This path is not accepted by MSYS2's Unix environment, requiring me to manually locate and modify the path.

After successfully locating the path, the command decorations are misaligned. They may shift positions, sometimes appearing on the line above the command, and then correct themselves after some time.

For the path problem, you probably need to change your .zshrc script to format it correctly. Maybe msys2 has a helper for that like wslpath.
The misalignment issue seems to originate from an upstream component and is not something VSCode can fix by making a change to our code. As such, I will go ahead and close it. Please try to reproduce in Windows Terminal and report to microsoft/terminal with repro steps.
If you cannot reproduce in Windows Terminal, chances are it's fixed in a later version of Windows. You can read more about how we consume conpty here. Thanks for understanding.
/label upstream terminal-conpty windows


build: run async task in concurrent

PR Checklist
Please check to confirm your PR fulfills the following requirements:

[ ] The commit message follows our guidelines: https://github.com/angular/angular-cli/blob/main/CONTRIBUTING.md#-commit-message-guidelines
[ ] Tests for the changes have been added (for bug fixes / features)
[ ] Docs have been added / updated (for bug fixes / features)

PR Type
What kind of change does this PR introduce?

[ ] Bugfix
[ ] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] CI related changes
[ ] Documentation content changes
[ ] Other... Please describe:

What is the current behavior?

Issue Number: https://github.com/angular/angular-cli/pull/27862
What is the new behavior?

Does this PR introduce a breaking change?

[ ] Yes
[ ] No

Other information

The changes were merged into the following branches: main, 18.1.x


Adds aws_region config to client initializer

I have a different global region config than the one I use for the SQS queue.
This change will make the region configurable in the rails initializer:
class Application < Rails::Application
  config.active_elastic_job.aws_region = 'eu-central-1'
end

👍 I am upvoting for this

Closing and reopening to trigger Travis CI build for V3 branch


Add create logic to cluster package

The following PR fills the logic gap missing from the cluster create command in https://github.com/ministryofjustice/cloud-platform-cli/pull/264. The changes in this PR perform the following:

when a user triggers a cluster create subcommand, the cli will first check the options passed.
it will create a cluster object and use the terraform package to apply the directory structure in the infrastructure repository.
print out the cluster details to the caller.

Codecov Report
Base: 35.03% // Head: 35.41% // Increases project coverage by +0.38% :tada:

Coverage data is based on head (34c6c84) compared to base (f995c4d).
Patch coverage: 39.47% of modified lines in pull request are covered.

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #267      +/-   ##
==========================================
+ Coverage   35.03%   35.41%   +0.38%
==========================================
  Files          43       44       +1
  Lines        2218     2445     +227
==========================================
+ Hits          777      866      +89
- Misses       1347     1474     +127
- Partials       94      105      +11

Impacted Files
Coverage Δ

pkg/cluster/create.go
38.96% <38.96%> (ø)

pkg/cluster/pod.go
56.14% <42.85%> (-4.33%)
:arrow_down:

pkg/terraform/terraform.go
82.00% <100.00%> (ø)

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


Internal User - User Access Administrator

Grant another person access to the fossil site system (or revoke access from someone).
The names in the left-most column of this table represent the different levels of access.
Levels of access correspond to: which columns of the data a user can access, whether the access is read-only or read/write, and which actions a user can perform (from the middle column of this table).

Example: Elisabeth and one or two other Heritage Branch staff would be the only User Access Administrators.
Clerks can be used to manage access for clerks and other internal users.


Async Method Return Type

Beginning with C# 8.0, async methods can also return IAsyncEnumerable<T>, so,ething not mentioned in the document.

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

ID: 158425f1-86b1-101a-9172-14c944867784
Version Independent ID: 6386f636-99b3-93c3-ca9e-0134f3e3be10
Content: Methods - C# Guide
Content Source: docs/csharp/methods.md
Product: dotnet-csharp
Technology: csharp-fundamentals
GitHub Login: @BillWagner
Microsoft Alias: wiwagn

Thanks for writing this @tanveerbadar
In addition to IAsyncEnumerable<T>, we should check to make sure ValueTask<T> and the pattern based async returns are mentioned.


Add "multiSelect" field type

I implemented this myself with very minimal effort. Would be great to see this in here by default.
This is my implementation:
formlyConfig.setType({
                name: 'multiSelect',
                extends: 'select',
                template: '<select multiple class="form-control" ng-model="model[options.key]"></select>'
            });

I would gladly turn this into a pull request, but I'm fairly new to Javascript and I'm not sure how I would write tests for this.

Here us a JS Bin with an example:
http://jsbin.com/reheko/edit?html,js,output

Awesome! I'd happily accept a PR for this. I'm not sure how I'd test this one either. But I'll go ahead and accept a PR for this even without tests. (This repo isn't set up with tests yet anyway).


Support formatting using line ranges

Black added support for formatting line-ranges https://github.com/psf/black/pull/4020
Would be nice if this was possible within ruff's formatter. The Black VSCode extension also has support for this now, and allows code to be formatted "on modification" https://github.com/microsoft/vscode-black-formatter/pull/380

Hy @jvacek Good news. This should be supported in the next ruff release https://github.com/astral-sh/ruff/pull/9733


DeployItems keep being reconciled for more than 6 months

/area helm-deployer
/bug bug|
/priority 3
What happened:
In the logging stack for LIVE there's a repeating issue with the reconciliation of all three deploy items of an installation, e.g. https://dashboards-sf-4b9f9729-2334-43cb-aa27-aa72888cf7b2.cls-01.cloud.logs.services.eu10.hana.ondemand.com/app/dashboards#/view/271d3fc0-f86f-11ed-97fa-61b53b28387e?_g=h@6dc552e&_a=h@731558efor
It is for tenant id k5f74a4p in resource cluster t-k5f74a4p/dev-landscaper-685gz, namespace cu-landscaper-resources-cf-us10-staging. The installation is "ingress-gateway-installation". Its three deployItems and the installation are all succeeded in April 2023, but the Helm deployer in the target landscaper keeps reconciling the DeployItems and fails with
{"level":"error","ts":"2023-10-31T13:12:30.659Z","logger":"deployer.helm","msg":"unable to get landscaper context: contexts.landscaper.gardener.cloud \"context\" not found","reconciledResourceKind":"DeployItem","deployItemType":"landscaper.gardener.cloud/helm","reconcileID":"5c3e7fda-0fd7-4163-8814-74c1409b3fe3","reconciledResource":"cu-landscaper-resources-cf-us10-staging/ingress-gateway-installation-istio-base-mtm79","method":"LogErrorAndGetReconcileResult","error":"unable to get landscaper context: contexts.landscaper.gardener.cloud \"context\" not found"}

as the installation refers to a context that has been deleted in the meantime
What you expected to happen:
The Installation / DeployItems should be updated to "failed", so that the HelmDeployer stops reconciling.
How to reproduce it (as minimally and precisely as possible):
Environment:
LIVE

Landscaper version: v0.79.0
Kubernetes version (use kubectl version): v1.25.12

Fixed with PR https://github.com/gardener/landscaper/pull/877


Adds GC column to the env table

Describe your changes and why you are making these changes
This PR adds a GC column to the execution environment table, and modifies existing logic to update this column correctly.
The PR also adds an async GC routine after the user deletes an workflow, as after that there could be exec envs that are no longer used.
Related issue number (if any)
Loom demo (if any)
Checklist before requesting a review

[ ] I have created a descriptive PR title. The PR title should complete the sentence "This PR...".
[ ] I have performed a self-review of my code.
[ ] I have included a small demo of the changes. For the UI, this would be a screenshot or a Loom video.
[ ] If this is a new feature, I have added unit tests and integration tests.
[ ] I have run the integration tests locally and they are passing.
[ ] I have run the linter script locally (See python3 scripts/run_linters.py -h for usage).
[ ] All features on the UI continue to work correctly.
[ ] Added one of the following CI labels:

run_integration_test: Runs integration tests
skip_integration_test: Skips integration tests (Should be used when changes are ONLY documentation/UI)

@likawind Since the column already has a property that defaults the entry to false, I think we are good here. I also verified that new columns are indeed populated with "false".


Remove unwrap in pod sandbox test

What type of PR is this?
/kind cleanup
What this PR does / why we need it:
There is no need to unwrap anywhere, so we can return a result in the test.
Which issue(s) this PR fixes:

None
Special notes for your reviewer:
None
Does this PR introduce a user-facing change?

None

Never used anyhow before but I looked it up. it seems really nice. Question, to me .unwrap() seems safe enough in a test right? other then the fact that using .unwrap() is considered bad is there anything i'm missing why we might now want it here?

No worries, I’m happy to answer all questions. 🙂
My general rule of thumb is to never use unwrap(). The ? operator is even shorter and correctly populates the error stack. Anyhow provides a Context trait (see several uses in the lib), which allows to stack errors with an additional context message. This also works for the Option type.
Sooo, yeah it would be “okay” to unwrap in the tests, but this habit can be omitted since test functions can return a Result in Rust.

/lgtm


Seems to assume test targets are nested under Tests/

I think this layout comes from Xcode, but it is not the default for native Swift packages. My test target is in the folder of the same name under Sources/. See my Package.swift for an example.

It is the de facto standard for native Swift packages. See Swift NIO as an example or even SwiftPM

(Regardless is should probably try and get the test sources from SwiftPM but having it under Tests/ is a sensible default)

Hi,
I'm very sorry for some reasons I've missed this issue.
And you are right it actually assumes the tests to be in the Test/ directory I honestly thought that tests had to go there for the project to build.
If you run
swift test --enable-test-discovery -l
Does it correctly shows your tests?
I will correct this behavior asap

Hello,
I should have resolved this problem with this fix.
Let me know if you are now able to see your tests.
I wasn't able to build your project under linux using swiftpm so I'm not sure if this will solve your problems
Feel free to open a new issue


feat: workspaceVersionsOnly

close #506

maybe bumpWorkspaceVersionsOnly?

maybe bumpWorkspaceVersionsOnly?

maybe bumpWorkspaceVersionsOnly?

That would be better 👍 @mitchellhamilton any naming preferences for this one? I'll leave this open for a few days - if we don't get any further comments on this one I'll be proceeding with bumpWorkspaceVersionsOnly.

maybe bumpWorkspaceVersionsOnly?

That would be better 👍 @mitchellhamilton any naming preferences for this one? I'll leave this open for a few days - if we don't get any further comments on this one I'll be proceeding with bumpWorkspaceVersionsOnly.

@zkochan looks like your issue is pretty close to my one  https://github.com/atlassian/changesets/issues/512
I have a question about how does it work.

Let's say we have a repo with three projects<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>foo has<EMAIL_ADDRESS>in the dependencies. Which is the same as in the monorepo.
bar has an older version of qar in dependencies: 1.0.0.

In your example, does bar has exact match version of qar? if not, how does it understand that it shouldn't bump  qar version in bar?

@zkochan looks like your issue is pretty close to my one  https://github.com/atlassian/changesets/issues/512
I have a question about how does it work.

Let's say we have a repo with three projects<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>foo has<EMAIL_ADDRESS>in the dependencies. Which is the same as in the monorepo.
bar has an older version of qar in dependencies: 1.0.0.

In your example, does bar has exact match version of qar? if not, how does it understand that it shouldn't bump  qar version in bar?

pnpm and Yarn support the workspace: protocol to link packages inside a monorepo:
https://pnpm.js.org/en/workspaces#workspace-protocol-workspace
So with this change, if the dependency has "qar: "workspace:1.0.0" in package.json, changeset will bump the version of qar. But if qar is specified without the workspace protocol: "qar": "1.0.0". In this case, changeset will not bump the version of qar in dependencies.

pnpm and Yarn support the workspace: protocol to link packages inside a monorepo:
https://pnpm.js.org/en/workspaces#workspace-protocol-workspace
So with this change, if the dependency has "qar: "workspace:1.0.0" in package.json, changeset will bump the version of qar. But if qar is specified without the workspace protocol: "qar": "1.0.0". In this case, changeset will not bump the version of qar in dependencies.

@zkochan so as I understood you need to change it manually. For example you have foo and bar and each of them are using qar via workspace protocol  "qar: "workspace:1.0.0" and therefore changesets will bump its version inside foo and bar. Then once you understand that bar package becomes stale and in order to avoid random breaking changes you set the version of qar without workspace and changesets stops incrementing qar version automatically?

@zkochan so as I understood you need to change it manually. For example you have foo and bar and each of them are using qar via workspace protocol  "qar: "workspace:1.0.0" and therefore changesets will bump its version inside foo and bar. Then once you understand that bar package becomes stale and in order to avoid random breaking changes you set the version of qar without workspace and changesets stops incrementing qar version automatically?

Sounds correct. In a huge monorepo used by many teams, this scenario can happen. It did happen at my company, so until this is merged, we are using a fork of this project.

Sounds correct. In a huge monorepo used by many teams, this scenario can happen. It did happen at my company, so until this is merged, we are using a fork of this project.

Got it, thanks

Got it, thanks

Maybe bumpVersionsWithWorkspaceProtocolOnly?

Maybe bumpVersionsWithWorkspaceProtocolOnly?

I have renamed the setting.

I have renamed the setting.

Is there something else that needs to be done?

Is there something else that needs to be done?


raw identifier's prefix not dropped when matching column names

Problem Description
Using a QueryableByName struct with raw identifiers will end up using the r# raw identifier prefix when matching the column name.
What are you trying to accomplish?
I'm trying to populate a struct by using sql_query() on a column which name is a reserved rust keyword. Therefore, a raw identifier is used in the struct: r#type.
What is the expected output?
I'd expect no errors and a successful serialization of the struct. As a workaround, some attribute macro that allows to override the column name would also work. Please note, that the column doesn't appear in table! where an attribute macro for overriding the name would exist.
What is the actual output?

Column r#type was not present in query

Are you seeing any additional errors?
No.
Steps to reproduce
#[test]
fn raw_identifiers() {
    #[derive(Debug, Clone, Copy, PartialEq, Eq, QueryableByName)]
    struct Foo {
        #[sql_type = "Integer"]
        r#type: i32,
    }

    let conn = connection();
    let data = sql_query("SELECT 1 AS type").get_result(&conn);
    assert_eq!(Ok(Foo { r#type: 1 }), data);
}

Checklist

[x] I have already looked over the issue tracker for similar issues.
[x] This issue can be reproduced on Rust's stable channel. (Your issue will be
closed if this is not the case)

So I've rechecked the documentation of QueryableByName here. It states the following:

If the name of a field on your struct is different than the column in your table! declaration, or if you are deriving this trait on a tuple struct, you can annotate the field with #[column_name = "some_column"]. For tuple structs, all fields must have this annotation.

Which means there is a way to specify the name of the column explicitly.
I'm closing this issue now as this is "fixed" in my opinion. Having seperate rules for raw identifiers don't seem like a good idea for me. Using the provided attribute is the much better solution for any non default behavior in my opinion.


For others' reference...

If migrating VERY old code dependent on usbioctl.h, you need to now reference the mentioned usbiodef.h instead. I spent hours trying to figure out why I couldn't get old USB code to work in the newer environment.

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

ID: 8915580d-8e2f-2921-f713-dbb11501401e
Version Independent ID: 272e2379-52cf-efd3-90e4-1eccd1084008
Content: GUID_CLASS_USB_DEVICE - Windows drivers
Content Source: windows-driver-docs-pr/install/guid-class-usb-device.md
Product: windows-hardware
GitHub Login: @tedhudek
Microsoft Alias: tedhudek

Thanks @szalkerous and apologies for the delay.  I've just checked in this fix, and it should appear on the live site within half an hour.


docker pull scratch failed

Description of problem:
I cannot pull scratch docker image (pulling of other images works without problem).

How reproducible:
Fresh installation of docker 1.5.0
Steps to Reproduce:

docker pull scratch with fresh installed docker and no empty images

scratch is a reserved name and not a real image anymore.
When you FROM scratch in a Dockerfile it no longer downloads an actual image layer (since it's just an empty fs anyway).
Is this presenting a particular problem? Why  are you trying to actually pull scratch?

Thanks for explaining. Actually it's not a problem. I like that all my images are tagged and I can see how peoples make their Dockerfiles (best practice learning etc.)
From my perspective => closed.
P.S. If scratch not a real image anymore, that means many official images will have less layers? E.g. debian had 3 layer and will have 2?

Hmm, I suppose they would be, once their are built with a 1.5 docker daemon.

I was using this image for a data-only container. is there a new recommended image now?

@wardi you can try the tianon/true image, which is 125 bytes (https://registry.hub.docker.com/u/tianon/true/)
or, if you're creating a data-container for a specific container (e.g. For your database container); use the same image as the container itself uses, but create it with a different command; using the same image multiple times doesn't cost any disk space.

@thaJeztah I agree with wardi and use the technique http://www.tech-d.net/2014/11/18/data-only-container-madness/ as best practice.

@nerro exactly, I wanted to add a link to that article, but didn't have it at hand. For people not following that best practice (there could be valid reasons), I think the tianon/true comes closest to scratch, alternatively, create one yourself; FROM scratch in a Dockerfile should still work.

Thanks @thaJeztah, this just for the case where someone is using boot2docker and the host volumes are too slow/incompatible. Using the database image sounds fine while I wait a nicer storage solution for docker on windows+mac :-)

I was previously creating data containers this way:
docker create --volume=/data --name data scratch ""

But now this is not working anymore. As suggested in the best practice, I can create from the same image as the application itself, but this application itself is created from java and so on... seems a bit fuzzy to me. Then I can create from tianon/true, but 'scratch' looked more clean when listing containers ...

@EricLanduyt if you need a "scratch" image, you can create it;
FROM scratch
VOLUME /data

docker build -t data ., which produces;
REPOSITORY   TAG     IMAGE ID            CREATED             VIRTUAL SIZE
data         latest  77f133bce7ba        21 seconds ago      0 B

And you don't even need to define the volume;
docker create --name my-data data

@thaJeztah thank you for the trick !

@nerro Consider the counterpoint in one of the comments on the article you linked: http://www.tech-d.net/2014/11/18/data-only-container-madness/#comment-1706806635

Instead of using the same image on the data-only container, I prefer this approach:
http://jdemarks.azurewebsites.net/2015/04/1083/
It's cleaner and when doing backups you don't have to remember there's other files there that you should exclude from backup.

Come to think about it, it seems too dangerous to use data-only volumes. If you need to remove it, the only reference to your data is lost and AFAIK there is no way you can recreate it. If this is not true, please do tell.

Instead of an empty data-only container, just create a volume (docker volume create ...)


Brazilian Portuguese translation

Hello!
I just added a new json file into 'translations' folder. If any change is needed, please, tell me.

Thank you for your contribution!


classic and image drivers fail to build - Ubuntu 22.04

Bug Report

Version of VIC that you are using (e.g. VIC.5.0.0)

Tried all 5x versions and the master branch, no issue with VIC 4.2.d

Name and version of the C compiler you are using

gcc 11.2
mpicc 11.2

Operating system

Ubuntu 22.04

A description of relevant model settings

N/A

A summary of the bug or error message you are getting

running make fails with "make[1]: *** [Makefile:126: model] Error 1" for the image driver Makefile that corresponds to this line "$(MPICC) -o ${COMPEXE}${EXT} $(OBJS) $(CFLAGS) $(LIBRARY)"

I am not a Linux or C code or Makefile expert, so don't really know how to debug the cause of the issue. I did also try using CentOS 7, and after figuring out how to get compilers installed and configured had no issues building the classic and image drivers. So, I'm assuming there is some issue related to the newer gcc version in Ubuntu 22.04.

Having the same issue with this line in Makefile. Any solutions?

@blounsbury-usbr  were you able to solve it?  I am having the same issue.

@ShihengDuan @bijoychandraAU Yikes, my brain is super fuzzy on this. Attached is the Makefile I used. It looks like I switched compilers from MPICC to GCC. However I just ran make, there were no errors (a bunch of warnings), but it did not produce vicNL.exe. So, unfortunately, I'm not sure how I got it to work, as a vicNL.exe exists in the directory. I can try to look around a bit more to see what I can find.
Makefile.txt

@blounsbury-usbr  thank you for your reply. Still, I getting the error with "make: *** No rule to make target 'CalcAerodynamic.c', needed by '.depend'.  Stop."

@bijoychandraAU, @ShihengDuan, @blounsbury-usbr I believe I ran into this same issue. I was able to compile the image driver by pointing directly to the mpicc location on line 44 of the makefile. You may need to change the path below to wherever mpicc is installed (you should be able to find it by running in your terminal: locate -br "^mpicc$")
Change MPICC = mpicc to MPICC = /usr/lib64/openmpi/bin/mpicc


V 1.6.0

Add Reddit Card
Add Uninstall URL
Add UTM to outbound links

Deployed, waiting Chome & Firefox to release it


error parsing redis metadata: no address given or host given

Keda is not  able to read Redis metadata ( address OR host+port) even  though they are defined clearly in the scaled object.
Expected Behavior
Keda is able to scale in/out the deployment based on Redis list size..
And keda-operator deployment logs are
"error":"error getting scaler for trigger #0: error parsing redis metadata: no address given or host given. Address should be in the format of host:port or you should provide both host and port",

Actual Behavior
Keda is not  able at all to read Redis from trigger's metadata
Steps to Reproduce the Problem

Run Keda operator  from image docker.io/kedacore/keda:1.4.1
Deploy the ScaledObject :

apiVersion: keda.k8s.io/v1alpha1
kind: ScaledObject
# ....
spec:
 cooldownPeriod: 30
 maxReplicaCount: 10
 minReplicaCount: 1
 pollingInterval: 15
 scaleTargetRef:
   deploymentName: queue-worker-academy-laravel
 scaleType: deployment
 triggers:
 - metadata:
     databaseIndex: "0"
     enableTLS: "false"
     address: redis-master.apps-system:6379
     listLength: "3"
     listName: queues:default
   type: redis

Specifications

**KEDA Version:image: docker.io/kedacore/keda:1.4.1  Keda is installed from the Helm repository

# helm -n kube-system list
NAME   	NAMESPACE  	REVISION	UPDATED                             	STATUS  	CHART               	APP VERSION
keda   	kube-system	1       	2020-07-01 00:00:48.04236 +0300 +03 	deployed	keda-1.4.2          	1.4.1

Platform & Version: kubernetes 1.16
Kubernetes Version: kubernetes 1.16
Scaler(s): keda.k8s.io/v1alpha1

More
Similar to #560   .. but it is still persistent

Hi @abdennour, I found it very confusing, but address should actually reference the env var that contains the address in the target container... It should not be an address. Can you try that?

Ah! really ?
so if we will haveaddress: REDIS_ADDRESS..
This means REDIS_ADDRESS is an environment variable assigned to pods of the reference deployment .
In this case, REDIS_ADDRESS must be defined in queue-worker-academy-laravel.
Please correct me if i am mistaken

@abdennour yeah that's correct, address: REDIS_ADDRESS should get it done

thank you @eexwhyzee . I will give it a trial

Did it fix your issue?

We will test it !


Use ome.python3_virtualenv role

Uses https://github.com/manics/ansible-role-python3-virtualenv to avoid installing python3 in multiple roles. Also takes care of some Ansible weirdness with virtualenv

Re: other repo -- seems straight-forward enough though I'm surprised that no one has come up with a solution for this yet.

Merging. Leaving release to you. (Note: galaxy.ansible.com has been misbehaving recently)


[RFC] BREAKING: Remove SupabaseAuthRequiredState as well as overriding methods in SupabaseAuthState

Comments are welcome!
This is just a proposal in an attempt to improve developer experience of this library.
Current behavior
Currently, there are SupabaseAuthState and SupabaseAuthRequiredState. A lot of their functionalities overlap, and having two different classes might be confusing.
Also, SupabaseAuthState have the following methods, but users don't necessary need all of them if they are using SupabaseAuthState just for auth state persistance.
  /// Callback when deeplink received and is processing. Optional
  void onReceivedAuthDeeplink(Uri uri) {
    Supabase.instance.log('onReceivedAuthDeeplink uri: $uri');
  }

  /// Callback when user is unauthenticated
  void onUnauthenticated();

  /// Callback when user is authenticated
  void onAuthenticated(Session session);

  /// Callback when authentication deeplink is recovery password type
  void onPasswordRecovery(Session session);

  /// Callback when recovering session from authentication deeplink throws error
  void onErrorAuthenticating(String message);

New behavior
All of the classes that were inheriting State has been removed, and deeplinking and auth state persistence logic has been consolidated into SupabaseAuth class.
Instead of relying on onAuthenticated() and onUnauthenticated(), users can utilize Supabase.instance.client.auth.onAuthStateChange() to navigate users to different routes depending on Auth state.

Also thinking that we could handle startAuthObserver() in a smarter way as well.

tests are failing

@bdlukaa I haven't changed the tests yet, but I wanted to see what you and other people think about the general direction of this PR.

@DanMossa @Vinzent03
It would be great if I could get some feedbacks on the general direction of this PR. Would you agree that this is a good change?

I'm currently not using this library in my Flutter app. Instead I'm using supabase-dart. I don't know exactly why I didn't choose the flutter version, but I think the weird state classes were one reason. Using the listener directly is a good idea. To understand the new class a bit more:
Should I place the class multiple times in my widget tree or just one time at the top?

Imo we should get rid of all these classes and let the dev do it

I think helper classes like this are only useful if they're basically required to be used.
Like, if 99% of people are going to use onUnauthenticated then that's awesome, but if there's other alternatives then I think it gets confusing.
My personal opinion is there should be 1 good way of doing something or else there's too much concern on which way the user should be doing it.

@Vinzent03 That is funny, because I do the same thing lol I use only supabase-dart in my app.

Should I place the class multiple times in my widget tree or just one time at the top?

Yeah, the currently the idea is to have only one of them alive in a widget tree at once.
@bdlukaa

Imo we should get rid of all these classes and let the dev do it

I agree. Having these classes are counter intuitive for Flutter devs and causes confusion. One thing that I would want is automatic token refreshing though. It would be nice to provide a way where developers don't have to think about refreshing tokens themselves, and in order to do that, we need to listen to app's lifecycle. The way we do it currently is not the most elegant way of doing it, but do you think the developer should manage token refreshing by themselves too? Or should we explore better way of automatically handling token refresh without creating an extended class from State?
@DanMossa
100% agree with what you are saying here. To me, this class that we provide is only good for automatically refreshing the auth token as well as handling deep links, but as I wrote earlier, I think we might be able to come up with a better way of handling automating token refresh without creating a class that extends State.
@Vinzent03 @bdlukaa @DanMossa
I think these are the questions that we want to ask ourselves.

Should we provide a way to handle deeplinks and automatic token refresh, or should each developers take care of them on their own?

-> In my opinion, not having to think about token refresh is a nice developer experience, and quite frankly something that developers expect especially if they come from Firebase world, but open to suggestions.

If we are going to provide a way to automatically refresh token and handle deeplinks, how should we do it?

-> I think with this PR, all developers have to do is to have single SupabaseAuthState alive somewhere within their widget tree, and that is all they need to do, so it is considerably simpler than the current implementation, but ideal world would be if the user installs supabase-flutter package and the auth state is persisted with no additional configuration. I will do some research on how we could possibly do this, but would any of you have any suggestions on how that could be achieved? I think as long as there is a way of listening to app's lifecycle changes, we can automatically perform all the token refresh and stuff.

@dshukertjr I think automatic token refreshing is really important. Callbacks for onAuthenticated or onErrorAuthenticating should be removed and not handled in the widget tree.
Listening to WidgetsBindingObserver does not directly need context or a widget, so it could be integrated in the flutter client without an extra widget. Disposing and initializing must be handled manually then.

@Vinzent03 I did not know that WidgetsBindingObserver can be used without it being in the widget tree! That's great!
Rewriting the PR as soon as I get back in front of a keyboard!

@dshukertjr I haven't tested it, but following this Stack Overflow answer it should work.

@dshukertjr Looks great, but there is still SupabaseAuthState for deep linking, right? What about moving this out of the widget tree too?

@Vinzent03 Thanks for the quick checkup! Yup, will move the deep link stuff out of the widget tree too!

Actually testing out deeplink on Android and ios now...

I think most of the rework is done.
One thing that I would want to add is a way to know when the initial authentication check is complete.
In an app, it is pretty common to show different things to the users depending on whether the user is logged in or not. Currently with this rework, there is no way of knowing when the initial auth check has been complete. If the user is logged in, onAuthStateChange will run when the token refresh is complete, but if the user is not logged in, nothing will happen. There is no way to tell if the user is not signed in, or is just waiting on token refresh.
What would be the best way to give developers a way to know when the initial  auth state? One idea that came to my mind was to have a completer name something like hasReceivedInitialAuthState or something, and users can await for the future of the completer, but I'm sure all of you have better ideas, so would love to hear them!

I think this PR is pretty much complete on my end. Idealy, we will merge https://github.com/supabase-community/gotrue-dart/pull/74 and https://github.com/supabase-community/postgrest-dart/pull/69 and bump the major version of this package to release all of these breaking changes!

@dshukertjr how would this work with say flutter riverpods? I was using firebase before and had a Stream but I see this uses GotrueSubscription.

@rlee1990
You should be able to use it very similar to how you are currently using Firebase!
By using auth.onAuthStateChange(), you can listen to auth state changes just like listening to auth state change in Firebase. There is two values that you can listen to, the event and state, so there it is not using Stream, but the basic functionality is the same! Do you have any specific concerns?

@dshukertjr Thanks for the quick reply. I currently use river pods flutter with a streamProvider. I will just need to see how I am going to use this in a different way with autoRouter and riverPods. Also was the deep link parts removed?

@rlee1990
If you are using StreamProvider, you could probably yield a new stream every time the auth state changes on auth.onAuthStateChange() listener!
Deep link related logic are not removed, but have been moved inside supabase_auth.dart file!


Filter deleted env to show only active environments on the web

What this PR does / why we need it:
Which issue(s) this PR fixes:
Fixes #
Does this PR introduce a user-facing change?:

Fix the problem of the environment being displayed even after deleting it

/lgtm

Thanks 🚀
/approve


Use with TS and without a build-step (ES modules syntax)

For various reasons I'm using Vue, with typescript, but without a build-step. I'm using ES modules syntax. I'd prefer to use a class for Vue 3 and was hoping vue-facing-decorator could help me out. It doesn't seem that ES module syntax is supported, correct?
The kind of code I'm writing with Vue 3:

{{ message }}

So, does vue-facing-decorator support ESM style coding?

v-f-d is a decorator library. It doesn't matter if you use es modules syntax or not. Does your build tool(webpack or vite) support load esm through url?

https://github.com/facing-dev/vue-facing-decorator/discussions/40


bug: shareable configs don't work with eslint's new "flat" config

I searched through the issues for something similar, and didn't find anything related to supporting the new Flat Config.  So I thought it would make sense to create this for tracking.
I'm currently building out a config using eslint.config.js and the new flat config structure.  When using this plugin's shareable config
import vitest from 'eslint-plugin-vitest';

export default [
  vitest.configs.recommended,
];

I receive the following error:
TypeError: Key "plugins": Key "0": Expected an object.
    at Object.validate (D:\src\ux\.yarn\cache\eslint-npm-8.45.0-bb6c5f1226-3e6dcce5cc.zip\node_modules\eslint\lib\config\flat-config-schema.js:315:23)
    at ObjectSchema.validate (D:\src\ux\.yarn\cache\@humanwhocodes-object-schema-npm-1.2.1-43b3ca2646-a824a1ec31.zip\node_modules\@humanwhocodes\object-schema\src\object-schema.js:218:35)
    at D:\src\ux\.yarn\cache\@humanwhocodes-object-schema-npm-1.2.1-43b3ca2646-a824a1ec31.zip\node_modules\@humanwhocodes\object-schema\src\object-schema.js:171:18
    at Array.reduce (<anonymous>)
    at ObjectSchema.merge (D:\src\ux\.yarn\cache\@humanwhocodes-object-schema-npm-1.2.1-43b3ca2646-a824a1ec31.zip\node_modules\@humanwhocodes\object-schema\src\object-schema.js:169:24)
    at D:\src\ux\.yarn\cache\@humanwhocodes-config-array-npm-0.11.10-33012f902e-1b1302e240.zip\node_modules\@humanwhocodes\config-array\api.js:916:42
    at Array.reduce (<anonymous>)
    at FlatConfigArray.getConfig (D:\src\ux\.yarn\cache\@humanwhocodes-config-array-npm-0.11.10-33012f902e-1b1302e240.zip\node_modules\@humanwhocodes\config-array\api.js:915:39)
    at FlatConfigArray.isFileIgnored (D:\src\ux\.yarn\cache\@humanwhocodes-config-array-npm-0.11.10-33012f902e-1b1302e240.zip\node_modules\@humanwhocodes\config-array\api.js:943:15)
    at D:\src\ux\.yarn\cache\eslint-npm-8.45.0-bb6c5f1226-3e6dcce5cc.zip\node_modules\eslint\lib\eslint\eslint-helpers.js:312:49

This is due to the fact that the shareable config defines plugins as a string array, rather than object:
https://github.com/veritem/eslint-plugin-vitest/blob/d55e5b0bdb1ceb45c8ed282fb3b0250c8f93e05a/src/index.ts#L51-L59
I'm able to work around it by constructing the config manually using the recommended rules and globals:
import vitest from 'eslint-plugin-vitest';

export default [
  {
    plugins: { vitest },
    rules: vitest.configs.recommended.rules,
    languageOptions: {
      globals: vitest.environments.env.globals,
    }
  },
];

But ideally this would be built-in to the shareable configs.
The eslint-plugin-react and eslint-plugin-jsdoc projects have updated to support this new config approach, if that helps with providing inspiration / examples.
Repro: https://github.com/michaelfaith/eslint-plugin-vitest-flat-config-bug

@michaelfaith do you have an example repo or a codesand box where i can play with your example? I would like to add support for this but also not break anything.

@veritem I don't at the moment, but I can create one.  If you already have a test repo, it would just be a matter of changing the config file name from .eslintrc to eslint.config.js and using something like this:
import vitest from 'eslint-plugin-vitest';

export default [
  vitest.configs.recommended,
];

Eslint is looking for the file name eslint.config.js to trigger handling the new config format.

@veritem I went ahead and created a repro based on the fixtures project in your repo:  https://github.com/michaelfaith/eslint-plugin-vitest-flat-config-bug
Appreciate the attention on this.  Let me know if you need any additional details from me.

Seems like my work around didn't fix your issue. I'll look more into it later.

check readme for an example config

check readme for an example config

Hey, maybe I'm missing something, but I don't see any mention of the flat config set up.  The closest I see is this, which looks like it may be what you mean, but the flat config doesn't use eslintrc files.  The file name has to be eslint.config.js.  So, may need a minor tweak to that, if that was the intent?

If you're using .eslintrc.js
import vitest from "eslint-plugin-vitest";

export default [
  {
    files: ["tests/**"], // or any other pattern
    plugins: {
      vitest,
    },
    rules: {
      ...vitest.configs.recommended.rules,
    },
    languageOptions: {
      globals: {
        ...vitest.environments.env.globals,
      },
    },
  },
];

And, while that's a good work around for the current set up, do you anticipate that you'll fully embrace the flat config structure at some point?

a pr is welcome


Keep some property with raw data

Hi，I have got a data convert problem.The following is my model data structure.
@interface SystemNotificationModel : BaseModel
@property (nonatomic, strong) NSDictionary* message;
@property (nonatomic, strong) NSString *created_at;
@property (nonatomic, strong) NSString *message_id;
@property (nonatomic, strong) NSString* msg_type;
@property (nonatomic, strong) NSString* content;

(NSString*)getCreateTime;
@end

The property message is a NSDictionary Class.I have read your instruction. If I use collection properties like NSArray, NSDictionary, the property should conform some protocol whose name is the same with the real Class name. But I just want to keep the raw data，I means do not conform any protocols, just keep the property "message" with original data, do not transfer it to any models. I do not think it is going work, then crash.Could Anybody can help me with this problem?Many thanks.

Will you please show us the original string data coming from server?

@sauvikatinnofied ,thanks for your reply, data coming from server is in varied forms, so I just want to keep it a dictionary.For example, message = {"avatar":http://123456, "nickname":"the walking dead"}, or message could be {"identifier":5211314, "sex":"male", "salary":"19k"}, and so on. I do not know If you understand what I said.My English is not good. Thank you again.

If you are getting JSON string for message in that following way
    "message": {
        "avatar": "http://123456",
        "nickname": "the walking dead"
    }

, then you have done modelling correctly. Will you please confirm the line of code
@interface SystemNotificationModel : BaseModel

is actually
@interface SystemNotificationModel : JSONModel

?

Thanks for your reply.I confirm is actually @interface SystemNotificationModel : JSONModel. Base Model Inherit from JsonModel. Thanks again.

You are most welcome. Please let me know whether your model class is working fine or not.

Thank you. My model class is not working fine. I change message property from  nsdictionary to nsstring.I transfer dictionary to string to store value, or it will crash. I thought the crash reason is that my model class "message" property did not confirm any protocol, so JSONModel can not find any Model to transfer.

@sauvikatinnofied ,hi, are you there?Could you help me with my problems above-mentioned.Many thanks.

@sauvikatinnofied ,I am so sorry. My friend who use the version 0.13.0 said that JSONModel support for keeping dictionary property with raw data already.It is my fault.So stupid.(^o^)/~.Thank you for your time.