Feature: Shorten the time to build multi-arch images

Motivation:

Waiting ~1h 20 min for the images to build is a bit long, with the CI pipeline taking more than 2 hours to complete,  shortening the building phase of the CI could decrease the time for the CI to complete substantially while also given faster feedback to the changes made in the codebase.
Description:

When making changes in only a single service the build times are reasonable, around ~10 mins, however, if any source file is changed that is common to all services they all need to be rebuild and the build times are at ~1h. When the E2E tests also fail making a fix for the issue repeats the cycle where the images need to be build waiting another ~1hour before the E2E tests run.
Exit criteria:

[ ] Shorten the time for building multi-arch images

big thumbs up.
we could explore using GOARCH for Go cross-compilation instead of QEMU; most of the stuff going into the images is written in Go anyway. the build artifacts could then be included into their respective images during the multi-arch build stage (using $VARIABLES FTW).


Email Test Service Partial Outage

Good Morning
We are currently aware of the issues affecting the Email Test Service autoresponder.
It’s been reported that there’s some funky code being sent with the mail, and that it isn’t detecting appropriate values as required (see screenshot below).
We’re currently working towards a solution as this issue should not be occurring.
If you require use of this service, please contact us via the CRM.
Thank You, we hope to have updates soon. - MPM

The Monday rain has come along and washed away the issue cause.
All systems now operational with the Email Test Service! - MPM


Discard incorret unused sleep define

Usually it is x / 1000 not * 1000. Anyway the sleep function is not called in the code so it is safe to remove IMO. Please double check.

Sleep() takes milliseconds, sleep() takes seconds, so multiplying is correct. Maybe you're thinking of usleep()?
But yes, it is unused.

Sleep() takes milliseconds, sleep() takes seconds, so multiplying is correct. Maybe you're thinking of usleep()?
But yes, it is unused.
e: And it is incorrect, though for another reason - sleep(2+2) would end up sleeping for 2+2*1000 = 2002 milliseconds.

My bad, you are correct!


Revert "Remove --no-module-directories"

Reverts Azure/azure-sdk-for-java#41777 to unblock cosmos release.

/check-enforcer override

/check - enforcer override

FYI, this doesn't fix the issue, so we can skip merging this in.
cc: @alzimmermsft @JimSuplizio

I'm going to close this down, this isn't the fix.


"Landing Page": Missing Feature/Label

Defect: There is no indication of which page of the 4 is the landing page when the site is first accessed.
Location: Navigation Tab Page
Recommended Fix:  Determining and clarifying which one of the 4 pages will be the 'homepage"/"landing page" for the website.
Criticality: Low

This is a non-issue thanks


[docs] add quantized training paper to docs

Contributes to #5606.
Adds the quantized training paper to the README alongside other papers.
@shiyu1994 @guolinke are there any others you'd like me to add?

Thank you!


Can Gradle 4.9 be used to automatically configure APT when using Buildship?

This may be wishful thinking, but I really want to avoid executing "eclipseFactorypath", "eclipseJdtApt" and "eclipseJdt" every time when importing projects into Eclipse or when the factorypath changes. (There is no way I can convince my colleages to do this).
I've just read the Gradle 4.9 rc-1 release notes, where it states:

The EclipseClasspath and EclipseProject tasks both accept beforeMerged and whenMerged closures, for advanced Eclipse-specific customisation.
Previous versions of Gradle did not execute the closures defined in EclipseProject when invoked from Buildship (only those in EclipseClasspath). Now Gradle executes them both, similarly to when invoked from the command-line.

Can this be used to avoid the need to manually execute said tasks?

Can this be used to avoid the need to manually execute said tasks?

No. Those tasks (and their closures) only deal with the .project and .classpath files; eclipseFactorypath, eclipseJdt and eclipseJdtApt all deal with different configuration files.
Follow https://github.com/eclipse/buildship/issues/329 and https://github.com/gradle/gradle/issues/2300 for better Buildship and Gradle integration of annotation processors.


Switch default plot aggregator from MinMax to MinMaxAverage

This will produce a less jagged plot
Before:

After:

Checklist

[x] I have read and agree to Contributor Guide and the Code of Conduct
[x] I've included a screenshot or gif (if applicable)
[x] I have tested the web demo (if applicable):

Using examples from latest main build: rerun.io/viewer
Using full set of examples from nightly build: rerun.io/viewer

[x] The PR title and labels are set such as to maximize their usefulness for the next release's CHANGELOG
[x] If applicable, add a new check to the release checklist!

PR Build Summary
Recent benchmark results
Wasm size tracking

To run all checks from main, comment on the PR with @rerun-bot full-check.

Yeah, I've changed my mind.
"Misleading when zoomed out" seems to be the default in the industry.
I'd rather have the width change to span min-max (https://github.com/rerun-io/rerun/issues/4969) but that's a lot more work.
We've had customers complain out the jagged plots.

well alternatively we could just aggregate less, that should in the limit have the same result

that's also what was proposed as the solution back then - if we have a sample per half-pixel then we should be fine

I've changed my mind again. Looking at how awful the plot aggregator in PostHog is I am now convinced that I rather have jagged, ugly plots, than misleading ones.


Select textures don't work but others do! (Solved)

The issue
I have a texture pack for 1.21 that im making which has a bunch of 3d weapon models that i have made and added as a big pack. In 1.20.1 the textures were working (all of them), now after downloading 1.21 version and the same pack, they dont work. A couple of them work as i will show in images, but the others ones dont and i cant figure out why. Please help! (My discord user is tophat_64 Ping me there if you can)

The name of the ones that work are -
Swords -
1MoreKill
NightFall
VoidHeart
Puma Blade
Axes -
Abyssal Fury
Equilibrium
Ones i would like to work are "LongHat", "ShortHat", "Striker" (All of them were made in blockbench)
Here is the pack for 1.21 fabric
https://github.com/user-attachments/files/17532012/TopHat.s.Weapons.zip
How to reproduce

Download this version of cit resewn.

(On feather client which is what im using)

Launch game and name the appropriate tools the names.

some work and some don't.

Logs
https://pastebin.com/mqmyeFLX
Checklist

[X] I checked the issues(both open and closed) and could not find a duplicate of my issue
[X] I am using the latest version of CIT Resewn for my Minecraft version
[X] I have disabled Broken Paths and the issue persists
[X] I am running the mod using Fabric Loader

I found the issue. It was related to me baming the .json, .properties and texture files as capital. When i retyped them in lower case, they worked. (Ex- ‘Example’ won’t work, but if i type ‘example’ as a name then it works)

It is solved.


feat: Add support for Turborepo Remote Cache to the build workflow

Just a thought: Do we still use all the labels that are available in product web?

Just a thought: Do we still use all the labels that are available in product web?

@mortenbroesby I don't think it's related to this PR but feel free to add a ticket to triage to clean up the labels 👍


Add job to lint on pull request

Pull request checklist
Before submitting your PR, please review the following checklist:

[x] Consider adding a unit test if your PR resolves an issue.
[x] All new and existing tests pass locally (palm test)
[x] Lint (palm lint) has passed locally and any fixes were made for failures
[x] Docs have been reviewed and added / updated if needed (for bug fixes / features)

Breaking changes

[ ] Check if this pull request introduces a breaking change

What does this implement/fix? Explain your changes.
Add a GH action job to lint code on PRs

The irony of so many changes caused by linting on the linting PR

I like to think of it as highlighting how many problems this change will prevent in the future ;)


8312.2 Run master_integration_fields.sql from /api/db/initialize

Shippable/pm#8312

Write master_integration_fields.sql. This should:

If there is no masterIntegrationFields table, create the table with default values
If a column doesn't exist, create that column
Insert all masterIntegrationFields in the existing base scripts.
Add fields for the following new masterIntegrations:

rabbitmq

ampqUrl
amqpUrlRoot
amqpUrlAdmin
amqpDefaultExchange
rootQueueList

redis

redisUrl

www

wwwUrl
wwwPort

mktg

mktgUrl
mktgPort

Run this script in /api/db/initialize

complete. closing.


Fix sample data

Describe your changes :

Sorry folks, Working on #4131 I messed up git somehow pushed without PR, breaking the sample data.
This PR fixes it.
Thanks,

Type of change :

[x] Bug fix
[x] Improvement
[x] New feature
[] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[] Documentation

Frontend Preview (Screenshots) :
For frontend related change, please link screenshots of your changes preview! Optional for backend related changes.

Checklist:

[x] I have read the CONTRIBUTING document.
[ ] I have commented on my code, particularly in hard-to-understand areas.
[ ] I have added tests that prove my fix is effective or that my feature works.
[x] All new and existing tests passed.

Reviewers

checking the failing tests


Update to 0.7.0

Update to 0.7.0

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.


MySQL error on profile page

