Storage refactor API and docstring tweaks

What this PR does / why we need it:
Addressing most of @ches's comments here: https://github.com/gojek/feast/pull/529
since that PR has already been merged.
The elephant in the room is unfortunately storage-api modules having Beam dependencies, which serving should not have. The two options currently on the table are:

Distill the modules further into separate write and read submodules
Move ingestion job initialization to Serving

Does this PR introduce a user-facing change?:

NONE

The metrics namespacing commit got brought into this PR now, not sure that was intended?

Crap. Forgot i rebased before :( Let me remove it

/retest

/lgtm


Effectiveness of Bot

Would you happen to have a demonstration video? I've been tinkering with this for the past hour or so and it seems painfully ineffective. I'm in the range with bots and the aimbot seems extremely slow and inaccurate. I've edited per your instructions, but i'm not sure if i've done something wrong. Have you tested this with live people? As with just the bots moving it seems impossible to hit.
If you do not have a video, i'd be happy to upload what it looks like for me.
Thanks!

Since this is meant to be educational, I have modified line(s) of code to purposeful slow down the program to reduce abuse.


Huge client memory leak in latest green and dev builds

I think you have a client side memory leak.  I recently updated to the latest recommended UE mod builds.  I started seeing garbage collection pauses within 30 minutes of playing.  I used VisualVM to profile minecraft and found the following:
With Mekanism installed, instances of various classes, but primarily 'net.minecraft.client.model.PositionTextureVertex' rapidly increase over time.
WITHOUT Mekanism installed, instances of that class start and stayed around 308,000 over the course of around 10 minutes play time.
WITH Mekanism installed, instances started at around 308,000, then within 5 minutes ballooned to over 2 million, and just kept climbing, using more and more ram until Minecraft ground to a halt after about 45 minutes because it was doing GC so often.
I've tested this on two pc's and seen the same behavior.
Tested on Mekanism 121, and 123.

This is still happening


aws_perimeter.control.s3_bucket_policy_prohibit_public_access check reports OK for buckets it can't process

Running the AWS perimeter mod control aws_perimeter.control.s3_bucket_policy_prohibit_public_access fails with the error
Error: operation error S3: GetBucketLocation, https response error StatusCode: 403, RequestID: <REDACTED>, HostID: <REDACTED>, api error AccessDenied: Access Denied (SQLSTATE HV000)
This looks to be down to several buckets with messed up permission policies.
So I modified the steampipe configuration to include
ignore_error_codes = ["AccessDenied", "AccessDeniedException", "NotAuthorized", "UnauthorizedOperation", "UnrecognizedClientException", "AuthorizationError"]
This at least allows the control to run to a conclusion however, the buckets that previously caused the control to fail now report OK
OK   : <BUCKET NAME REDACTED> policy does not allow public access. .......................................................... <nil> <ACCOUNT NAME REDACTED>
Steampipe version (steampipe -v)
v0.17.4
Plugin version (steampipe plugin list)
+--------------------------------------------------+---------+-------------+
| Installed Plugin                                 | Version | Connections |
+--------------------------------------------------+---------+-------------+
| hub.steampipe.io/plugins/turbot/aws@latest       | 0.91.0  | aws         |
| hub.steampipe.io/plugins/turbot/steampipe@latest | 0.6.0   | steampipe   |
+--------------------------------------------------+---------+-------------+

To reproduce
Create a bucket policy which only allows access to a specific role.
Expected behavior
Should these particular resources be flagged as ERROR, as the credentials being used are insufficient for these buckets to be evaluated even though certain error codes are being ignored?

@rbracewell Appreciate trying out Steampipe!
Sad to see it's not yielding the expected result for you. Nicely detailed information to replicate the issue at our end; we will look into it and revert.

Hi @rbracewell  thanks for sharing your observation. Appreciate it!
We did reproduce the issue in line with your error as one of the example cases, i.e. restricting the getLocation call by specifying the bucket resource policy. The current plugin design is handling this issue in the way mentioned here. Hence, when we ignore the AccessDenied  in aws.spc > ignore_error_codes,  it, sets the bucket location as nil  and this results in making the affected bucket policy as, nil.  This is not getting you the expected result; for now, pls refer to the below attached query, where we are moving the validation to Info , the reason being we may have cases where there may not be any policy set in the bucket and that returns nil. Let us know if this fits your current need. Pls keep us informed of any other edge cases, you are coming across. Meanwhile, we are discussing further how we can handle it better way. We will keep this thread posted.
with wildcard_action_policies as (
  select
    arn,
    count(*) as statements_num
  from
    aws_s3_bucket,
    jsonb_array_elements(policy_std -> 'Statement') as s
  where
    s ->> 'Effect' = 'Allow'
    -- aws:SourceOwner
    and s -> 'Condition' -> 'StringEquals' -> 'aws:sourceowner' is null
    and s -> 'Condition' -> 'StringEqualsIgnoreCase' -> 'aws:sourceowner' is null
    and (
      s -> 'Condition' -> 'StringLike' -> 'aws:sourceowner' is null
      or s -> 'Condition' -> 'StringLike' -> 'aws:sourceowner' ? '*'
    )
    -- aws:SourceAccount
    and s -> 'Condition' -> 'StringEquals' -> 'aws:sourceaccount' is null
    and s -> 'Condition' -> 'StringEqualsIgnoreCase' -> 'aws:sourceaccount' is null
    and (
      s -> 'Condition' -> 'StringLike' -> 'aws:sourceaccount' is null
      or s -> 'Condition' -> 'StringLike' -> 'aws:sourceaccount' ? '*'
    )
    -- aws:PrincipalOrgID
    and s -> 'Condition' -> 'StringEquals' -> 'aws:principalorgid' is null
    and s -> 'Condition' -> 'StringEqualsIgnoreCase' -> 'aws:principalorgid' is null
    and (
      s -> 'Condition' -> 'StringLike' -> 'aws:principalorgid' is null
      or s -> 'Condition' -> 'StringLike' -> 'aws:principalorgid' ? '*'
    )
    -- aws:PrincipalAccount
    and s -> 'Condition' -> 'StringEquals' -> 'aws:principalaccount' is null
    and s -> 'Condition' -> 'StringEqualsIgnoreCase' -> 'aws:principalaccount' is null
    and (
      s -> 'Condition' -> 'StringLike' -> 'aws:principalaccount' is null
      or s -> 'Condition' -> 'StringLike' -> 'aws:principalaccount' ? '*'
    )
    -- aws:PrincipalArn
    and s -> 'Condition' -> 'StringEquals' -> 'aws:principalarn' is null
    and s -> 'Condition' -> 'StringEqualsIgnoreCase' -> 'aws:principalarn' is null
    and (
      s -> 'Condition' -> 'StringLike' -> 'aws:principalarn' is null
      or s -> 'Condition' -> 'StringLike' -> 'aws:principalarn' ? '*'
    )
    and (
      s -> 'Condition' -> 'ArnEquals' -> 'aws:principalarn' is null
      or s -> 'Condition' -> 'ArnEquals' -> 'aws:principalarn' ? '*'
    )
    and (
      s -> 'Condition' -> 'ArnLike' -> 'aws:principalarn' is null
      or s -> 'Condition' -> 'ArnLike' -> 'aws:principalarn' ? '*'
    )
    -- aws:SourceArn
    and s -> 'Condition' -> 'StringEquals' -> 'aws:sourcearn' is null
    and s -> 'Condition' -> 'StringEqualsIgnoreCase' -> 'aws:sourcearn' is null
    and (
      s -> 'Condition' -> 'StringLike' -> 'aws:sourcearn' is null
      or s -> 'Condition' -> 'StringLike' -> 'aws:sourcearn' ? '*'
    )
    and (
      s -> 'Condition' -> 'ArnEquals' -> 'aws:sourcearn' is null
      or s -> 'Condition' -> 'ArnEquals' -> 'aws:sourcearn' ? '*'
    )
    and (
      s -> 'Condition' -> 'ArnLike' -> 'aws:sourcearn' is null
      or s -> 'Condition' -> 'ArnLike' -> 'aws:sourcearn' ? '*'
    )
    and (
      s -> 'Principal' -> 'AWS' = '["*"]'
      or s ->> 'Principal' = '*'
    )
  group by
    arn
)
select
  r.arn as resource,
  case
    when r.policy is null then 'info'
    when p.arn is null then 'ok'
    else 'alarm'
  end as status,
  case
    when r.policy is null then title || ' does not have defined policy or insufficient access to the policy.'
    when p.arn is null then title || ' policy does not allow public access.'
    else title || ' policy contains ' || coalesce(p.statements_num, 0) ||
    ' statement(s) that allow public access.'
  end as reason,
  r.region,
  r.account_id
from
  aws_s3_bucket as r
  left join wildcard_action_policies as p on p.arn = r.arn

Agreed Info would be better than Error given your description.

Thanks for the response, @rbracewell , we will adjust the query to info for such edge cases for the time being.


ImportError: 'onedrivesdk' has been deprecated.

so basically this repository should be achieved?

I don't get that error. Make sure you installed this library, not the deprecated version. You may be able to upgrade by running
sudo pip3 install git+https://github.com/OneDrive/onedrive-sdk-python.git
sudo pip3 install --upgrade git+https://github.com/OneDrive/onedrive-sdk-python.git

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


Default handler for unhandledMessage event

Currently no event-handlers are registered by default. The unhandledMessage event is somewhat important, especially now that error-handling is done through messages which are optional to handle.
Add a default unhandledMessage "handler" which will trigger if no event-handler has been provided for unhandledMessage.

Duplicate of #11


@material-ui/core 4.9.11 cannot be compiled by shadow-cljs.

@material-ui/core 4.9.11 cannot be compiled by shadow-cljs since it has multiple versions of dom-types.
$ npm list | grep dom-helpers
| | +--<EMAIL_ADDRESS>|   +--<EMAIL_ADDRESS>
Current Behavior 😯
$ npx shadow-cljs compile webapp
shadow-cljs - config: /work/shadow-cljs.edn
NPM dependency "react" has installed version "^16.12.0"
"16.8.6" was required by jar:file:/home/node/.m2/repository/re-frame/re-frame/0.10.9/re-frame-0.10.9.jar!/deps.cljs
NPM dependency "react-dom" has installed version "^16.12.0"
"16.8.6" was required by jar:file:/home/node/.m2/repository/re-frame/re-frame/0.10.9/re-frame-0.10.9.jar!/deps.cljs
[:webapp] Compiling ...
The required JS dependency "dom-helpers/addClass" is not available, it was required by "node_modules/react-transition-group/cjs/CSSTransition.js".

Search in:
	/work/node_modules
You probably need to run:
  npm install dom-helpers/addClass

See: https://shadow-cljs.github.io/docs/UsersGuide.html#npm-install

Expected Behavior 🤔
$ npx shadow-cljs compile webapp
shadow-cljs - config: /work/shadow-cljs.edn
NPM dependency "react" has installed version "^16.12.0"
"16.8.6" was required by jar:file:/home/node/.m2/repository/re-frame/re-frame/0.10.9/re-frame-0.10.9.jar!/deps.cljs
NPM dependency "react-dom" has installed version "^16.12.0"
"16.8.6" was required by jar:file:/home/node/.m2/repository/re-frame/re-frame/0.10.9/re-frame-0.10.9.jar!/deps.cljs
[:webapp] Compiling ...
npm package "@material-ui/react-transition-group" expected version<EMAIL_ADDRESS>but "5.1.4" is installed.
[:webapp] Build completed. (567 files, 1 compiled, 0 warnings, 6.93s)

Steps to Reproduce 🕹

Steps:

git clone -b issue1 https://github.com/veer66/shadow1.git shadow1-issue1
cd shadow1-issue1
sudo docker run -it --rm -u $(ls -n README.md | awk '{ print $3 }') -v $(pwd):/work -e HOME=/work -w /work veer66/node-jdk bash
npm install
npx shadow-cljs compile webapp

Context 🔦
I want to use the latest version of Material-UI with ClojureScript.
Your Environment 🌎

Tech
Version

Material-UI
v4.9.11

React
v16.12.0

shadow-cljs
v2.8.98

I believe the problem has to do with @material-ui/react-transition-group, which is using version 3.4.0 of dom-helpers. I looked and it seems that repo is about 50 commits behind upstream react-transition-group.
I'd be happy to open a PR against @material-ui/react-transition-group if anyone would be willing to provide some guidance as to what needs to be done.

I'd be happy to open a PR against @material-ui/react-transition-group if anyone would be willing to provide some guidance as to what needs to be done.

You'd need sync it with the latest relase of react-transition-group.


Darker style focus/hover on active buttons

Currently, hovering with mouse or setting focus on a button which is
active has same styling as on a non-active button. This results in
problems for keyboard users, who set focus on a toggle and activate it,
but cannot visually see that their action had any effect. Ditto for
mouse users hovering over a toggle and clicking it. This adds an
explicit additional style for focus/hover on active buttons.
Note that this does not address issues of browser focus remaining on a
button after a mouse click (e.g. #13971), as this will likely require
extra JavaScript to fix.

Here's a quick before/after for http://getbootstrap.com/javascript/#buttons-single-toggle using keyboard navigation.

/cc @cvrebert @mdo for comment

/cc @mdo

Btw not really a LESS expert, so my clumsy hacking away can probably be achieved in a far more elegant manner...

I agree that the problem this addresses is worth trying to fix. If nothing else, it makes some things easier to debug.

The more fundamental problem of :focus and .active being the same (barring the focus outline) remains, as does the "after clicking with a mouse, browsers also set :focus which makes the button look active until I click somewhere else" issue, but that will definitely require some JS as there's no clean way in pure CSS to address it. It could be mitigated by making :focus and .active slightly different though...

Not so sure I like the aesthetics, but I think I understand the desired behavior here. What browser is that with that particular outline there?

Not so sure I like the aesthetics

The only change here is that toggled AND focused/hovered is a shade darker, and that the border for :focus and .focus gets a tiny bit darker too...not a dramatic new aesthetic, in my opinion?
I didn't touch any of the outline stuff, and that's what BS looks like by default in Chrome/Win.

Ah, yeah, sorry, was overthinking this. I'm fine with shipping this. It complicates buttons even more than before, but I suppose that's to be expected when accounting for this kind of stuff.


Update processor_alpaca.py

Error delta not found
Changed line 57
from:
if pd.Timedelta(time_interval).delta < day_delta:
to:
if pd.Timedelta(time_interval).total_seconds() < day_delta:

thanks for your codes
have you tested it?

thanks for your codes have you tested it?

Apologies for not responding sooner, I have only tested on my system with no integration/unit/e2e tests


Support for wdio7

Environment (please complete the following information):

Node.js version: [14.15.4]
NPM version: [6.14.10]
webdriver.io version: [7.0.1]
@wdio/cucumber-framework version: [7.0.1]
wdio-cucumberjs-json-reporter version: [2.0.2]

Describe the bug
I migrated from wdio6 to wdio7 and I got the following:
[0-18] 2021-02-10T17:37:00.773Z ERROR @wdio/runner: TypeError: Cannot read property 'split' of undefined at CucumberJsJsonReporter.getStepDataObject (/project/node_modules/wdio-cucumberjs-json-reporter/build/reporter.js:314:35) at CucumberJsJsonReporter.addStepData (/project/node_modules/wdio-cucumberjs-json-reporter/build/reporter.js:361:54) at CucumberJsJsonReporter.onHookStart (/project/node_modules/wdio-cucumberjs-json-reporter/build/reporter.js:124:17) at CucumberJsJsonReporter. (/project/node_modules/@wdio/reporter/build/index.js:71:18) at CucumberJsJsonReporter.emit (events.js:315:20) at CucumberJsJsonReporter.EventEmitter.emit (domain.js:467:12) at /project/node_modules/@wdio/runner/build/reporter.js:36:56 at Array.forEach () at BaseReporter.emit (/project/node_modules/@wdio/runner/build/reporter.js:36:25) at CucumberReporter.emit (/project/node_modules/@wdio/cucumber-framework/build/reporter.js:194:24) at CucumberReporter.handleBeforeStep (/project/node_modules/@wdio/cucumber-framework/build/reporter.js:57:14) at CucumberEventListener.emit (events.js:315:20) at CucumberEventListener.EventEmitter.emit (domain.js:467:12) at CucumberEventListener.onTestStepStarted (/project/node_modules/@wdio/cucumber-framework/build/cucumberEventListener.js:280:14) at EventEmitter. (/project/node_modules/@wdio/cucumber-framework/build/cucumberEventListener.js:40:22) at EventEmitter.emit (events.js:327:22) [0-18] Error: Cannot read property 'split' of undefined

Thanks for filing a bug, I will take a look at it this weekend hope hope to fix it asap, unless you have some time for a PR 😜

Hi @fogrizovic
I found the bug and fixed it, I only need to get in contact with the WDIO team because more seems to be broken in V7. You can now use version 2.0.3, see the comments in the changelog.
Closing it for now, but feel free to open it when you are still facing issues

Hi @wswebcreation . I tried the update and worked fine.
Yes, i'm getting some other errors but from wdio, not this plugin.
thanks!

Thanks for the feedback


ofs.uio:add peek dump and log level Command-line arguments

peek-dump Command-line arguments
--peek-dump address size
Peek CSR start address size (e.g.--peek-dump 0x0 0x20).
log level  Command-line arguments
--log-level {verbose,info}
log level to use

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

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

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
13695

Relevant Lines:
20196

💛  - Coveralls


bash completion for load and save image events

Ref: #22137
Please schedule for 1.12.0 because the feature is present there.
ping @sdurrheimer for zsh completion

LGTM 🐯

LGTM


Build Wazuh Infrastructure

Build the following Wazuh components for the entire infrastructure
The following blog posts can be found here

Backend Storage
Log Ingestion
Log Analysis
Wazuh Agent Installation
Intelligent SIEM Installation
Best Open Source SIEM Dashboards
Firewall Log Collection Made Easy
Firewall Threat Intel with Greynoise
Log Normalization
MISP Threat Intel

Manual Deployment YouTube Demos:

Log Normalization

Wazuh Indexer Install - Installing our SIEM Backend Storage

Graylog Install — Log Ingestion

Wazuh Manager Install

Terraform and Ansible Deployments

Offical Wazuh Ansible Deployment Documentation
Wazuh Ansible Deployment Code
Terraform Ansible Deployment
Wazuh Agent Install
Intelligent SIEM Logging

More Helpful Articles

Deploy a Virtual Machine to Proxmox with Terraform
Integrate Ansible With Terraform

YouTube - Proxmox and Terraform

Proxmox virtual machine automation in Terraform

Wazuh indexer, server and dashboard are configured. However I'm receiving a "Wazuh dashboard is not ready yet" error message

The dashboard is active and running but there's a "Response error" error message

Edited the dashboard config file

Logs from Wazuh Dashboard
Commands
journalctl -u wazuh-dashboard

cat /usr/share/wazuh-dashboard/data/wazuh/logs/wazuhapp.log | grep -i -E "error|warn"

Logs from Wazuh Indexer
Command
cat /var/log/wazuh-indexer/wazuh-cluster.log | grep -i -E "error|warn"

Solved it! Followed steps 3 and onwards in the password management section of Wazuh documentation


Image modal restricted to parent container

I have an image strip that's 120px high. I'd like to be able to have each image open up to a modal window with a caption if clicked but the materialbox container is restricted to the parent so if I have an overflow:hidden on the parent, the image viewbox is cropped to 120px high.
Is there anyway we can bust that out of when activated?

This has been fixed


Jump to PHPStan level 4

Also enable inferPrivatePropertyTypeFromConstructor

Coverage decreased (-0.5%) to 97.205% when pulling b4e14fc8b6f9132b27d010a5110f6c3d7690eb6f on phpstan-level-4 into 235108f9b6d1cd5734d14f7cf15312ae25d2d1e6 on master.


Replace various config files with a single config

This is the re-factor for DB-296.

Remove app init scripts that prompt for config settings
Code now gets config settings via a dataactcore.config import
Interfaces now get db names from config

There will be a subsequent PR that includes the corresponding doc changes.

@jworcestBAH and @nmonga91 this is ready for review--thanks!


⚠ Bofrost.de has degraded performance

In 23da33d, Bofrost.de (https://www.bofrost.de) experienced degraded performance:

HTTP code: 200
Response time: 1268 ms

Resolved: Bofrost.de performance has improved in b858022 after 7 minutes.


iOS 12 crash

Description
We have experienced a persistent crash on iOS 12 devices and managed to salvage a very obscure error message that goes
 dyld: Symbol not found __chkstk_darwin  Expected in /usr/lib/libSystem.B.dylib
I found pieces of information that indicate that Skia might not be operational on devices prior to iOS 13 due to Metal limitations, but does it mean crashing?
Commenting out all skia renders does not seem to help, only complete removal of the library fixes those crashes. Is there a way to somehow bypass this behavior for iOS 12 devices?
Version
0.1.172
Steps to reproduce

Install react-native-skia on iOS 12.5.5 device

Snack, code example, screenshot, or link to a repository

I'm seeing this as well on version 0.1.176 right now.  It seems like iOS version 12 is completely unsupported.  The crash appears to happen on app load, not in the Skia canvas.

@chrfalch should we document the iOS 13 requirement? Can this be enforced in code?

Yes, @wcandillon - documentation would be nice here. I believe we could make this work on earlier iOS versions, but it seems to me like a task we can't prioritise now. I'll make a documentation update.


networkmanager tries to execute /sbin/modprobe

I use network-manager to create a wifi-hotspot.
journalctl --unit network-manager gives the following:

Jan 01 11:38:38 nixos NetworkManager[15086]:  [1451648318.618482] [NetworkManagerUtils.c:346] nm_utils_modprobe(): modprobe: '/sbin/modprobe ip_tables' failed: Failed to execute child process "/sbin/modprobe" (No such file or directory)

And the same for /sbin/modprobe ip_tables, /sbin/modprobe iptable_nat, /sbin/modprobe nf_nat_ftp, /sbin/modprobe nf_nat_irc, /sbin/modprobe nf_nat_sip, /sbin/modprobe nf_nat_tftp, /sbin/modprobe nf_nat_pptp.
The errors were followed by following with

Jan 01 11:38:39 nixos NetworkManager[15086]:  [1451648319.864292] [rdisc/nm-lndp-rdisc.c:68] send_rs(): (wlp2s0): cannot send router solicitation: -101.

The workaround ln -s /run/current-system/sw/bin/modprobe /sbin/ worked for me for now; I'll try to look into it a little bit more in the next days.

the path /sbin/modprobe seems to be hard coded in the networkmanager source. The solution is probably to patch this with /run/booted-system/sw/bin/modprobe.

the path /sbin/modprobe seems to be hard coded in the networkmanager source. The solution is probably to patch this with /run/booted-system/sw/bin/modprobe.

Or lookup modprobe in $PATH?
Maybe it's just me, but I feel hardcoding NixOS specific /run/... paths is just as ugly as having /sbin/... paths (even though it makes little sense to run nixpkgs networkmanager on non-NixOS).

Or lookup modprobe in $PATH?
Maybe it's just me, but I feel hardcoding NixOS specific /run/... paths is just as ugly as having /sbin/... paths (even though it makes little sense to run nixpkgs networkmanager on non-NixOS).

that's also possible, I don't know.
I'm wondering if I should file a bug against networkmanager and what to ask them for. Make the path compile-time configurable (then we still woudn't be able to use $PATH)? Using $PATH always? Make it configurable to use $PATH?
Maybe we should just patch it for now.

that's also possible, I don't know.
I'm wondering if I should file a bug against networkmanager and what to ask them for. Make the path compile-time configurable (then we still woudn't be able to use $PATH)? Using $PATH always? Make it configurable to use $PATH?
Maybe we should just patch it for now.

i opened a bug in networkmanager as well https://bugzilla.gnome.org/show_bug.cgi?id=760061

:+1:

networkmanager is completely broken about finding binaries. It uses the absolute path instead of just looking into $PATH, and it does it for every single binary it calls. It's a mess every time we try to upgrade.

Closing as https://github.com/NixOS/nixpkgs/pull/12076 is merged.


yo fwsp-hydra hello: Unhandled 'error' event

events.js:189
throw err; // Unhandled 'error' event
Error [ERR_UNHANDLED_ERROR]: Unhandled error. (<Buffer 6e 70 6d 20 69 6e 66 6f 20 69 74 20 77 6f 72 6b 65 64 20 69 66 20 69 74 20 65 6e 64 73 20 77 69 74 68 20 6f 6b 0a 6e 70 6d 20 76 65 72 62 20 63 6c 69 ... >)
at child.emit (events.js:187:17)
at Immediate. (C:\dev\npm\node_modules\generator-fwsp-hydra\app\node_modules\yeoman-generator\lib\base.js:446:16)
at runCallback (timers.js:705:18)
at tryOnImmediate (timers.js:676:5)
at processImmediate (timers.js:658:5)

Hi @koolb, thanks for the bug report. I haven't checked on this project in a while, but will investigate this issue tonight.

Node 10-16 npm that comes with it
6.9.0 windows with cygwin or bash got
Sent from my Samsung Galaxy smartphone.
-------- Original message --------
From: Eric Adum<EMAIL_ADDRESS>Date: 7/30/19 5:17 PM (GMT-05:00)
To: flywheelsports/generator-fwsp-hydra<EMAIL_ADDRESS>Cc: Kool Breeze<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Subject: Re: [flywheelsports/generator-fwsp-hydra] yo fwsp-hydra hello: Unhandled 'error' event (#27)
Hi @koolbhttps://github.com/koolb, thanks for the bug report. I haven't checked on this project in a while, but will investigate this issue tonight.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/flywheelsports/generator-fwsp-hydra/issues/27?email_source=notifications&email_token=AARCL6WXWGJJT37EHJRIKP3QCCVXBA5CNFSM4IH7F252YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3FK5AI#issuecomment-516599425, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AARCL6RH7IHCGOIEPAOY5H3QCCVXBANCNFSM4IH7F25Q.

@koolb
The problem is yeoman introduced some breaking changes in the 2.x upgrade. I don't have time to upgrade this package right now for the latest version of yeoman, but there's a simple workaround which should work - just target yo version 1.x in your npm install. E.g.
npm -g i yo@^1 generator-fwsp-hydra
I'll update the docs to reduce confusion. Thanks!

Sent from my Samsung Galaxy smartphone.
-------- Original message --------
From: Eric Adum<EMAIL_ADDRESS>Date: 7/31/19 1:20 PM (GMT-05:00)
To: flywheelsports/generator-fwsp-hydra<EMAIL_ADDRESS>Cc: Kool Breeze<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Subject: Re: [flywheelsports/generator-fwsp-hydra] yo fwsp-hydra hello: Unhandled 'error' event (#27)
@koolbhttps://github.com/koolb
The problem is yeoman introduced some breaking changes in the 2.x upgrade. I don't have time to upgrade this package right now for the latest version of yeoman, but there's a simple workaround which should work - just target yo version 1.x in your npm install. E.g.
npm -g i yo@^1 generator-fwsp-hydra
I'll update the docs to reduce confusion. Thanks!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/flywheelsports/generator-fwsp-hydra/issues/27?email_source=notifications&email_token=AARCL6S7ZQHMUKDP4ZNOFBDQCHCUJA5CNFSM4IH7F252YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3H6OQQ#issuecomment-516941634, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AARCL6RS3YBFA6ZTGI66ZXTQCHCUJANCNFSM4IH7F25Q.

This still has same error on windows using yo 1.85. fyi.


mypy 0.981 compatibility

mypy 0.981 released on 9/26/22.  If you do a manual re-run of a job, it picks that up, and we get some failures.  Could be mypy bugs, or settings, or errors we need to fix.
Might be able to remove the python 3.10.6 restriction, since I think 0.981 is supposed to fix the issue of using 3.10.7 or later.

pandas-stubs/core/series.pyi:440: error: Overloaded function signatures 1 and 2 overlap with incompatible return types  [misc]

This is an actual ambiguity/error as None is Hashable. Can probably be silenced in the stubs but should still work for users.

error: No overload variant of "concat" matches argument types "Dict[str, Series[Any]]", "int"  [call-overload]

I think there might be two issues, something about using HashableT (replacing it with Any solves many of those errors - not sure what's going on there) and probably a mypy bug as axis=1 seems to be infered as int and not as Literal[1].

error: Dict entry 0 has incompatible type "Tuple[str]": "str"; expected "str": "str"  [dict-item]

Could be a mypy bug with how it handles HashableT:  the typevar is used a second time in the declaration of get_dummies (so the two instances have to have the same type) but the second time it is not used because columns is not passed.

tests/test_resampler.py:277: error: Expression is of type "Union[str, bytes, date, timedelta, complex]", not "Union[str, bytes, date, datetime, timedelta, bool, complex, Timestamp, Timedelta]"  [assert-type]

It seems that _typing.Scalar might contain redundant types: pd.Timedelta is part of datetime.timedelta and so on. It seems that mypy compacts Scalar in some cases but not always creating this discrepancy.
I will try to create minimal examples later and report them at mypy.

@hauntsaninja it might be great to add pandas-stubs to mypy-primer. Pandas-stubs has many annotations and some of them might also be dubious - perfect test case for mypy-primer :)

Thanks, added!

Mypy 0.981 adds support for unpacking kwargs https://github.com/python/mypy/pull/13471
from typing import TypedDict
from typing_extensions import Unpack

class Style(TypedDict, total=False):
    margin: int
    sticky: bool

def add_button(label: str, **kwds: Unpack[Style]) -> None:
    ...

That could make many overloads much smaller and easier to understand as we can put all the non-overload-related keywords in a TypedDict!

tests/test_resampler.py:277: error: Expression is of type "Union[str, bytes, date, timedelta, complex]", not "Union[str, bytes, date, datetime, timedelta, bool, complex, Timestamp, Timedelta]"  [assert-type]

It seems that _typing.Scalar might contain redundant types: pd.Timedelta is part of datetime.timedelta and so on. It seems that mypy compacts Scalar in some cases but not always creating this discrepancy.

Created https://github.com/python/mypy/issues/13760
It seems that 0.971 did type narrowing on unions, but 0.981 does it inconsistently.

With respect to Hashable, I think we should consider removing all uses of Hashable, because how it is interpreted by type checkers has some ambiguity.
If we want a type to correspond to what could be a column name or index name, we could do something like:
ValidName= Union[str, complex, Timestamp, Timedelta, tuple, None, OTHER_TYPES]
ValidNameT = TypeVar("ValidNameT", bound=ValidName)

where OTHER_TYPES are other types we know are OK for values of column names, index labels, then we replace all uses of HashableT with ValidNameT and all uses of Hashable with ValidName .
This might (but I'm not sure) clean up these mypy issues.

With respect to Hashable, I think we should consider removing all uses of Hashable, because how it is interpreted by type checkers has some ambiguity.

I would first wait for the next mypy release (or check mypy main) to know which errors are actual errors and which aren't. I think pandas-stubs/core/series.pyi:440 is an error/ambiguity. Since type checkers pick the first matching overload, we could live with this ambiguity.

With mypy 0.982, we are now down to only three errors :)
We need to fix this (or ignore it):

pandas-stubs/core/series.pyi:445: error: Overloaded function signatures 1 and 2 overlap with incompatible return types  [misc]

I think we have to just add a # type: ignore on this one.

Union-simplifications (wait for mypy 0.983?):

tests/test_resampler.py:277: error: Expression is of type "Union[str, bytes, date, timedelta, complex]", not "Union[str, bytes, date, datetime, timedelta, bool, int, float, complex, Timestamp, Timedelta]"  [assert-type]
tests/test_pandas.py:313: error: Expression is of type "Union[ndarray[Any, dtype[Any]], str, bytes, date, timedelta, complex, DataFrame, Series[Any], None]", not "Union[ndarray[Any, dtype[Any]], Union[str, bytes, date, datetime, timedelta, bool, int, float, complex, Timestamp, Timedelta], DataFrame, Series[Any], None]"  [assert-type]

So they claimed to have fixed the bug here: https://github.com/python/mypy/pull/13781
But I looked at the source for tag for 0.982, and it doesn't include that fix, so let's wait for that.

If we had a good solution for optional CI runs that are allowed to fail without screaming in red that they failed, it might be nice to add a run with mypy nightly. This would allow us to more quickly correct errors that newer versions of mypy will detect and if mypy has unexpected behaviors, we can report them before a new version is released.


Sleep tracking

Fi has recently introduced Sleep tracking to their ver. 2 dog collars, it would be awesome to see these new stats show up as entities within HA.
In the app you can see stats on your dogs napping, and sleeping habits from the night before, but also: hourly, daily, weekly, and monthly. The app also pinpoints at which point during the night your pup had an interruption (it counts these per night), and was awoken.
More information on the new Sleep tracking feature from Fi.

@dougtechdude - there has been a recent enhancement to include the sleep and nap metrics. This was updated in v0.0.14.


maybe use aws-sdk multipartUpload

http://docs.aws.amazon.com/aws-sdk-php/v3/guide/service/s3-multipart-upload.html

Multipart uploads are designed to improve the upload experience for larger objects. With it you can upload objects in parts that can be uploaded independently, in any order, and in parallel. You can use a multipart upload for objects from 5 MB to 5 TB in size.
Amazon S3 customers are encouraged to use multipart uploads for objects greater than 100 MB.

@svycka the sdk does this internally by default, the default threshold is 16777216 bytes (16MB) and when uploading a larger file will use 3 concurrent uploads.


Reduce unnecessarily high logging level

Several logs have the logging levels ERROR/WARN but do not contain error or warning information.
For those the log level has to be changed for keeping a clean log file.
Only errors shall be marked as errors.
For example: Error. The error key is: USER_ERROR_EMAIL_USED

[x] filter error and warn loggings and change loglevel where necessary

Merged.


feat: add WidgetExt trait for debugging widgets

Importing the WidgetExt trait allows users to easily get a string
representation of a widget with ANSI escape sequences for the terminal.
This is useful for debugging and testing widgets.
use ratatui::{prelude::*, widgets::widget_ext::WidgetExt};

fn main() {
    let greeting = Text::from(vec![
        Line::styled("Hello", Color::Blue),
        Line::styled("World ", Color::Green),
    ]);
    println!("{}", greeting.to_ansi_string(5, 2));
}

Fixes: https://github.com/ratatui-org/ratatui/issues/1045

Made AnsiStringBuffer less private so this works too:
use ratatui::{prelude::*, widgets::ansi_string_buffer::AnsiStringBuffer};

fn main() {
    let mut buf = AnsiStringBuffer::new(5, 2);
    buf.render_ref(&Line::styled("Hello", Color::Blue), Rect::new(0, 0, 5, 1));
    buf.render_ref(&Line::styled("World", Color::Green), Rect::new(0, 1, 5, 1));
    println!("{buf}");
}

Things I'm not 100% sure of with this:

Naming

WidgetExt / WidgetAnsiExt
AnsiStringBuffer / ?
to_ansi_string() ?

Use of WidgetRef vs Widget

render_ref / render
I can't make a blanket impl for Widget if there's a blanket impl for WidgetRef as the implementations clash - this could suggest that there's a deeper issue about how these traits work.

Putting this in a new type (AnsiStringBuffer) vs adding to the existing buffer
Any obvious idiomatic approaches using conversion traits
Whether to just use a lib for the ANSI stuff
Underline color is missing (I skipped because it was a little more complex than I'd like)


updates for 0.12

bunch of updates for 0.12 and filterable, wip.
Not entirely sure if compactable is supposed to be implemented in a different way.

Thanks! Looks good, I'll merge this after the compiler is released. Until then, your branch can be used in the package set, right?

Yup, that's what I'm planning to do for now: https://github.com/purescript/package-sets/pull/175/

Good to merge? only depends on https://github.com/purescript-contrib/purescript-drawing/pull/27 which is a dev dependency

Is there anything missing here? I really want to upgrade my underlying lib and my chatbot~

I'd like to review open PRs but I haven't had time. I'll get to it soon, I hope. Sorry for the delay.

I'm working on migrating a few libraries that depend on behaviors. Anything that I can do to help with this PR?

I'm working through PRs slowly. This one will be next, but I'm thinking I'll break the Event part out into a separate package, since people seem to use that more than Behavior.

Sounds fair

@paf31 Is it possible to release a new version of this library for 0.12 compatibility alone?
It would make for an easier transition for folks like @justinwoo and my team and likely less stress for you if this (and libraries like parsing) were available in their current form for 0.12, and later, when you have time & at your convenience, another update could be made to break Event out to a separate package.
Halogen updated this way and it's been quite nice; they get to relax and take their time working on the next big improvement to the library, but the rest of the dependent ecosystem can complete the transition to 0.12 without relying on forks.

Thanks @justinwoo. That helps make it possible to use your fork easily with psc-package, though it doesn't resolve relying on a fork vs. an official 0.12 release. We're considering whether to work with forks or continue to wait things out, and would very much prefer to avoid forking where possible. Regardless, thanks for the tip!

Thanks!

purescript-event is now broken out. I'm waiting on drawing, which is waiting on canvas, and when those are done, I'll finish this up and make a release. For now, this is merged so you can refer to it by the hash of master.


Creating 11M actors and sending 11M messages causes segfault on app shutdown

There's a skynet microbenchmark:

Creates an actor (goroutine, whatever), which spawns 10 new actors, each of them spawns 10 more actors, etc. until one million actors are created on the final level. Then, each of them returns back its ordinal number (from 0 to 999999), which are summed on the previous level and sent back upstream, until reaching the root actor. (The answer should be<PHONE_NUMBER>00).

I've ported skynet in pony and everything works fine for 1M actors on the final level. However, having 10M actors on the final level successfully completes the task but then fails (when shutting down?) for different reasons:
Segmentation fault: 11

Assertion failed: (view != NULL), function unblock, file src/libponyrt/gc/cycle.c, line 619.
Abort trap: 6

Also, running it with gdb reports:
Program received signal SIGBUS, Bus error.
0x00000001000059ce in set_flag (actor=0x100000001, flag=16 '\020') at src/libponyrt/actor/actor.c:27
27	  actor->flags |= flag;

Pony version: 0.2.1-536-gd888dab (d888dab8bdcc4e02ce043f41cad62a9adcc88b5d)
Mac OS X 10.10.5

@jonas-l Are you running on a 64 bit machine or a 32 bit machine?
I notice that the actor pointer in your GDB output is just over the maximum value representable by 32 bits.

It's a 64 bit machine.

My guess would be that you're running out of memory. A Pony actor has an overhead of around 250 bytes, so 11M of them would be around 2.5GB. Depending on your machine's setup and exactly how OS X handles out of memory conditions you could expect the failures you're seeing.
It might be worth us writing a simple test program that creates an infinite list of actors to see exactly when and how we fail.
Of course, even if this is an out of memory failure, and even if we can catch it, it's not obvious what we can do about it other than die in a slightly different way.

@andymcn - The interesting part is that it finishes the program (prints the result), at which point it should have already allocated all of the memory it was going to allocate.  It appears to be running into some error when cleaning up the actors.
When running with a debug build of pony, and outside of GDB, I saw a large amount (at least tens of thousands of lines) of output like this:
0x7ff1344cf000: 0/266 (unblocked) ERROR
  --- ERROR
  0x7ff134633000: 1
  0x7ff133763000: 256
  0x7ff133762200: 256
  0x7ff133762800: 256
  0x7ff133761c00: 256
  0x7ff133762000: 256
  0x7ff133763200: 256
  0x7ff133761400: 256
  0x7ff133762600: 256
  0x7ff133763e00: 256
  0x7ff133761e00: 256
0x7ff1234f6000: 0/266 (unblocked) ERROR
  --- ERROR
  0x7ff122862600: 256
  0x7ff122862e00: 256
  0x7ff122863600: 256
  0x7ff122862000: 256
  0x7ff122862400: 256
  0x7ff122863400: 256
  0x7ff122862c00: 256
  0x7ff122862200: 256
  0x7ff122863e00: 256
  0x7ff122863c00: 256
  0x7ff123635e00: 1
0x7ff1124a4000: 0/266 (unblocked) ERROR
  --- ERROR
  0x7ff111521e00: 256
  0x7ff111521a00: 256
  0x7ff111522800: 256
  0x7ff111523200: 256
  0x7ff111522a00: 256
  0x7ff111521800: 256
  0x7ff111521600: 256
  0x7ff111521400: 256
  0x7ff111521c00: 256
  0x7ff111523000: 256
  0x7ff11262de00: 1
0x7ff10977f400: 256/256 (blocked)
  0x7ff109dac000: 1/1
0x7ff109710400: 256/256 (blocked)
  0x7ff109da0800: 1/1
0x7ff11263bc00: 266/266 (blocked)

And the output finished with lines like this:
0x7ff1094d4200: uncollectable
0x7ff109d08a00: uncollectable
0x7ff11257b000: uncollectable
0x7ff12b646600: uncollectable
0x7ff123402000: uncollectable
0x7ff12b429800: uncollectable
0x7ff1097d8e00: uncollectable
0x7ff109e11800: uncollectable
0x7ff10985c800: uncollectable
0x7ff11ac5a000: uncollectable
0x7ff11acf9e00: uncollectable
0x7ff13455dc00: uncollectable
0x7ff11acf5200: uncollectable

That output seems to correspond to a supposedly unreachable branch in cycle_dispatch:
https://github.com/ponylang/ponyc/blob/87120a2dfbf71a560364cf121277d5055eb12c42/src/libponyrt/gc/cycle.c#L810-L817

There are a couple of ways that running out of memory could be seen while cleaning up.

The clean up process involves quite a bit of message passing, and those messages take up memory. The memory the messages need is way less than the actors, but they still require allocation.
It could be that we don't die when we run out of memory but carry on with various things overwriting each other. It's perfectly possible this would only be seen once the memory was tidied up, leading to double frees, accessing freed memory, etc. This kind of thing often points to supposedly unreachable branches.

Of course I may be wrong and it might be something else entirely, but out of memory seems to fit the observations.

This was a tricky bug, and ended up being the same as #603. Should be fixed now.

I've updated to version 0.2.1-637-ga1deebb but still seeing segmentation fault, bus error, etc.
Is it just my machine, or somebody else experience this as well?

I tested the skynet code with an initial parameter of 11_000_000 and it runs fine for me (OSX 10.11.3, 2 core laptop).
But "works for me" is not the same thing as fixed :) Can you make clean ponyc, rebuild the skynet test, and try again, just in case?

If you installed by doing make config=release, make sure you do make clean config=release

It works! Thanks a lot.

Thank goodness! You had me seriously worried :)


Add steam family games

it is possible to add the option to add your family games on the playnite library? Or do we need the API for each account?

Not possible, Steam API doesn't support it.

not sure if this is already known BUT...
it does:
https://steamapi.xpaw.me/#IFamilyGroupsService/GetFamilyGroup (needed for retrieving the Group ID)
and:
https://steamapi.xpaw.me/#IFamilyGroupsService/GetSharedLibraryApps (group ID is required even tho the documentation says its not)


Support for Altair Accelerator

Hi,
I've been using Dask on a cluster that runs Altair Accelerator. I've been mostly launching the workers manually, but I have some rough code (based on the LSF cluster module) to launch them using dask-jobqueue. I was wondering whether you'd be interested in this, and what I would have to provide (minimum functionality, tests, etc).
Regards
Ignacio

I've been using Dask on a cluster that runs Altair Accelerator. I've been mostly launching the workers manually, but I have some rough code (based on the LSF cluster module) to launch them using dask-jobqueue.

Great to hear that the dask-jobqueue code has already been useful for you!
I have never heard of Altair Accelerator so out of curiosity:

where is it used mostly, academia, companies, any particular type of companies ?
does it look like a job scheduler that we already support (you started with the LSF code so it may look like LSF a little bit) ?

I was wondering whether you'd be interested in this, and what I would have to provide (minimum functionality, tests, etc)

This is a very good question and the answer is I don't really know ... there is a cost/benefit analysis that is rather tricky to do.
In particular it depends on:

how likely it is to be used by other people
how different is Altair Accelerator from the job schedulers we already support
how much code does it would add to dask-jobqueue
for adding tests how easy it is to have a Docker image with a toy cluster

Because I am a maintainer in dask-jobqueue (and variety of other small reasons e.g. I have never heard of Altair Accelerator before, it seems proprietary, etc ...) I will tend to err on the conservative side, so my current personal recommendation would be to encourage you to put together a package and see where it leads you.

You're right, it seems very niche: I can hardly find people asking about it on Google. My company uses it mostly to run electronics CAD simulations. I believe it's related to LSF because it includes wrapper scripts and instructions for people migrating from LSF. I don't believe there's a free version we could use for testing.
I'll publish my code for fun on a fork but it's probably not worth maintaining on the main branch.

That makes sense, thanks a lot for the details and your understanding!

Hi, just to say that Altair is the company that is behind PBS Pro scheduler, which has already a licensed version (and a dask-jobqueue implementation). So it's a little weird to see another job queueing system from them? The website of Altair is currently down, so I cannot see how this differs from PBS.

It looks like PBS is set up using comments on a shell script, while Accelerator uses command-line arguments in the submission command (nc run)


Add emoji support to the yaml text editor

Some of the example files are using emojis, like "green circle":
# CPUs: if you see performance issues, try limiting cpus to 1.
# 🟢 Builtin default: 4
cpus: null

# Memory size
# 🟢 Builtin default: "4GiB"
memory: null

# Disk size
# 🟢 Builtin default: "100GiB"
disk: null

But these codepoints are not currently supported by the text editor:

See e.g. https://unicode.org/emoji/charts/full-emoji-list.html#1f7e2
There is support for this in https://github.com/raven-worx/qrwemoticons

https://www.openmoji.org/ (CC BY-SA 4.0)

https://www.openmoji.org/library/emoji-1F7E2/

Fixed, 285c58830246d2b761dd70370687b1de546e0ac4


MCMC example documentation on readthedocs didn't render

In the section where we attempt to use MCMC on theta, that block errored out:
https://gpflow.readthedocs.io/en/stable/notebooks/regression.html

Thx, we will fix it.

Thanks! I feel like something might have changed with the API eh? (I'm also getting errors when I'm trying to MCMC)

This is working for me locally. How does the readthedocs version get updated?

Related to #582 - same notebook, just latest vs stable...

@sadatnfs "stable" and "latest" versions of readthedocs are deprecated. We now have "master" for the master branch (latest actual release) and "develop" for the develop branch (bleeding-edge latest version on github). Please check you are looking at the correct version of the docs. If you find any links pointing to "stable" or "latest", please let us know so we can fix them! (Feel free to re-open this issue!)


Allow passing arguments to imagemagick convert which must precede the source filename

Addresses #391.

thanks for this - looks like it's a duplicate of https://github.com/markevans/dragonfly/pull/398 - you guys must have done it around the same time - I pulled the other one in though I'm afraid as it was tested - cheers

Great! thanks for the update.


Bump to Spring Boot 3.2 and move to .imports file

Also prepare for wavefront-spring-boot 3.2.0 release.

looks good to me


Refactor enable logic to use counts instead of for_each

what
Use count instead of for_each to manage if a resource is enabled or disabled.
why
The usage of for_each to manage the enabled state of resources is does
not play well with the terraform execution planner, throwing errors like
this one:
╷
│ Error: Invalid for_each argument
│
│   on .terraform/modules/test.default_iam_role/main.tf line 59, in data "aws_iam_policy_document" "service_account_assume_role":
│   59:   for_each = toset(compact([module.service_account_label.id]))
│     ├────────────────
│     │ module.service_account_label.id is a string, known only after apply
│
│ The "for_each" value depends on resource attributes that cannot be determined until apply, so Terraform cannot predict how many instances
│ will be created. To work around this, use the -target argument to first apply only the resources that the for_each depends on.

references

@elventear thank you for the contribution! It's always refreshing to see new contributors.
While this PR may allow geting around the issue you're facing, it may disrupt current consumers of this module since we are changing from for_each to count.
Generally, we move from count to for_each so reordering doesn't trigger recreations of equivalent resources.
There must be an alternative. The error is thrown on the data aws iam policy document. Perhaps a local.enabled check could help?
  for_each = local.enabled ? toset(compact([module.service_account_label.id])) : toset([])

Was it required to change the other for_eachs to count as well? I'm interested in seeing your exact inputs to reproduce this issue. If possible, it would be nice to see a test that can reproduce the error and then modify this module in such a way that will retain the for_each for backwards compatibility.
cc: @Nuru what do you think?

I understand the issue with backwards compatibility but the problem is complete blocker for more general usage. The only two options I would have is either copy the contents within my own TF, or fork the module.

/test all

/test all

@elventear Thank you for bringing this to our attention. For most users, all of the elements of the service account name, and therefore the name itself, are known at plan time, so for_each is not an issue. But as you have experienced, this is not always the case, and converting to count will fix that.
I made some changes for style and to cover some missing tests, and updated the PR description. I hope you don't mind that I added it to this PR rather than creating a separate one.

/test all

/test all


Uncaught TypeError: stream.destroy is not a function

In https://github.com/pull-stream/stream-to-pull-stream/blob/master/index.js#L156 it is assumed that the stream has a destroy method, but some streams do not have those. This results for me in
Uncaught TypeError: stream.destroy is not a function
      at node_modules/stream-to-pull-stream/index.js:156:14

Ah. Yeah we should not crash if that happens.
However, I would also strongly encourage streams to implement destroy. It's not listed as a mandatory in the official node docs, but if you read between the lines, destroy is essential. most node streams implement it (I've never seen this error until now ;)
especially if they inherit from through or through2.

not implementing destroy means it's possible you'll have a resource leak pull-streams don't have this problem, but you are using stream-to-pull-stream without destroy, then you'll get resource leaks.

I fixed this in 1.6.9
it won't crash, but it will log a warning.

Thanks :)

