post on zoom forums

Awesome work on the bot! If/when you think it's ready to reach a larger audience, here's a good place to post (this is how I found otto)... I think lots of ppl are looking for something close to this: https://devforum.zoom.us/t/breakout-rooms-api/4255

I saw that thread too! And was also bummed!
It's a dev forum so I'll just post it there. No way it can spiral out of control!

https://devforum.zoom.us/t/breakout-rooms-api/4255/91?u=nelsonjchen


Improved theme settings support

Bug/issue #, if applicable: 97040358
Summary
This PR updates the existing support for the theme-settings.json file to be more fully featured and capable. This is the Swift-DocC-Render implementation support for my recent forum proposal titled
Customizing the look and feel of Swift-DocC-Render.
Major Changes:

removed default theme-settings.json file since it only existed for pseudo documentation purposes (full OpenAPI spec will be created for Swift-DocC as well as conceptual docs)
fixed bugs with overwritten colors not working right when switching between Light/Dark/Auto modes
added support for global border-radius override
added support for overriding content and code font stacks
added support for overriding builtin SVG icons
added support for overriding component specific borders of the following elements

asides
badges
buttons
code listings

added some new colors to make it easier to customize the follow elements:

buttons
documentation intro
tutorials overview page

added support for customizing outer border radius of step elements
all supported properties of the theme-settings.json file should be specified here (will open PR on Swift-DocC for this soon)

More documentation PRs will be created for the swift-docc repo next to guide users on how to utilize this file.
Dependencies
https://github.com/apple/swift-docc/pull/339 (already merged to Swift-DocC main)
Testing
Steps:

From this branch, run npm run build to build this branch of swift-docc-render
Checkout swift-docc and pull the latest main branch
Extract the example theme-settings.json file and custom article.svg icon from files.zip and copy them into the top level of the documentation catalog for SwiftDocC at Sources/SwiftDocC/SwiftDocC.docc
From the swift-docc repo, run env DOCC_HTML_DIR=/path/to/swift-docc-render/dist bin/preview-docs SwiftDocC
Open http://localhost:8000/documentation/swiftdocc and check that the theme settings are applied as expected
Play around with your own settings and check that there are no regressions if there are no theme settings provided

Checklist
Make sure you check off the following items. If they cannot be completed, provide a reason.

[X] Added tests
[X] Ran npm test, and it succeeded
[X] Updated documentation if necessary

@swift-ci test

Awesome work Marcus, just a few questions:

Would we keep the old --colors vs --color naming convention? I think --colors used to come from the initial version of the theme-settings? Or are we just deprecating that for now, without removing support?

From an API point of view, I think it should be considered unofficially deprecated. Since none of the implementation for it has been changed, things should continue to work if the plural form is used in the cases where it was previously being used, although ideally those clients using the old form could very simply adopt to the new version. Going forward, I think the singular form would be documented as the correct API. (I went with that version only because it has a 1-1 correlation with the actual CSS property names.)

I've opened a PR on DocC that adds an API reference for theme-settings.json and a conceptual article to walkthrough examples of using the file: https://github.com/apple/swift-docc/pull/359

@swift-ci test

@swift-ci test

@swift-ci test


Rebar3 build

moved to rebar3
changed otp versions to more fresh

Hey, @comtihon. I'm not sure this repo. is still active.

Hey, @comtihon. I'm not sure this repo. is still active.


[Bug] App is crashing when launched

Unity editor version: 2020.3.22f1___
Firebase Unity SDK version: 9.0.0___
Source you installed the SDK: _.unitypackage (.unitypackage or Unity Package Manager)
Problematic Firebase Component: _Storage (Auth, Database, etc.)
Other Firebase Components in use: Auth, Database_ (Auth, Database, etc.)
Additional SDKs you are using: _____ (Facebook, AdMob, etc.)
Platform you are using the Unity editor on: Mac_ (Mac, Windows, or Linux)
Platform you are targeting: iOS_ (iOS, Android, and/or desktop)
Scripting Runtime: IL2CPP_ (Mono, and/or IL2CPP)
Pre-built SDK from the website or open-source from this repo: _____

Application is working fine when debugging (running ) using Xcode. but when launch from device without xcode attached. app is keep on crashing. I managed to get the error from console application.
Error loading /var/containers/Bundle/Application/82904F4D-D348-4C96-8757-4813BDDDCCAA/CrashCheck.app/Frameworks/UnityFramework.framework/UnityFramework:  dlopen(/var/containers/Bundle/Application/82904F4D-D348-4C96-8757-4813BDDDCCAA/CrashCheck.app/Frameworks/UnityFramework.framework/UnityFramework, 0x0109): code signature in (/private/var/containers/Bundle/Application/82904F4D-D348-4C96-8757-4813BDDDCCAA/CrashCheck.app/Frameworks/UnityFramework.framework/Frameworks/libswift_Concurrency.dylib) not valid for use in process: mapped file has no cdhash, completely unsigned? Code has to be at least ad-hoc signed.
Create New Project Unity Editor version 2020.3.22f1
Download firebase_unity_sdk_9.0.0
Add FirebaseAuth.unitypackage from dotnet4 folder
Add FirebaseStorage.unitypackage from dotnet4 folder
Now build for iOS, run iOS project from xcode.
Now run from the mobile device directly, app keeps crashing.

Hi @FazalConsoliads,
Could you confirm if the issue persists when the app is built using an updated version of the Unity editor (Unity 2020.3.35f1 is the latest LTS version)? If so, please provide the Xcode version you're using as well as the details pertaining to the device you've tested (such as its iOS version or if it's a simulator).


Update mauve-sim to account for final workflow

Change p2plex to enable listening on channel and filtering incoming by key
Change hosterAddFeed to download instead of request encoding
Add encoder public key to hosterAddFeed, use to generated shared channel
Add event to hoster for notifying chain when it's got an encoded chunk
Have encoder generate shared channel to send data through
Update mauve-mvp with new flow, have chain choose encoder and hoster and notify them

@ninabreznik:

Emit shared event (pubKeys of selected hosters and pubKeys of selected encoders)
Encoding
Joining the swarm (swarmkey derived from hoster-encoder pubKeys => shared channel)
Hoster notifies chain that they are done


chore: run golangci-lint action for all code independently of changes

Description
We run the golangci-lint linter in our local developments and in our main branch against all code and not only against new changes. This PR updates the golangci-lint action to run the linter for all code to match the behavior in all environments.
Verification Steps
PR checks pass

Checklist (Definition of Done)

[ ] All acceptance criteria specified in JIRA have been completed
[ ] Unit and integration tests added that prove the fix is effective or the feature works (tested against emulated and non-emulated OCM environment)
[ ] Documentation added for the feature
[ ] CI and all relevant tests are passing
[ ] Code Review completed
[ ] Verified independently by reviewer
[ ] All PR comments are resolved either by addressing them or creating follow up tasks
[ ] Required metrics/dashboards/alerts have been added (or PR created).
[ ] Required Standard Operating Procedure (SOP) is added.
[ ] JIRA has been created for changes required on the client side

thanks @miguelsorianod !


⚠ Bofrost.be has degraded performance

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

HTTP code: 200
Response time: 1373 ms

Resolved: Bofrost.be performance has improved in 77eb646.


Docker-compose failing startup

@rripken and @ktarbet were having issues getting the docker-compose to startup in their development environments. The specific errors can be added to the description or as comments.

15-Nov-2023 17:41:22.005 SEVERE [http-nio-7000-exec-1] cwms.cda.security.OpenIDAccessManager. Unable to initialize realm.
data-api_1                | 	java.net.ConnectException: Connection refused (Connection refused)
data-api_1                | 		at java.net.PlainSocketImpl.socketConnect(Native Method)
data-api_1                | 		at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)

@MikeNeilson  Thanks for pointing me to networking.
The instructions say:
Add <real host ip> cwms-data.localhost auth.localhost traefik.localhost to the /etc/hosts file
So instead of <IP_ADDRESS>  I  used <IP_ADDRESS>  in /etc/hosts
<IP_ADDRESS> is my Private IP,  and I can now see the swagger UI!

It would be good to figure out a way to not need to do that, but given how just utterly picky some of those services are about URLs and docker with address I'm not sure we can.

Perhaps a bigger font could help future users though.

I have a PR here to warn about <IP_ADDRESS> : https://github.com/USACE/cwms-data-api/pull/466

Closing this issue - docker compose is working for me -- below is my writeup.
https://github.com/USACE/cwms-data-api/wiki/How-to-use-Docker‐compose-with-a-windows-Client


[movies] UI to remove list

When hovering/focusing a list in /my-lists, show a little (X) button that removes the list.

the button isn't working for me 🙈 and vercel crashes. https://h0-movies-demo.vercel.app/login