Found a bug? Please fill out the sections below.
Issue Summary
Viewing the account profile page (/account/profile) brings about this error from Django:
ProgrammingError at /accounts/profile/
(1064, 'You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '."id" FROM "catalogue_category" AS "CATALOGUE_CATEGORY_BASE"\nLEFT JOIN "catalogu' at line 2')
Steps to Reproduce
Log in to Oscar
View the account profile page
Any other relevant information. For example, why do you consider this a bug and what did you expect to happen instead?
It seems like a query template isn't being resolved here.   Haven't found the reason yet.

Hi. Just want to leave my five cents for people like me who have this error. In case of MariaDB 11.4 setting SET sql_mode = 'ANSI_QUOTES'; helped me.


How to select edge of part in particular drawing view to attach balloon's leader to it using SolidWorks API?

Using SolidWorks API in drawing sheet, How can I automate balloons at exact location and attach arrow(Balloon leaders) to the defined an edge(silhouette, face, or vertex) of part in the particular view(Section view and details view of section view)?
Please find the attachment for review the code and test it with Assy.SLDDRW.
Assy.zip

Hi Rashish,
Thank you for the ticket and the sample model. Please take a look at this macro: Insert BOM Balloons. It demonstrates how to add all balloons one-by-one (not an auto balloons) to the first drawing view and attach the leader to the center of the corresponding edge and also align the balloon itself by offsetting by 10 mm in X and Y.
The above example adds the balloon to the first edge found. Here is another example which can be useful which demonstrates how to find and select the specific edge: Find and select specific edge in the drawing view


CheckInventory action doesn't work on non-player entities

Unsure if this is a bug or intended, but 'CheckInventory' does not seem to be able to check entities inventories at the moment. I'm currently trying to run a spell on mobs that will check what item they are wearing/holding and to run actions depending on the result (mostly as a way to set and save data to work around the issue #1217 ). Unfortunately through most of my attempts, the spells don't seem to recognize/pass an entity other than a player for CheckInventory.
E.g. I tried casting a test spell that checks if the target has 'leather_leggings' in their inventory and sends the message "true" to the caster. I tested on both a player and a zombie wearing leggings, but it only worked for the player

That action is not made to look at non-players.
It could probably be re-worked to do so, but would time be better spent trying to figure out #1217?

I just viewed your comment in #1298 about the save_non_player_mages configuration which actually turned out to solve the entirety of #1217 for my usecase! I feel silly for not noticing the config option previously, but it has completely fixed the issues I was having with attributes not saving. :sob:


Only log.info() messages are output in catch() when the level is set to info

I set the log level to info. I try() executing a command and catch() its output. In catch(), I’d like to output some messages based on the log level. However, only info messages are output.
Note that when I set the log level to trace, besides info messages, debug messages are output too.
IMHO, all messages up to the set level should be output.
log.setLevel('info')

catch (error) {
	log.trace('trace')
	log.debug('debug')
	log.info('info')
	log.warn('warn')
	log.error('error')
}

Can you provide an example to reproduce this issue? Which version of loglevel are you using, in what environment?
Otherwise as far as I can tell this already works correctly, and this is well-tested & in widespread use in all sorts of places. Testing your code in a node REPL for example:
> const log = require('loglevel')
undefined
> log.setLevel('info')
undefined
> try {
...     throw new Error();
... } catch (error) {
... 	log.trace('trace')
... 	log.debug('debug')
... 	log.info('info')
... 	log.warn('warn')
... 	log.error('error')
... }
info
warn
error

As expected - info, warn & error all log, and trace & debug are excluded.
Can you share more details about your setup, so I can reproduce the behaviour you're describing myself?

Can you provide an example to reproduce this issue? Which version of loglevel are you using, in what environment?
Otherwise as far as I can tell this already works correctly, and this is well-tested & in widespread use in all sorts of places. Testing your code in a node REPL for example:
> const log = require('loglevel')
undefined
> log.setLevel('info')
undefined
> try {
...     throw new Error();
... } catch (error) {
... 	log.trace('trace')
... 	log.debug('debug')
... 	log.info('info')
... 	log.warn('warn')
... 	log.error('error')
... }
info
warn
error

As expected - info, warn & error all log, and trace & debug are excluded.
Can you share more details about your setup, so I can reproduce the behaviour you're describing myself?

FYI, I installed loglevel 1.7.1 via npm on Fedora 31 x86_64 (Workstation) and on CentOS 8 (non-Stream, minimal server).
However, now I can’t reproduce the behaviour. However, I am sure it didn’t work in my case (even with the MWE). It always worked with info level, but not with warn level.
Sorry I opened an issue I can’t reproduce anymore. :disappointed:

FYI, I installed loglevel 1.7.1 via npm on Fedora 31 x86_64 (Workstation) and on CentOS 8 (non-Stream, minimal server).
However, now I can’t reproduce the behaviour. However, I am sure it didn’t work in my case (even with the MWE). It always worked with info level, but not with warn level.
Sorry I opened an issue I can’t reproduce anymore. :disappointed:

Fair enough, no worries!
I'm going to close this for now since there's nothing really I can do to investigate, but if you or anybody else manages to reproduce this then do let me know, I'm very happy to look into it further.

Fair enough, no worries!
I'm going to close this for now since there's nothing really I can do to investigate, but if you or anybody else manages to reproduce this then do let me know, I'm very happy to look into it further.


New command: Load trajectory

This will give a convenience for loading an existing trajectory from an external file into an OPS file.
Although it is loading into the OpenMM snapshot format, this is mainly because that is internally stored. We should be able to write out to most MD-based engines based on that internal format.
TODO:

[x] Tests

This is ready for review and comment. Without review, I will merge this after at least 24 hours, no sooner than Mon 26 Aug 05:00 GMT (07:00 my local).


use allocator properly in varopt union

Tried to use a newer C++ standard and discovered varopt used deprecated allocator methods.  Those were relatively small, but I also discovered that the union didn't use the allocator properly at all.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

4 of 4 (100.0%)  changed or added relevant lines in 2 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.002%) to 93.873%

Totals

Change from base Build<PHONE_NUMBER>:
0.002%

Covered Lines:
2329

Relevant Lines:
2481

💛  - Coveralls


[CH] Add package with spark 3.5

What changes were proposed in this pull request?
Package with spark 3.5
How was this patch tested?
Test by ci package
https://opencicd.kyligence.com/job/gluten/job/gluten-package/1699/

LGTM


[GSoC2024] Fix difficult two point polyline dragging

Motivation and context
Fix #6841
It is hard to drag two point polylines because they are small and need the cursor to be placed exactly on itself.
Implemented by increasing the appropriate (polyline, 2 points, unpinned and activated) shapes stroke-width attr.
If it is a drag or resize event, the stroke-width will be reset so that the annotator sees exactly what position or size the final polyline will be.
The new stroke-width is manually set to consts.BASE_STROKE_WIDTH * 4.

My cursor isn't captured but the draggable area is correctly resized with the activated polyline.
https://github.com/cvat-ai/cvat/assets/128531452/ad4472ca-639d-451a-a4f5-cedc2772cef2
Shows the behavior when activated/deactivated, dragged, resized and pinned/unpinned.
There is a lot of repeated code but I decided to not put everything in a function or add a new STROKE_WIDTH constant because this is for a very specific case - a two point polyline that is unpinned and activate, and the function would look very out of place, let me know if this should be changed.
How has this been tested?
Branch: develop, fbc2610d2
Manually hover, deselect, resize, drag, pin and unpin two point polylines.
Checklist

[x] I submit my changes into the develop branch
[x] I have created a changelog fragment
- [ ] I have updated the documentation accordingly
- [ ] I have added tests to cover my changes
[x] I have linked related issues (see GitHub docs)
[x] I have increased versions of npm packages if it is necessary
(cvat-canvas,
cvat-core,
cvat-data and
cvat-ui)

License

[x] I submit my code changes under the same MIT License that covers the project.
Feel free to contact the maintainers if that's a concern.

Issues

[x] Clicking on the resize handler or dragging, without actually resizing or dragging won't automatically resize the polyline back up.

Ideally (in my opinion) this would be implemented:

With no changes to the shape.
With no custom drag behavior and no function overrides so that default svg.draggable.js is still used.
Use distance to the shape and trigger svg.draggable functions with mouse events instead so that the annotator can click on an area around the activated shape (in addition to the default behavior.)

As of now, that is the only way I can think of to drag a shape without changing the shapes size, as svg.draggable is attached to the shape itself.
The reason for wanting to avoid temporarily changing the shapes size is to completely avoid a situation where it may be possible to save polylines with the increased size, a number of polylines close together may also make selecting more difficult from the increased size of one of the polyline, although the annotator could use the sidebar.
When implemented as an event firing function that takes a shape, it can also be applied to other shapes, as this problem can also exist if they are overly small, I tested this by making a rect with a very small dimensions.
Reasons for not implementing the above
DragHandler is not exported and I was unable to trigger svg.draggables init with fired events of my own.
I'm certain that I've gotten quite a few details wrong, if this is a better implementation, please correct me and I'll work on it afterwards!

Hello,

There was not a problem with horizontal polylines (as in your example), only with vertical ones
There was not a problem with width of the polyline (width does not affect selection algorithm at all)

The problem is inside the selected code (cvat-core module). When cursor is in the center of polyline, over it, selection does not work, because distance to the nearest point is calculated (and this distance is more then threshold). In the example you may find 66px when threshold is about 50px.

I will close the PR for now.
Please, do not hesitate ask to reopen if you are planning to finish the pull request.
Thank you.


AppTP Exclusion List - Design Review changes

Task/Issue URL: https://app.asana.com/0/inbox/1157893581871899/1203207224809713/1203208190764907
Description
UI changes done for the Design Review. Details in task

@aitorvs  this is ready for review. Build breaks due to ongoing translations


error while running the project

Problem encountered on https://dotnet.microsoft.com/en-us/learn/aspnet/blazor-tutorial/run
Operating System: windows
Provide details about the problem you're experiencing. Include your operating system version, exact error message, code sample, and anything else that is relevant.
Error	NETSDK1004	Assets file 'C:\Users\DELL\source\repos\BlazorApp\obj\project.assets.json' not found. Run a NuGet package restore to generate this file.	BlazorApp	C:\Program Files\dotnet\sdk\7.0.202\Sdks\Microsoft.NET.Sdk\targets\Microsoft.PackageDependencyResolution.targets	266

can you provide dotnet --info output? Also can you remove bin and obj directory from your app and retry? I assume you've installed SDK (https://dotnet.microsoft.com/en-us/download)?

Severity	Code	Description	Project	File	Line	Suppression State
Error	NETSDK1004	Assets file 'C:\Users\DELL\source\repos\BlazorApp\obj\project.assets.json' not found. Run a NuGet package restore to generate this file.	BlazorApp	C:\Program Files\dotnet\sdk\7.0.202\Sdks\Microsoft.NET.Sdk\targets\Microsoft.PackageDependencyResolution.targets	266
where are obj and bin folders  in my app? I can't see them.
Yes i have installed SDK.

looking at the error message they should be here: C:\Users\DELL\source\repos\BlazorApp\

no,bin and obj directrories are not created at this location.

can you try running dotnet restore in that location from command prompt?


Hotfix: Update usage of SAVE api in preprocessor after latest changes

What's done:

Update usage of SAVE api in preprocessor after latest changes

Update api after https://github.com/cqfn/save/commit/a24210b6b70f8e816d8df672144a264d17332356


System.TypeInitializationException thrown using Assembly.Load(File.ReadAllBytes(path));

Is this a bug report?
MassTransitIssue.zip
Yes

Can you also reproduce the problem with the lastest version?
Yes
Environment

Operating system: Windows 10
Visual Studio version: 2017
Dotnet version: 4.7.1

Steps to Reproduce

(Write your steps here:)

Load the Masstransit Assembly with using Assembly.Load(File.ReadAllBytes(pathToAssembly));
Create a bus using RabbitMQ

Expected Behavior

Everything works

(Write what you thought would happen.)
Actual Behavior

System.TypeInitializationException thrown

(Write what happened. Please add screenshots!)
See MassTransitIssue.zip or Screenshot below

(Paste the link to an example project and exact instructions to reproduce the issue.)