Side note on stream.destroy(); WG def wants to implement this in Node core, but is writing regression tests for existing functionality first so when it's added, it doesn't break like everything around it. No specific ETA though hey

I thought that all core node streams (except stdio) had destroy? which ones dont?

@dominictarr none do - it's something through2 has, and widely regarded as necessary, but not yet part of any of the constructors exposed by Node core.

Oh right, got it.
All the actual core streams node creates, net, fs, etc, etc all have destroy.
 There'll be a good amount of streams WG folks hanging out in Ams around Sept; hopefully we can make node core streams catch up to 2012 then :grin:

oh cool. I'll be around for nodeconf.eu was planning on coming through AMS also.

yeah, cool! - should totes hang :tada:


FIX accept both float and array-like for time_horizon in predict_proba

There is a bug in SurvivalBoost.predict_proba. The time_horizon parameter does not currently accept array-like while it should.

Could you please fix the shape information of the predict_cumulative_incidence docstring? It lacks the time dimension. I believe it should be (n_samples, n_events + 1, n_time_horizons)

I would do that in a subsequent PR.


kvm: unnecessary cni plugins in stage1 image

kvm flavor uses only ipam plugins (host-local, dhcp) cni plugins copied into rootfs/usr/lib64/rkt/plugins/net in stage1 image. Rest of plugins are reimplemented in the init process (tbh partially in init, and partially in lkvm/systemd units), so there from 37M of binaries landing in stage1 rootfs, there could be stripped out something around ~24M.
@krnowak could You propose some method how to skip coping in these files? (probably something similar with manifest files for coping in bits from pxe image).