Thanks, it's working.
If I understood correctly, we want to add a X button to delete the list from the account. I have a doubt regarding it.
Is it a tentative solution? Because if we are copying (https://tastejs.com/movies/), we can make the /my-lists show all the lists. Similar to https://next-movies-zeta.vercel.app/my-lists?page=1 and then build /list, /list/add-or-edit, and so on.

Thanks, it's working.
If I understood correctly, we want to add a X button to delete the list from the account. I have a doubt regarding it.
Is it a tentative solution? Because if we are copying (https://tastejs.com/movies/), we can make the /my-lists show all the lists. Similar to https://next-movies-zeta.vercel.app/my-lists?page=1 and then build /list, /list/add-or-edit, and so on.

Sorry, I actually mixed two ideas... The (x) was to remove a movie from the list.
Yea, please use the nextjs app as a UI spec for now.


arch: boards: Add support for i.MX RT1052 SoC and development board

Adds support for the new i.MX RT1052. This initial port includes only essential drivers (uart and gpio) to enable the hello_world and basic/blinky samples; additional drivers will come later.

Moved change to jlink.py. @mbolivar

Seems reasonable. The original order was copied from the shell script, but this looks better. Has it been tested on boards with permanent flash?

Has it been tested on boards with permanent flash?

Yes, I tested on frdm-k64f

Has it been tested on boards with permanent flash?
Yes, I tested on frdm-k64f

No objections from me, thanks!

Addressed @dbkinder's doc comments, fixed an incorrect link to the board schematic, and rebased to the latest arm branch.

Updated for cmake


[Enhancement] add support for late materialization in paquet reader

What type of PR is this：

[ ] bug
[ ] feature
[x] enhancement
[ ] refactor
[ ] others

Which issues of this PR fixes ：
Fixes #
Problem Summary(Required) ：
When reading a parquet column chunk:

Read columns data with filter predicates.
Filter the read result and save selected row indices.
Read other columns, and filter page with the selected row indices returned before.  Read page header and check whether some selected rows exists in current page, if no one, skip it.
Merge the result data returned by step 1 and step 3.

Some performance benchmark report will be added here later.
Perf Test：
Use following queries on tpch_100g
-- l_suppkey is not prefix key, so there is a lot parquet read.
-- Q01. for tpch-100g, there are 574 rows.
select l_orderkey, l_partkey, l_suppkey, l_linenumber from lineitem where l_suppkey = 768951;

-- Q02. for tpch-100g, there are 574 rows.
select l_orderkey, l_partkey, l_suppkey, l_linenumber, l_quantity, l_extendedprice, l_discount, l_tax, l_returnflag, l_linestatus from lineitem where l_suppkey = 768951;

-- Q03. for tpch-100g, there are 574 rows.
select * from lineitem where l_suppkey = 768951;

-- l_orderkey is prefix key, so parquet read is less
-- Q04. for tpch-100g, there are 6 rows.
select l_orderkey, l_partkey, l_suppkey, l_linenumber from lineitem where l_orderkey = 575233123;

-- Q05. for tpch-100g, there are 6 rows.
select l_orderkey, l_partkey, l_suppkey, l_linenumber, l_quantity, l_extendedprice, l_discount, l_tax, l_returnflag, l_linestatus from lineitem where l_orderkey = 575233123;

-- Q06. for tpch-100g, there are 6 rows.
select * from lineitem where l_orderkey = 575233123;

-- Q07
-- predicates on lineitem is only l_orderkey > 0, which means have to scan all rows
select * from supplier join lineitem on s_suppkey = l_suppkey where s_name = 'Supplier#000768951' and l_orderkey  > 0;

As the late materialization performance may be effected by coalesce read, so we test in different situations.

parquet_coalesce_read_enable=false

Query
Disable LM
Enable LM

Q01
6548
6173

Q02
22574
5246

Q03
44310
7078

Q04
1051
1155

Q05
2385
1341

Q06
5157
1384

Q07
48747
11147

parquet_coalesce_read_enable=true

Query
Disable LM
Enable LM

Q01
2597
2535

Q02
12238
9065

Q03
21311
17099

Q04
838
861

Q05
1485
1595

Q06
2913
2367

Q07
25214
23964

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.Gavin seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.

plz add more stats number. eg, how much page skipped, how much row group skipped...


wayyyyy to much padding guys

Just asking to reduce padding in messages.

Any particular examples that would help illustrate the problem here? I may do some visual tweaks soon so it would be helpful to see what you're seeing.

I do a lot of web dev, so even though I have a monster monitor, every square inch very precious, because I always need multiple tools open. So, I just need the chat to take up less space.
Right now, each message has a ton of padding top and bottom, and it also shows my name, which is redundant information. Also, the font size is big...

Just because of the nature of the tool, I going to be sending a receiving a lot of long messages containing code snippets. Because so much vertical space is devoted to padding and username/profile pic, I can only really see one or two question/response pairs in the chat.

I would rather use copilot chat because I've already payed for a subscription, but I may end up using the ai in Warp terminal just its use of vertical space is so much more economical.

I'm not saying this is the worst thing ever or anything--just I would be happier as a user if the copilot chat widget were a more responsible consumer of screen space.

Compact mode :)

Sorry, I'm seeing much fatter margins in Warp and a very large empty space at the bottom... you're saying that UI is more efficient?


More concrete examples for ConfidentialClientApplicationBuilder

A complete example for ConfidentialClientApplicationBuilder would be much more useful. Even an ARM template to create an app registration, the code that goes with and a couple of code examples would be very useful coming from Microsoft. To be able to use this feature we relied on several posts to make it work and none of them came from Microsoft.
Thank you

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

ID: 9686ad69-398c-d6ab-f12c-eef02eca0a05
Version Independent ID: cdaea9ec-7edb-e787-07a0-ff4087a45d67
Content: Instantiate a confidential client app (MSAL.NET) - Microsoft Entra
Content Source: articles/active-directory/develop/msal-net-instantiate-confidential-client-config-options.md
Service: active-directory
Sub-service: develop
GitHub Login: @Dickson-Mwendia
Microsoft Alias: dmwendia

@happyiphone
Thanks for your feedback! We will investigate and update as appropriate.

Hi @happyiphone, thanks for opening this issue and helping us to improve our developer documentation.
First, my apologies that you were not able to figure out how to build/configure a confidential client application using the guidance on our docs.  Here are a few resources that will help:

ASP.NET tutorial series - https://learn.microsoft.com/en-us/azure/active-directory/develop/web-app-tutorial-01-register-application
MSAL.NET API reference - https://learn.microsoft.com/en-us/dotnet/api/microsoft.identity.client.confidentialclientapplicationbuilder?view=msal-dotnet-latest
Our Microsoft identity platform samples page has example applications using MSAL and our authentication SDKs.

In case you're still having trouble, please share the scenario you're working on (app type and platform/language) and I will help you out.
Thanks!

@happyiphone I'll go ahead and close this issue. However, do not hesitate to reach out in case you run into issues using our Microsoft identity platform and MSAL documentation.
Thanks!

#please-close


not working features for FloatSlider widget

value isn't returned

not working features:

slider_color
continuous_update
visible

The problem seems to be connected to ipywidgets implementation changes of FloatSlider.
The FloatSlider still has the deprecated slider_color property that is not used anymore.
While the IntSlider has the new style property that supposed to work now.
To change the slider color use eg. fs.style.handle_color = 'lightblue' (the demo file needs updates);


fixed some clippy warnings

Mostly small readability things, the code is already quite good :+1:

Thanks for that, definitely going to have to start using clippy in future :+1:

My pleasure. :slightly_smiling_face:


Cannot use lava/water eggs in tanks

Issue Description:
I play with a custom (1.12.2) modpack that includes the chickens mod, more chickens, hatchery, and some tech mods like ender io, tinkers, and thermal expansion. I recently noticed that I cannot get the lava eggs to go into any sort of tank as they did in 1.10.2, and cannot find any information online regarding this issue. The only thing I can do with the egg is right click the ground to make a lava source block, but the egg cannot be used as a fuel source anymore. I am not sure if this has been changed, but I was really excited to use the lava eggs as they are much easier to deal with than the lava buckets themselves.
Steps to reproduce (important):

Right click tank (ender io, tinkers, thermal expansion, etc.) with egg in hand (OR)
Shift-click egg into tank GUI (OR)
Drag and drop egg into tank GUI
...

What happens:
The egg will not fill the tank with lava nor will the tank accept the egg. When you right click the tank with the egg, it simply opens the GUI. When you shift click or drag the egg into a slot, the tank doesn't accept it.
What you expected to happen:
The tank fills with lava from the egg, as it did in 1.10.2

Affected Versions (Do not use "latest"):

Chickens: 6.1.0v, 6.0.4v, 6.0.3v, 6.0.2v (all versions for 1.12.2)
Minecraft: 1.12.2
Forge: <IP_ADDRESS>29

I think this is an issue to do with the IFluidHandlerItem not being implemented with those eggs. While it seems to have been fixed in the code, until the mod is updated there's not much that can be done.
If you have other mods, you can make a work around with some kind of mechanical user using the eggs with a fluid collector picking up the lava/water.

I'll look into it.. the fix should have been live a while back ago. but I will check it out.

Thanks. I know I have the latest version of chickens mod, but putting lava/water eggs directly into tanks/machines in other mods still isn't working. Even using the the tank or machines GUI will not work.

yeah its not live yet.. not sure why I didn't get that build finished. Im looking at pushing out a couple of mods soon, this will be in the batch that's updated.

Still having this issue in August of 2019. Was there any forward movement on this?


Flashes of Unstyled Content (FOUC) errors

Example URL(s)
All pages
Actual Behavior
We're seeing flashes of unstyled content when loading pages in dev docs.
This applies to all pages (home / non-home layouts).
https://user-images.githubusercontent.com/26727299/222509752-3f495629-a0fe-47ac-852b-555b090bbef5.mov
Expected Behavior
For this not to happen?
Additional information
There are two versions of style.css loading, both a hashed and unhashed version. Not sure if that's related?
You can see it clearly when you disable cache + throttle your network connection to Slow 3G.
Seems to have been introduced with #7580.
Tested a few fixes in #7820 #7776 #7775, but none of them seemed to work.

This is an odd one. Having looked into it, although it's pretty difficult to reproduce (in particular, it helpfully doesn't reproduce in dev mode), it seems like elements with transitions are somehow having their default state applied on page load, resulting in a run of their transition on page load (which explains the padding transition in the content, as well as the site title colour transition). This doesn't seem to happen in Firefox, and appears to be a Chrome bug/optimisation (CSS in the head should be render blocking, but doesn't appear to always be for transitions).
I'd like to investigate this more to isolate whether it is actually a Chrome bug, but in the meantime the fix is fairly simple; CSS rules with transitions should be moved to inline styles. I'll open a PR tomorrow for that.
As to why this is happening more now, I think this is because the early hints header is being manually set in a _headers file. This bug is intermittent, and much more prevalent on slower networks/when the styles aren't cached, which I think increased when the new Vite additions were merged, in which I inadvertently broke early hints. That's just a hypothesis though, I'm not super sure on that.

For whatever reason, this appears to be less of an issue lately.


Quick info for abstract class names/methods do not inform the user of abstractness

this looks like the same behavior as C# and VB. would like to keep the experience as close as we can,

Perhaps Roslyn should inform the user of abstractness as well. @CyrusNajmabadi any thoughts?

@DanielRosenwasser can you log a https://github.com/dotnet/roslyn issue for this.

Tracking this at https://github.com/dotnet/roslyn/issues/5739.


SLING-6592 introduce "Content" interface instead of nested maps

closing this one, it's superseded by #203


add exponential linear units activation layer

see Fast and Accurate Deep Network Learning by Exponential Linear Units (ELUs)

Looks good to me.

+1
Damn your fast...

btw, why a layer and not just an activation? or why not both? ELU doesn't have any state to require an entire class for it. Also, this way you can't use ELU inside RNNs for instance. Could you see https://github.com/fchollet/keras/pull/1083 ?


using orf as input fasta for mmseqs easy-taxonomy

Hi, just a direct question that when the ORF fasta files (predicted by prodigal) is the input file with easy-taxonomy (MMseqs Version:                        	14.7e284), whether the fasta sequence will be again used to predict the ORF first or without ORF prediction and directly for a taxonomy assigment?
Thanks

If you give amino-acid sequences produced by prodigal to MMseqs2, it will not rerun any ORF calling.

Thank you very much.


--full-path option show the relative paths with the relative root

Set relative paths in .gitconfig

[ghq]
root = ~/.go/src
root = ./vendor

Run ghq list with --full-path, -p option

$ cd /path/to/some/golang/repo
$ ghq list -p
/Users/delphinus/.go/src/github.com/mattn/gom
/Users/delphinus/.go/src/github.com/mattn/gover
/Users/delphinus/.go/src/github.com/mattn/goveralls

...

vendor/github.com/BurntSushi/toml
vendor/github.com/urfave/cli

I think the last two paths should be absolute, such as...
/path/to/some/golang/repo/vendor/github.com/BurntSushi/toml
/path/to/some/golang/repo/vendor/github.com/urfave/cli

Is it the specification, or the bug?

Actually I have not imagined setting a relative path to ghq.root. Should be counted as a bug.

When I manage package dependencies in golang projects, I usually use package manager such as gom, glide,... that will clone packages below /path/to/projects/vendor directory.
I noticed this bug when I use unite-ghq (my self-made plugin) for Vim to show up that package dependencies list. I want to show local packages (below ./vendor/github.com/...) with global packages (below $GOPATH/github.com/...) by this plugin.

I can deal with this case by rewriting paths in VimScript, but I would appreciate your fixing this bug.


[e2e] VM details and list actions e2e testing

Signed-off-by: Matan Schatzman<EMAIL_ADDRESS>
📝 Description
Adding e2e cypress testing for VM details and list actions.

@gouyang ptal

/retest


Azure Devops Services Bug Tracker Auto create ticket to raise Issue not a bug

Describe the solution you'd like
Be able to specify that an issue is raised rather than a bug in Azure Devops Services, when auto-creating tickets.
Describe alternatives you've considered
Not using the behaviour.
Additional context
Because these are just callstacks that require investigation we want them to be created as issues. Then be investigated to whether a duplication can be found, and a bug with duplication plan created.

Any review on this one?


New version: vim.vim.nightly version 9.1.0065

Pull request has been created with WinGet Releaser v2 :rocket:
Microsoft Reviewers: Open in CodeFlow

Hi @chrisbra,
The package didn't pass a Defender or similar security scan. This might be a false positive and we can rescan tomorrow.
(Automated response - build 677.)

Automatic Validation ended with:

Installation failed with exit code -1978335187 2024-01-29 16:47:34.532 [FAIL] Installer failed security check. Url: https://github.com/vim/vim-win32-installer/releases/download/v9.1.0065/gvim_9.1.0065_x86.exe Result: 0x80004005

(Automated response - build 677.)

/AzurePipelines run


Nukeeper inspect, order alphabetic

Would be nice to order the output from inspect alphabetically, sometimes I can't use the automated update due to dependency issues but putting them all together I can work out how to apply the changes manually.

While not desirable it's possible to have multiple versions of the same package in a single solution.  Can I suggest this is extended to be ordered alphabetically then by version?

Had a quick play with this. branch here:
https://github.com/shep1987/NuKeeper/commit/4ff2cf0362408da8a2cbb520019a66c0f354aaf1
@AnthonySteele Can you provide some context into PrioritySort I wouldn't want to remove it if people are using it! From my point of view i didn't understand the order until i looked into this code.

PrioritySort is a heuristic (i.e. informal algorithm) to decide which package it is best to update first. This comes into play heavily when there are e.g. 50 potential updates, but a limit of will be applied. Which 3? You want the most impactful / important  / obvious ones, but the rules to determine that are a bit of a guess.
There are rules such as