Looks like the Problem lies in the Constructor of BusHostInfo.
Possible Solution:
public BusHostInfo(bool initialize)
{
FrameworkVersion = Environment.Version.ToString();
OperatingSystemVersion = Environment.OSVersion.ToString();
var entryAssembly = System.Reflection.Assembly.GetEntryAssembly() ?? System.Reflection.Assembly.GetCallingAssembly();
var currentProcess = Process.GetCurrentProcess();
MachineName = Environment.MachineName;
MassTransitVersion = typeof(IBus).GetTypeInfo().Assembly.GetName().Version.ToString();
ProcessId = currentProcess.Id;
ProcessName = currentProcess.ProcessName;
        var assemblyName = entryAssembly.GetName();
        Assembly = assemblyName.Name;
        AssemblyVersion = assemblyName.Version.ToString();

}

I have never seen this happen, why is it happening to you? In what environment?

So looking at your sample, you're trying to load the MT assemblies from another path. Unless you can figure out how to load the same version information from the custom assembly resolver, I'm going to have to reject the PR since it ends up putting a different version in the message.

Hello @phatboyg !
Thank you for your reply. That was unexpected fast 👍 !
I created a new project (on an other PC, but still Windows 10 and .NET 4.7.1 with VS 2017) to compare the different ways to determine a version:
MassTransitVersionCompare.zip
For me they are the same:

Sorry, if I got it wrong.

thank you @phatboyg.


Allow @objc accessibility for colors in GlobalTokens

Platforms Impacted

[x] iOS
[ ] macOS

Description of changes
Making GlobalTokens be accessible from Objective-C.
Currently focused on colors
Verification
Colors still load as expected in both Swift and Objective-C.

Swift
Objective-C

Binary size impact on test app:

Before
After
Delta

31,715 kb
31,784 kb
+ 69 kB

Pull request checklist
This PR has considered:

[x] Light and Dark appearances
[x] iOS supported versions (all major versions greater than or equal current target deployment version)
[ ] VoiceOver and Keyboard Accessibility
[ ] Internationalization and Right to Left layouts
[ ] Different resolutions (1x, 2x, 3x)
[ ] Size classes and window sizes (iPhone vs iPad, notched devices, multitasking, different window sizes, etc)
[ ] iPad Pointer interaction
[x] SwiftUI consumption (validation or new demo scenarios needed)
[x] Objective-C exposure (provide it only if needed)

Microsoft Reviewers: Open in CodeFlow

Consider moving to colors branch to keep 0.9 slim, binary-wise?

Consider moving to colors branch to keep 0.9 slim, binary-wise?

Think I'm gonna take it to main for now and eat the cost -- I want to minimize the number of unique diffs in fluent2-colors wherever possible.


is it possible to use each module as a separate github repo?

for example: If you consider these repo's nWidart/core, nWidart/contact, nWidart/notification

Can you plug and play contact and/or notification module with core module for different projects?
With this module package (nWidart/laravel-modules) is it possible to push updates to contact and notification modules when it is used by multiple projects and without crashing the existing functionality ? i.e like composer update
How do you develop and test the contact or notification module locally? should nWidart/contact and nWidart/notification be separate laravel application ?

Yes you can, a module is just a package.

Don't know what you mean. But you can use modules anywhere.
Yes. Take a look at AsgardCMS
That's more complex, take a look at asgardcms.


Add positional argument specifiers for format

Allows compatibility with Python 2.6

Thanks!

Is that only thing stopping it from running on Python 2.6?

As far as I could tell from my testing, yes. I'm happy to create further PR's if I find any other issues and am able to fix.

Alright, I lowered the requirements to Python 2.6.

Hi @tamentis are you able to release this new package on pypi please? We have a few customers waiting on this so it'd be great to see this published soon!

Of course, I'll do that today.

There you go: https://pypi.python.org/pypi/mdstat/1.0.4

Thanks!


Deploy .rego file as configmap in opa namespace

The dev-test configuration in which we set up OPA has it automatically reading configmaps from the opa namespace.  It should therefore be easy for a developer working on a .rego file to deploy it into that namespace for testing.

Closed via #4.


Update links for repo moves/renames

Anyone know how I might have broken this test?

@NTaylorMullen @rynowak @pranavkm @ajaybhargavb okay with merging?


model.save() with server_default is failing on refreshing server_default values

Describe the bug
model.save() is raising NoMatch when it tries to refresh a server_default that is a PK. I was able to fix this locally by just setting self.pk = pk in https://github.com/collerek/ormar/blob/master/ormar/models/model.py#L85-L96. happy to open a PR if the issue is valid.
To Reproduce
Steps to reproduce the behavior:
import asyncio
import uuid
from datetime import date, datetime
from typing import Optional

import ormar
import sqlalchemy
from databases import Database
from sqlalchemy import func, text

database = Database(url="postgresql://postgres@<IP_ADDRESS>:5432/postgres", force_rollback=True)
engine = sqlalchemy.create_engine("postgresql://postgres@<IP_ADDRESS>:5432/postgres")
metadata = sqlalchemy.MetaData()

class BaseMeta:
    metadata = metadata
    database = database

class Jimmy(ormar.Model):
    class Meta(BaseMeta):
        tablename = "jimmy_rus"

    id: uuid.UUID = ormar.UUID(
        primary_key=True, server_default=text("gen_random_uuid()"), uuid_format="string"
    )

async def main():
    await database.connect()
    metadata.drop_all(bind=engine)
    metadata.create_all(bind=engine)
    jimmy = Jimmy()
    await jimmy.save()

if __name__ == '__main__':
    asyncio.run(main())

Expected behavior
should not raise an exception after the item is already persisted to the db.
Versions (please complete the following information):

Database backend used (mysql/sqlite/postgress) postgres
Python version 3.9
ormar version 0.11.2
pydantic version 1.9

Additional context
I've tracked the offending code down:
https://github.com/collerek/ormar/blob/master/ormar/models/model.py#L85-L96
from what I can tell, the pk is correctly returned via insert expr, however self.pk never gets set. so when self.load is called it doesnt correctly select for item that was insert since self.pk is None.

draft PR: https://github.com/collerek/ormar/issues/744


Bring back macOS 10.11 into the game

This PR restores macOS 10.11 compatibility.
The deployment target has been set both in the macOS framework target and the demo application.
The code has also been fixed for build to succeed.

Hi, thanks for it.
There is now already a branch "ios9" in which I guess the same thing was contained. I also downgrade the supported version for macOS there, can you check that branch?
For some reason described here and some other similar issues, we do not have a plan to introduce it back to master or a release.

Hi @onevcat
Well alright I'll check the ios9 branch.
Reading the issue linked, I can't see really why these changes would be an issue here, at least for macOS :
The timer scheduling code was the sole piece incompatible with macOS 10.11 APIs.. everything else builds fine. Also this change would not block any other development on iOS
Despite what Apple advises, macOS 10.11 remains an operating system in use because people tend to less update their systems than on mobile devices.
So.. well I think there's a little chance you consider supporting macOS 10.11 officially again, that's why I'm arguing here ;)


Imported TypeScript files in eslint.config.ts doesn't work

The following structure is publicily available at https://github.com/jellyfin/jellyfin-vue
Steps to reproduce

Click on Code > Create codespace from master (or clone the repository locally)
cd frontend && npm run lint:inspect

Description
This an overview of the setup

Using TypeScript configuration files with jiti v2. Looks like that is already covered
A monorepo (called @jellyfin-vue/configs in my case) where TypeScript modules export factory functions for rule configs.
Those factory functions are imported in frontend/eslint.config.ts, working perfectly with ESLint but not with the inspector.

I have a hard time understanding what it is that doesn’t work.
Can you maybe add a screenshot or something where you show what’s wrong or missing?

@voxpelli I was able to better triage the issue and create a minimal reproduction: https://stackblitz.com/edit/vitejs-vite-9abzaz
Steps to reproduce

cd packages/configs and run npm run lint:inspect
ESLint config inspector will load successfully, since the TypeScript file imported is referenced from the same project
Change to the packages/main directory and run npm run lint:inspect there. The config inspector will fail to load with the following error, since the base rules are being imported from the monorepo:

Additional context
It looks like the issue exists when importing .ts files from node_modules in monorepo setups. Similar to what happens in Vite. Hence, the workarounds listed there are also applicable to this project


⚠ Bofrost.be has degraded performance

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

HTTP code: 200
Response time: 2068 ms

Resolved: Bofrost.be performance has improved in 1d7dfc0.


Add 'My exciting journey into Kubernetes’ history' blog post

This adds an unpublished blog post to the Kubernetes website. I thought this would be a good fit so I'm kindly asking for review. Please hold for the publishing date if we can agree that this is something we want to add here.

YES! Thank you, @saschagrunert - I'll take a look at this today and get you some feedback :smile:

YES! Thank you, @saschagrunert - I'll take a look at this today and get you some feedback 😄

Thank you for the quick response @onlydole! 🙏

Awesome, thank you @onlydole and @sftim for the detailed review! Do you think that we can publish it tomorrow or do we have to find another date? :)

Apologies for the latency, @saschagrunert! I say this looks good, with exception to @sftim's comments and CDN feedback. Once that's cleared, I'm happy to sign off on this (thank you again for such a great post).

Apologies for the latency, @saschagrunert! I say this looks good, with exception to @sftim's comments and CDN feedback. Once that's cleared, I'm happy to sign off on this (thank you again for such a great post).

Thank you! :pray: I added the images to the PR as well as changed the release date to May 20th if that is fine for you.

Hey @onlydole @sftim, is there anything else what I can do here or do you think this is now ready to be merged? :)

Apologies, @saschagrunert! This slipped my mind and I think it’s looking good enough to merge! Might just need a blog date update is all 😜

Could you change this date and the date of the file name, @saschagrunert? Then I think it’s ready for a final approval!

Thank you! Changed the file names as well as the paths for the static images to the new date.

/approve
This is awesome.


rule's cypress tests update

Description
Updated cypress test for the rules
Check List

[x] Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Codecov Report

Merging #581 (6fddb0c) into main (feb0ed7) will not change coverage.
The diff coverage is n/a.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
@@           Coverage Diff           @@
##             main     #581   +/-   ##
=======================================
  Coverage   31.47%   31.47%
=======================================
  Files         138      138
  Lines        4340     4340
  Branches      723      723
=======================================
  Hits         1366     1366
  Misses       2835     2835
  Partials      139      139


question regarding color value range enforcement

Hi. Quite excited about the work you're doing.
Reading over the white paper, I noticed that the acceptable range for color values is set to be [0,1]. Does this imply that nonconforming color spaces should be excluded?
For example, ACES 2065-1, CIE LAB/LUV and OKLAB can have negative color values. Now, perceptual color spaces might be a questionable choice here, but it seems conceivable that someone would want to define their materials with AP0 primaries.