@krnowak might not have time to work on this. Maybe @s-urbaniak ?

This work closer to build system - if @s-urbaniak feels strong enough on this - that would be great.

Visiting for triage. Low priority and unassigned, I'm de-milestoning for the moment. Anybody stepping in to push this further will be highly appreciated!

Closing it, as there is a plan to move interface creation into cni plugins, so they will be again needed.


Update typo in README.md

I felt this was too mental, why falling back to metrics helps ease of mind when reading this README.

Thanks for this @almereyda!

It took longer to write the PR description, than actually forking and fixing it.


[BUG] looks like thunderstore kicked the mod - maybe a re-upload would be enough?

Describe the issue
[Describe what isn't working the way you expect it to.]
https://valheim.thunderstore.io/package/nwesterhausen/DiscordConnector/ is dead
Expected behavior
https://valheim.thunderstore.io/package/nwesterhausen/DiscordConnector/ should contain the mod
Additional context
Some time ago they had problems at thunderstore and removed some mods (malware detection?) - they fixed it but maybe they (the files) need to be uploaded again?

Thanks for posting the issue. I had to reach out to them beck when they updated there detection stuff a few weeks ago.
I just reached out and it was very quick for them to fix it. It shows up for me now.

Website is back, still waiting for the searchindex (thunderstore mod manager / r2modman) to show it.
Thanks :)