If there is more than one current version in use, do that first - i.e prefer to consolidate.
Prefer to a package used in 2 places over a package used in 1 place
Prioritise changes that have been around for longer (ScoreAge)
Prioritise  changes that go from prerelease to release versions (get out of beta)

etc.  PrioritySort can  be modified, but it serves a purpiose. If you want to sort all potential updates alphabetically for display, do that to output just before displaying?


ignore the next week if current is still going

i.e. there may be three days left on current week but there's already a next week, and currently parser focuses on the newest, which is bad

doesn't make sense with the new schedule format


(BKR-1199) Allow beaker to use iam_role

beaker-aws modified to use iam_role

Can one of the admins verify this patch?

@tvpartytonight should be good now.

@cdenneen I'm a bit unclear how removing the credentials sets the ec2 instance to use an IAM role; can you point me to some documentation describing this new behavior in the AWS EC2 docs?

The node you are running beaker needs a profile attached to it with
stsAssumeRole in the policy for ec2:*
The nodes beaker creates are then created because the node creating them
already has the role attached. This can be done via console or in
Cloudformation but I think AWS role creation might fall outside the scope
here.
Aws SDK and cli were updated a long time ago now to support trying to
AssumeRole if no credentials are provided. So when the AWS.config is passed
missing the creds it will try to assume the role.
On Mon, Aug 28, 2017 at 8:44 PM Tony Vu<EMAIL_ADDRESS>wrote:

@cdenneen https://github.com/cdenneen I'm a bit unclear how removing
the credentials sets the ec2 instance to use an IAM role; can you point me
to some documentation describing this new behavior in the AWS EC2 docs?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/puppetlabs/beaker-aws/pull/4#issuecomment-325521783,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAr84ekhRA_DCBWa91OW0oMSBjcfFADYks5sc17ngaJpZM4PEjsI
.

Sorry for the delay in response here @cdenneen; I think I didn't realize that this was for testing with the beaker coordinator running in ec2, and I was confused by that.
In doing some testing from my laptop, the AWS gem still loads AWS credentials from a ~/.aws/ folder when use_iam_role is set. Because of this, I think it makes sense to gate this functionality with a name more like use_aws_fog_credentials: false; we can't be certain that it will actually use the iam role when we skip loading fog credentials.

So even with the credential load commented out by setting use role to true
it still loads from the .aws configuration. So therefore using use_aws_fog
is misleading because it actually still is at the SDK level even if not in
beaker code. So by setting the Boolean for using role to true might still
be able to load creds, even if not explicitly from beaker code loading, you
at least know you are "attempting to bypass" for use with a role. Setting
Boolean for use fog doesn't automatically mean someone set a role at all,
just means they don't want to load from fog right?
On Mon, Sep 18, 2017 at 3:25 PM Tony Vu<EMAIL_ADDRESS>wrote:

Sorry for the delay in response here @cdenneen
https://github.com/cdenneen; I think I didn't realize that this was for
testing with the beaker coordinator running in ec2, and I was confused by
that.
In doing some testing from my laptop, the AWS gem still loads AWS
credentials from a ~/.aws/ folder when use_iam_role is set. Because of
this, I think it makes sense to gate this functionality with a name more
like use_aws_fog_credentials: false; we can't be certain that it will
actually use the iam role when we skip loading fog credentials.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/puppetlabs/beaker-aws/pull/4#issuecomment-330329887,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAr84RlhPxTftNVzHYXefaLx1hl4GVwiks5sjsOvgaJpZM4PEjsI
.

@cdenneen I'm not quite sure I can follow what you wrote there. I am proposing the following change:
For the setting :use_aws_fog_credentials = true, beaker would behave as it has up to this point, hardcoded to read in the values :aws_access_key_id and :aws_secret_access_key from the .fog file.
For the setting :use_aws_fog_credentials = false, beaker would not pass in the :access_key_id and :secret_access_key parameters to AWS.config(config). This allows for AWS.config to load different credentials than that provided in the .fog file. Since we can't make any guarantees that it would use the IAM role if we don't load the .fog credentials, I think we should change the name for this setting to more accurately reflect what is being toggled.
Implied in this solution is adding a default setting of :use_aws_fog_credentials to true. You could get around this by calling the setting :ignore_aws_fog_credentials but I dislike settings with a negative denotation, as they are difficult to parse.
Per your comment

So therefore using use_aws_fog
is misleading because it actually still is at the SDK level even if not in
beaker code.

In my own testing I see that that turning on :use_iam_role does not load the .fog file, but the ~/.aws/credentials file. Are you seeing something different?

@tvpartytonight Yes I can do this. I guess my point was technically the .fog piece has actually been deprecated. As far as I can tell you are only using fog to read in the credentials which you've proven works from ~/.aws/credentials so it renders them legacy code that can probably be removed.
With that being true then without that code the aws-sdk can read from ~/.aws/credentials or try to assume attached role.
With that being said would it make more sense to deprecate fog all together requiring just removal of the code to read the credentials?

@cdenneen I have created BKR-1207 to track what to do with the current .fog workflow.

Thanks... currently I have to modify the bundled gem to comment out that
credential code part (sed hackery) which isn't ideal. Obviously this PR
wouldn't be needed if the fog code is removed but I'm stuck in a holding
pattern and don't want to implement the defaults for load_fog_credentials
as suggested if deprecating fog is potentially coming soon.
Hopefully we can push BKR-1207 along for another release soon.

@cdenneen the PR here should have the same name I suggested above, :use_aws_fog_credentials. Also, it looks like this one is still using :use_iam_role so that will need to be changed as well.

@tvpartytonight the PR does and this is the old one that we decided to use #5 instead so closing this one.


[Discussion] Refactor the Decimals by using constant generic.

Is your feature request related to a problem or challenge? Please describe what you are trying to do.
This is actually a question or a discussion.
Our current may to implement Decimal128 and Decimal256 is:
trait BasicDecimal: ... {
    const BIT_LENGTH: i32;
}

struct Decimal128 {}

struct Decimal256 {}

impl BasicDecimal for Decimal128 {}
impl BasicDecimal for Decimla256{}
impl Decimal128 {}

Actually I find an alternative way to implement this:
struct Decimal<const BYTE_LENGTH: usize> {
    precision: usize,
    scale: usize,
    value: [u8; BYTE_LENGTH],
}
impl<BYTE_LENGTH> Decimal<BYTE_LENGTH> {}

type Decimal128 = Decimal<16>;
type Decimal256 = Decimal<32>;

impl Decimal128 {}

I am not sure which one is better, but these are some pros and cons I thought:
pros: don't need the basic trait, reducing using macro when coding (better debugging)
cons: cannot restrict the bit_length to be 128 or 256 because const_generic_exprs is an unstable feature.

cc @viirya. Looking forward to your opinions.

related to #1999

Oh, I have considered generic. But as I cannot use 16, 32 as generic parameter, I don't go for this direction.

But as I cannot use 16, 32 as generic parameter, I don't go for this direction.

Why can't 16, 32 be used as generic parameter? Rust has supported const generic

didn't you already say it is unstable feature?

Oh, that's const_generic_exprs. I don't know we can use const as generic parameter.

didn't you already say it is unstable feature?
Oh, that's const_generic_exprs. I don't know we can use const as generic parameter.

Sorry for the confusion.
You are right. Theconst_generic is stable but  the const_generic_exprs is ubstable, which means we can't add bound to the const generic so far:
(not tested)
#![feature(const_generic_exprs)]
impl<const BYTE_LENGTH> Decimal<{BYTE_LENGTH}> // const generic is stable
where {BYTE_LENGTH == 16 || BYTE_LENGTH == 32} // const generic expr is unstable
{...}

This is just an alternative way to implment Decimal, DecimalArray and DecimalArrayBuilder.

@sunchao @alamb @tustvold Welcome to have a look and look forward to your opinions.

Thank you for everyone's discussion! 😀
I will close this issue.
If anyone has some new ideas, we can reopen it.


[Bug] Error running unit tests that use the dbt_utils.star macro

Is this a new bug in dbt-core?

[X] I believe this is a new bug in dbt-core
[X] I have searched the existing issues, and I could not find an existing issue for this bug

Current Behavior
When running unit tests that involve the star macro from dbt-utils, I encounter an error indicating that the macro cannot be used with ephemeral models. However, the models in question are all materialized as views, not ephemeral models.
Test fails with error:
Compilation Error in unit_test test_positions (models/poc/test_positions.yml)
  The `star` macro cannot be used with ephemeral models, as it relies on the information schema.
  `KLARNA` is an ephemeral model. Consider making it a view or table instead.

  > in macro _is_ephemeral (macros/jinja_helpers/_is_ephemeral.sql)
  > called by macro default__star (macros/sql/star.sql)
  > called by macro star (macros/sql/star.sql)
  > called by unit_test test_positions (models/poc/test_positions.yml)

Expected Behavior
The test should run successfully without any errors, as the model is materialized as a view.
Steps To Reproduce

Create a model that uses the star macro from dbt-utils.
Materialize the model as a view.
Write a unit test for the model
Run dbt test --select <your_test>.

Relevant code:
unit_tests:
  - name: test_positions
    description: "Should enrich positions"
    model: pos__enriched_pc__klarna
    given:
      - input: source('POS__CANONIC_PC', 'KLARNA')
        rows:
          - {
            "ID": 1,
            "SOURCE_PATH": "example_source_path",
          }
    expect:
      rows:
          - {
            "ID": 1,
            "SOURCE_PATH": "example_source_path"
          }

KLARNA.sql
{{ config(schema='POS__CANONIC_PC') }}
select
  null::integer as ID,
  null::text as SOURCE_PATH
where false

pos__enriched_pc__klarna.sql
{{
    config(
        alias='KLARNA',
        materialized="view"
    )
}}

WITH relevant_at_records AS (
    SELECT * FROM {{ source('POS__CANONIC_PC','KLARNA') }} p
)

SELECT {{ dbt_utils.star(source('POS__CANONIC_PC', 'KLARNA'), 'p') }}
FROM relevant_at_records p

sources.yml
sources:
  - name: POS__CANONIC_PC
    schema: main_POS__CANONIC_PC
    tables:
      - name: KLARNA

Relevant log output
17:51:37.821071 [debug] [MainThread]: Sending event: {'category': 'dbt', 'action': 'invocation', 'label': 'start', 'context': [<snowplow_tracker.self_describing_json.SelfDescribingJson object at 0x1030a6650>, <snowplow_tracker.self_describing_json.SelfDescribingJson object at 0x104986680>, <snowplow_tracker.self_describing_json.SelfDescribingJson object at 0x104986260>]}