This is a non-trivial question.
I would like to think of the color values in the model as defining the properties of the physical material. If the colors were specified in a fully spectral manner, I think they would correspond essentially to "spectral albedos", i.e. physically what fraction of each particular wavelength is absorbed or transmitted on passing through some layer, say. (Except for emission_color which would be the spectrum of emitted light).
Those albedos should physically all be in the range $[0,1]$ (i.e. it would be meaningless to absorb a negative amount of energy, or more than 100%).
However since we use RGB values, the spectral interpretation is ambiguous. The albedo per color channel represents some integral over (unknown) underlying physical albedos, with weights depending on the color space. I would expect that normally the channels should be in $[0,1]$, in standard color spaces and under some reasonable assumptions about the possible underlying spectral albedo curve. But I'm not sure, in the cases of the "non-conforming" color spaces you mentioned, perhaps it could make sense to allow that the RGB albedo components can be negative, or exceed 1? It would be strange to work with negative color channels in a renderer, but perhaps could be done consistently with care (obviously physical radiances must be positive, but RGB renderers don't work directly with physical radiance).
Generalizing this properly might also require re-expressing some of the math in the model (not to mention, in other similar models).  For example, in the standard Schlick model for metallic Fresnel:

it is assumed that $\mathbf{F_0}=(1, 1, 1)$ corresponds to perfect Fresnel reflectivity. But in these exotic color spaces, is that the case?

Hello,
Thanks to @portsmouth for pointing me to this thread!
This is a great question and I will try to address it by reinstating what I think the prime objective of physically-based rendering is: Simulating the imaging of the electro-magnetic spectrum radiation incident to an observer in a way that the simulation would be indistinguishable from reality to a similar observer.
I took great care not using the words human, colour or light anywhere in the previous sentence because, often, and especially in the VFX industry, the observer is a motion picture or stills camera. A camera is typically not colorimetric, i.e. its sensitivities are not a linear combination of the human cone responses. Put another way, it does not capture incident light the same way than us, and we need to process the images it captures to make them colorimetric. We might also be required to simulate an infrared camera which images a portion of the electro-magnetic spectrum that is invisible to us.
You might be wondering where I am going with that? It is simple: We should strive for the modelling of the scene in the physically-based rendering process to be agnostic of the observer. To be very specific, defining the physical properties of the objects taking part in the simulation should be independent of the observer. The act of "observing" an object does not change its characteristics in the real word, why should there be correlation in our simulations?
With that in mind, describing colour information in a renderer using a perceptually uniform space correlates the simulation to the observer, thus, changing the space will change the simulation. This is true with RGB colourspaces and especially noticeable with indirect illumination. We have shown that different spaces produce different images. See https://www.colour-science.org/anders-langlands/, https://www.colour-science.org/posts/about-rendering-engines-colourspace-agnosticism/ and https://computergraphics.stackexchange.com/questions/8152/for-shader-math-why-should-linear-rgb-keep-the-gamut-of-srgb/8163#8163 for more information.
The act of using photometric quantities is problematic, especially when describing surface characteristics: They are weighted by our very own human sensitivities.
The ideal renderer would only use radiometric quantities as input, e.g. spectral reflectance, transmittance or absorptance, spectral irradiance, etc.., unfortunately, we have created a world of problem by adopting RGB as the space for most renderers to operate in. There are good reasons for that, e.g. "apparent" simplicity and cost effectiveness. Whilst it is correct that a RGB renderer is typically faster and has readily available material to feed on, the consequential complexity in modelling the real world is problematic.
When we take a photograph and use it as a texture in a renderer, the illuminant is "baked" into it: In a simplified way, it is the result of the integration by the camera sensitivities of the multiplication of the environment irradiance with the reflectance, transmittance, and absorptance of the objects in the scene. The mechanics are similar for us:

Let me continue a bit as I'm also hoping to see more definitions and terminology clarification in the whitepaper: What is albedo? The CIE does not have a definition for it and I could not find any standard one. A tentative one might be as follows:

Albedo refers to the measure of the reflectivity of a surface or object. It is the ratio of the reflected light from an object to the incident light upon it. Albedo is typically expressed as a percentage or a decimal value between 0 and 1, where 0 represents complete absorption of light (no reflection) and 1 represents complete reflection (no absorption). A high albedo means that an object reflects a large portion of the incident light, whereas a low albedo indicates that most of the light is absorbed.

Why are we then surfacing our virtual objects with photographs that have illumination baked in? What illuminant should we be using when creating new textures in Mari or Substance Painter? D60, D65? Why not using the equal energy illuminant E? How should a blackbody, e.g. fire, converted to RGB for rendering, what does this mean to the physical camera white balancing?
It should hopefully be clear why I wrote "apparent" simplicity: We introduce observer correlation and coupling everywhere in the virtual scene authoring process when working with RGB values. Everything becomes extremely complicated when you start deeply thinking about it. Fortunately, all those problems disappear under the elegance of spectral rendering :)
To finally reply to your question, and to echo what Jamie said, I would limit albedo to [0, 1] because it is by "definition" a measure of reflectivity.
Cheers,
Thomas

Thank you both for the detailed responses.
So, if I'm understanding correctly, the design philosophy here is to limit parameters to "computation-ready" values, immediately suitable for rendering, without any additional pre-processing steps.
I'm working on an interchange file format, which will probably not see much use (if any) outside its associated projects, but I wanted make sure that I'm reading the white paper correctly. If this is the goal - I suppose I might make a version for "OpenPBR-ish" parameters, where color spaces can be arbitrary (and converted for the renderer as needed), and then a strictly-conforming one, where all color values must be in [0, 1] range, in a scene-linear color space.

the design philosophy here is to limit parameters to "computation-ready" values, immediately suitable for rendering, without any additional pre-processing steps.

Yes, this is ideal because the renderer can focus only on rendering and does not have to deal with pre-transformations of all sort to bring the image resources into the RGB working space.
It is worth noting that your RGB working space is primarily driven by the RGB colourspace the image resources are encoded with. Some conversions require knowledge of the RGB working space, e.g. blackbody irradiance to RGB, but it is mostly an implicit condition.
Cheers,
Thomas

That sounds reasonable. I suppose my confusion stems from the fact that a scene may include many different materials, potentially using different color spaces. I assumed that, at some point, this would necessitate choosing a rendering space anyway, and doing the necessary transformations.
e.g. a scene-linear Rec. 2020 and ACEScg are both fine according to the spec, but you can't exactly use them together side-by-side as-is.

that a scene may include many different materials, potentially using different color spaces

If the renderer exposes a way to conform the textures to the same working space, e.g. OpenColorIO or internal color transformation engine, it should be fine. As you point out, you would want all the input to be in the same working space otherwise you would be mixing metrics, akin to mix meters with inches.
Worth noting that BT.2020 and ACEScg are for practical purposes the same space and a human observer has a hard time making a difference between the two, so it would not be catastrophic, in this particular case to mix them! :)

It seems like a good idea to try to formalize the reasoning a bit to clarify what it means exactly to say that the reflectance (i.e. albedo) of a material is described by some (R, G, B) triple.
There may be different possible reasonable interpretations, so I though it was worth writing down how I interpret the discussion above from a computational/mathematical standpoint, at least to verify that I have the right mental model. (I found this exercise helpful anyway, though this is probably obvious to others). I found the paper "Physically Meaningful Rendering using Tristimulus Colours" by Meng et. al to be quite helpful in understand the relationship between physical albedos and RGB colors.
If we assume the illumination is uniform with luminance $Y$ (in nits) and has the spectral power distribution (SPD) of the standard illuminant D65, we can express the incident spectral radiance as:
L_e(\lambda) = \left(\frac{Y}{Y_\mathrm{D65}}\right) \; S_\mathrm{D65}(\lambda)

where
Y_\mathrm{D65} = \int \bar{y}(\lambda) \;  S_\mathrm{D65}(\lambda) \; \mathrm{d}\lambda \ .

Say for simplicity that the surface has a Lambertian BRDF with spectral reflectance (albedo) $\rho(\lambda)$, where physically, $\rho(\lambda) \le 1$ for every wavelength $\lambda$, in order to conserve energy.
Given that, we can write down the rendering equation at the surface point:
L_o(\lambda) = \int \frac{\rho(\lambda)}{\pi} L_e(\lambda) \; \mathrm{d}\omega^\perp = \rho(\lambda) \, L_e(\lambda) \ .

Thus the tristimulus values of the reflected light (as observed by the measuring/recording apparatus, i.e. camera or eye) are given by
X_o = \left(\frac{Y}{Y_\mathrm{D65}}\right) \; \int \bar{x}(\lambda) \; \rho(\lambda) \; S_\mathrm{D65}(\lambda) \; \mathrm{d}\lambda

Y_o = \left(\frac{Y}{Y_\mathrm{D65}}\right) \; \int \bar{y}(\lambda) \; \rho(\lambda) \; S_\mathrm{D65}(\lambda) \; \mathrm{d}\lambda

Z_o = \left(\frac{Y}{Y_\mathrm{D65}}\right) \; \int \bar{z}(\lambda) \; \rho(\lambda) \; S_\mathrm{D65}(\lambda) \; \mathrm{d}\lambda

using the CIE color matching functions $(\bar{x}(\lambda), \bar{y}(\lambda), \bar{z}(\lambda))$.
Then we can interpret the albedo colors in our model (and in input textures) as corresponding to the resulting measured tristimulus $(X_0, Y_0, Z_0)$ when illuminated by the D65 illuminant normalized to luminance $Y = 1$ nit. The equations above then guarantee that $Y_o \le 1$, since $\rho(\lambda) \le 1$. Presumably this constraint corresponds to the color theory version of the BRDF energy conservation requirement.
This tristimulus can be converted to/from the RGB values $(\rho_r, \rho_g, \rho_b)$ of reflectances in the model via the usual transformation depending on that color space (assumed ACEScg by default, and presumably generally always linear / "scene referred").
Given the RGB reflectance values in the model defined in that fashion, we then have a well-defined transformation to RGB albedo in the renderer, leading to the usual operations in RGB, e.g. the calculation of the R channel of the reflected light:
R = \int \bar{r}(\lambda) \; \rho(\lambda) \; L_e(\lambda)  \; \mathrm{d}\lambda = Y \; \rho_r \ .