There it is


Mesos DNS changes in scheduler

Please check the new changes @elingg @adam-mesos.
I moved the DNS resolution code into a separate file and cleaned up the phases. Instead of adding extra phases, I decided to move the logic into the state machine because it simplifies the state transitions. Took out the logic in the executor and turned that into a sendMessageAfterNNResolvable method.
I'm confident about the functionality here and its ready to merge IMHO.

Thanks for your changes @abhay-agarwal! This solution has evolved and is much simpler and cleaner without the duplicated logic. It is looking good. I will test it out today and look it over one last time. My main remaining concern is the bug automatically deleting the Active NN directory. We need to revert that logic.

Okay @elingg, i'm fine with changing the logic around, but I would just like to see in practice. the recovery you describe. Also, the Name node needs to send its status update no matter what, so there was still a bug in your former code, correct?

Hey @abhay-agarwal, we discussed in person and you made the update that is correct in your last commit. Let me do a final test, look it over one last time, and once @adam-mesos is ready we can merge

should be good now, @elingg!

Awesome! thx. Let me test, take a final look, and then I'll merge.@adam-mesos, do let us know if you have any final objections.

:100: Let's merge!


Add syntax highlighting for shell-scripts

Pretty much exactly as the title says. Leaving this here primarily as a self-reminder for later.