============================== 17:51:37.823932 | d44c1e2a-c921-4960-ae79-3532a9943558 ==============================
17:51:37.823932 [info ] [MainThread]: Running with dbt=1.8.1
17:51:37.824236 [debug] [MainThread]: running dbt with arguments {'printer_width': '80', 'indirect_selection': 'eager', 'log_cache_events': 'False', 'write_json': 'True', 'partial_parse': 'True', 'cache_selected_only': 'False', 'warn_error': 'None', 'debug': 'False', 'fail_fast': 'False', 'log_path': '/Users/guy.eliyahu/repo/luma_unit_tests/logs', 'version_check': 'True', 'profiles_dir': '/Users/guy.eliyahu/.dbt', 'use_colors': 'True', 'use_experimental_parser': 'False', 'no_print': 'None', 'quiet': 'False', 'warn_error_options': 'WarnErrorOptions(include=[], exclude=[])', 'invocation_command': 'dbt test --select test_positions', 'introspect': 'True', 'static_parser': 'True', 'target_path': 'None', 'log_format': 'default', 'send_anonymous_usage_stats': 'True'}
17:51:37.988223 [debug] [MainThread]: Sending event: {'category': 'dbt', 'action': 'project_id', 'label': 'd44c1e2a-c921-4960-ae79-3532a9943558', 'context': [<snowplow_tracker.self_describing_json.SelfDescribingJson object at 0x104adbc40>]}
17:51:38.012620 [debug] [MainThread]: Sending event: {'category': 'dbt', 'action': 'adapter_info', 'label': 'd44c1e2a-c921-4960-ae79-3532a9943558', 'context': [<snowplow_tracker.self_describing_json.SelfDescribingJson object at 0x104a33ee0>]}
17:51:38.013373 [info ] [MainThread]: Registered adapter: duckdb=1.8.0
17:51:38.028159 [debug] [MainThread]: checksum: ebc509fb14e151ea268e89b60fd5abf912ed99129f87516462718fa2f14f4838, vars: {}, profile: , target: , version: 1.8.1
17:51:38.137805 [debug] [MainThread]: Partial parsing enabled: 0 files deleted, 0 files added, 1 files changed.
17:51:38.138187 [debug] [MainThread]: Partial parsing: updated file: unit_tests://models/sources.yml
17:51:38.194200 [debug] [MainThread]: Sending event: {'category': 'dbt', 'action': 'load_project', 'label': 'd44c1e2a-c921-4960-ae79-3532a9943558', 'context': [<snowplow_tracker.self_describing_json.SelfDescribingJson object at 0x104aae140>]}
17:51:38.267129 [debug] [MainThread]: Sending event: {'category': 'dbt', 'action': 'resource_counts', 'label': 'd44c1e2a-c921-4960-ae79-3532a9943558', 'context': [<snowplow_tracker.self_describing_json.SelfDescribingJson object at 0x104ed0c40>]}
17:51:38.267412 [info ] [MainThread]: Found 6 models, 1 source, 525 macros, 2 unit tests
17:51:38.267603 [debug] [MainThread]: Sending event: {'category': 'dbt', 'action': 'runnable_timing', 'label': 'd44c1e2a-c921-4960-ae79-3532a9943558', 'context': [<snowplow_tracker.self_describing_json.SelfDescribingJson object at 0x104ef15a0>]}
17:51:38.268313 [info ] [MainThread]:
17:51:38.268593 [debug] [MainThread]: Acquiring new duckdb connection 'master'
17:51:38.271115 [debug] [ThreadPool]: Acquiring new duckdb connection 'list_dbt_main'
17:51:38.345485 [debug] [ThreadPool]: Using duckdb connection "list_dbt_main"
17:51:38.345699 [debug] [ThreadPool]: On list_dbt_main: BEGIN
17:51:38.345840 [debug] [ThreadPool]: Opening a new connection, currently in state init
17:51:38.351464 [debug] [ThreadPool]: SQL status: OK in 0.0 seconds
17:51:38.351629 [debug] [ThreadPool]: Using duckdb connection "list_dbt_main"
17:51:38.351775 [debug] [ThreadPool]: On list_dbt_main: /* {"app": "dbt", "dbt_version": "1.8.1", "profile_name": "unit_tests", "target_name": "dev", "connection_name": "list_dbt_main"} */
select
      'dbt' as database,
      table_name as name,
      table_schema as schema,
      CASE table_type
        WHEN 'BASE TABLE' THEN 'table'
        WHEN 'VIEW' THEN 'view'
        WHEN 'LOCAL TEMPORARY' THEN 'table'
        END as type
    from system.information_schema.tables
    where table_schema = 'main'
    and table_catalog = 'dbt'

17:51:38.368430 [debug] [ThreadPool]: SQL status: OK in 0.0 seconds
17:51:38.369176 [debug] [ThreadPool]: On list_dbt_main: ROLLBACK
17:51:38.369873 [debug] [ThreadPool]: Failed to rollback 'list_dbt_main'
17:51:38.370009 [debug] [ThreadPool]: On list_dbt_main: Close
17:51:38.371237 [debug] [ThreadPool]: Re-using an available connection from the pool (formerly list_dbt_main, now list_dbt_main_POS__CANONIC_PC)
17:51:38.372695 [debug] [ThreadPool]: Using duckdb connection "list_dbt_main_POS__CANONIC_PC"
17:51:38.372850 [debug] [ThreadPool]: On list_dbt_main_POS__CANONIC_PC: BEGIN
17:51:38.372974 [debug] [ThreadPool]: Opening a new connection, currently in state closed
17:51:38.375621 [debug] [ThreadPool]: SQL status: OK in 0.0 seconds
17:51:38.375768 [debug] [ThreadPool]: Using duckdb connection "list_dbt_main_POS__CANONIC_PC"
17:51:38.375901 [debug] [ThreadPool]: On list_dbt_main_POS__CANONIC_PC: /* {"app": "dbt", "dbt_version": "1.8.1", "profile_name": "unit_tests", "target_name": "dev", "connection_name": "list_dbt_main_POS__CANONIC_PC"} */
select
      'dbt' as database,
      table_name as name,
      table_schema as schema,
      CASE table_type
        WHEN 'BASE TABLE' THEN 'table'
        WHEN 'VIEW' THEN 'view'
        WHEN 'LOCAL TEMPORARY' THEN 'table'
        END as type
    from system.information_schema.tables
    where table_schema = 'main_POS__CANONIC_PC'
    and table_catalog = 'dbt'