RGB values in textures can be converted to the model color space as usual, although this strictly only makes sense if the standard illuminant of the color space matches the assumed SPD of all light sources.
As Meng notes, if the illuminant of the lights can vary, then it would make more sense to stipulate e.g. that the model albedo colors are defined assuming a flat SPD (standard illuminant E). But this only seems to make sense for a spectral renderer, which does "uplifting" from RGB albedos to spectral and renders with general spectral illuminance.
For a tristimulus renderer, it makes more sense to just assume that the same illuminant (e.g. D65) is used consistently, as @anderslanglands proposed in UsdLux.
For OpenPBR, I'm not sure if we need to elaborate on any of this, though perhaps to be complete we should include some kind of discussion.

This is essentially baking the illumination into the definition of the albedo which is not ideal

the Illuminant is ready baked into the definition of whatever RGB space you’re using to store your texture data in.

the Illuminant is already baked into the definition of whatever RGB space you’re using to store your texture data in.

Right yes, so given texture data in a given (linear) RGB space, the R value means
R = \int \bar{r}(\lambda) \; \rho(\lambda) \; S(\lambda)  \; \mathrm{d}\lambda

given the spectral albedo $\rho$ and standard illuminant SPD $S$.
I meant this is problematic in the sense that once this is baked in the dependence on that particular SPD can't be disentangled. If the surface is assigned that RGB albedo, but illuminated with a different SPD, there is no way to compute the integral for that to get the reflected RGB. The only way to complete the integral is if you assume that the SPD of all lights in the scene is the same.
Which seems a workable, if artificial, assumption for an RGB renderer. That's all I meant by "not ideal". (For a spectral renderer you can do everything correctly/ideally though, in principle).

It seems like a good idea to try to formalize the reasoning a bit to clarify what it means exactly to say that the reflectance (i.e. albedo) of a material is described by some (R, G, B) triple.

I never liked talking about reflectance in that case because it is integrated reflectance for a given observer and illuminant. I don't really like albedo either because there are multiple definitions for it and I haven't seen a standard one that can be pointed at, are we talking about spectral albedo, average albedo, etc... I suggested that OpenPBR clarifies the definition it uses.
When we talk about scene-referred rendering the RGB values are colour estimates of the scene and not its irradiance. The critical aspect is the linear relationship between the scene and the scene-referred image: We know that a doubling of scene exposure yields a doubling of image luminance. In that sense, and I understand it is mouthful, but maybe "referred-reflectance" is a better term? Or this could be given as an explanation example tying the logic that the scene is in the radiometric domain and the scene-referred image is necessarily in the photometric domain.

Do you mean we're looping back around and actually "diffuse colour" was the best nomencalture after all? :P

agreed that albedo is a horrible term for this. I'm fine with reflectivity though personally as the referred- or integrated- nature being implicit is ok imo.
I do prefer reflectivity over reflectance as reflectance implies it's the output quantity rather than the factor, but anyway...

I think "color" works ...   these are colors aren't they (RGB triples)?  We need to specify a color space (as we say the metadata should provide, otherwise default to ACEScg).
The only potentially non-obvious thing is how exactly to interpret the color as a reflectance. We may want to say explicitly that it's this relationship (if you agree that is right):
R = \int \bar{r}(\lambda) \; \rho(\lambda) \; S(\lambda)  \; \mathrm{d}\lambda

G = \int \bar{g}(\lambda) \; \rho(\lambda) \; S(\lambda)  \; \mathrm{d}\lambda

B = \int \bar{b}(\lambda) \; \rho(\lambda) \; S(\lambda)  \; \mathrm{d}\lambda

and then some brief discussion about how this works in a traditional tristimulus renderer, versus a spectral renderer (along the lines of the discussion above).
What about this?

We do say that color values are enforced to be in $[0,1]$, which may technically be violated in certain color spaces, though (as pointed out in the original question by @Sam-Izdat) -- even if the underlying spectral albedos are physical in $[0,1]$.

That does seem to be the case actually -- i.e. it could be totally legit for a material to have a diffuse color of (-0.1, 0.5, 1.0) in some color space (ACES 2065-1 was mentioned) according to the definition above, and this be meaningful, though weird. If that's allowed, we should mention it in the spec, since right now we forbid that (color ranges are said to be $[0,1]$).

The only potentially non-obvious thing is how exactly to interpret the color as a reflectance.

What about the others cases? Including all the .*_color for completeness:

base_color : Integrated reflectance
specular_color : ?
subsurface_color : ?
transmission_color : Integrated transmittance
coat_color : ?
fuzz_color : ?
emission_color : Integrated irradiance

ACES 2065-1 covers the entire spectral locus so you're not going to get negative RGB values there, but you could get negative values if your colours are stored in a wide gamut space (e.g. ACEScg) and your rendering space is narrower (e.g. sRGB). Negative reflectances don't make any sense, so you have to adapt the gamut somehow, and the easiest thing to do there is to clip.

Negative reflectances don't make any sense

Agreed that the spectral reflectance $\rho(\lambda)$ must be non-negative, but I think a negative RGB reflectance does make sense in principle since e.g.
R = \int \bar{r}(\lambda) \; \rho(\lambda) \; S(\lambda)  \; \mathrm{d}\lambda

can be negative even if $\rho(\lambda)$ is positive for all wavelengths (e.g. make $\rho(\lambda)$ be a delta-function spike somewhere where $\bar{r}(\lambda) < 0$). I assume that reasonable assumptions about the shape of $\rho(\lambda)$, this is unusual though. In practice one probably doesn't run into issues by clipping to [0, 1] I expect.

The only potentially non-obvious thing is how exactly to interpret the color as a reflectance.

What about the others cases? Including all the .*_color for completeness:

base_color : Integrated reflectance
specular_color : ?
subsurface_color : ?
transmission_color : Integrated transmittance
coat_color : ?
fuzz_color : ?
emission_color : Integrated irradiance

I would interpret all of these except emission_color as albedos for reflection or transmission (i.e. reflectances or transmittances). Connecting the spectral quantities (albedos/transmittances) to the RGB colors could be done via similar line of reasoning to the discussion above for a diffuse surface.
Though coat_color might doesn't quite fit into that picture since we say that technically it specifies the square of the coat transmittance, so the RGB quantity is really the integral over the spectral transmittance squared.
I don't think we necessarily need to elaborate on this in the spec though.
We are discussing how to interpret emission_color in https://github.com/AcademySoftwareFoundation/OpenPBR/issues/85.

We should not talk about "RGB reflectance" once reflectance has been integrated by the Observer, reflectance is a radiometric quantity, RGB is a photometric one.
I think that you might be confusing the RGB CMFS that were measured during the colour matching experiments those have negative lobes and the XYZ CMFS, e.g., CIE 1931 2 Degree Standard Observer which do not and are used for conversion from spectral domain to CIE XYZ tristimulus values. Thus, CIE XYZ tristimulus values cannot be negative.
Straight from my slides:

I meant that the RGB can be negative, even if the XYZ must be positive (as you pointed out).
So I think the RGB components corresponding to e.g. the base_color in OpenPBR, can in principle be negative if you assume they were derived from some arbitrary underlying physical spectral reflectance $\rho(\lambda)>0$. Do you see any mathematical reason that cannot happen?
As noted though, in practice it might be reasonable to just assume that negative RGB values are forbidden, and clamp to make that so if they are generated.

Do you see any mathematical reason that cannot happen?

They cannot be negative because we never ever use the RGB CMFS in computations. The RGB space defined by the RGB CMFS is not the same one than the RGB colourspace derived from the CIE XYZ colourspace. The red negative lobe is a by-product of the method used to assemble the curves. The cone fundamentals are all but positive:

Thus, there cannot be anything that produce negative tristimulus values. It is also possible to define a RGB space using an identity matrix from CIE XYZ, this RGB space, which covers the visible spectrum entirely, in a wasteful way, is always positive, like ACES.

we do obviously informally inside RGB renderer implementations use RGB albedos and transmittances

I think that this is damaging terminology and that we should not mix radiometric and photometric terms like that:
How will we explain reflectance recovery from RGB values when we have talked about RGB reflectance for years incorrectly?
https://scholar.google.com.au/scholar?hl=en&q=reflectance+recovery+rgb&btnG=&oq=reflectance+recovery

Not sure I'm familiar enough with color science to fully understand, but don't these "cone fundamentals" mean essentially the spectral response of the different kind of cones to different frequencies,  so by definition they are positive and give a positive color (in "LMS" color space)?
How does that guarantee that the corresponding RGB will not be negative in some other color space? (Maybe it does though). Should we not just say that regions of RGB space that have negative color components exist but are "out of gamut", so if they are generated we have to do some kind of correction?

I think that this is damaging terminology and that we should not mix radiometric and photometric terms like that:
How will we explain reflectance recovery from RGB values when we have talked about RGB reflectance for years incorrectly?

We do currently talk about RGB albedos in multiple places in the spec, e.g. below. So in your view this terminology is bad? What alternative do you have in mind, maybe replacing albedo with "integrated albedo" say? It is a color, representing the diffuse reflectance/albedo of the surface, so not sure I see the issue. Can we not just make a note that by RGB albedo we mean the physical albedo integrated over appropriate CMFs, etc.?

so by definition they are positive and give a positive color (in "LMS" color space)?

Yes, and thus in CIE XYZ also. My point is that we never use the equation you shown pertaining to the RGB CMFS in computations:

and it is certainly not used to integrate reflectances so we should probably never mention it unless there is a will to discuss about the history of colour science. Modern CMFS such as the CIE 2015 XYZ CMS are actually derived from the Cone Fundamentals directly thus there is no CIE 2015 RGB CMFS.

So in your view this terminology is bad?

"RGB reflectance" is bad imho, reflectance should be left to the spectral radiometric domain, it is not a quantity we are manipulating in a RGB renderer. Albedo is very much similar, I don't like it, but easier to sacrifice under the "Totem of Approximation"  as it is used a lot already in the literature. I do think though that it should be defined properly in the white paper. It is also worth noting that "Reflection albedo" in your screenshot is tautologic as albedo is a measure of reflectivity.

It is a color, representing the diffuse reflectance/albedo of the surface, so not sure I see the issue.

But this the entire problem: It is not representing the reflectance of the surface at all, it is modelling the colour of the surface for the Standard Human Observer under an illuminant, i.e., that of the encoding colourspace. We cannot even say "average reflectance" to discard the spectral component because it has been weighted by the Standard Human Observer and the illuminant.

Modern CMFS such as the CIE 2015 XYZ CMS are actually derived from the Cone Fundamentals directly thus there is no CIE 2015 RGB CMFS.