JFC, this was added forever-ago, and I forgot.
$ apropos self-reminders


tools/prepare-source.sh: Run go mod generate before fmt and mod

go generate somehow touches go.sum, which causes issues for dependabot PRs (osbuild/image-builder#418 for example). Run mod tidy command last.

I force pushed the #428 emoji fix here :facepalm:


When I deploy to the server, it is wrong to open the web page.

It's very unclear how you deploy. Please write full description for this issue.

I have the same problem.  Install from source.
Start command:  label-studio start --port 8089

目前还不清楚你是如何部署的。请写下这个问题的完整描述。

The problem has been solved. I added a port to the domain name yesterday.

The problem has been solved. I added a port to the domain name yesterday.

The problem has been solved. I added a port to the domain name yesterday.
Where did you add it？

Do you know how to delete users?


Quick typo fix

Quick typo fix here!

Hi @ScottBrenner 👋
Thanks a ton for the fix! I really appreciate it! I've been meaning to fix the typos for some time now and been very lazy about it.
I believe there's some more typo in copies and I was thinking about getting it to proofread by someone native. I'd also like suggestions around how the sentences could be made simpler and better. I'm not extremely proud of my English, haha 😅
If you're interested and have time, that'd be a huge help!
Also, yours marks the first PR on any of my personal projects and I can't say how happy I am! Thanks!! 😄


chore: adjust CI and prettier settings

What does this PR introduce ?

Add artifacts cache types to .prettierignore
Make solc ci run only on solidity changes
Remove not working settings in benchmark ci

Closed in favor of #529


🐞 [Bug]: Dashboard manual link redirects to connect docs

Is there an existing issue for this?

[X] I have searched the existing issues

which package/s did you face the problem with?
Dashboard
What happened?
Wrong URL.
Steps To Reproduce

Go to Dashboard
Open manual link in connect tab

which network/s did you face the problem on?
Dev
version
2.6.0
Twin ID/s
No response
Node ID/s
No response
Farm ID/s
No response
Contract ID/s
No response
Relevant screenshots/screen records

Relevant log output
-

the correct link: https://www.manual.grid.tf/documentation/dashboard/wallet_connector.html


Update gems

Coverage decreased (-0.0008%) to 99.266% when pulling 86274935de532e967c6da472aaf6fe831eff5f44 on mb-update-gems into e14a23c6e4255bb88ca35ca6f713b7da37f3636d on master.


ODH-ADR-Operator-0004-replica-image-support

Update DSC CRD with new customization values.
Description
Upgrade the DSC CRD to support customizing the replica count, images and modifying the resource limits/requests of individual components.

@andrewballantyne , some questions

If we are going to use HPA, then should we add it as a resource along with the other kustomize manifests?(the odh-manifests repo)
Should this be configured for each component?
If HPA is configured, then users need not worry about the replica count right? So there is no need to add a custom replica functionality ? 😅 (Please correct me if I am wrong)

@andrewballantyne , some questions

If we are going to use HPA, then should we add it as a resource along with the other kustomize manifests?(the odh-manifests repo)
Should this be configured for each component?
If HPA is configured, then users need not worry about the replica count right? So there is no need to add a custom replica functionality? 😅 (Please correct me if I am wrong)

As @VaishnaviHire  says, can we also move the HPA configurations to devFlags?
Also instead of directly modifying the replica count, can we plan to modify the minReplicas and maxReplicas?
@ykaliuta ^

@andrewballantyne , some questions

If we are going to use HPA, then should we add it as a resource along with the other kustomize manifests?(the odh-manifests repo)
Should this be configured for each component?
If HPA is configured, then users need not worry about the replica count right? So there is no need to add a custom replica functionality? 😅 (Please correct me if I am wrong)

As @VaishnaviHire says, can we also move the HPA configurations to devFlags as well? Also instead of directly modifying the replica count, can we plan to modify the minReplicas and maxReplicas? @ykaliuta ^

I think HPA configurations/replicas can be updated by users, so they should not be included in the devFlags, just the images

understood 👍

@andrewballantyne , some questions

If we are going to use HPA, then should we add it as a resource along with the other kustomize manifests?(the odh-manifests repo)
Should this be configured for each component?
If HPA is configured, then users need not worry about the replica count right? So there is no need to add a custom replica functionality ? 😅 (Please correct me if I am wrong)

So let us start at the top-level... HPA will be extra work to configure (over just Replicas). If we ever intend to support non HPA deployments (maybe the backend teams don't want HPA?) then Replicas sound like something we will need to support -- so maybe we just start there until we understand HPA edges more.
HPA is (imo) a needed feature for the Dashboard & I imagine every component (but probably used less by many). The Dashboard can get hit by 1000s of users at the same time and our pod needs to scale for that. If 10 people use it at the same time, no need to spend the resources putting up several replicas. This can always be done through pure replica's, as determined by the Installing User (eg. "I have thoughts of 1000s of users concurrently using it vs I have an intent for only 10 to be using it at any point in time" -- which would be several replicas or just one)
I'm worried at this point that HPA will be entirely dictated by me for the Dashboard needs and I think we need to avoid a single component owner driving this. Maybe this is an AC topic for a future enhancements, and we go with Replicas for now.
Thoughts @VaishnaviHire @AjayJagan ?

@andrewballantyne , some questions

If we are going to use HPA, then should we add it as a resource along with the other kustomize manifests?(the odh-manifests repo)
Should this be configured for each component?
If HPA is configured, then users need not worry about the replica count right? So there is no need to add a custom replica functionality ? 😅 (Please correct me if I am wrong)

So let us start at the top-level... HPA will be extra work to configure (over just Replicas). If we ever intend to support non HPA deployments (maybe the backend teams don't want HPA?) then Replicas sound like something we will need to support -- so maybe we just start there until we understand HPA edges more.
HPA is (imo) a needed feature for the Dashboard & I imagine every component (but probably used less by many). The Dashboard can get hit by 1000s of users at the same time and our pod needs to scale for that. If 10 people use it at the same time, no need to spend the resources putting up several replicas. This can always be done through pure replica's, as determined by the Installing User (eg. "I have thoughts of 1000s of users concurrently using it vs I have an intent for only 10 to be using it at any point in time" -- which would be several replicas or just one)
I'm worried at this point that HPA will be entirely dictated by me for the Dashboard needs and I think we need to avoid a single component owner driving this. Maybe this is an AC topic for a future enhancements, and we go with Replicas for now.
Thoughts @VaishnaviHire @AjayJagan ?
EDIT: Let me answer your questions in case you guys do want to go ahead with HPA.

The Operator will definitely need to entirely manage this, no implementation should come from any component, this is outside of their world
Yes
That's my hope -- but like I noted in the block above, does everyone want to be HPA-enabled?

Looking at it from your perspective, we may need to draw a line between frontend and backend apps(for using HPA) so if you ask me let's do it iteratively, so the first version of this can be replicas and maybe we only provide HPA configurability for the dashboard(or if other teams require this, we can extend the HPA functionality) -- this is just my thoughts. Any new idea is welcome 😄 . And thanks for the detailed explanation

@jwforres Perhaps this is just the inefficiency of the Dashboard pod 🤔 No backend component ever needs more pods if they have direct API calls in the 1000s concurrently? I may be off base here then.
Replicas for the Dashboard at least are 5 by default for RHOAI; to support Perf requests. ODH is 2 by default. Are we the only RHOAI deployment that needs to be controlled based on the number of users?

So if I understand this correct
Front-end = configurable replica count(maybe not it the devFlags) - In future we can consider HPAs
Back-end = configurable replica count only in the devFlags(maybe we can have a limit set there to max = 2)
Is this assumption right?
@jwforres @andrewballantyne @VaishnaviHire ^

I clarified in slack but will do so here as well - my comment about only 2 replicas was specific to controllers. Backend API servers may still require scaling beyond 2.  With controllers only 1 replica is ever serving as the active one, so there is no benefit to going beyond having a single passive backup. That same situation isn't true with backend API servers that are serving requests.

I clarified in slack but will do so here as well - my comment about only 2 replicas was specific to controllers. Backend API servers may still require scaling beyond 2. With controllers only 1 replica is ever serving as the active one, so there is no benefit to going beyond having a single passive backup. That same situation isn't true with backend API servers that are serving requests.

ok, now it's clear - the why... Thanks for the clarification 😄

I understand that the main driver for this change is giving dev teams the ability to slim down deployments so they can be run in the constrained clusters. If that is the case I think this would be a great opportunity to rework devFlags and make them flexible. What I was thinking of is to make devFlag a *runtime.RawExtension field so that each component can model settings fitting their needs by providing their own structs matching exactly all the resources they wish to make configurable.
From a broader perspective, incorporating elements like replicas directly into the DSC API appears to be a somewhat leaky abstraction. This approach could lead to further additions of similar nature in the future, complicating the API. Additionally, the meaning of a parameter like replicas: 2 becomes ambiguous, particularly for components responsible for creating multiple Deployments (aside from controllers).
I think providing some reasonable defaults through means of HorizontalPodAutoscaler and perhaps PodDisruptionBudget and letting users fine-tune them might be a better option to start with.

I am very much agree with @bartoszmajsak suggestion to expose *runtime.RawExtension which could be easily customize to take differet input.
I am seeing this requirement as starting of various customization which could be required to expose for different component. Currently we are maintaining single CRD DataScienceCluster where we are trying to capture every customization of every component. Soon it would became big and nightmare to maintain.
Proposal
In addition to @bartoszmajsak suggestion, I am proposing to maintain seperate CRDs for each ODH component where every component team design them as per their need.
like Seperate CRD for:

DashboardConfiguration
NotebookConfiguration
ModelServingConfiguration

For example:
In ModelMesh Serving, there is no single image which user could just override. KServe component use to run 4 container in a pod so user could provide customize image for any of it.
I am proposing to maintain something like below:
ModelServingConfiguration.yaml
apiVersion: opendatahub.io/v1
kind: ModelServingConfiguration
metadata:
  name: default
spec:
  odh-model-controller:
    replica: 1
    image: quay.io/vajain/odh-model-controller:2.0
    manifests:
      contextDir: config
      sourcePath: ''
      uri: 'https://github.com/opendatahub-io/odh-model-controller/tarball/main'
  kserve:
    replica: 2
    kserve-agent
      image: quay.io/vajain/kserve-agent:2.0
    kserve-storage-initializer
      image: quay.io/vajain/kserve-storage-initializer:2.0

I know its completely contradictory to current design but if we follow above described approach then we could complete remove the DataScienceCluster CRD. To enable and disable specific component we could rely on Component CRD like if user create an instance of  ModelServingConfiguration CRD then he want to enable ModelServing in the project. Its very similiar how Serveless team provide support for knative-serving and knative-eventing
@danielezonca

Any progress on this one?

@VaishnaviHire @andrewballantyne I have updated the ADR a bit. Let me know how it looks :)

Any progress on this one?

Hi @vaibhavjainwiz AFAIK, the idea of separate CRDs can be put into a separate ADR 😅 . wdyt?

I'm catching up on this thread but wanted to weigh in on a couple of different things.
I'm 100% in alignment with @andrewballantyne on focusing on setting replicas for the dashboard and focusing on HPA afterwards.  Replicas should be a much easier change and HPA's are a nice to have.  I would recommend considering how HPAs might be integrated into that at a later phase.
Like @andrewballantyne said, having the dashboard scaled to 5 replicas is great for 1000 active users but most customers may have 10-15 users at any given time.  On top of that I would say that 95% of the time users are working with OpenShift-AI they are working on things outside of the Dashboard (such as in a notebook and the OCP console) and only 5% of the time they are actively working in the Dashboard.
As for setting images, that was originally suggested before DevFlags existed.  I don't expect it should be a "supported" feature for customers.  I think that including it under the DevFlags is perfectly fine.  I think that if customers want to deploy their own image, we probably need to better understand why they need their own image (e.g. adding custom certs to the image) and see about building that capability into the operator as a first class feature instead of just using their own image.
I have previously voiced some concerns around the DevFlag but I will say them again here.  DevFlags seem like a bit of a kludgy way to say "this is supported and this isn't supported" instead of just documenting it.    Do we need to change the API spec to make that policy change if it is currently located under devFlags?
For the controllers I will make the argument that they should NEVER be more than a single replica.  Having a standby replica is a waste of resources and IMO should have never been introduced.  Controllers are designed around eventual consistency and there is no guarantee of "response time" from a controller.  So what is the risk of a controller crashing with a single pod?  The resource you are attempting to deploy takes 45 seconds instead of 30 seconds to deploy?  The controller going down doesn't cause the resource it has deployed to stop working.  So your model server API endpoint still functions if the modelmesh-controller goes down, it just won't get updated if the resource definition is modified until the pod comes back up.
So in my ideal solution all of the controllers should be 1 replica by default and there is no need to even add the replicas feature outside of the dashboard.  If a component teams insists that they need an HA deployment of the controller, I need to have the ability to set it to 1 replica for Single Node Deployment or one where we have some resource sensitivity.
Regarding the ModelServingConfiguration idea...   What value does having this as a separate object have over doing it in the existing DSC?  It is still a one to one relationship between DSC and ModelServingConfiguration so it appears to me to just be moving the configuration from one object to another.  I would prefer to keep the configuration of these types of items consistent across all components and keep them in a single location.  If we want ant move to a unique object per component we should do away with the DSC entirely and only have unique objects for each component.  Mixing the two is just going to cause confusion on "what should I set where?".
My ideal configuration of the DSC would look something like this:
apiVersion: datasciencecluster.opendatahub.io/v1
kind: DataScienceCluster
metadata:
  name: default
spec:
  components:
    codeflare:
      managementState: Removed
    dashboard:
      managementState: Managed
      dashboard: <1>
        autoscale: <2>
          enabled: true
          hpa:
            minReplicas: 1
            maxReplicas: 10
            metrics:
              - type: Resource
                resource:
                name: cpu
                target:
                  type: Utilization
                  averageUtilization: 50
    datasciencepipelines:
      managementState: Managed
      data-science-pipelines-operator-controller-manager:
        resources:
          requests:
            cpu: 100m
            memory: 128Mi
          limits:
            cpu: 200m
            memory: 256Mi
    kserve:
      managementState: Removed
    modelmeshserving:
      managementState: Managed
      odh-model-controller: <3>
        replicas: 1
        image: quay.io/vajain/odh-model-controller:2.0 <4>
      modelmesh-controller:
        replicas: 1
      devFlags:
        manifests:
          contextDir: config
          sourcePath: ''
          uri: 'https://github.com/opendatahub-io/odh-model-controller/tarball/main'
    ray:
      managementState: Removed
    workbenches:
      managementState: Managed

1 - The dashboard component today only deploys a single set of pods but by setting these options under spec.dashboard.dashboard we give ourselves more flexibility if the Dashboard chooses to add additional pods in the future as part of the Dashboard component.
2 - This autoscaling configuration is based on how ArgoCD handles setting up Autoscaling for it's components.  I know RH has an aversion to "true/false" values in the CRD so that could be changed or maybe even just the presence of the autoscaling/hpa sections is enough to infer that we want it enabled.  HPA could potentially be moved up to spec.dashboard.dashboard.hpa but I think keeping it under autoscaling probably gives us more flexibility in the long run.  For example the controllers may benefit from having an option to setup VPA in the future.
3 - The modelmeshserving component is a good example of something that deploys multiple sets of pods with odh-model-controller and modelmesh-controller.  We need to be able to control these independently so having the pattern of spec.<component>.<deployment> like with the dashboard makes a lot of sense here.
4 - Including the image here was always what I imagined before the devFlag idea was introduced.  We could set this same value under spec.modelmeshserving.devFlags.odh-model-controller.image as well but it seems like a lot of redundant structure to the object.  I don't think anyone will question that we aren't going to support a custom image that they built themselves though.

@strangiato

If we want ant move to a unique object per component we should do away with the DSC entirely and only have unique objects for each component. Mixing the two is just going to cause confusion on "what should I set where?".

Same thought came to me as well to completly remove the DSC and ony define independent object for each component but  earlier restrict my self because it would be a big architectural change. But I belive this is the cleaner way of doing it. WDYT?

modelmeshserving:
managementState: Managed
odh-model-controller: <3>
replicas: 1
image: quay.io/vajain/odh-model-controller:2.0 <4>
modelmesh-controller:
replicas: 1
devFlags:
manifests:
contextDir: config
sourcePath: ''
uri: 'https://github.com/opendatahub-io/odh-model-controller/tarball/main'

I have been thinking about this part:
modelmeshserving:
      managementState: Managed
      odh-model-controller: <3>
        replicas: 1
        image: quay.io/vajain/odh-model-controller:2.0 <4>
      modelmesh-controller:
        replicas: 1
      devFlags:
        manifests:
          contextDir: config
          sourcePath: ''
          uri: 'https://github.com/opendatahub-io/odh-model-controller/tarball/main'

if user prefer using devFlags, why would they set 2 deployments odh-model-controller and modelmesh-controller?
it would be much easier to config whatever they want(image, replica, resources etc) in the remote tarball in one go.
so the question is,  if the difficulty of using devFlags becomes a hinder which starts to introduce other options, then maybe we should not even keep devFlags, instead of having ".deployment." only (deploymentX will be provided in an official way so the users know what exactly to put there)
something like:
modelmeshserving:
      managementState: Managed
      deployments:
        odh-model-controller:     // need to set to exact name to match whats been deployed in the cluster, or it wont work
           image: quay.io/my/image1:tag
           resources:
              requests:
                 cpu: 100m
                 memory: 128Mi
              limits:
                 cpu: 200m
                memory: 256Mi
        modelmesh-controller:         // if the deploymentX does not contains "controller" then replica value will be valid
           image: quay.io/my/image2:tag
           replica:  2         // here will fall back to 1 since it is a controller
           .....

I have been thinking about this part:
modelmeshserving:
      managementState: Managed
      odh-model-controller: <3>
        replicas: 1
        image: quay.io/vajain/odh-model-controller:2.0 <4>
      modelmesh-controller:
        replicas: 1
      devFlags:
        manifests:
          contextDir: config
          sourcePath: ''
          uri: 'https://github.com/opendatahub-io/odh-model-controller/tarball/main'

if user prefer using devFlags, why would they set 2 deployments odh-model-controller and modelmesh-controller? it would be much easier to config whatever they want(image, replica, resources etc) in the remote tarball in one go.
so the question is, if the difficulty of using devFlags becomes a hinder which starts to introduce other options, then maybe we should not even keep devFlags, instead of having ".deployment." only (deploymentX will be provided in an official way so the users know what exactly to put there) something like:
modelmeshserving:
      managementState: Managed
      deployments:
        odh-model-controller:     // need to set to exact name to match whats been deployed in the cluster, or it wont work
           image: quay.io/my/image1:tag
           resources:
              requests:
                 cpu: 100m
                 memory: 128Mi
              limits:
                 cpu: 200m
                memory: 256Mi
        modelmesh-controller:         // if the deploymentX does not contains "controller" then replica value will be valid
           image: quay.io/my/image2:tag
           replica:  2         // here will fall back to 1 since it is a controller
           .....

@andrewballantyne @etirelli  thoughts on this?

We need the tarball manifest uri -- this is key to overriding everything. The image is a QoL as an often use-case is "I want everything standard, but I want my PR's custom image, or some feature built image ... so you have to fork and make a new manifest file. This is more hinderance to nightly images and things that are quickly updated than it is for pinned releases and updates.
I agree with Trevor, we should probably not look to bloat it up high -- but as I noted in the AC, devFlags have a lot of value and removing them is not a great idea imo. If we don't want to expand it, it is a flexible mechanism for it not to be a blocker going forward.

@AjayJagan I agree with Trevor's points, except for having the image outside of devflags. The purpose of devflags is to allow developers like us to have the flexibility of overriding settings during the development cycle, without confusing users about what they should or should not use. Overriding an image is not something I expect users should ever do.

@andrewballantyne @etirelli thanks for clarifying again. So we stick to the devFlags idea and may be iteratively incorporate Trevor's idea(apart from the images)... wdyt @zdtsw ?

If I understand @AjayJagan you correctly:
2 valid configurations for devFlags ?
(for example 1)
modelmeshserving:
      managementState: Managed
      devFlags:
        odh-model-controller:     // need to set to exact name to match whats been deployed in the cluster, or it wont work
           image: quay.io/my/image1:tag
           resources:
              requests:
                 cpu: 100m
                 memory: 128Mi
              limits:
                 cpu: 200m
                memory: 256Mi
        modelmesh-controller:         // if the deploymentX does not contains "controller" then replica value will be valid
           image: quay.io/my/image2:tag
           replica:  2         // here will fall back to 1 since it is a controller
           .....

and example 2 (as what we are having already) :
modelmeshserving:
      managementState: Managed
      devFlags:
        manifests:
          contextDir: config
          sourcePath: ''
          uri: 'https://github.com/opendatahub-io/odh-model-controller/tarball/main'

@andrewballantyne @etirelli thanks for clarifying again. So we stick to the devFlags idea and may be iteratively incorporate Trevor's idea(apart from the images)... wdyt @zdtsw ?

If I understand @AjayJagan you correctly: 2 valid configurations for devFlags ? (for example 1)
modelmeshserving:
      managementState: Managed
      devFlags:
        odh-model-controller:     // need to set to exact name to match whats been deployed in the cluster, or it wont work
           image: quay.io/my/image1:tag
           resources:
              requests:
                 cpu: 100m
                 memory: 128Mi
              limits:
                 cpu: 200m
                memory: 256Mi
        modelmesh-controller:         // if the deploymentX does not contains "controller" then replica value will be valid
           image: quay.io/my/image2:tag
           replica:  2         // here will fall back to 1 since it is a controller
           .....

and example 2 (as what we are having already) :
modelmeshserving:
      managementState: Managed
      devFlags:
        manifests:
          contextDir: config
          sourcePath: ''
          uri: 'https://github.com/opendatahub-io/odh-model-controller/tarball/main'

So the resources and replicas are planned to be moved out of devFlags. Only the image field will remain as part of the devFlags.
And I think there should be 2 configurations
1 - The manifest URI
2 - The image(direct update)

Could we please create a seperate ADR to followup on images part

In our last OpenShift AI - Architecture Council meeting we had some consensus that maintaining separate CRDs for each component would be a viable way to tackle current challenges. So to avoid polluting the current ADR I had started the discussion thread on slack to raise this point.
https://redhat-internal.slack.com/archives/C05KDB2HFQQ/p1705989784479989

It would be great to use e.g. GitHub discussions instead of internal channels if we want to keep this open to the community.

@LaVLaS I have updated the ADR with the changes haveing 1:1 mapping between the subcomponent names & the deployment. Please let me know if this looks fine :)

Splitting this ADR to get more focussed reviews for configuring resources - https://github.com/opendatahub-io/architecture-decision-records/pull/32


Items draggable over "fixed" items

I have a list with many items in it. The first two items and the last item are set as not sortable.
It's possible to drag the, say, 12th item above the first of second item.
Is there some way to prevent items being dropped above the not sortable items? Or is there some way I can send the item back after the second item without me needing to manipulate the DOM directly?

Hey @ap-prog sadly no.
The only idea would be to capture the events and check the items position. If the first item is not first anymore you could set it to the beginning of the list.
I have currently no idea of how to change the plugin to allow for this behaviour without breaking other behaviours, but if you find a way, let me know and maybe you could send a PR.
You can of course add the first item in a separate list that is not a sortable, if that works for your case.

I tried capturing events but it turned out to be to much effort. Instead I've nested a list as you suggested and that does what I need. Thanks.


nixos-14.12 release branch hasn't updated in 12 days

The channel https://github.com/nixos/nixpkgs-channels/tree/nixos-14.12 is at commit<PHONE_NUMBER>b3e15e2121365f067c1c8c56bb4722 from May 8th.

@aszlig chromium is failing: http://hydra.nixos.org/build/22414128
misc tests also fail, it's probably transient: http://hydra.nixos.org/build/22439184

@domenkozar: Thanks, going to throw more OCR at it :see_no_evil:

The channel is on yesterday's commit times now.

@vcunat, huh? The channel seems to be at bc4f18506cfad0564da1b7958ba3bb0206499233, according to https://github.com/nixos/nixpkgs-channels/tree/nixos-14.12.

That's the latest commit in 14.12:
https://github.com/NixOS/nixpkgs/commits/release-14.12
On Tue, Jun 9, 2015 at 2:52 PM, Peter Simons<EMAIL_ADDRESS>wrote:

@vcunat https://github.com/vcunat, huh? The channel seems to be at
bc4f185
https://github.com/NixOS/nixpkgs/commit/bc4f18506cfad0564da1b7958ba3bb0206499233,
according to https://github.com/nixos/nixpkgs-channels/tree/nixos-14.12.
—
Reply to this email directly or view it on GitHub
https://github.com/NixOS/nixpkgs/issues/8059#issuecomment-110347494.

Ah, okay. I was confused because that commit "was authored 24 days ago". Now I see it's the latest. Thanks!

That's because cherry-picking preserves authoring time, but still it gives new commiting time.


Day-night extraction over multiple days

When trying to run multiple days at once, I get the error message:

|............................................                     |  68%
label: extract_get_day_and_night
Quitting from lines 265-275 (vp-processing.Rmd)
Error in mutate_impl(.data, dots) : Not a vector
Calls:  ... mutate -> mutate_ -> mutate_.tbl_df -> mutate_impl -> .Call
In addition: Warning messages:
1: In (function (...)  : Vertical profiles are not from a single radar
2: In bind_rows_(x, .id) : Unequal factor levels: coercing to character

So, probably something going wrong with the "date-of-dusk" when there are multiple dates involved?

Yeah, that code wasn't really tested. 😬 Can you mail me a small example dataset that spans multiple days?

For reference, this line was causing the error:
mutate(latitude = settings$radars[[radar_id]]$latitude) %>%

This is my understanding of the bug: for a single date, only one radar_id was referenced. But if there were multiple dates, a vector of (identical) radar ids (e.g. c("nldbl", "nldbl") would be referenced from the settings, which would break.
This can be solved by creating a dataframe from the settings, with one row for each radar. We then join that info. Haven't completely done that yet (and there's still another bug), but at least I know what is causing it. 😌


docs(start): add options wrapper e starter branch

@brandyscarney  When you are on a time available and can review ;)

Hey @ramonornela! Thank you so much for the PR! We're actually not going to display these flags because they're really for our internal testing and we don't want to confuse anyone. We really appreciate it though!


add: 3 clients interacting with a server that uses a postgres database

Disclaimers:

This is closed
It's not the original project remote history sorry 🤷

Reasons:

I screwed it up, so i skipped directly to step 5

Nice


feat: pomelo username types

Add types for Pomelo usernames (the new unique usernames) and display names.
display_name is marked as deprecated in favor of global_name

Cool thank you!

Published in @ 1.4.4


ui/ux: JSON view suggestions

Hello! I have a few nitpicky complaints about the UI/UX for json view, which will improve the quality of life of the user.
with JSON view enabled there is no slider, so I often have to strech the window over multiple monitors to be able to view both sides when dealing with long values.
Along with this, the keys get condensed which isn't very pleasing on the eyes.

I'm not sure what causes this, but there is only about 1-2 pixels where I can select the slider so it isn't always easy.

If possible, I think it'd be best if the slider is easier to select and JSON view also has a slider if it's longer then the window's width.
Let me know what you think!

Hey, thanks for pointing out. The JSON rendering is from another package but the scroll mbar stuff should be possible to address. However I most likely won't have time in upcoming few weeks. Fell free to open a PR with a fix if you're able to. If not I'll check when I'm back.

yooooo W


[Boosty.to] It is possible to download with a parser update.

DO NOT REMOVE OR SKIP THE ISSUE TEMPLATE

[X] I understand that I will be blocked if I intentionally remove or skip any mandatory* field

Checklist

[X] I'm reporting a new site support request
[X] I've verified that I'm running yt-dlp version 2023.10.13 (update instructions) or later (specify commit)
[X] I've checked that all provided URLs are playable in a browser with the same IP and same login details
[X] I've checked that none of provided URLs violate any copyrights or contain any DRM to the best of my knowledge
[X] I've searched known issues and the bugtracker for similar issues including closed ones. DO NOT post duplicates
[X] I've read the guidelines for opening an issue
[ ] I've read about sharing account credentials and am willing to share it if required

Region
Global
Example URLs

Single post https://boosty.to/asmr.camp/posts/097bc7c4-ec51-44d2-9649-f9bb4b8dc98a

Provide a description that is worded well enough to be understood
I have no knowledge of how does ytdlp parses a web page, below is my findings and assumptions. In order to download any boosty post the YT-DLP requires following:

Find the "

Duplicate of #5900


Unable to override tsconfig.compilerOptions.moduleResolution

Current Behavior

If I want to use moduleResolution as node16, currently tsdx ignores what is specified in tsconfig and uses legacy module resolution. This causes typescript errors.
The particular feature that I want to use is package.json exports. For this to work, the moduleResolution should be set to node16. By setting this, typescript errors in vscode disappear, however tsdx build does not succeed (and the error that it gives is similar to what vscode gives without node16 moduleResolution).
Example error:
(typescript) Error: /my/project/src/file/path.ts(5,34): semantic error TS2307: Cannot
find module 'ethers/address' or its corresponding type declarations.

Here, ethers is a package, and address is defined as an export in it's package.json.
Expected behavior

It should build.
Suggested solution(s)

Additional context

Your environment

  System:
    OS: macOS 12.0.1
    CPU: (8) arm64 Apple M1
    Memory: 134.91 MB / 16.00 GB
    Shell: 5.8 - /bin/zsh
  Binaries:
    Node: 16.17.1 - ~/.nvm/versions/node/v16.17.1/bin/node
    Yarn: 1.22.19 - ~/.nvm/versions/node/v16.17.1/bin/yarn
    npm: 8.15.0 - ~/.nvm/versions/node/v16.17.1/bin/npm
  Browsers:
    Chrome: 109.0.5414.119
    Firefox: 89.0.1
    Safari: 15.1
  npmPackages:
    tsdx: ^0.14.1 => 0.14.1
    typescript: ^4.6.3 => 4.8.3
  npmGlobalPackages:
    typescript: 4.8.4

It seems this issue is caused in rollup-plugin-typescript2. The user's tsconfig is overridden and moduleResolution is set to legacy node resolution (relevant code).
I've locally tried to patch this. However, the build gets stuck forever. There may be a reason why this is overridden.
I've created an upsteam issue https://github.com/ezolenko/rollup-plugin-typescript2/issues/437.


Ensure distance is greater than 0 in CameraMoveToTarget

Hello! This fixes the distance check in CameraMoveToTarget to avoid a 0 value. Thank you!

@kolunmi thanks for the review!


Change format based on script output

Is it possible to change, say format-underline for a module, based on the output from a custom script?
I thought it would be possible by using raw tags, but I can only find raw tags for foreground and background and not much else in the documentation.

You can use %{U#rrggbb +u}underlined text%{-u} for example.

Awesome, thank you!


Style::MultilineLiteralBraceLayout fixed: ignore single-line nodes

The style has had a behavior conflicting with its name.

The style has had a behavior conflicting with its name.

More details, please. :-)

It was not ignoring single-line literals as it should have been doing, cause this spec is only for multi-line literals, according to its name.

Looks good, but you need to add a changelog entry.

fixed here - https://github.com/alexdowad/rubocop/commit/7ec472baa852edc83b77454a577ae35bdbf4623c


ResultProperties: Added keywords for CCSD quantities.

Added keywords for CCSD quantities. Is this all that needs to be done? Or does the qc_schema also need to be updated?

I think this should a PR to QCSchema first. A few of those quantities will need string explanations with them and there will be some feedback there I am guessing.

I have made a PR to QCSchema for the CCSD quantities (https://github.com/MolSSI/QCSchema/pull/61).

This should be good to update.

So I have added the CC keywords to QCElemental. Should I also go ahead with the renaming of mp2_total_correlation_energy to mp2_correlation_energy?

Should I also go ahead with the renaming of mp2_total_correlation_energy to mp2_correlation_energy?

yes, please. any and all changes to make qcel agree with the qcschema PR.

Okay I've updated the mp2 to match the QCSchema PR. Presumably this will cause some problems in other parts of the QCArchive.

I'm happy to leave as is and add in more in later rounds. So to clarify do I need to add a line for the current PR to https://github.com/MolSSI/QCElemental/blob/master/docs/source/changelog.rst ?

Lets leave it as is, but snip off everything after CCSD(T). The changeling line would be great!

Okay so snip out stuff after CCSD(T) here in results.py but leave those quantities in QCSchema? And great I'll add a line.


[Commerce] Sticky sidebar

Ensure sidepanels on wider viewports are fixed to the top whilst the page scrolls.
Potentially a fix for #432 ?

Merge conflicts addressed.


Use different pressure value for vacuum start/stop

Upstream is changed.
https://github.com/iory/rcb4/pull/74

Simple picking and stowing demo.
Adsorption is turned on and off by clicking on AtomS3.
https://github.com/user-attachments/assets/02837939-7fc9-4a85-b150-7cbf8b6ae995