17:51:38.387015 [debug] [ThreadPool]: SQL status: OK in 0.0 seconds
17:51:38.387607 [debug] [ThreadPool]: On list_dbt_main_POS__CANONIC_PC: ROLLBACK
17:51:38.387787 [debug] [ThreadPool]: Failed to rollback 'list_dbt_main_POS__CANONIC_PC'
17:51:38.387905 [debug] [ThreadPool]: On list_dbt_main_POS__CANONIC_PC: Close
17:51:38.388942 [debug] [MainThread]: Sending event: {'category': 'dbt', 'action': 'runnable_timing', 'label': 'd44c1e2a-c921-4960-ae79-3532a9943558', 'context': [<snowplow_tracker.self_describing_json.SelfDescribingJson object at 0x104a82500>]}
17:51:38.389171 [debug] [MainThread]: Using duckdb connection "master"
17:51:38.389292 [debug] [MainThread]: On master: BEGIN
17:51:38.389408 [debug] [MainThread]: Opening a new connection, currently in state init
17:51:38.392039 [debug] [MainThread]: SQL status: OK in 0.0 seconds
17:51:38.392175 [debug] [MainThread]: On master: COMMIT
17:51:38.392292 [debug] [MainThread]: Using duckdb connection "master"
17:51:38.392412 [debug] [MainThread]: On master: COMMIT
17:51:38.392564 [debug] [MainThread]: SQL status: OK in 0.0 seconds
17:51:38.392689 [debug] [MainThread]: On master: Close
17:51:38.393291 [info ] [MainThread]: Concurrency: 1 threads (target='dev')
17:51:38.393515 [info ] [MainThread]:
17:51:38.394795 [debug] [Thread-1 (]: Began running node unit_test.unit_tests.pos__enriched_pc__klarna.test_positions
17:51:38.395006 [info ] [Thread-1 (]: 1 of 1 START unit_test pos__enriched_pc__klarna::test_positions ................ [RUN]
17:51:38.395239 [debug] [Thread-1 (]: Re-using an available connection from the pool (formerly list_dbt_main_POS__CANONIC_PC, now unit_test.unit_tests.pos__enriched_pc__klarna.test_positions)
17:51:38.395393 [debug] [Thread-1 (]: Began compiling node unit_test.unit_tests.pos__enriched_pc__klarna.test_positions
17:51:38.395542 [debug] [Thread-1 (]: Began executing node unit_test.unit_tests.pos__enriched_pc__klarna.test_positions
17:51:38.446075 [debug] [Thread-1 (]: Compilation Error in unit_test test_positions (models/poc/test_positions.yml)

  The `star` macro cannot be used with ephemeral models, as it relies on the information schema.

  `KLARNA` is an ephemeral model. Consider making it a view or table instead.

  > in macro _is_ephemeral (macros/jinja_helpers/_is_ephemeral.sql)
  > called by macro default__star (macros/sql/star.sql)
  > called by macro star (macros/sql/star.sql)
  > called by unit_test test_positions (models/poc/test_positions.yml)
17:51:38.446418 [error] [Thread-1 (]: 1 of 1 ERROR pos__enriched_pc__klarna::test_positions .......................... [ERROR in 0.05s]
17:51:38.446718 [debug] [Thread-1 (]: Finished running node unit_test.unit_tests.pos__enriched_pc__klarna.test_positions
17:51:38.447576 [debug] [MainThread]: Using duckdb connection "master"
17:51:38.447741 [debug] [MainThread]: On master: BEGIN
17:51:38.447871 [debug] [MainThread]: Opening a new connection, currently in state closed
17:51:38.450818 [debug] [MainThread]: SQL status: OK in 0.0 seconds
17:51:38.450971 [debug] [MainThread]: On master: COMMIT
17:51:38.451095 [debug] [MainThread]: Using duckdb connection "master"
17:51:38.451220 [debug] [MainThread]: On master: COMMIT
17:51:38.451379 [debug] [MainThread]: SQL status: OK in 0.0 seconds
17:51:38.451501 [debug] [MainThread]: On master: Close
17:51:38.452173 [debug] [MainThread]: Connection 'master' was properly closed.
17:51:38.452371 [debug] [MainThread]: Connection 'unit_test.unit_tests.pos__enriched_pc__klarna.test_positions' was properly closed.
17:51:38.452514 [info ] [MainThread]:
17:51:38.452660 [info ] [MainThread]: Finished running 1 unit test in 0 hours 0 minutes and 0.18 seconds (0.18s).
17:51:38.452939 [debug] [MainThread]: Command end result
17:51:38.470776 [info ] [MainThread]:
17:51:38.471006 [info ] [MainThread]: Completed with 1 error and 0 warnings:
17:51:38.471147 [info ] [MainThread]:
17:51:38.471323 [error] [MainThread]:   Compilation Error in unit_test test_positions (models/poc/test_positions.yml)

  The `star` macro cannot be used with ephemeral models, as it relies on the information schema.

  `KLARNA` is an ephemeral model. Consider making it a view or table instead.

  > in macro _is_ephemeral (macros/jinja_helpers/_is_ephemeral.sql)
  > called by macro default__star (macros/sql/star.sql)
  > called by macro star (macros/sql/star.sql)
  > called by unit_test test_positions (models/poc/test_positions.yml)
17:51:38.471464 [info ] [MainThread]:
17:51:38.471604 [info ] [MainThread]: Done. PASS=0 WARN=0 ERROR=1 SKIP=0 TOTAL=1
17:51:38.473212 [debug] [MainThread]: Resource report: {"command_name": "test", "command_wall_clock_time": 0.6966405, "process_user_time": 0.970085, "process_kernel_time": 0.23907, "process_mem_max_rss": "137936896", "command_success": false, "process_in_blocks": "0", "process_out_blocks": "0"}
17:51:38.473459 [debug] [MainThread]: Command `dbt test` failed at 17:51:38.473416 after 0.70 seconds
17:51:38.473646 [debug] [MainThread]: Sending event: {'category': 'dbt', 'action': 'invocation', 'label': 'end', 'context': [<snowplow_tracker.self_describing_json.SelfDescribingJson object at 0x1030a6650>, <snowplow_tracker.self_describing_json.SelfDescribingJson object at 0x104a33c70>, <snowplow_tracker.self_describing_json.SelfDescribingJson object at 0x104e61e10>]}
17:51:38.473814 [debug] [MainThread]: Flushing usage events

Environment
- OS: macos
- Python: 3.10.0
- dbt: 1.8.1

Which database adapter are you using with dbt?
No response
Additional Context
No response

just notified on slack that i must mock macros of the unittest:
adding this solve the issue:
    overrides:
      macros:
        dbt_utils.star: 'ID, SOURCE_PATH, PARTNER'

@dbeatty10 Could you reopen this issue? I'm running into the exact same error, but as I used the dbt_utils.star macro more than once to select columns from different models, I couldn't overwrite the macro results like OP did.

See below for a reproducible example that involves at least two calls to dbt_utils.star that have different outputs. The example is a bit contrived, but I think it demonstrates the issue being raised.
Reprex
Create these files:
models/my_model_a
select 1 as id, 1 as id_a

models/my_model_b
select 1 as id, 2 as id_b

models/my_model_c
select
    a.id,
    {{ dbt_utils.star(ref('my_model_a'), except=["id"]) }},
    {{ dbt_utils.star(ref('my_model_b'), except=["id"]) }}

from {{ ref('my_model_a') }} as a
inner join {{ ref('my_model_b') }} as b on a.id = b.id

models/_unit_tests.yml
unit_tests:
  - name: dbt_core_10254
    model: my_model_c
    given:
      - input: ref('my_model_a')
        rows:
          - { id: 0, id_b: 123 }
      - input: ref('my_model_b')
        rows:
          - { id: 0, id_c: 456 }
    expect:
      rows:
          - { id: 0, id_b: 123, id_c: 456 }

Run these commands:
dbt run -s +my_model_c
dbt build -s my_model_c

Get this output:
22:47:33  Running with dbt=1.8.6
22:47:33  Registered adapter: postgres=1.8.2
22:47:33  Found 3 models, 533 macros, 1 unit test
22:47:33
22:47:34  Concurrency: 5 threads (target='postgres')
22:47:34
22:47:34  1 of 2 START unit_test my_model_c::dbt_core_10254 .............................. [RUN]
22:47:34  1 of 2 ERROR my_model_c::dbt_core_10254 ........................................ [ERROR in 0.05s]
22:47:34  2 of 2 SKIP relation dbt_dbeatty.my_model_c .................................... [SKIP]
22:47:34
22:47:34  Finished running 1 unit test, 1 view model in 0 hours 0 minutes and 0.36 seconds (0.36s).
22:47:34
22:47:34  Completed with 1 error and 0 warnings:
22:47:34
22:47:34    Compilation Error in unit_test dbt_core_10254 (models/_unit_tests.yml)

  The `star` macro cannot be used with ephemeral models, as it relies on the information schema.

  `my_model_a` is an ephemeral model. Consider making it a view or table instead.

  > in macro _is_ephemeral (macros/jinja_helpers/_is_ephemeral.sql)
  > called by macro default__star (macros/sql/star.sql)
  > called by macro star (macros/sql/star.sql)
  > called by unit_test dbt_core_10254 (models/_unit_tests.yml)
22:47:34
22:47:34  Done. PASS=0 WARN=0 ERROR=1 SKIP=1 TOTAL=2

I'm running into a very similar issue with a macro that accepts a ref as an argument (like star) and is used more than once, with different arguments, in the same model.


Controller support for bindings

More of a feature request, predominantly for when using an Xbox Controller.
Would be great if the Microsoft VKs could be assigned to the CET hotkeys (VKs documented here: https://docs.microsoft.com/en-us/windows/win32/api/xinput/ns-xinput-xinput_keystroke)
//Edit - ideally, VK combinations could be used just like multiple keyboard hotkeys in the current releases.

We would like to add controller support too for bindings, is planned.
However, what you wrote would not work in general for this game in particular.
For whatever reason, they do not seem to utilize xinput at all, everything is routed throguh RAW input.
Anyway, we have it planned, we know cca what we would have to do to make it work, we just need time to implement it all. Already have quite a big list of planned things as you may have seen looking through issues. :)

Ill put this here just for reference.
https://github.com/yamashi/CyberEngineTweaks/issues/424#issuecomment-779278773

Thanks for getting back to me, very interesting that xinput isn't utilised!

Just another vote to let you know people are interested.  I've managed to get this installed on my Steam Deck - but there's no keyboard on the device.  (Just an overlay...)
I luckily had a spare keyboard lying around with a USB-C connector I could use to put in a default binding, but I’m pretty much guaranteed to never be able to open the menu again.

@DanStaal You can use the Steam Deck's button mapping system to bind a button on the Steam Deck (e.g. L4) to a keyboard key (e.g F12), and then bind that keyboard key in Cyber Engine Tweaks to open the menu. You can just edit the default "Gamepad with Joystick Trackpad" layout. See this article for info about the button mapping system. (I tried this and it worked for me.)


mWeb- Chat - Keyboard not opening when editing message.

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Issue found when executing PR https://github.com/Expensify/App/pull/19477
Action Performed:

Go to URL https://staging.new.expensify.com/
Open any conversation.
Long press on the message.
Press on the edit message.
Input should be focused, and the keyboard should appear.

Expected Result:
The keyboard should open automatically when the message changes.
Actual Result:
Keyboard not opening when editing message.
Workaround:
Unknown
Platforms:

Which of our officially supported platforms is this issue occurring on?

[ ] Android / native
[ ] Android / Chrome
[ ] iOS / native
[x] iOS / Safari
[ ] MacOS / Chrome / Safari
[ ] MacOS / Desktop

Version Number: <IP_ADDRESS>
Reproducible in staging?: yes
Reproducible in production?: yes
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos: Any additional supporting documentation
https://platform.applause.com/services/links/v1/external/778f3baa67dffd2d70747df8fbee6af3a8c7b4277154fa0676da50cc2032d71a
Expensify/Expensify Issue URL:
Issue reported by: Applause - Internal Team
Slack conversation:
View all open jobs on GitHub

Hi @PauloGasparSv and @fedirjh - @kbecciv has indicated this is an issue associated with your PR: https://github.com/Expensify/App/pull/19477
Do you mind taking a look at this? Cheers!

Yes, the PR introduces the .native file instead of .android file, so the web should not be affected.
Also the root cause of the bug was related to the bug (or feature, since they made the same behavior on both iOS and Android) in the implementation of react-native-modal.
But on the web we don't use react-native-modal.
I'll take a look at what exactly is causing this.

I'm currently experiencing this bug on Android native too.

I'm currently experiencing this bug on Android native too.

What phone and version of the app do you use?  Is it in production?

This happened in DEV against the staging server.

Phone: Samsung Galaxy A14
App veraion: v1.3.18-2

@Victor-Nyagudi can you try logging onto staging instead? I'm on v1.3.19-2 (Pixel 3a, Chrome) and can't repro - the keyboard pops up and I can edit properly:

It's working fine in staging on mobile web, @jliexpensify .
By the way, is there a staging/production app for mobile (iOS and Android)?
The one from the play store seems to be the same as the one installed when running npm run android.

@Victor-Nyagudi can you share a video and the version number?
Also, any luck with your investigation @terrysahaidak ?

@jliexpensify v1.3.19-7
The keyboard does show up when you tap the editing composer - my laptop was just a bit slow in the video.
https://github.com/Expensify/App/assets/79470910/1178da6b-0d1d-46e8-88d2-e7d03fcd662e

Got it, so to clarify: there isn't an issue then?

I thought the keyboard's supposed to show up on its own whenever the editing composer comes into focus.

I thought the keyboard's supposed to show up on its own whenever the editing composer comes into focus.
That's my understanding too, and I am seeing this on the current Staging build (v1.3.22-0) and Prod (v1.3.21-2), so I don't think this is an issue anymore?
@PauloGasparSv do you mind weighing in here?

@PauloGasparSv do you mind weighing in here?

Sure thing! Checked the discussion and there really seems to be no error anymore, that's the desired behaviour.
I'm closing this, let's re-open if this happens again


Support XML based APIs

Some APIs use XML instead of JSON, such as Shutterfly.
Shouldn't be that hard to add support: http://www.baeldung.com/jackson-xml-serialization-and-deserialization

There's nothing preventing XML APIs from being supported in an extension, so either this is already possible (although with more work than just pointing a serializer at the data model) or not planned (not sure how useful it truly is to just point a serializer at the data model since companies have their own data models in their APIs.

After discussion with other maintainers, going to close this as "not planned" in that we're not planning to do work to explicitly add extra support for XML since it's already possible to do .


Update to 4.62.2

Checklist

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

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

The tests pass in https://dev.azure.com/conda-forge/feedstock-builds/_build/results?buildId=366817

ah got in just before the automated #111 :)


Sporadic "disk image is malformed" errors when used within WSGI

Previously, a user raised a concern that langcodes' use of sqlite3 was not thread-safe. I thought this was fixed in modern versions of Python and SQLite, but apparently it isn't.
For reasons I don't understand, this manifests itself when the langcodes database is being accessed from a WSGI process.
I think it may be time to stop relying on sqlite3 for language data.

Fixed in v1.4, which doesn't use sqlite.


Fixes warnings for unused datavars and addons

Hi @Chengfeng-Jia, I made a start with #104. I think it has mostly been resolved, but it lacks tests. If @bvdmitri agrees with the solution approach, we can start writing those.
@bvdmitri Is the proposed solution okay? I added the warn argument also in the ModelOptions struct, such that we can use this upon model creation.

ping @bvdmitri :)

@bartvanerp Solution approach is good! I've changed some minor stuff, simple tests would be nice

Thanks @bvdmitri! @Chengfeng-Jia would you be available to test the functionality?

I will write some tests for that.

Hi, guys, I wrote some tests for this improvement. However, I added some new models to the existing test code. If you think it's unnecessary please let me know.

Thanks @Chengfeng-Jia! In my opinion the tests look good. I moved everything to test_inference.jl, as we are specifically testing the inference() function, but aside from that, excellent job! @bvdmitri ready for review


Add support for managing Teams similarly to what's possible with PowerShell

For the list of available operations, see https://www.powershellgallery.com/packages/MicrosoftTeams/0.9.0

I'm on it...

Closing this one in favor of separate issues for each command for easier progress tracking


Eye tracking calibration prompt

At present, if eye tracking is enabled in a Unity OpenXR App the user will always:

Be prompted for permission if not granted
Be prompted to calibrate if not calibrated

Is there a way to control whether or not these prompts are shown? Or the timing of them?
I'd like to use eye tracking if the user has calibrated, but if they haven't, then don't worry about it.

OK.. based on the docs: https://learn.microsoft.com/en-us/windows/mixed-reality/develop/advanced-concepts/eye-tracking-calibration
I will try:

Don't enable any InputActions that use Eye Tracking
Check for EyesPose::IsCalibrationValid
If valid pose (or not running in UWP), then enable said input actions.

I'll re-open this issue if this doesn't work.
It would be great if this was configured as an OpenXR feature instead!


x/sys/unix: add *at (POSIX.1-2008 conformed) functions on darwin.

OS X 10.10 (IOS 8.0) add list of *at syscalls.

openat
renameat
fchmodat
fstatat
mkdirat
faccessat
fchownat
linkat
readlinkat
symlinkat
unlinkat

Currently, only fchmodat is exposed.

These syscalls are also supported on FreeBSD, and I need them for a project that currently only supports Linux.

I would like to second both requests (macOS / FreeBSD) in this issue.
Other popular BSDs (Net, Open)most likely support the requested system calls as well.

Yes. Openat is required, as I understand it, to be able to reliably open a path without following symlinks. Currently this is only possible on Linux, with Go...

I encourage anyone who wants to fix this to write a patch and submit it following the guidelines at https://golang.org/doc/contribute.html.


⚠ GitHub has degraded performance

In 9765fc1, GitHub (https://www.githubstatus.com/api/v2/status.json) experienced degraded performance:

HTTP code: 200
Response time: 274 ms

Resolved: GitHub performance has improved in d95a8ee.


Added option to customize partition events by stage logic subclasses

This is a small PR, which adds a way to customize partition events handling by different stage logic classes.
Before this PR partitions events were handled by SingleSourceStageLogic without any option to override it. Besides, original kafka driver callbacks also provide consumer instance passed to callbacks, so actually handling could use some consumer's methods.
Now consumer is passed to this callbacks, and the callbacks itself may be customized by logic subclasses (looks like only for TransactionalSourceLogic so far).

During PR #48 review process, I thought that IPartitionEventHandler interface will be made public. But currently all references in original alpakka project, that use this interface, are private/internal. So actually making it public will not give library users any option of use this interface - so keeping it internal so far. We can switch it to public whenever there will be any option to use it from outside.

@IgorFedchenko FYI, on the previous commit had one test failure:
Akka.Streams.Kafka.Tests.Akka.Streams.Kafka.Tests.Integration.PlainSourceIntegrationTests.PlainSource_consumes_messages_from_KafkaProducer_with_subscribe_to_topic
You can see the logs and such if you click through here: https://github.com/akkadotnet/Akka.Streams.Kafka/runs/227053848
Might have a race condition of some kind with that test.

@Aaronontheweb Created issue for that - looks little bit wierd, so unfortunately can not fix this right now, "on the fly".


Update JNI to 23.04.0-SNAPSHOT and update new delta-stub ver to 23.04

Signed-off-by: Peixin Li<EMAIL_ADDRESS>New JNI build w/ cudf branch-23.04, and also test ENV to use 23.04 cudf-py
Also update new delta-stub module version to 23.04

I will retrigger all CI once the JNI artifact is available

build

Pass all other runtimes CI but failed known issue https://github.com/NVIDIA/spark-rapids/issues/7595 in db113
Going to merge this one to unblock 23.04 ENV setup (pipelines and docker images)


Http serializers:

Added:

new methods that turn objects to bodies of http POST/PUT requests by:

Gson
Jackson
Gsoup
tools from the org.w3c.dom.* package

new functions that turn string values of http responses to objsects by:

Gson
Jackson
Gsoup
tools from the org.w3c.dom.* package

Also:

dependency updates

@ArisAgnew @neparij PR has been changed


Add Data Prediction Functionality

Title: Add Data Prediction Functionality
Description: Implement a button that adds a predicted data point to the population chart.
Acceptance Criteria:

Create a button with id="add-data".
Implement the formula to calculate the mean delta and add a new data point based on that.

Additional Notes:
Ensure the new data point is appended to the existing chart data correctly.

Implemented.


How to set parameters such as columns

When using a tetra cube monster input how do you use columns to split a statblock.

Add the
columns: 2 forceColumns: true
after the "statblock"


RC4 is not a block cipher

RC4 is a stream cipher therefore EVP_CIPHER_CTX_block_size() should
return 1.
This fixes a test failure in ssl_test_old when enable-weak-ssl-ciphers
has been configured.

Thanks for fixing this Matt.. Merged to master.


several things on device catalog

[ ] the micro:bit entry should show just the micro:bit, without the jacdaptor: /devices/microbit-educational-foundation/microbitv2/
[x] we should definitely have a separate section for devices that can support Jacdac, but that don't have the Jacdac edge connector.

@mmoskal new picture please
@tballmsft separate issues please


Popup card not working good anymore

Hi
I'm experiencing havy problems.
Im on latest version.
I think it was quite good 2 versions ago
But now, its heavy, not loading good anymore
On my laptop/browser its good
On my android phone, using companion app,
Its sloooooow, then scrolling in the popup is hell !
Buttons arent fully loaded, and scrolling is true hell
Cleared cache, but doesnt fix it, any idea?

To add stuff
I tried to use the normal mode, and the optimized mode, no difference
Popup card on phone,  isnt loading good

But on laptop and tablet, its working as expected

Tried on different phones with the app, always the same

I having problems too. My feed cameras not working with sound

Hi and thank you for your feedback, are you using card-mod in your pop-ups? And also have you tried to set the background blur to 0?

I removed some popups and now the card is working again, i think it was too heavy to load...

Do you have/had pop-ups with cameras?

Yes 1 popup with 3 cameras

Smells like the DOM thing in #370

Hi, I've just released a new version that that should fix that issue 🤞
https://github.com/Clooos/Bubble-Card/releases/tag/v1.7.0


optimize the log

(1) controller pod
如下 info 级别的日志 就  ”reconciling“  几乎没有什么价值，
把一些重要的日志 合并一起打印 ，降低行数，，一方面 降低一些 日志级别
{"level":"info","ts":"2023-07-31T08:26:46.252Z","caller":"controller/egress_node.go:101","msg":"reconciling","name":"egressgateway-worker","kind":"Node"}
{"level":"info","ts":"2023-07-31T08:26:46.253Z","caller":"controller/egress_cluster_info.go:232","msg":"reconciling","kind":"Node","name":"egressgateway-worker"}
{"level":"info","ts":"2023-07-31T08:26:46.253Z","caller":"controller/egress_cluster_info.go:297","msg":"update event","kind":"Node","name":"egressgateway-worker"}
{"level":"info","ts":"2023-07-31T08:31:04.605Z","caller":"controller/egress_node.go:101","msg":"reconciling","name":"egressgateway-control-plane","kind":"Node"}
{"level":"info","ts":"2023-07-31T08:31:04.606Z","caller":"controller/egress_cluster_info.go:232","msg":"reconciling","kind":"Node","name":"egressgateway-control-plane"}
{"level":"info","ts":"2023-07-31T08:31:04.606Z","caller":"controller/egress_cluster_info.go:297","msg":"update event","kind":"Node","name":"egressgateway-control-plane"}
{"level":"info","ts":"2023-07-31T08:31:29.739Z","caller":"controller/egress_node.go:101","msg":"reconciling","name":"egressgateway-worker2","kind":"Node"}
{"level":"info","ts":"2023-07-31T08:31:29.739Z","caller":"controller/egress_cluster_info.go:232","msg":"reconciling","kind":"Node","name":"egressgateway-worker2"}
{"level":"info","ts":"2023-07-31T08:31:29.740Z","caller":"controller/egress_cluster_info.go:297","msg":"update event","kind":"Node","name":"egressgateway-worker2"}
{"level":"info","ts":"2023-07-31T08:31:53.086Z","caller":"controller/egress_node.go:101","msg":"reconciling","name":"egressgateway-worker","kind":"Node"}
{"level":"info","ts":"2023-07-31T08:31:53.086Z","caller":"controller/egress_cluster_info.go:232","msg":"reconciling","kind":"Node","name":"egressgateway-worker"}
{"level":"info","ts":"2023-07-31T08:31:53.087Z","caller":"controller/egress_cluster_info.go:297","msg":"update event","kind":"Node","name":"egressgateway-worker"}
{"level":"info","ts":"2023-07-31T08:36:12.132Z","caller":"controller/egress_node.go:101","msg":"reconciling","name":"egressgateway-control-plane","kind":"Node"}
{"level":"info","ts":"2023-07-31T08:36:12.132Z","caller":"controller/egress_cluster_info.go:232","msg":"reconciling","kind":"Node","name":"egressgateway-control-plane"}
{"level":"info","ts":"2023-07-31T08:36:12.133Z","caller":"controller/egress_cluster_info.go:297","msg":"update event","kind":"Node","name":"egressgateway-control-plane"}
{"level":"info","ts":"2023-07-31T08:36:35.394Z","caller":"controller/egress_cluster_info.go:232","msg":"reconciling","kind":"Node","name":"egressgateway-worker2"}
{"level":"info","ts":"2023-07-31T08:36:35.394Z","caller":"controller/egress_cluster_info.go:297","msg":"update event","kind":"Node","name":"egressgateway-worker2"}
{"level":"info","ts":"2023-07-31T08:36:35.394Z","caller":"controller/egress_node.go:101","msg":"reconciling","name":"egressgateway-worker2","kind":"Node"}
{"level":"info","ts":"2023-07-31T08:36:58.904Z","caller":"controller/egress_node.go:101","msg":"reconciling","name":"egressgateway-worker","kind":"Node"}
{"level":"info","ts":"2023-07-31T08:36:58.904Z","caller":"controller/egress_cluster_info.go:232","msg":"reconciling","kind":"Node","name":"egressgateway-worker"}
{"level":"info","ts":"2023-07-31T08:36:58.905Z","caller":"controller/egress_cluster_info.go:297","msg":"update event","kind":"Node","name":"egressgateway-worker"}

(2)什么事件没发生， controller pod  周期打印如下， 会把日志打爆， 另外，是基于事件触发的，什么实现 是基于了 周期性轮训 ？
{"level":"info","ts":"2023-07-31T08:46:23.543Z","caller":"controller/egress_node.go:101","msg":"reconciling","name":"egressgateway-control-plane","kind":"Node"}
{"level":"info","ts":"2023-07-31T08:46:23.543Z","caller":"controller/egress_cluster_info.go:232","msg":"reconciling","kind":"Node","name":"egressgateway-control-plane"}
{"level":"info","ts":"2023-07-31T08:46:23.544Z","caller":"controller/egress_cluster_info.go:297","msg":"update event","kind":"Node","name":"egressgateway-control-plane"}

(3) 什么事件没发生， agent pod  周期打印如下， 会把日志打爆。另外，是基于事件触发的，什么实现 是基于了 周期性轮训 ？
{"level":"info","ts":"2023-07-31T08:43:22.913Z","caller":"agent/vxlan.go:58","msg":"reconciling","name":"egressgateway-control-plane","kind":"EgressTunnel"}
{"level":"debug","ts":"2023-07-31T08:43:22.915Z","caller":"route/route.go:145","msg":"ensure rule","linkName":"egress.vxlan","table":643013051,"mark":643013051,"family":2}
{"level":"debug","ts":"2023-07-31T08:43:22.915Z","caller":"route/route.go:154","msg":"list rule","count":1}
{"level":"debug","ts":"2023-07-31T08:43:22.916Z","caller":"route/route.go:90","msg":"get link","linkName":"egress.vxlan","table":643013051,"mark":643013051}
{"level":"debug","ts":"2023-07-31T08:43:22.916Z","caller":"route/route.go:105","msg":"ensure route","linkName":"egress.vxlan","table":643013051,"mark":643013051,"family":2,"ip":"<IP_ADDRESS>"}
{"level":"debug","ts":"2023-07-31T08:43:22.916Z","caller":"route/route.go:105","msg":"ensure route","linkName":"egress.vxlan","table":643013051,"mark":643013051,"family":10,"ip":"<nil>"}
{"level":"info","ts":"2023-07-31T08:43:22.918Z","caller":"agent/vxlan.go:58","msg":"reconciling","name":"egressgateway-worker","kind":"EgressTunnel"}
{"level":"info","ts":"2023-07-31T08:43:22.919Z","caller":"agent/vxlan.go:58","msg":"reconciling","name":"egressgateway-worker2","kind":"EgressTunnel"}
{"level":"debug","ts":"2023-07-31T08:43:22.919Z","caller":"route/route.go:145","msg":"ensure rule","linkName":"egress.vxlan","table":647977681,"mark":647977681,"family":2}
{"level":"debug","ts":"2023-07-31T08:43:22.920Z","caller":"route/route.go:154","msg":"list rule","count":1}
{"level":"debug","ts":"2023-07-31T08:43:22.920Z","caller":"route/route.go:90","msg":"get link","linkName":"egress.vxlan","table":647977681,"mark":647977681}
{"level":"debug","ts":"2023-07-31T08:43:22.921Z","caller":"route/route.go:105","msg":"ensure route","linkName":"egress.vxlan","table":647977681,"mark":647977681,"family":2,"ip":"<IP_ADDRESS>"}
{"level":"debug","ts":"2023-07-31T08:43:22.921Z","caller":"route/route.go:105","msg":"ensure route","linkName":"egress.vxlan","table":647977681,"mark":647977681,"family":10,"ip":"<nil>"}
{"level":"info","ts":"2023-07-31T08:43:28.926Z","caller":"agent/police.go:721","msg":"reconciling","kind":"EgressPolicy","name":"test","namespace":"default"}
{"level":"debug","ts":"2023-07-31T08:43:28.927Z","caller":"agent/police.go:340","msg":"check ipset","ipset":"egress-src-v4-738bb014438bdbfe7"}
{"level":"debug","ts":"2023-07-31T08:43:28.927Z","caller":"agent/police.go:340","msg":"check ipset","ipset":"egress-dst-v4-738bb014438bdbfe7"}
{"level":"debug","ts":"2023-07-31T08:43:28.933Z","caller":"agent/police.go:376","msg":"add ipset entries","entries":[]}
{"level":"debug","ts":"2023-07-31T08:43:28.933Z","caller":"agent/police.go:376","msg":"add ipset entries","entries":[]}
{"level":"info","ts":"2023-07-31T08:43:28.968Z","caller":"agent/police.go:721","msg":"reconciling","kind":"EgressPolicy","name":"test","namespace":"default"}
{"level":"debug","ts":"2023-07-31T08:43:28.969Z","caller":"agent/police.go:340","msg":"check ipset","ipset":"egress-src-v4-738bb014438bdbfe7"}
{"level":"debug","ts":"2023-07-31T08:43:28.969Z","caller":"agent/police.go:340","msg":"check ipset","ipset":"egress-dst-v4-738bb014438bdbfe7"}
{"level":"debug","ts":"2023-07-31T08:43:28.975Z","caller":"agent/police.go:376","msg":"add ipset entries","entries":[]}
{"level":"debug","ts":"2023-07-31T08:43:28.975Z","caller":"agent/police.go:376","msg":"add ipset entries","entries":[]}
{"level":"debug","ts":"2023-07-31T08:43:29.166Z","caller":"agent/vxlan.go:346","msg":"link ensure has completed"}
{"level":"debug","ts":"2023-07-31T08:43:29.166Z","caller":"agent/vxlan.go:356","msg":"route ensure has completed"}
{"level":"debug","ts":"2023-07-31T08:43:29.167Z","caller":"route/route.go:145","msg":"ensure rule","linkName":"egress.vxlan","table":643013051,"mark":643013051,"family":2}
{"level":"debug","ts":"2023-07-31T08:43:29.167Z","caller":"route/route.go:154","msg":"list rule","count":1}
{"level":"debug","ts":"2023-07-31T08:43:29.168Z","caller":"route/route.go:90","msg":"get link","linkName":"egress.vxlan","table":643013051,"mark":643013051}
{"level":"debug","ts":"2023-07-31T08:43:29.168Z","caller":"route/route.go:105","msg":"ensure route","linkName":"egress.vxlan","table":643013051,"mark":643013051,"family":2,"ip":"<IP_ADDRESS>"}
{"level":"debug","ts":"2023-07-31T08:43:29.169Z","caller":"route/route.go:105","msg":"ensure route","linkName":"egress.vxlan","table":643013051,"mark":643013051,"family":10,"ip":"<nil>"}
{"level":"debug","ts":"2023-07-31T08:43:29.170Z","caller":"route/route.go:145","msg":"ensure rule","linkName":"egress.vxlan","table":647977681,"mark":647977681,"family":2}
{"level":"debug","ts":"2023-07-31T08:43:29.170Z","caller":"route/route.go:154","msg":"list rule","count":1}
{"level":"debug","ts":"2023-07-31T08:43:29.171Z","caller":"route/route.go:90","msg":"get link","linkName":"egress.vxlan","table":647977681,"mark":647977681}
{"level":"debug","ts":"2023-07-31T08:43:29.171Z","caller":"route/route.go:105","msg":"ensure route","linkName":"egress.vxlan","table":647977681,"mark":647977681,"family":2,"ip":"<IP_ADDRESS>"}
{"level":"debug","ts":"2023-07-31T08:43:29.171Z","caller":"route/route.go:105","msg":"ensure route","linkName":"egress.vxlan","table":647977681,"mark":647977681,"family":10,"ip":"<nil>"}
{"level":"debug","ts":"2023-07-31T08:43:29.173Z","caller":"agent/vxlan.go:376","msg":"route rule ensure has completed"}
{"level":"info","ts":"2023-07-31T08:43:30.115Z","caller":"agent/police.go:537","msg":"reconciling","kind":"EgressClusterInfo","name":"default"}
{"level":"info","ts":"2023-07-31T08:43:30.463Z","caller":"agent/eip.go:134","msg":"","event":"announced interface to exclude","interface":"cali2c157879001"}
{"level":"info","ts":"2023-07-31T08:43:30.464Z","caller":"agent/eip.go:134","msg":"","event":"announced interface to exclude","interface":"cali9f508428a80"}
{"level":"info","ts":"2023-07-31T08:43:30.518Z","caller":"agent/police.go:679","msg":"reconciling","kind":"EgressGateway"}
{"level":"info","ts":"2023-07-31T08:43:30.518Z","caller":"agent/police.go:109","msg":"apply policy"}
{"level":"info","ts":"2023-07-31T08:43:30.518Z","caller":"agent/eip.go:36","msg":"reconcile","name":"default","kind":"EgressGateway"}
{"level":"debug","ts":"2023-07-31T08:43:30.524Z","caller":"agent/police.go:340","msg":"check ipset","ipset":"egress-src-v4-738bb014438bdbfe7"}
{"level":"debug","ts":"2023-07-31T08:43:30.524Z","caller":"agent/police.go:340","msg":"check ipset","ipset":"egress-dst-v4-738bb014438bdbfe7"}
{"level":"debug","ts":"2023-07-31T08:43:30.530Z","caller":"agent/police.go:376","msg":"add ipset entries","entries":[]}
{"level":"debug","ts":"2023-07-31T08:43:30.530Z","caller":"agent/police.go:376","msg":"add ipset entries","entries":[]}
{"level":"debug","ts":"2023-07-31T08:43:30.531Z","caller":"iptables/table.go:312","msg":"updating rule insertions","table":"filter","ipVersion":4,"chainName":"FORWARD"}
{"level":"debug","ts":"2023-07-31T08:43:30.531Z","caller":"iptables/table.go:755","msg":"invalidating dataplane cache","table":"filter","ipVersion":4,"reason":"insertion"}
{"level":"debug","ts":"2023-07-31T08:43:30.531Z","caller":"iptables/table.go:312","msg":"updating rule insertions","table":"filter","ipVersion":4,"chainName":"OUTPUT"}
{"level":"debug","ts":"2023-07-31T08:43:30.531Z","caller":"iptables/table.go:752","msg":"would invalidate dataplane cache but it was already invalid","table":"filter","ipVersion":4,"reason":"insertion"}
{"level":"info","ts":"2023-07-31T08:43:30.531Z","caller":"iptables/table.go:350","msg":"queueing update of chain.","table":"mangle","ipVersion":4,"chainName":"EGRESSGATEWAY-MARK-REQUEST"}
{"level":"debug","ts":"2023-07-31T08:43:30.532Z","caller":"iptables/table.go:755","msg":"invalidating dataplane cache","table":"mangle","ipVersion":4,"reason":"chain update"}
{"level":"debug","ts":"2023-07-31T08:43:30.532Z","caller":"iptables/table.go:312","msg":"updating rule insertions","table":"mangle","ipVersion":4,"chainName":"FORWARD"}
{"level":"debug","ts":"2023-07-31T08:43:30.532Z","caller":"iptables/table.go:752","msg":"would invalidate dataplane cache but it was already invalid","table":"mangle","ipVersion":4,"reason":"insertion"}
{"level":"debug","ts":"2023-07-31T08:43:30.532Z","caller":"iptables/table.go:312","msg":"updating rule insertions","table":"mangle","ipVersion":4,"chainName":"POSTROUTING"}
{"level":"debug","ts":"2023-07-31T08:43:30.533Z","caller":"iptables/table.go:752","msg":"would invalidate dataplane cache but it was already invalid","table":"mangle","ipVersion":4,"reason":"insertion"}
{"level":"debug","ts":"2023-07-31T08:43:30.533Z","caller":"iptables/table.go:312","msg":"updating rule insertions","table":"mangle","ipVersion":4,"chainName":"PREROUTING"}
{"level":"debug","ts":"2023-07-31T08:43:30.533Z","caller":"iptables/table.go:421","msg":"incref chain","table":"mangle","ipVersion":4,"chainName":"EGRESSGATEWAY-MARK-REQUEST"}
{"level":"debug","ts":"2023-07-31T08:43:30.533Z","caller":"iptables/table.go:432","msg":"decref chain","table":"mangle","ipVersion":4,"chainName":"EGRESSGATEWAY-MARK-REQUEST"}
{"level":"debug","ts":"2023-07-31T08:43:30.534Z","caller":"iptables/table.go:752","msg":"would invalidate dataplane cache but it was already invalid","table":"mangle","ipVersion":4,"reason":"insertion"}
{"level":"info","ts":"2023-07-31T08:43:30.534Z","caller":"iptables/table.go:350","msg":"queueing update of chain.","table":"mangle","ipVersion":4,"chainName":"EGRESSGATEWAY-MARK-REQUEST"}
{"level":"debug","ts":"2023-07-31T08:43:30.535Z","caller":"iptables/table.go:752","msg":"would invalidate dataplane cache but it was already invalid","table":"mangle","ipVersion":4,"reason":"chain update"}
{"level":"info","ts":"2023-07-31T08:43:30.535Z","caller":"iptables/table.go:350","msg":"queueing update of chain.","table":"nat","ipVersion":4,"chainName":"EGRESSGATEWAY-SNAT-EIP"}
{"level":"debug","ts":"2023-07-31T08:43:30.535Z","caller":"iptables/table.go:755","msg":"invalidating dataplane cache","table":"nat","ipVersion":4,"reason":"chain update"}
{"level":"debug","ts":"2023-07-31T08:43:30.535Z","caller":"iptables/table.go:312","msg":"updating rule insertions","table":"nat","ipVersion":4,"chainName":"POSTROUTING"}
{"level":"debug","ts":"2023-07-31T08:43:30.536Z","caller":"iptables/table.go:421","msg":"incref chain","table":"nat","ipVersion":4,"chainName":"EGRESSGATEWAY-SNAT-EIP"}
{"level":"debug","ts":"2023-07-31T08:43:30.536Z","caller":"iptables/table.go:432","msg":"decref chain","table":"nat","ipVersion":4,"chainName":"EGRESSGATEWAY-SNAT-EIP"}
{"level":"debug","ts":"2023-07-31T08:43:30.536Z","caller":"iptables/table.go:752","msg":"would invalidate dataplane cache but it was already invalid","table":"nat","ipVersion":4,"reason":"insertion"}
{"level":"info","ts":"2023-07-31T08:43:30.536Z","caller":"iptables/table.go:779","msg":"updating post-write interval","table":"nat","ipVersion":4,"newPostWriteInterval":"100ms"}
{"level":"debug","ts":"2023-07-31T08:43:30.536Z","caller":"iptables/table.go:752","msg":"would invalidate dataplane cache but it was already invalid","table":"nat","ipVersion":4,"reason":"post update"}
{"level":"info","ts":"2023-07-31T08:43:30.537Z","caller":"iptables/table.go:779","msg":"updating post-write interval","table":"nat","ipVersion":4,"newPostWriteInterval":"200ms"}
{"level":"info","ts":"2023-07-31T08:43:30.537Z","caller":"iptables/table.go:779","msg":"updating post-write interval","table":"nat","ipVersion":4,"newPostWriteInterval":"400ms"}
{"level":"info","ts":"2023-07-31T08:43:30.537Z","caller":"iptables/table.go:779","msg":"updating post-write interval","table":"nat","ipVersion":4,"newPostWriteInterval":"800ms"}
{"level":"info","ts":"2023-07-31T08:43:30.537Z","caller":"iptables/table.go:779","msg":"updating post-write interval","table":"nat","ipVersion":4,"newPostWriteInterval":"1.6s"}
{"level":"info","ts":"2023-07-31T08:43:30.537Z","caller":"iptables/table.go:779","msg":"updating post-write interval","table":"nat","ipVersion":4,"newPostWriteInterval":"3.2s"}
{"level":"info","ts":"2023-07-31T08:43:30.537Z","caller":"iptables/table.go:779","msg":"updating post-write interval","table":"nat","ipVersion":4,"newPostWriteInterval":"6.4s"}
{"level":"info","ts":"2023-07-31T08:43:30.537Z","caller":"iptables/table.go:779","msg":"updating post-write interval","table":"nat","ipVersion":4,"newPostWriteInterval":"12.8s"}
{"level":"info","ts":"2023-07-31T08:43:30.537Z","caller":"iptables/table.go:779","msg":"updating post-write interval","table":"nat","ipVersion":4,"newPostWriteInterval":"25.6s"}
{"level":"debug","ts":"2023-07-31T08:43:30.537Z","caller":"iptables/table.go:443","msg":"loading current iptables state and checking it is correct","table":"nat","ipVersion":4}
{"level":"debug","ts":"2023-07-31T08:43:30.547Z","caller":"iptables/table.go:674","msg":"parsing line","table":"nat","ipVersion":4,"line":"# Generated by iptables-nft-save v1.8.7 on Mon Jul 31 08:43:30 2023"}
{"level":"debug","ts":"2023-07-31T08:43:30.547Z","caller":"iptables/table.go:700","msg":"not an append, skipping","table":"nat","ipVersion":4,"line":"# Generated by iptables-nft-save v1.8.7 on Mon Jul 31 08:43:30 2023"}
{"level":"debug","ts":"2023-07-31T08:43:30.548Z","caller":"iptables/table.go:674","msg":"parsing line","table":"nat","ipVersion":4,"line":"*nat"}
{"level":"debug","ts":"2023-07-31T08:43:30.548Z","caller":"iptables/table.go:700","msg":"not an append, skipping","table":"nat","ipVersion":4,"line":"*nat"}
{"level":"debug","ts":"2023-07-31T08:43:30.548Z","caller":"iptables/table.go:674","msg":"parsing line","table":"nat","ipVersion":4,"line":":PREROUTING ACCEPT [7:500]"}
{"level":"debug","ts":"2023-07-31T08:43:30.548Z","caller":"iptables/table.go:690","msg":"found forward-reference","table":"nat","ipVersion":4,"line":":PREROUTING ACCEPT [7:500]","chainName":"PREROUTING"}
{"level":"debug","ts":"2023-07-31T08:43:30.548Z","caller":"iptables/table.go:674","msg":"parsing line","table":"nat","ipVersion":4,"line":":INPUT ACCEPT [5:380]"}
{"level":"debug","ts":"2023-07-31T08:43:30.549Z","caller":"iptables/table.go:690","msg":"found forward-reference","table":"nat","ipVersion":4,"line":":INPUT ACCEPT [5:380]","chainName":"INPUT"}
{"level":"debug","ts":"2023-07-31T08:43:30.549Z","caller":"iptables/table.go:674","msg":"parsing line","table":"nat","ipVersion":4,"line":":OUTPUT ACCEPT [22424:1345588]"}
{"level":"debug","ts":"2023-07-31T08:43:30.549Z","caller":"iptables/table.go:690","msg":"found forward-reference","table":"nat","ipVersion":4,"line":":OUTPUT ACCEPT [22424:1345588]","chainName":"OUTPUT"}
{"level":"debug","ts":"2023-07-31T08:43:30.549Z","caller":"iptables/table.go:674","msg":"parsing line","table":"nat","ipVersion":4,"line":":POSTROUTING ACCEPT [22560:1356145]"}
{"level":"debug","ts":"2023-07-31T08:43:30.550Z","caller":"iptables/table.go:690","msg":"found forward-reference","table":"nat","ipVersion":4,"line":":POSTROUTING ACCEPT [22560:1356145]","chainName":"POSTROUTING"}
{"level":"debug","ts":"2023-07-31T08:43:30.550Z","caller":"iptables/table.go:674","msg":"parsing line","table":"nat","ipVersion":4,"line":":DOCKER_OUTPUT - [0:0]"}
{"level":"debug","ts":"2023-07-31T08:43:30.550Z","caller":"iptables/table.go:690","msg":"found forward-reference","table":"nat","ipVersion":4,"line":":DOCKER_OUTPUT - [0:0]","chainName":"DOCKER_OUTPUT"}
{"level":"debug","ts":"2023-07-31T08:43:30.550Z","caller":"iptables/table.go:674","msg":"parsing line","table":"nat","ipVersion":4,"line":":DOCKER_POSTROUTING - [0:0]"}
{"level":"debug","ts":"2023-07-31T08:43:30.551Z","caller":"iptables/table.go:690","msg":"found forward-reference","table":"nat","ipVersion":4,"line":":DOCKER_POSTROUTING - [0:0]","chainName":"DOCKER_POSTROUTING"}
{"level":"debug","ts":"2023-07-31T08:43:30.551Z","caller":"iptables/table.go:674","msg":"parsing line","table":"nat","ipVersion":4,"line":":EGRESSGATEWAY-SNAT-EIP - [0:0]"}
{"level":"debug","ts":"2023-07-31T08:43:30.551Z","caller":"iptables/table.go:690","msg":"found forward-reference","table":"nat","ipVersion":4,"line":":EGRESSGATEWAY-SNAT-EIP - [0:0]","chainName":"EGRESSGATEWAY-SNAT-EIP"}
{"level":"debug","ts":"2023-07-31T08:43:30.551Z","caller":"iptables/table.go:674","msg":"parsing line","table":"nat","ipVersion":4,"line":":KUBE-KUBELET-CANARY - [0:0]"}
{"level":"debug","ts":"2023-07-31T08:43:30.551Z","caller":"iptables/table.go:690","msg":"found forward-reference","table":"nat","ipVersion":4,"line":":KUBE-KUBELET-CANARY - [0:0]","chainName":"KUBE-KUBELET-CANARY"}
{"level":"debug","ts":"2023-07-31T08:43:30.552Z","caller":"iptables/table.go:674","msg":"parsing line","table":"nat","ipVersion":4,"line":":KUBE-MARK-MASQ - [0:0]"}
{"level":"debug","ts":"2023-07-31T08:43:30.552Z","caller":"iptables/table.go:690","msg":"found forward-reference","table":"nat","ipVersion":4,"line":":KUBE-MARK-MASQ - [0:0]","chainName":"KUBE-MARK-MASQ"}
{"level":"debug","ts":"2023-07-31T08:43:30.552Z","caller":"iptables/table.go:674","msg":"parsing line","table":"nat","ipVersion":4,"line":":KUBE-NODEPORTS - [0:0]"}
{"level":"debug","ts":"2023-07-31T08:43:30.552Z","caller":"iptables/table.go:690","msg":"found forward-reference","table":"nat","ipVersion":4,"line":":KUBE-NODEPORTS - [0:0]","chainName":"KUBE-NODEPORTS"}
{"level":"debug","ts":"2023-07-31T08:43:30.553Z","caller":"iptables/table.go:674","msg":"parsing line","table":"nat","ipVersion":4,"line":":KUBE-POSTROUTING - [0:0]"}

这些信息是比较重要的，做一些合并，减少日志量；
kubelet 的 Node 的更新事件触发的；
这个是 agent 定期维护 policy 规则，确保第三方例如用户误删除，会尽快恢复。


Automated cherry pick of #6670: get snapshots order by created at asc

Cherry pick of #6670 on release/3.2.
#6670: get snapshots order by created at asc

Codecov Report

Merging #6671 into release/3.2 will decrease coverage by 0.00%.
The diff coverage is 0.00%.

@@               Coverage Diff               @@
##           release/3.2    #6671      +/-   ##
===============================================
- Coverage         7.03%    7.03%   -0.01%
===============================================
  Files              650      650
  Lines           111812   111821       +9
===============================================
- Hits              7869     7865       -4
- Misses          103334   103347      +13
  Partials           609      609

Flag
Coverage Δ

#aFlag
7.03% <0.00%> (-0.01%)
:arrow_down:

Impacted Files
Coverage Δ

pkg/baremetal/tasks/bm_register.go
0.00% <0.00%> (ø)

pkg/baremetal/tasks/ipmiprobe.go
0.00% <0.00%> (ø)

pkg/cloudcommon/db/namevalidator.go
0.00% <0.00%> (ø)

pkg/cloudcommon/db/opslog.go
1.50% <0.00%> (-0.01%)
:arrow_down:

pkg/cloudcommon/db/scoperesource.go
0.00% <0.00%> (ø)

pkg/cloudcommon/db/tenantcache.go
2.93% <0.00%> (-0.35%)
:arrow_down:

pkg/cloudcommon/policy/resources.go
0.00% <ø> (ø)

pkg/cloudprovider/cloudprovider.go
1.53% <0.00%> (ø)

pkg/cloudprovider/instance.go
0.00% <ø> (ø)

pkg/cloudprovider/objectstore.go
2.48% <0.00%> (-0.01%)
:arrow_down:

... and 22 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update f330d01...41673a5. Read the comment docs.


Add support for javascript / typescript functions as queries

Use case: Allow a user to run a javascript query independently from any job.
Extensions to existing query context:

get access to entities or changes of any dataset (security allowing)
write to the response incrementally.

This is implemented


Unexpected Token

Getting the following error while building:
SyntaxError: Unexpected token: name (MultiStep) [./~/react-multistep/src/index.js:2,0]
Running React 15.5.4

Couldnt get it sorted out with different babel presets. So I just pulled MultiStep out of the node module and threw it in a Util folder within my app.

will check this weekend, thanks!

swamped... is this still a problem?

Yes its still a problem

I believe the problem is that the package is published to npm without the dist folder. https://npm.runkit.com/react-multistep Testing here fails too.

thank you for including repro @sriram-dev - will take a look asap

Same problem here.
/node_modules/react-multistep/src/index.js:2 import MultiStep from './multistep' ^^^^^^ SyntaxError: Unexpected token import
Thanks!

hmm, I cannot reproduce... can somebody outline steps to get this error, please?
thanks!

I'm getting unexpected token import too
I npm installed the latest version and just followed the docs

sorry to hear that.... long weekend ahead, will try to find some time to look into it...

@srdjan no worries... I was looking at this component as a POC for a functionality I was building.  Decided to go another direction

cool, as you can see I don't have much time to put in here...
but, happy that you found the way...


[Java Client] Send CloseProducer on timeout

Motivation
When producer creation times out, send the CloseProducer before sending a command to recreate the Producer. This ensures a better time to recovery.
This issue was discussed on the mailing list here, https://lists.apache.org/thread/tko0z4jg0oq0yf931rbow2zf9fq8wjt1. The protocol spec has already been updated to indicate that this is the correct client behavior https://github.com/apache/pulsar/pull/12948.
Modifications

Update the java client to send CloseProducer when the producer creation times out.
Add tests.
Clean up some comments and unnecessary calls to close() in the modified test file.

Verifying this change
I added tests to verify this change.
Does this pull request potentially affect one of the following parts:
There are no breaking changes. This is an improvement to the protocol. The previous implementation was valid, but not ideal.
Documentation

[x] no-need-doc
Docs were added here: https://github.com/apache/pulsar/pull/12948

/pulsarbot run-failure-checks

/pulsarbot run-failure-checks

/pulsarbot run-failure-checks


#Post: elastic/ATT&CK Navigator integration

Stand up elastic stack instance and ingest forensic artefacts, similar to the custom elrond Splunk app

May need to leverage elrond Splunk app for ATT&CK navigator integration


meta: load md5

Codecov Report
Base: 57.69% // Head: 57.61% // Decreases project coverage by -0.08% :warning:

Coverage data is based on head (5d5cbc4) compared to base (f0c15e5).
Patch has no changes to coverable lines.

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #166      +/-   ##
==========================================
- Coverage   57.69%   57.61%   -0.09%
==========================================
  Files          40       40
  Lines        2437     2437
  Branches      435      354      -81
==========================================
- Hits         1406     1404       -2
- Misses        950      952       +2
  Partials       81       81

Impacted Files
Coverage Δ

src/dvc_data/hashfile/meta.py
69.04% <ø> (ø)

src/dvc_data/hashfile/build.py
73.80% <0.00%> (-1.59%)
:arrow_down:

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

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


Comment old OPG implementation

👷 Deploy Preview for balkantransport processing.
🔨 Explore the source changes: a067a9667e3c5f7bb96eec8967bd0b3970c34583
🔍 Inspect the deploy log: https://app.netlify.com/sites/balkantransport/deploys/6234c9561dd94f0009d97ddc


Liyou/review/enable shared memory backend

@rdelfin last PR to upstream to the rules_ros2 repo, would much appreciate your review.

@robin-wayve would you mind checking this from an IP point of view for up-streaming please?


[FEATURE] ⏲ Better timestamping

Problem
FusionCache currently does not keep track the logical moment when a cache value has been set the first time.
This can useful in general, and in particular for example in scenarios like when comparing 2 different entries, both stale, one found in the memory cache and one in the distributed cache: one may be more fresh than the other, so FusionCache can decide which one is better to use.
Solution
Add an internal Timestamp property to each entry, with the value being when the entry has been logically created.
Here "logically" means not when the entry instance has been created, but the original one: for example when an entry is taken from the distributed cache and ported over to the memory cache in a typical "get" flow (first check memory cache, then distributed cache, then copy over the data) the timestamp should remain the one found in the distributed cache, so that it represents the point in time of when the cached value has been created.
This can also be useful in scenarios when multiple nodes may call the factory in rapid succession, very near in time between each others: with this new piece of information FusionCache can make better decisions on what to keep and what to use as the most fresh piece of data.
Additional context
Because of gradual upgrades and the way some serializes work, it has been observed that it would be better to make the field nullable and handle the null case explicitly, otherwise there may be problems while updating to the new version of FusionCache for existing users with an already populated distributed cache, containing entries serialized with the old format that may have problems deserializing in the new format.

Hi all, v0.22.0 has been released and this is included 🎉


Timeout waiting for connection from client app

as title said.

I’ll need a bit more information if possible.

sorry, I found that the error presented because I didn't run the app yet.


rust 1.26.1 compatibility

Adds :: to the front of all std namespaces.
My previous PR did not do that, but this is important for downstream crates that want to guarantee support for older rust versions.
This also bumps the patch version, as the API has not changed, and no new features have been added.

Thanks for that. I completely missed the PR 😢