OK sure, but I take it you would agree that it is at least possible for there to be negative RGB values (for "referred-reflectance") in certain color spaces? For example, if base_color is (1, 0, 0) in ACEScg, this  tells me that the sRGB value for that is (1.26269, -1.67573, -0.31223).
I was only saying that in principle that sRGB color is still a valid description (of the "referred-reflectance") that could be used inside the renderer. In practice though since the color is out of the sRGB gamut, it should probably be clamped to the closest in-gamut color (or something like that). Maybe we should say that explicitly in the spec, since it's a practical thing that can happen (as in the (1, 0, 0) example above).

"RGB reflectance" is bad imho, reflectance should be left to the spectral radiometric domain, it is not a quantity we are manipulating in a RGB renderer.

But this the entire problem: It is not representing the reflectance of the surface at all, it is modelling the colour of the surface for the Standard Human Observer under an illuminant, i.e., that of the encoding colourspace.

I see your point of view I think.  I just think the terminology of "RGB reflectance/albedo" is not really misleading, at least as a short-hand, since it will be understood that the fact that we're working with RGB quantities at all implies that these are perceptually-based quantities, not radiometric ones. I disagree that the RGB value is "not representing the reflectance of the surface at all", it is representing the combined effect of the physics of the light emitted and scattered from the surface+ the physics/physiology of the effect of that light on the human visual system. All that is implied whenever colors are involved, I thought that should be implicitly understood. Thus it seems reasonable to me to talk about the reflectance color of an object.

OK sure, but I take it you would agree that it is at least possible for there to be negative RGB values (for "referred-reflectance") in certain color spaces?

Absolutely.

since it will be understood that the fact that we're working with RGB quantities at all implies that these are perceptually-based quantities

I don't think this is true, I would think that most people not familiar with radiometry, photometry, colour science and spectral rendering don't make the difference. Also, "perceptual" is a keyword with a specific meaning in colour science, i.e. perceptual uniformity, so I would probably stick to "photometric" until not possible.

II disagree that the RGB value is "not representing the reflectance of the surface at all", it is representing ...

It is akin to say that iron is the same thing than steel, or that cacao is the same thing than a chocolate cake. Surface reflectance is one of the ingredients that contributes to the sensation in the HVS, the full, albeit simplistic, recipe requires the CMFS and the illuminant.
We really do need precise terminology and if we take shorthand, we need to explain why. I would like to avoid the "linear" situation from 20 years ago where no-one knew what linear meant.
Is there a source for the white-paper? I would be keen to try giving a crack at putting a few things to help clarifying all that.

Is there a source for the white-paper? I would be keen to try giving a crack at putting a few things to help clarifying all that.

Sure, that would be great to see your proposal.
You would just fork the repo, make your changes (it's just an index.html with markdown), and create a PR.

Ah, I totally missed it! https://github.com/AcademySoftwareFoundation/OpenPBR/blob/main/index.html

OK sure, but I take it you would agree that it is at least possible for there to be negative RGB values (for "referred-reflectance") in certain color spaces?

Absolutely.

So we currently state that color components are in $[0,1]$. Do you think we should require negative values to be removed (e.g. clamped), or allow negative values?  (That was the original query from @Sam-Izdat at the top of the thread, I think).

The colourspace is implicitly defined by the encoding used by the values so it is up to the user and a good idea that the spec does not enforce a working colourspace.
Negative values should be removed because they violate energy conservation, and I would certainly enforce that on the implementation side, e.g., base_color is clamped between [0, 1], systematically.

Which formula are you referring to specifically?
I'm talking in general term of using negative values in rendering. How are we expecting a system simulating light transport, even in the photometric domain like RGB, to behave properly with negative values? As far as I know, there is no such a thing as an anti-photon in particle physics that would contribute to make an object invisible.
If we allow negative reflectance, by the same principle, why would not we allowing negative irradiance values?

It doesn't seem inconsistent to imagine the renderer working with negative RGB albedos, generating a negative RGB stimulus, which is a correct representation of the observed color.

Just imagine what happens at each vertex when bouncing a diffuse colour of [-0.2, 1, 1] around multiple times

Yep, no doubt a negative albedo is pretty disastrous if used inside an RGB renderer, I'm not disputing that. I think that happens essentially because multiplying two RGB quantities, e.g. input radiance and albedo inside the rendering equation, does not correspond to a valid spectral calculation. (But not because negative color values make no sense in general).
So perhaps we can just say that the color components in the assumed color space must be positive (i.e. "within gamut")?

Yes this goes back to @KelSolaar 's point that colours are not reflectances I think.
I think it would just be sensible to say explicitly what the valid range is for each colour parameter, e.g. [0, 1) for diffuse colour.

Currently we explicitly say all color components are in $[0,1]$.  That seems more restrictive than in-gamut (is any positive-valued color in-gamut?). Presumably a color channel > 1 for an albedo is also disastrous though, in RGB rendering.

Yes. I would relax that on emission_color though

@anderslanglands and @KelSolaar This may be slightly off-topic, but do you think it is feasible to use OpenPBR in the context of a spectral rendering engine? Or would it require some changes to the parametrization and spec for that to make sense?

No it all works fine.
On Wed, 6 Mar 2024 at 09:57, Jamie Portsmouth @.***>
wrote:

@anderslanglands https://github.com/anderslanglands and @KelSolaar
https://github.com/KelSolaar This may be slightly off-topic, but do you
think it is feasible to use OpenPBR in the context of a spectral rendering
engine? Or would it require some changes to the parametrization and spec
for that to make sense?
—
Reply to this email directly, view it on GitHub
https://github.com/AcademySoftwareFoundation/OpenPBR/issues/149#issuecomment-1981476975,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAOYQXMUXTAWJIU5UNANTLDYW5KIXAVCNFSM6AAAAABAYJHWTCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOBRGQ3TMOJXGU
.
You are receiving this because you were mentioned.Message ID:
@.***>

No it all works fine.

For example, base_color=(1.0, 0.5, 0.1) in ACEScg does not define the spectral reflectance of the base uniquely (obviously). But I take it a spectral renderer would just need to do its own conversion to the spectral albedo consistent with the supplied color, according to some reasonable scheme.

Agreeing with @anderslanglands, I don't see any issue. The renderer would recover reflectance, irradiance, etc..., i.e., up-sample, according to the input type if the input is non-spectrally represented.

Ok, I'm gonna be That Guy.
OpenPBR is new, not preserving back compatibility with an existing standard surface. It's derived-from and inspired-by existing standards obviously, but must we be beholden to olden assumptions we made when we were young and naive?
Why not just bite the bullet, and say OpenPBR inputs are fundamentally spectral, and that tristimulus values can only be observations on values produced by OpenPBR?
Until tools produce spectral data, a hypothetical spectralizing NN could bridge existing content. Machine learning with image understanding could likely produce good enough spectral inputs from texture data, by virtue of hallucinating physical materials to motivate the observed colors. OpenPBR could provide a reference color picker (and possibly other required user interface elements) to help applications produce spectral color workflows for artists.
I release this is completely contrary to where the project started not that long ago with an idea of being simply a best-practices consolidation of well respected industry models, but are assumptions about being stuck with RGB forever etched in stone?

Why not just bite the bullet, and say OpenPBR inputs are fundamentally spectral, and that tristimulus values can only be observations on values produced by OpenPBR?

I would LOVE to see that!

Why not just bite the bullet, and say OpenPBR inputs are fundamentally spectral

What do you actually mean by that? That every colour input on OpenPBR should be changed so an array of [wavelength, reflectance] pairs?

I think we could add some sentence or two to the spec, indicating that the color parameters are specifically RGB (with a defined color space) and how a spectral renderer should interpret this (I assume doing "upsampling"/"uplifting" from RGB to spectral reflectance/emission, in a renderer-specific way).
I take it Nick you mean that some real time (and/or more offline) renderers are switching to spectral, so they do this uplifting etc. and internally work with spectra? If so, I think it still makes sense for OpenPBR to work with RGB, as in practice presumably all renderers currently have to deal with assets which are authored with RGB colors and textures, and do such uplifting. In the future, perhaps we will instead all work with assets whose pixels contain a full spectral representation (in some standard way), and maybe instead of color pickers we manipulate spectra in some way?
At that point it would be reasonable to switch from explicit RGB colors to spectra in the OpenPBR model, but that seems like it would be over-complicated or confusing right now to state it that way.

At a large, spectral-enjoying VFX company I worked at, the number of times artists specified spectra was basically zero, to the point where it wasn’t even possible to specify spectra in the the artist-facing shading system because no-one had found it necessary to implement.
It turns out that for the vast majority of materials, RGB “reflectances” (sorry Thomas) work just fine. What’s more, sRGB reflectances work just fine in most cases.
More to the point: there’s no readily available tools for capturing or authoring spectral data. We’d need spectral cameras, spectral photoshop, spectral-aware shading systems etc etc. this is unlikely to happen, ever imo. The vast majority of image data out there is still 8-bit PNG and JPG!
Where I do think spectral data matters and is practical is in specifying illumination, which goes to the discussion we were having recently about adding illuminant specification to UsdLux, which is something I will absolutely drive.
@portsmouth I don’t think you need to specify anything about spectral handling: any spectral renderer is already doing uplifting, and specifying methodology would be restrictive to the point of being ignored. Colours are already defined clearly as to what space they’re in which is exactly the information that’s needed.

Let me double check in the forum whether they are talking about uplifting or something more fundamental. I do agree of course that it makes sense to deliver an OpenPBR based on RGB. I also agree that spectrally describing lights is low hanging fruit that should probably be plucked first. I humbly disagree that no one is ever going to create spectral-anything tools, and that artists will never work that way. I'm being a bit provocative to say so but It calls to mind the moment twenty years ago when there was much argument spent on whether we could ever convince artists not to paint shading into their textures so that we could start to transition to PBR in the first place. Nonethelless to repeat, I do agree that it makes sense to first deliver a spec based on RGB.

I cannot see a future where there won't be tools allowing you to author data spectrally, it is already trivial to define spectral input for emission, e.g., is my light a LED, tungsten or fluorescent one? We also put spectral transmission or diffusion gels and filter lights with them.
I don't see any reason why we could not extend Mari for example, and add a type channel, e.g., wood, brick, leaf, plastic, guiding the reflectance recovery model. Mari could then either output hyper spectral images (HSI) or guide the renderer during its up/sampling process.
I think that it should be possible to load an HSI directly into the renderer: a key use case would be for IBL, e.g. onset with mixed lighting such as LED wall, HMI.

I disagree with both of you, but will be very happy to be proven wrong.

but It calls to mind the moment twenty years ago

20 years ago, many people told me that realtime raytracing would never be a thing!

The answer from games folks is that spectral rendering in real time engines is done to support creating training data for ML to simulate vehicle cameras have which tend to be be infrared sensitive. Spectral light sources are also in their infancy, but rendering in that case is still for the most part done in a wide gamut space like ACEScg. Still early days.


Update projects.json

Adding Skulliance to projects section.
Need to figure out how to upload the light and dark icons to the project images folder to support these images on the project page.
Description
Adding Skulliance to projects section.
Where should the reviewer start?
Ensure the images are uploaded before pushing the change.
Motivation and context
It adds another partner to the website.
Which issue it fixes?
The lack of Skulliance on the home page.
How has this been tested?
It follows the formatting of the other partner projects and just requires that the associated images be uploaded.

Covered by #259

Covered by #259


Session Id aware endpoints with Azure Service Bus

I have a queue which uses Sessions, so I need to be able to set SessionId on each message. I'm not sure how I can do this today.
Error I get when I don't set it is:
 System.InvalidOperationException: The SessionId was not set on a message, and it cannot be sent to the entity. Entities that have session support enabled can only receive messages that have the SessionId set to a valid value.
My workaround for now is to propagate messages using IProjection in Marten, where I do the following:
var msg = new ServiceBusMessage(@event.Data.ToString()) {           SessionId = @event.StreamId.ToString()    };

Tasks

[ ] Envelope.GroupId
[ ] DeliveryOptions.GroupId
[ ] DeliveryOptions.Override maps it
[ ] Add mapping to AzureServiceBusEnvelopeMapper
[ ] End to end w/ FIFO queue
[ ] End to end w/ Azure SErvice Bus scheduled messages
[ ] ISendMyself helper. object.WithGroupId(string) and object.WithSessionId(string) in Azure Service Bus model


Write protect the master branch

The master branch needs to be write protected to only allow pull requests after automated testing is completed and passed.

Master branch is write protected and requires passing travis tests for pull requests. I have not enabled a coverage threshold or coverage decrease threshold because I wasn't sure I could set different thresholds for master and other branches and wanted to wait to see what kind of fluctuation in coverage we might tolerate making branches available between developers during active development. Though I guess we could set the bar pretty low (like 95%) with no problem. In any case I am getting slack notifications and of course run the tests before any commit so this is probably a less urgent issue, unless anyone has strong feelings about the right thing to do.


KAFKA-17491: Move BrokerServerMetrics to server module

Committer Checklist (excluded from commit message)

[ ] Verify design and implementation
[ ] Verify test coverage and CI build status
[ ] Verify documentation (including upgrade notes)

@chia7712 @mimaison Hello, please take a look at the PR.


Support for TiDB

I think it would be add support for TiDB to Everest.
There is a operator for TiDB available [here]) https://github.com/pingcap/tidb-operator).
From what I understood at the presentation during Percona Connect Amsterdam it should be easy to add more database flavors. However looking at the source code it looked like the current MySQL(PXC)/PostgreSQL/MongoDB things are quite intertwined with all other code. I didn't see any extension/plugin system. I also didn't see much documentation about how to add more database flavors.
Besides adding support for something else that could serve as an example for adding more databases could be useful. Maybe Valkey?

@dveeden that is a valid concern that we don't have extension/plugin system. It is on our radar to make it simpler.
On our horizon we want to add Valkey and Clickhouse. TiDB frankly was not in the list, but we might reconsider. It don't have any particular ETAs though to share.

Valkey or KeyDB would be amazing! Also clickhouse, we are using that quite a bit.


Ajax Data - Load on demand

Is there any way I could work with Ajax Data? I mean it works beautifully currently with data table but if I have more than 5000 rows, it's not a good idea to send everything.
I would prefer if TableFilter could talk to an Data API where it fetches on demand - 10 rows in the beginning and if something is searched, then connect back and get more data. Similarly if next page is clicked, get more data.
The only trouble I see is on sorting. But even in that case, the backend api should be able to help.

Hi @shekharsom, the basic principle/philosophy behind this library is to work on a pre-existing html table, no matter how that is generated. Loading data/rendering the table is intentionally beyond the scope of this script. This means it is the developer's responsibility to put an appropriate loading/rendering strategy in place especially for large datasets. TableFilter has an extensive API with many hooks available, lots of callbacks and events. So you can imagine having custom column filters asynchronously loading and rendering the data before taking advantage of the script's filtering capabilities.

You might have a look to the documentation and the WIKI for the callbacks and events.
Don't hesitate to ask.


Create the lidar sensor

Create the lidar sensor and include it to the main robot xacro file

Created laser sensor with the topic > /laser/scan


chore: remove gh-pages

This PR removes GH pages, which are unneeded because we deploy docs via Netlify on any merge to the dev branch.
After merging this PR, we can delete the gh-pages branch.
One thing I'm a bit uncertain of is if docs/assets/CNAME and docs/assets/circle.yml are used in some other way. The code doesn't have any references after deleting scripts/update-docs.sh, but I'm still paranoid.
Thoughts?

The CNAME is for GHpages to allow domain binding. Netlify should not need it.
As for circleCI config, once we remove the branch, it should be fine.

PRs that reduce total amount of code - my favorite kind.


workflows/eval: Add the eval summary as a comment

See it in action https://github.com/azuwis/nixpkgs/pull/9
Make https://github.com/NixOS/nixpkgs/pull/360339 more discoverable.
Will post a comment like:

Eval summary

Added packages: 0
Removed packages: 0
Changed packages: 1
Rebuild Linux: 1
Rebuild Darwin: 0

Compared to https://github.com/NixOS/nixpkgs/pull/360962:

Only post single comment, and update it on subsequent push, reduce noise for long-running pull requests
See https://github.com/NixOS/nixpkgs/pull/360962#discussion_r1865303075
Only summary and link, no details, will not affect GH search results
See https://github.com/NixOS/nixpkgs/pull/360962#issuecomment-2510730459

Things done

Built on platform(s)

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

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

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

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

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

[ ] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

I think the main benefit here is the link to the evaluation results. Numbers are already provided by the labels

https://github.com/NixOS/nixpkgs/pull/361344#issuecomment-2513701701

Hmm not sure if I like having such a comment on every single PR

How about only post the comment, if more than 10 packages are added/removed/changed? Like this https://github.com/NixOS/nixpkgs/pull/361365#issuecomment-2513813206

Does requesting reviews actually creates a notification? I don't think it did this for me in the past. I agree with @infinisil I noticed that I found myself having to open updated pull requests more often just to see it was only yet another bot comment: https://github.com/NixOS/nixpkgs/pull/361388


Add documentation for building/running tests & docs

We should have clean docs explaining how to run tests & build docs.

This is quite an old issue (actually the oldest open one I think).
Is this already fixed? I'm digging into elastalert more and more so any kind of development documentation would be very helpful?

I don't think anything in the docs right now mentions the unit tests (which need serious love/refactoring anyway :) )
Should be pretty simple, roughly:

pip install -r requirements-dev.txt
tox


show how to swap content on tab change

i'm not sure this is the canonical method for revealing content associated with a tab, but i think the example should demonstrate how to do that.
i've tested the approach submitted here with an example on the svelte REPL:
https://svelte.dev/repl/6c5f9a70af7d45989fae0b162c8ac15d

Don't need more complex example. Users who using Svelte, should know what is property binding and wont have any problem.
PS: this is really mind-blowing for newbies =)
     Something


Renamed spaces_around_equal to space_character.

Fixes #119

✔ Checklist:

[x] This PR has been added to CHANGELOG.md (at the top of the list);
[ ] Tests for the changes have been added (for bug fixes / features);
[x] Docs have been added / updated (for bug fixes / features).

@SaMuRa1ReM1X 👋Thank you for your contribution! 💪
I have left a comment. Could you please fix it?
Also you have forgotten to update the README.md file.

@SaMuRa1ReM1X Thank you! 🖖


Let's say I have this code
this.gmailJs.observe.on("view_email", (domEmail) => {...
How can I specify that domEmail is of type GmailDomEmail? It seems that I can't get to that type at all :( Thanks!

If your Typescript compiler is setup correctly, all you should need to do is add the type-annotation for that parameter:
this.gmailJs.observe.on("view_email", (domEmail: GmailDomEmail) => {...

Or are you not getting types loaded at all?

@josteink Thanks for the answer! Well, to add that type annotation I need to import the type, but since there are no exports in gmail.d.ts file, it's not considered a module.
Right now, as a solution, I just copied the gmail.d.ts file and added export to the declare class Gmail line at the bottom of the file. It then allows me to do this import type {Gmail, GmailDomEmail, GmailDomCompose} from './@types/gmail'.

I'm literally not doing anything in particular to get those types available in my IDE of choice (Emacs) and to get the compiler to recognize or enforce them.
I don't have to import the types at all. This is the code I have in my GmailJS pre-loader:
// gmail.js needs to be loaded as early as possible to be able to intercept
// embedded email-data in the gmail HTML!
//
// To do that we:
// - just load it
// - make sure it's initialized
// - and do nothing else!
//
// Let the "big" GmailLink extension bundle load separately!

// eslint-disable-next-line @typescript-eslint/no-var-requires
const GmailFactory = require("gmail-js");
// eslint-disable-next-line @typescript-eslint/no-var-requires
const jquery = require("jquery");

const ns = (window as any).ProductName;
ns.Vendor = {};
ns.Vendor.Gmail = new GmailFactory.Gmail(jquery) as Gmail;

And in my extension I can just cast that to value Gmail later on and get type-safety for everything else automatically:
export class GmailHandler {
    gmail: Gmail;

    // ... snip

    constructor() {
        this.gmail = (window as any).ProductName.Vendor.Gmail as Gmail;

I literally didn't have to configure anything for it, at least not as far as I can remember.
Can you share the repo you are using where are struggling to get this working?
Or at least a minimal POC demonstrating your issues? :)

@josteink I've created a stripped down repo at https://github.com/DrParanoia/chrome-gmail-demo.
Basically, I am using PHPStorm. And for example, you can look at src/interface/demo-interface.ts where I used my copied gmail.d.ts file "hack".
Without the "hack", how can I specify types for the interface properties? Also, without the "hack" autocomplete does not work in PHPStorm.
Or, for example, if you look at the src/component/page-change-watcher.ts, how can I specify, that the constructor parameter is of type Gmail without creating a new instance and casting it as Gmail without the "hack"?
I appreciate your help by the way, thanks! 😄

It seems like I added a file called types.d.ts to my project which I forgot about. It basically consists of this one-liner:
import "gmail-js";

That does the trick, and in your repo too! (I've tested :smile:  )

@josteink Thanks for the advice, will try it out! 😆 On a side note, maybe it's worth it to include it by default in the package (or maybe just export the Gmail class in the gmail.d.ts file)? Would be nice if types would work out of the box 😆

If you simply add export to declare class Gmail it also allows you to use the library like this
import {Gmail} from 'gmail-js';
let gmailJs = new Gmail($);

Unfortunately Gmail.js itself does not use “real” classes and “real” exports, so that mighty create a mismatch between the “real” code and the type-definitions.
Before implementing such a change, I’d have to look over it quite thoroughly and make sure:

that the typescript-declared behaviour matches the actual implementation behaviour
that the changes are backwards compatible from both a compile-time and run-time perspective.

To be clear, I’m not against such a change, but I’m not going to do it on a whim.
PRs welcome, I guess 😅

Sure 😆 Well, at least the types.d.ts file workaround works 😅 Maybe at least add it to the readme? 🤣

Just did 1 hour ago 😉

@josteink Nice! Thank you very much! 😆

Great. Considering this issue closed then 🙂

So I got curious and did some testing here.
I've started the work on a v2.0 with breaking changes, and it lives in the vnext-branch.
I've tested that with my code. With that I could remove my types.d.ts hack, and use it like a "normal" NPM-package, and I think that is a great improvement, although an incompatible one! :smile:
Feel free to try it out and let me know what you think!

@josteink Looks nice! I mean the types.d.ts hack is pretty nice (don't have to import any types to use them) 😆 But I feel like importing the types is the proper way of doing it 🤣
Will there be a lot of breaking changes for v2.0? I am currently working on a project for a Gmail Chrome extension, and I think I'll stick with the "hack" for now, simply so that nothing would break in the middle of development 😄

"Planned" breaking changes so far mostly involve removing known broken or useless functions, and some non-async method-forms people shouldn't be using anyway.
In short, if you are:

already using GmailJS via npm and script-bundling
already using typescript
not using known broken functions
and using async-methods where both sync and async options are available...

Then the risk of using the newer code should be absolutely minimal. But then again, the risk in a future upgrade should be similarly small.
No shame in using the current production version for now, if you want to play it safe.


WIP: autoscaling by request rate

Addresses:
#2
#3
#42
Additions:

Adds a support helm chart that includes the Grafana and Prometheus dependencies
Adds autoscaling baed on request rate
removes providerContext garbage
adds docs

@ranchodeluxe , all the improvements  from https://github.com/developmentseed/eoapi-k8s/pull/55 , has been merge to this branch!


e2e: INPROCESS=1 for in-process test debugging

Opt-in, no-guarantee in-process kcp.

Doesn't work without https://github.com/kcp-dev/kcp/pull/424. Closing.


Change healthcheck port Mattermost-app

Default MM port is 8065, so lets have the healthcheck at that port

Summary

Ticket Link

Hello @hpwjnijs,
Thanks for your pull request! A Core Committer will review your pull request soon. For code contributions, you can learn more about the review process here.
Per the Mattermost Contribution Guide, we need to add you to the list of approved contributors for the Mattermost project.
Please help complete the Mattermost contribution license agreement?
Once you have signed the CLA, please comment with /check-cla and confirm that the CLA check is green.
This is a standard procedure for many open source projects.
Please let us know if you have any questions.
We are very happy to have you join our growing community! If you're not yet a member, please consider joining our Contributors community channel to meet other contributors and discuss new opportunities with the core team.

/check-cla

Seems not to be a solution to  'healtcheck' problems.


YAML snapshot contains an extra newline at EOF. Is this intended?

A YAML snapshot contains an extra newline at EOF. For example, line 8 in insta/tests/snapshots/test_basic__unnamed_yaml_vector.snap. Is this intended?
https://github.com/mitsuhiko/insta/blob/f2469bf8f662718fc5fdc1704d8c57bed95334d7/tests/snapshots/test_basic__unnamed_yaml_vector.snap#L1-L8

I am not sure. Sounds like something that should be fixed but I wonder if this regressed as part of some YAML changes.


Issue with autoFormatOnSave and yapf

From @dcramer on June 1, 2017 6:44
Environment data
VS Code version:  1.12.2 (tried Insiders as well)
Python Extension version:  0.6.4
Python Version:   2.7.13
OS and version:    macOS Sierra 10.12.4
Actual behavior
Upon save it reformats the file, and does not appear to behave the same as yapf -i file.
For example, this content:
from __future__ import absolute_import

from django.db import models
from django.utils import timezone

from sentry.db.models import (BoundedBigIntegerField, FlexibleForeignKey,
                              Model, sane_repr)

When I hit save, it generates invalid Python:
from __future__ import absolute_import

from django.db import models
from django.utils import timezone

from sentry.db.models import (
    BoundedBigIntegerField, FlexibleForeignKey, Model, sane_repr
)
)

Expected  behavior
The expected output should be:
from __future__ import absolute_import

from django.db import models
from django.utils import timezone

from sentry.db.models import (
    BoundedBigIntegerField, FlexibleForeignKey, Model, sane_repr
)

Steps to reproduce:

add editor.formatOnSave to workspace settings
save the file

Even when it doesnt incorrectly format the file into invalid Python, it doesnt seem to respect the configuration within setup.cfg (i still get different output from yapf -i).
Here is the changeset which we identified this behavior in:
https://github.com/getsentry/sentry/commit/a2587aa38a40c283eb6780e34f9caefa452ccf77
Settings
Your launch.json (if dealing with debugger issues):

Your settings.json:
{
    "files.exclude": {
        "**/*.pyc": true,
        "static": true,
        "node_modules": true,
        "src/sentry/static/dist": true,
        "env": true
    },
    "prettier.bracketSpacing": false,
    "prettier.singleQuote": true,
    "prettier.printWidth": 90,
    "eslint.options": {
        "configFile": ".eslintrc"
    },
    "[javascript]": {
        "editor.formatOnSave": true
    },
    "[json]": {
        "editor.formatOnSave": true
    },
    "editor.formatOnSave": true,
    "python.linting.pylintEnabled": false,
    "python.linting.flake8Enabled": true,
    "python.formatting.provider": "yapf",
    "python.pythonPath": "${env.WORKON_HOME}/sentry/bin/python"
}

Copied from original issue: DonJayamanne/pythonVSCode#992

From @dcramer on August 10, 2017 4:57
@seanbrant great idea! Will give this a try tomorrow and report back.

From @seanbrant on August 10, 2017 2:42
@dcramer I was running into this as well and might have a temporary solution.
"python.formatting.yapfArgs": ["--style", "${workspaceRoot}/setup.cfg"],

@yegorski, apologies for not having resolved this issue yet. Will look into this soon. I believe I know the problem (I'm creating a temporary file to perform the formatting, and in doing so, the config file isn't picked up)

From @yegorski on October 16, 2017 15:57
As far as autopep8 config is concerned, I got away with this in VS Code's User Settings:
"python.formatting.autopep8Args": ["--max-line-length=120"]
Now on my Mac's VS Code, pressing Option + Shift + F formats the files I want to format.

Is there any workaround for this in the meantime?

Yes, the work around is as follows:
As poured out by @seanbrant
"python.formatting.yapfArgs": ["--style", "${workspaceRoot}/setup.cfg"],

Unfortunately that doesn't seem to work (I did use .style.yapf instead of setup.cfg, but I don't think that should make a difference).

I have a similar issue with yapf as the formatter. VSC with autopep8 works fine for me, but not with yapf. My yapf settings are
"python.formatting.provider": "yapf",
  "python.formatting.yapfArgs": [
        "-p",
        "--style",
        "~/.config/yapf/style"
    ]

There is a one file "0001_initial.py" which VS Code doesn't format with yapf on save (for other files it worked correctly). I tried to switch off all VS Code extensions except Python extension - doesn't help. Manually formatting yapf -i <filename> works. But when I make some changes in the file and save it then formatting worked. When I just save it without any changes formatting doesn't work. May be separate issue should be created? Please advise

@osya can you open a new issue?

@brettcannon I tried to reproduce this issue, but I can't. This file 0001_initial.py is a Django migration file which was generated from PyCharm, outside from VS Code. But I find another thing:

Take some file which already formatted with yapf and open it in VS Code
Press Ctrl-S several times. Nothing changes in formatting. It is as expected
Then make some changes in the file. And save it. Formatting changes - not according to the yapf settings in the setup.cfg file. This behaviour is not expected. Then press Ctrl-S several times again. And now formatting changes according to the yapf settings from the setup.cfg.
Please advise weither it is issue, or may be it is a correct behavior due to may be yapf rereading config file after every file changes?

Without knowing what your settings are set to I don't know. Please open a separate issue.

I believe it's another manifestation of saving temporary files outside the workspace so the tools can't find their config files. It should be fixed on master.

See https://github.com/Microsoft/vscode-python/issues/730

It seems that #730 covers my issue. Though for yapf settings I used section [yapf] in the setup.cfg file rather than .style.yapf file in the #730. So this issue seems can be closed. I can't understand in which version of VS Code #730 merged so didn't test it.


chore: release master

:robot: I have created a release beep boop
@allaround/all-components: 1.3.1
Dependencies

The following workspace dependencies were updated

dependencies

@allaround/button bumped from ^1.2.0 to ^1.3.0
@allaround/input bumped from ^2.1.0 to ^2.2.0
@allaround/label bumped from ^1.0.0 to ^1.1.0

button: 1.3.0
1.3.0 (2023-06-05)
Features

fill prop (85fbf94)

input: 2.2.0
2.2.0 (2023-06-05)
Features

fill prop (85fbf94)

label: 1.1.0
1.1.0 (2023-06-05)
Features

fill prop (85fbf94)

allaround-components: 2.2.0
2.2.0 (2023-06-05)
Features

fill prop (85fbf94)

This PR was generated with Release Please. See documentation.

:robot: Release is at https://github.com/wholesome-ghoul/allaround-components/releases/tag/all-components-v1.3.1 :sunflower:

:robot: Release is at https://github.com/wholesome-ghoul/allaround-components/releases/tag/button-v1.3.0 :sunflower:

:robot: Release is at https://github.com/wholesome-ghoul/allaround-components/releases/tag/input-v2.2.0 :sunflower:

:robot: Release is at https://github.com/wholesome-ghoul/allaround-components/releases/tag/label-v1.1.0 :sunflower: