Enhancement: TaskSetup and TaskTeardown

I think it would be useful to have actions that could be executed before and after each task, particularly if those blocks receive an instance of the current task (or metadata about the task).
For example, that would make it easy to report progress to TeamCity, or maybe add blocks around each task in TeamCity's output to make its build logs more readable.

@jrnail23 Sounds like a good idea :+1:

:+1:

ok then, I'll get started on it :smile:

@patriksvensson, @RichiCoder1, I wanted to get some quick feedback here.
I'm thinking for my TaskSetup/TaskTeardown actions, I want to pass in the Task and the ICakeContext as args, to be available for use by the user's code.
I want ICakeContext to get access to the Log, Environment, etc.
I only really want the Task info to get access to things like Name & Description, etc. -- I don't think it would be advisable to allow the task to be mutated or executed or anything like that.
That suggests at least two alternate approaches:

Create an immutable TaskInfo object that only has the Task's descriptive properties.
Define an ITaskInfo interface that only exposes getters for those descriptive properties, and have CakeTask implement it using its existing members.

What do you guys think?

@jrnail23 I agree with what you're saying.
I would go with option 2. Maybe call it ICakeTaskInfo and expose Name/Description/Criterias and Dependencies.
However, I don't think that you need to provide the ICakeContext for this.

I'd vote two. ITaskInfo sounds like a more testable and future proof solution.
So they'd end up looking like this?:
TaskSetup((context, taskInfo) => {
    Information(context is ICakeContext); // true
    Information(taskInfo.Name); // MyTask
    Information(taskInfo.Description); // MyTask does this thing.
    Information(taskInfo.Dependencies); // IReadOnlyList<string>.Count = 1
    Information(taskInfo.Criterias); // IReadOnlyList<Func<bool>>.Count = 1
});

TaskSetup((context, taskInfo, taskResult) => {
    Information(context is ICakeContext); // true
    Information(Task.Name); // MyTask
    Information(taskResult.RunTime); // TimeSpan (5 seconds)
    Information(taskResult.RanToCompletion); // True    <----
    Information(taskResult.Exception); // null   <------------------  These two are probably redundant with the existing task error reporting extensions.
});

@patriksvensson, the Context would already just be available, right?  The reason I thought to include it is that the CakeTaskBuilder.Does() extension has an overload that provides ICakeContext.
Can you please explain when that overload is intended to be used, as opposed to the one that doesn't provide the context?

@RichiCoder1, that's pretty much what I was thinking.  Good call on including the taskResult in the TaskTeardown.  I hadn't considered that!

Or possible do what places like Roslyn or Auth does and have an ICakeTaskSetupContext and ICakeTaskTeardownContext. The former would just have information about the task, while the later also contains task completion information information.
Also, should they really be called Setup and Teardown? Maybe something like BeforeStart and Completed would be more appropriate?

@patriksvensson, the Context would already just be available, right? The reason I thought to include it is that the  CakeTaskBuilder.Does()  extension has an overload that provides  ICakeContext .
Can you please explain when that overload is intended to be used, as opposed to the one that doesn't provide the context?

Hmm, I'm not exactly sure. That's a good point. Gut feeling says we should pass it in.

@jrnail23 You're right. Include ICakeContext there as well.
@RichiCoder1 What would taskResult contain?

@RichiCoder1 What would  taskResult  contain?

Run time, exception information if and error was thrown, as well as whether or not the Task was even run (all task criterias were met). That last one might not be obvious information, so I'd be ok with leaving that out.

@RichiCoder1 I think TaskSetup/TaskTeardown would go well together with Setup/Teardown.

@patriksvensson, are you saying I should overload it (one method with ICakeContext and one without), or only one with the context?

@jrnail23 Have just one with ICakeContext.
I just realized we already have a Finally handler for tasks. Not sure if TaskTeardown would provide any value.

I also think the task result should probably include the task's duration.

@jrnail23 @RichiCoder1 Maybe we could call the TaskTeardown method Finally instead.

@patriksvensson, the Finally handler is defined per task, right?  TaskTeardown would be defined once and apply to all tasks.

@jrnail23 You're right! Sorry! :smile:

@jrnail23 Should definitly be called TaskSetup and TaskTeardown then.

Yup. That was my argument. Finally is for specific tasks and only takes specific information. TaskTeardown is purely for reporting purposes and receives a lot more general and diagnostic information.

@RichiCoder1, it sounds like you and I are definitely on the same page here.  I also look at this as a way to possibly provide richer feedback/interaction with CI systems like TeamCity.

@jrnail23 @RichiCoder1 Yup. Sounds good to me.
A good thing is to keep things as simple as possible in the first implementation. Less is more until we're absolutely sure about how stuff should be.

@patriksvensson, agreed.  I'll put up a prototype of the implementation ASAP for review and feedback.

@jrnail23 Sounds good :+1: :smile:

Yup. TeamCity is the biggest thing I have in mind, for the exact reasons you mention. Taking of build log blocks would be an easy win with this.
@patriksvensson Yup. I think what we've outlined here should be good.
Rough sketch of possible interfaces @jrnail23
public interface ITaskInfo
{
    public string Name { get; }

    public string Description { get; }

    public IReadOnlyList<string> Dependencies { get; } // Should this be something more concrete? Like ITaskInfos?

    public IReadOnlyList<Func<bool>> Criterias { get; } // Maybe something more concrete too? So we're not re-evaluating criteries that Cake has already evalutated?
}

public interface ITaskSetupContext
{
    public ITaskInfo Task { get; set; }

     public bool MeetsCriteria { get; set; } // Yes/no?
}

public interface ITaskTeardownContext
{
    public ITaskInfo Task { get; set; }

    public TimeSpan Elapsed { get; set; }

    public bool RanSucessfully { get; set; }

    public Exception? ExceptionInfo { get; set; }
}

@RichiCoder1, if the task doesn't meet the criteria, should its task setup even be performed?
(I can imagine arguments both for and against this one)
Also, for the ITaskTeardownContext, RanSuccessfully could be a little confusing.  I think  there may be two questions to ask there:

Did the task run at all?
If it did run, was it successful?

In theory, if ITaskSetupContext.MeetsCriteria is false, then ITaskTeardownContext.RanSuccessfully would be false and ITaskTeardownContext.ExceptionInfo would be null. We could make that more explicit though, I agree that it's vague. An enum of states could possibly work. ITaskStatus with Success, Skipped, Error might work. I would like setup and teardown to be run even if the task itself isn't, if only to allow for custom reporting of skipped tasks.

Like I said before it's probably wise to include as little information as
possible and let this grow organically. We can't change this once we
release it...
On Sep 4, 2015 18:36, "Richard Simpson"<EMAIL_ADDRESS>wrote:

In theory, if ITaskSetupContext.MeetsCriteria is false, then
ITaskTeardownContext.RanSuccessfully would be false and
ITaskTeardownContext.ExceptionInfo would be null. We could make that more
explicit though, I agree that it's vague. An enum of states could possibly
work. ITaskStatus with Success, Skipped, Error might work. I would like
setup and teardown to be run even if the task itself isn't, if only to
allow for custom reporting of skipped tasks.
—
Reply to this email directly or view it on GitHub
https://github.com/cake-build/cake/issues/389#issuecomment-137785492.

I think I agree with reporting skipped tasks.  The only downside I can think of there is additional noise in your logs, but the user can always decide not to log anything if the task was skipped.

I also don't want to release something that's hamstringed. That being said the most simple and straight forward implementation would be to remove ExceptionInfo and RanSuccesfully from teardown, MeetsCriteriafrom Setup, and addSkipped` to teardown. Would allow you to report Start, Header, Skipped Or Not, and Footer.

Also in the interest of preserving our ability to add additional info over time, I think ITaskSetupContext and ITaskTeardownContext are a good idea, even if they start out pretty threadbare.
With those in place, we can add new methods and properties without modifying the signatures, thereby preserving reverse compatibility.

Absolutely.

Yes I agree. The two contexts are a really good idea :smile:
On Sep 4, 2015 18:44, "Richard Simpson"<EMAIL_ADDRESS>wrote:

Absolutely.
—
Reply to this email directly or view it on GitHub
https://github.com/cake-build/cake/issues/389#issuecomment-137787770.

in the teardown context, do you guys prefer Elapsed or Duration?  (I like Duration myself, but if Elapsed is already used elsewhere, I want to stay consistent with your existing vocabulary)

Engine used Elapsed, but Report uses Duration, so I'd say Duration.

Revised interfaces:
public interface ITaskInfo
{
    public string Name { get; }

    public string Description { get; }

    public IReadOnlyList<string> Dependencies { get; }

    public IReadOnlyList<Func<bool>> Criterias { get; }
}

public interface ITaskSetupContext
{
    public ITaskInfo Task { get; set; }
}

public interface ITaskTeardownContext
{
    public ITaskInfo Task { get; set; }

    public TimeSpan Duration { get; set; }

    public bool Skipped { get; set; }
}

And in IScriptHost:
void TaskSetup(Action<ICakeContext, ITaskSetupContext> action);

void TaskTeardown(Action<ICakeContext, ITaskTeardownContext> action);

Isn't Duration what we use?
On Sep 4, 2015 18:48, "James Nail"<EMAIL_ADDRESS>wrote:

in the teardown context, do you guys prefer Elapsed or Duration? (I like
Duration myself, but if Elapsed is already used elsewhere, I want to stay
consistent with your existing vocabulary)
—
Reply to this email directly or view it on GitHub
https://github.com/cake-build/cake/issues/389#issuecomment-137788528.

I'd like to omit Criterias from ICakeTaskInfo for the first iteration.
I think it could introduce some unwanted complexity up front.
You guys cool with that?

I'm abiveliant to criterias to be honest, just included it for completeness. @patriksvensson ?
And yes, re-searching the case, Duration is was CakeReportEntry uses, which is the defacto way that Cake is currently storing that information.

ok, now on to the next question.... what should we do with these things when using a DryRunExecutionStrategy?

Agree. "Duration" is probably best. Engine stuff is internal I think.
On Sep 4, 2015 18:55, "Richard Simpson"<EMAIL_ADDRESS>wrote:

I'm abiveliant to criterias to be honest, just included it for
completeness. @patriksvensson https://github.com/patriksvensson ?
And yes, re-searching the case, Duration is was CakeReportEntry uses,
which is the defacto way that Cake is currently storing that information.
—
Reply to this email directly or view it on GitHub
https://github.com/cake-build/cake/issues/389#issuecomment-137789932.

ok, now on to the next question.... what should we do with these things when using a  DryRunExecutionStrategy ?

Huh. My gut says no, but I'll also defer to @patriksvensson  on this one.

the existing Setup and Teardown actions are no-ops in a dry run, FYI.

You wouldn't really perform a dry run in a CI environment, right?

No, very unlikely.

and I guess there's no telling what the user might choose to do in those actions anyway.  They could, in theory, manipulate the file system.  Having a dry run actually execute those manipulations would violate principle of least surprise.

Indeed, go with noop for now.

@devlead :+1:

The dry run execution strategy shouldn't execute any tasks or anything similar at all.

Just posted my initial prototype --
Some of the complexity or "lack of elegance" is probably a result of me trying to stay consistent with the behavior of the script-level Setup & Teardown actions (if setup fails, don't run the task, but still run the teardown).
Not sure if that's really the desired behavior -- any opinions on that?


test-branch/execute-job/wrong-comment-on-pr/d9401c3c-9deb-4360-bb88-df618dc389d6

PR for testing 5549430ac419a0eab87fdf770821aa9bd0aebde8

comment 1


Post run is slow even when there are no cache misses

Presumably(?) that's because the cache is being saved.  But if there were no misses, there's nothing new to save, so it might be better to just skip it.

The slowdown is probably the same issue as detailed here: https://github.com/hendrikmuhs/ccache-action/issues/178#issuecomment-1913376963.


Doorway home page total listings

Design
As a user on the Doorway Public site looking at the home page,
I want to see text showing "Total Results" indicating the number of listings available and the (Page X of Y) showing how many pages of listings there are in the filter bar,
So that I have a quick way to understand how many listings are available on DHP.
AC:

The filter bar should be sticky
The "Total Results" number should show all the open listings that are available on Doorway, posted directly on Doorway or pulled in from HBA.
The "Page X of Y" should be responsive, so that if I'm the second page out of 5, I should see (Page 2 of 5)

@sarahlazarich I'm wondering about design assets for this…here's a totally unstyled version of this as I'm working on it:

and I was poking around in Figma and I found this example:
https://www.figma.com/design/r2AcSv6D7VwYVdOF5jmt0d/dwy-patterns?node-id=4-11091&t=5nJZl2xDCDGvX5u2-4
Should we explore something in that direction perhaps?

@sarahlazarich It looks like we'll need translations for the following strings:
search.totalResults: "Total results"
t.pageXofY: "Page %{current} of %{total}"

Spanish:
Resultados totales
Página %{current} de %{total}
Chinese:
總結果
第 %{current} 頁，共 %{total} 頁
Vietnamese:
Tổng kết quả
Trang %{current} trên %{total}
Tagalog:
Kabuuang mga resulta
Pahina %{current} ng %{total}

Hi! Seeing some weirdness here - The "Total Results" says 3 but there are 4 things returned.

Also - noticing that the listing tags obscure this when you scroll through

@sarahlazarich will look into it!


Update chainlist

Related issue: #3020

🚀 Deployed on https://pr-3024--sw-web-runner.netlify.app


Non-integer ID field + PUT - property not being escaped

ID field for my REST resource is the string Name property, thus I have:
.factory("Dormitory", ['Restangular', function (Restangular) {
    return Restangular.withConfig(function (RestangularConfigurer) {
        RestangularConfigurer.setRestangularFields({ id: "Name" });
    });
} ]);

GET works fine, when called like this:
Dormitory.one("dormitory", encodeURIComponent($route.current.params.Id)).get();
unfortunately, when I later edit (through form with ng-model) the retrieved object and want to store it in the backend, I call
$scope.dorm.put().then(_redirect);
which causes the invalid url to be built, i.e. the "Name" property should be escapeURIComponent-ed, but they're not. In my case, when I type "Akademik #1" as the Name, I end up with the PUT request being sent to the following URI:
PUT http://localhost:8080/dormitory/Akademik%20
as you can see, the Name property is being trimmed after first space.

This is still broken for me -- you escaped the ID on line 674 but not on line 663

Actually, I think the bug I am experiencing is in ng-admin, sorry.

I think my specific bug was caused by ng-admin, not Restangular, sorry.
Line 663 does look bugged to me though.


Document what versions of MATLAB are supported

I can't find information about what versions of MATLAB are working.
There seem to be big changes in 2012 and again in 2016. Do we support earlier versions? What versions are tested?

I would need to go back and test. All versions since I started building it in 2019 should work, I don’t remember any issues that weren’t corrected on our end. But versions previous to that haven’t been tested. I can look into doing this.

It might be good enough to say "R2019b and newer" as long as we know it works with the most recent MATLAB as well…?

I upgraded to Matlab 2024a and everything seems to work as expected.

I added to the readme a line stating that the tools are compatible with matlab versions R2019b and newer, but are untested on earlier versions. If you think this is enough, I'll go ahead and close this issue, but I could download earlier versions and test them if you think it's worth it, especially if there are particular versions that underwent large changes.

Adding the versions here might also be helpful? Maybe 2019b…2024a instead of 2019b and newer?
I think it is more than reasonable to support 5 years and 10 versions of a language and software development kit, so no need to test earlier versions from my point of view.

Sure, we'll just need to remember to update the docs every time a new version is released, once we test it out. I'll add to that page as well.

resolved with commit 246b814


Request (documentation) - New simple multi-layers map example

Add a second (simpler) multi-layers map example in the documentation on this page https://leafletjs.com/examples/layers-control/
create 3 layers
create a layers control, add the 3 layers to it,
create a map with the first layer
add the layers control to the map
(why? following the existing layers + overlays example, i'd added all 3 layers to the map at the same time, causing a lot of unnecessary tile requests. It was only the concatanated attributions that eventually alerted me to this)

Hi,
Thanks for suggestion, but can you explain how adding 3 layers (your use case) is different than adding 2 layers (current tutorial use case)

Being new to leaflet (google maps price changes!), I followed the current example to try and create a map with 3  possible layers (A or B or C).
It seemed to work, but I'd managed to add 3 layers to the map all at the same time, causing 3 x (tile requests), with layer 1 hiding layers 2 and 3.
Hence a suggestion of  a simple 3 layers map example for people to copy, with no overlays (e.g. road / satellite / terrain)

I believe that current example is good enough.


[v2]: drop support for old operating systems

Time has come. I've come here to delete code and chew bubblegum. And I'm all out of bubblegum.
🔥 🔥 🔥 Windows XP 🔥 🔥 🔥
/cc @libuv/collaborators
I haven't tried to compile this yet, it's possible some includes are missing now that we call many functions directly instead of the dynamically loaded ones.
More improvements might be possible on Windows now that we drop the XP baggage, for example using CancelIoEx, but that's a story for another patch.
I also dropped support for MSVC < 2015, everyone just get with the program already.

LGTM with a comment.  Also down with dropping support for pre-VS 2015.
One of the commits says "drop support for macOS < 10.9" but it looks like it's actually dropping support for < 10.7?

One of the commits says "drop support for macOS < 10.9" but it looks like it's actually dropping support for < 10.7?

See https://github.com/libuv/libuv/pull/966/commits/2cfc28601053586a4492a186821b3a24996ffcbf#diff-6a16903c26af4b4035eda9922a73ecc9L339
It will probably continue to compile, though with a warning. Same for 10.7, it would compile and run, but a test or 2 will fail. It's kinda more of a statement. I'll also update the README to reflect that.

Nice! LGTM

LGTM if it works :)

CI: https://ci.nodejs.org/view/libuv/job/libuv-test-commit/82/

CI is 💚 for the relevant platforms. Game on!

Btw, @piscisaureus if you have suggestions on things we could do better now that XP/2k3 support is not a concern, please let me know!


[FLINK-26694] LookupFunction doesn't support multilevel inheritance.

What is the purpose of the change
Describe [FLINK-26694] . Let LookupFunction support multilevel inheritance.
Brief change log
(for example:)

The TaskInfo is stored in the blob store on job creation time as a persistent artifact
Deployments RPC transmits only the blob storage reference
TaskManagers retrieve the TaskInfo from the blob cache

Verifying this change
Please make sure both new and modified tests in this PR follows the conventions defined in our code quality guide: https://flink.apache.org/contributing/code-style-and-quality-common.html#testing
(Please pick either of the following options)
This change is a trivial rework / code cleanup without any test coverage.
(or)
This change is already covered by existing tests, such as (please describe tests).
(or)
This change added tests and can be verified as follows:
(example:)

Added integration tests for end-to-end deployment with large payloads (100MB)
Extended integration test for recovery after master (JobManager) failure
Added test that validates that TaskInfo is transferred only once across recoveries
Manually verified the change by running a 4 node cluster with 2 JobManagers and 4 TaskManagers, a stateful streaming program, and killing one JobManager and two TaskManagers during the execution, verifying that recovery happens correctly.

Does this pull request potentially affect one of the following parts:

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

Documentation

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

@tsianglei  Could you share the development about this issue? Why this pr is closed?


setup mock website for stakeholder feedback

Per commit https://github.com/mhk-env/bakerydemo/commit/6d06386e6732c5e3a056f6a9748ee6c66976af8b, I added the following web services to mhk-env.us:

cms.mhk-env.us: content management system using wagtail, initially populated with bakerydemo

rstudio.mhk-env.us: RStudio IDE for R

shiny.mhk-env.us: Shiny apps

Grabbed nginx.tmpl from [FEATURE] Allow multiple ports per virtual host by frederikbosch · Pull Request #1157 · jwilder/nginx-proxy to get goin with these two small commits:

nginx-proxy w/ multiple ports for shiny:3838 rstudio:8787 fixes https… · mhk-env/bakerydemo@5ec6d84
init +nginx-proxy +rstudio-shiny · mhk-env/bakerydemo@6d06386

2019-07-22 wagtail initial setup
See: mhk-env/bakerydemo: docker-compose.yml
login to server

Installing SSHPass
pipe - piping a password located in a file to the ssh command - Unix & Linux Stack Exchange

sshpass -f ~/.mhk-env.us_bbest.password ssh<EMAIL_ADDRESS>
docker run wagtail
Your first Wagtail site — Wagtail 2.5.1 documentation
Forked:

wagtail/bakerydemo

#sudo apt install python3-pip
sudo apt install docker-compose

git clone https://github.com/mhk-env/bakerydemo.git wagtail
cd wagtail

#docker network create netproxy
# rm wag*: docker ps -aq --filter name=wag* | xargs docker rm
# rm *: docker ps -aq | xargs docker rm
docker-compose up --build -d
# wait until all containers are up
docker-compose run app /venv/bin/python manage.py load_initial_data

# stop
docker-compose stop
# start
docker-compose up -d
# list
docker ps -a

edit docker-compose.yml
cd wagtail
vi docker-compose.yml

app:
  networks:
    - netproxy
  environment:
    VIRTUAL_HOST: mhk-env.us
  expose:
    - "8000"
networks:
  netproxy:
    external:
      name: netproxy

setup reverse proxy

jwilder/nginx-proxy: Automated nginx proxy for Docker containers using docker-gen

Automated Nginx Reverse Proxy for Docker ·

Old
docker network create --driver bridge netproxy

docker run -d -ti --rm -p 80:80 \
  -v /var/run/docker.sock:/tmp/docker.sock:ro \
  --network netproxy \
  --name proxy jwilder/nginx-proxy

New
Fold into wagtail/docker-compose.yml
Need same rstudio-shiny container to serve two different ports:
upstream shiny.mhk-env.us {
	server <IP_ADDRESS>:3838;
}

upstream rstudio.mhk-env.us {
	server <IP_ADDRESS>:8787;
}

SOLUTION: [FEATURE] Allow multiple ports per virtual host by frederikbosch · Pull Request #1157 · jwilder/nginx-proxy

used nginx.tmpl

messing with nginx-proxy
docker logs proxy

# extract the generated nginx configuration
docker exec wagtail_nginx-proxy_1 cat /etc/nginx/conf.d/default.conf

# terminal
docker exec -it wagtail_nginx-proxy_1 bash
cat /etc/nginx/conf.d/default.conf

# manually reload nginx
docker exec wagtail_nginx-proxy_1 nginx -s reload

# edit conf
apt-get update
apt-get install vim
vi /etc/nginx/conf.d/default.conf


Merge upstream

Here are the latest changes from upstream, including the changes to the engine code for reducing the need for byte swapping :) Once this is merged I can start going over the changes, cleaning up the history and picking individual parts for merging.

nice , one thing, shouldn't libpthreds be called libpthread ?

I have error  can't find -lpthreads
I have -lpthread here without 's'.
Didn't have that error earlier.

Really not sure what that could be related to, have you tried rerunning the CMake script from a clean folder? You will have to debug it since I'm not having this issue on any of my Linux systems (Windows and Mac builds also pass).

OK, I will.


Configuration setting need to have an option to disallow "any" in TypeScript source code

TypeScript Version:
1.8.10
Code
var foo = 23;
var fee = "fff";

**Expected behavior:**
Somehow show that any is being used and strict data type need to be used.   The problem is JavaScript is too forgiving where "foo" can bee seen as either a number or string.

**Actual behavior:**
Both foo and fee default to "any" because data type is not being specified.  Example "var foo: number = 23;" and "var fee: string = "fff";".

@fletchsod-developer, in typescript, the types of foo and fee will be deduced as number and string by the inferred type of the RHS of the assignment, and will not be deduced as any
However, had you written the following, foo would be inferred as any:
var foo; // implicitly typed as any
foo = 23;

In that case, there is already a compiler option noImplicitAny that would produce compiler errors in this case, requiring you to either be explicit about the use of any:
var foo: any; // explicitly typed as any
foo = 23

or better by using the actual type (or union type) of the variable:
var foo: number|string; // explicitly typed
foo = 23
foo = "fff";

I see.  It doesn't returned compiler error when 'noImplicitAny' is set to true.

there are no any types in this sample. they are number and string.
these two are identical.
var foo = 23;
var foo: number = 23;;

A variable is given the type any, if 1. it does not have a type annotation, and 2. a type could not be inferred from its initialization.
so:
var foo; /// this is of type any.

compiler that with --noImplicitAny and you will see an error.

Shouldn't --noImplicitAny raise compiler error when this example below is missing : number
 var foo = 23;

because foo: number isn't being used.

you do not need to add a type annotation to every thing. the compiler can infer types on its own. if you forgot and did not give a variable a type at declaration site, --noImplicitAny will warn you about it.

Okay.  We'll have to get used to it.  Thanks.

hover is your friend :)


API server prohibits duplicate names

- API server checks for unique values on Groups, Hooks and Workflow objects. Also checks for unique values on Hook Checks and Operations
- if duplicate names are detected, Kube API server will not create/edit the object, which greatly simplifies runtime error checking

Signed-off-by: Travis Janssen<EMAIL_ADDRESS>

df214a30417c0131b50394425239c3b6614eb7ac contains both updates: CRDs have been updated, and unit tests have been added.


[CLI] fix: ensure process exits when user selects 'No' in git tracking prompt

Please check if the PR fulfills these requirements:

[x] The commit message follows our code of conduct and contributing guidelines
[ ] Tests for the changes have been added (for bug fixes/features)
[ ] Docs have been added / updated (for bug fixes / features)

Please include the following information in your pull request:

What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)

Bug fix

What is the current behavior? (You can also link to an open issue here)

When the target folder is not tracked by git and the user selects 'No' in the prompt indicating that the codemod changes might be irreversible, the process continues instead of exiting. This is due to a return statement that causes the function to exit prematurely.

What is the new behavior (if this is a feature change)?

The process now correctly exits when the user selects 'No' in the prompt, ensuring that the codemod changes are not applied if the target folder is not tracked by git.

Does this PR introduce a breaking change? (What changes might users need to make in their application due to this PR?)

No, this PR does not introduce any breaking changes.

Any other information (if needed):

@all-contributors add @morinokami for code and bug fixes


ExportInspectorTest

nice work!

Thanx. I'm going to hit one class at a time until we have full coverage.


breadcrumb when deleting any resource

What would you like to be added:
when deleting a kind like a pod or a deployment, have the confirmation box show the full breadcrumb like <cluster>/<namespace>/<kind>/<name>. currently it only shows <name>
Why is this needed:
UX - with so many clusters and namespaces, it is useful to double check the breadcrumb in one area instead of looking all over the lens app screen to verify
Environment you are Lens application on:
all

Kubernetes distribution: [EKS, AKS, GKE, Rancher, ...]
all

Desktop OS:
mac os big sur

@jansav thank you!


[Bug] [Question]: New opyplus release seems to break sinergym import

Bug, Question 🐛❓
On trying to verify installation by running the tests I get the  error below. I noticed that opyplus released a new version yesterday (25/06/2024), could it be the issue?
ImportError while loading conftest '/workspaces/sinergym/tests/conftest.py'. tests/conftest.py:10: in <module>     import sinergym sinergym/__init__.py:7: in <module>     from sinergym.utils.common import convert_conf_to_env_parameters sinergym/utils/common.py:13: in <module>     from opyplus.epm.record import Record E   ModuleNotFoundError: No module named 'opyplus.epm.record'; 'opyplus.epm' is not a package
To Reproduce
Install sinergym and open a terminal on the running container. Try to validate installation by running
pytest /tests -vv

I followed the installation steps below a windows 11 system with docker desktop and git bash:

git clone https://github.com/ugr-sail/sinergym.git
docker build -t sinergym-image .
winpty docker run -it "image-tag"
pytest /tests -vv

Expected behavior
Successful test logs

Hi @V-for-Vaggelis!
First, thank you very much for informing me about the issue. Since I was working with the container and didn't rebuild, I hadn't noticed this problem.
I took advantage of the latest PR I was working on and added the patch that fixes it. Additionally, Sinergym is now compatible with the latest stable version of Python (3.12.3), as opyplus was the cause of the incompatibility.
Thank you very much, and I hope this is helpful to you :)


tidy deps

Pull Request Test Coverage Report for Build<PHONE_NUMBER>0
Details

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

Totals

Change from base Build<PHONE_NUMBER>2:
0.0%

Covered Lines:
2374

Relevant Lines:
2787

💛  - Coveralls


Batch Delete() with separate transaction for each DELETE command.

Hi Team,
I need to delete millions records from a table using some condition. (Truncate table is not an option for me). But I cannot run Delete command in one transaction as transaction log file will grow too much. I want to run batch delete and wrap each delete command in a separate transaction to control size of transaction log file.
Your lib is great. And I wonder if you support such case.
Currently, if I run this
ctx.Tbl
    .Where(x => x.StateCode == "CA" && x.Version == "V1")
    .Delete();

It produces this sql commands:
SELECT
    [Extent1].[Id] AS [Id]
    FROM [dbo].[Tbl] AS [Extent1]
    WHERE (N'CA' = [Extent1].[StateCode]) AND (N'V1' = [Extent1].[Version])

-- Executing at 5/27/2018 10:07:14 AM -04:00
-- Completed in 0 ms with result: null

DECLARE @rowAffected INT
DECLARE @totalRowAffected INT

SET @totalRowAffected = 0

WHILE @rowAffected IS NULL
    OR @rowAffected > 0
    BEGIN
        DELETE TOP (4000)
        FROM    A
        FROM    [dbo].[Tbl] AS A
                INNER JOIN ( SELECT
    [Extent1].[Id] AS [Id]
    FROM [dbo].[Tbl] AS [Extent1]
    WHERE (N'CA' = [Extent1].[StateCode]) AND (N'V1' = [Extent1].[Version])
                           ) AS B ON A.[Id] = B.[Id]

        SET @rowAffected = @@ROWCOUNT
        SET @totalRowAffected = @totalRowAffected + @rowAffected
    END

SELECT  @totalRowAffected

-- Executing at 5/27/2018 10:07:14 AM -04:00
-- Completed in 5 ms with result: 1

Why do you have SELECT while deleting rows?
SELECT
    [Extent1].[Id] AS [Id]
    FROM [dbo].[Tbl] AS [Extent1]
    WHERE (N'CA' = [Extent1].[StateCode]) AND (N'V1' = [Extent1].[Version])

And actually what I am looking for is something like below:
-- No parent transaction as we use separate transaction for each batch inside loop
DECLARE @rowAffected INT
DECLARE @totalRowAffected INT

SET @totalRowAffected = 0

WHILE @rowAffected IS NULL
    OR @rowAffected > 0
    BEGIN
        BEGIN TRANSACTION

        DELETE TOP (4000)
        FROM    A
        FROM    [dbo].[Tbl] AS A
                INNER JOIN ( SELECT
    [Extent1].[Id] AS [Id]
    FROM [dbo].[Tbl] AS [Extent1]
    WHERE (N'CA' = [Extent1].[StateCode]) AND (N'V1' = [Extent1].[Version])
                           ) AS B ON A.[Id] = B.[Id]

        SET @rowAffected = @@ROWCOUNT
        SET @totalRowAffected = @totalRowAffected + @rowAffected

        COMMIT
    END

SELECT @totalRowAffected

--
Sergiy

Hello @smzinovyev ,
The first SELECT doesn't hit the database. It's a trick on our side to get the SELECT to include in the INNER JOIN
The INNER JOIN is required because we use some Entity Framework. We are aware the query can be optimized but we will no longer be able to support as much as we do currently.
We will eventually try to remove the INNER JOIN when that's not needed but currently, that is too much effort for the time we are able to pass on this library.
Best Regards,
Jonathan

Hello @smzinovyev ,
This issue will be closed since it has been answered.
However, we still have an open task on our to-do list on our side to eventually fix it.
Best Regards,
Jonathan


When switching the rootViewController out all of the views double in size

I have just updated my copy of this library from the version it was back in August and I'm getting a strange bug where all of the content views in my view hierarchy are double in size. I'm not sure if it is being caused by this library as I did update a few others (but none of them would or should have an effect on the view hierarchy), I'm interested though to see if you or anyone else has come across this?
*screenshot attached

*

You need to override method rootViewWillLayoutSubviewsWithSize:
Something like that:
- (void)rootViewWillLayoutSubviewsWithSize:(CGSize)size {
    self.rootView.frame = CGRectMake(0.0, 0.0, size.width, size.height);
}

Or you can add constraints to it's superview

This fixed it! Thanks for the rapid response!

You are welcome :)


Add implementation links to pystac for sat, scientific, and version.

Related Issue(s): #
None
Proposed Changes:

Added implementation links for the sat, scientific, and version extensions in pystac

PR Checklist:

[ ] I have added my changes to the CHANGELOG or a CHANGELOG entry is not required.

I don't think this warrants a CHANGELOG entry, but I can add one if folks thing there should be one

I only added the extensions that I implemented.  I can add links for the rest of the pystac extensions if folks want.

More a general question @cholmes @matthewhanson , but wasn't the list of implementations meant to include catalogs exposing the fields (i.e. example catalogs) so that we get details on the maturity? But it seems at the moment people only add software libraries so we may want to reconsider this. What is meant to be listed here? For example, the validators implement all extensions, but it doesn't seem to be very valuable to add them here.

I agree a better use of the "Implementations" section would be to point to catalogs that use the extension, rather than tools that include a feature for that specific extension.

Thanks for the clarification

Yes, intent was to be the actual catalogs using it. Though I do think it would be good to also list the software that supports a given extension, so users can know that they can use X software to help with the extension, and it's also an indication of maturity.

Weren't we going to move Implementations out of the spec and onto the stac website? That gives us a way to keep a live version without having to make a release or look at the dev branch.
Also, maybe stacindex is the better place to store this info (for catalogs). Using the extensions advertised it could be automatically generated and used to generate implementation lists for each extension. That way it wouldn't be reliant on someone adding this information.

Yes, I agree. We should try to leave this out of the spec to limit changes and friction here.

Closing for now as I've started implementing that [API] extensions can be assigned to each ecosystem entry on stacindex.org. I still need to support modifying existing entries, but we'll get there another day. Until then I'm happy to change it manually, just send me an e-mail with a full list of supported STAC extensions / STAC API extensions.


Broken link to Azure Linux documentation

There is a link on this page to the Azure Linux documentation on Github that takes me to a 404 - here's the link:
https://microsoft.github.io/CBL-Mariner/docs/#cbl-mariner-linux

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

ID: e1977c22-c4c0-fd89-371a-1dc86a6607c6
Version Independent ID: 80cdb329-c65d-c887-224d-c3a943889592
Content: Use the Azure Linux container host on Azure Kubernetes Service (AKS) - Azure Kubernetes Service
Content Source: articles/aks/use-azure-linux.md
Service: azure-kubernetes-service
GitHub Login: @MGoedtel
Microsoft Alias: magoedte

@MGoedtel
Can you please check and add your comments on this doc update request as applicable.

I'll file a work item and update the article in a moment. The author should have specified this for the link - https://github.com/microsoft/azurelinux. I'm opening a PR now to correct it.
Thanks for letting us know about the broken link.  #please-close

Created PR - https://github.com/MicrosoftDocs/azure-docs-pr/pull/267608


1 means not_entailment in RTE?

I test the fine-tuned model of RTE and find that 1 means not_entailment. Is that right?

Hey, so the way fairseq finetuning treats labels is as just like token dictionary.
You can find the mapping in of label_index i.e. 1 to real label string in RTE-bin/label/dict.txt
You can find the mapping by following line also:
label_fn = lambda label: roberta.task.label_dictionary.string(
    [label + roberta.task.target_dictionary.nspecial]
)

Please take a look at the "Inference on GLUE task" section here


Allow control over automatic bond assignment

Hey all, This is working great so far. Except that my models are coarse-grained, so the bonds that come out from automatic assignment are not correct.
I have the topology information, so I can provide bonds (ideal solution), or I was think I could generate cylinder shapes for each bond. An alternative is that I could scale, or modify, the radii constrain for determining bonding information.
Any suggestions on which approach is best?

If you want to implement the machinery to provide bond information we'd be open to include it (though I'd suggest we first have a bit of discussion on how to do it so that it doesn't make other use cases more complicated or slow). We most definitely do not have the bandwidth to actively help though.
Otherwise, if you want to do this with existing infrastructure, manually defining the bonds as shapes is probably the easiest way, look at the implementation of ase_merge_pi_frames.

I would be very happy to contribute this feature in the future. I am not familiar with typescript, but it does seem like that would be quite a major overhaul of dataset.ts and viewer.ts to do this without breaking anything.
So, I will work with the ase_merge_pi_frames code for now, which seems to do exactly what I want with the shapes.
Thank you!

If I may make a suggestion - if you make a topology_to_shapes utility function that is fairly general and based on standard topo formats, this would be a very much welcome contribution. I'm leaving this open in case you go this way.

This would be quite nice to have. If someone wants to take a shot at it, here is what would need to happen for a full, clean integration:

add bond information in the Structure interface, likely as Array[[number, number]], where each number is the index of one atom in the bonds
use this bond information in the StructureViewer, using the current automatic bond assignment only if the data is not provided in the input.
update the Python code to emit bond information when converting from user-provided structures. I don't think ASE stores the topology in the Atoms objects, so this would be a feature of other structure converters / manually added after conversion.

None of this should break other code, it should be fairly self-contained!

Thank you, both!
I will start with the topology_to_shape approach because it seems simpler.
Once I have that working, I can share that and we can see if @Luthaf suggestion would work nicely based on it.
Thank you again!

I think both options are useful to have so it's great to start from the easy one. Good chemiscoping.

Hey both,
I have managed to get bonding information written as shapes, but I am not seeing the shapes in the viewer, and I cannot figure out if there is something I am obviously doing wrong. Attached is a json file with one structure:
cs_2p3_toff_2P3.json
Because there are more bonds than atoms, I had to use the structure properties to add vectors. But then you need one entry per structure for a given shape, so I have N shapes for the number of bonds, which have a list of vectors and positions for each structure.

yes this definitely won't work, you're right. didn't think that the path integral helper has one bond per atom.
I can see two options (besides doing the "right thing" straight away and implement @Luthaf  solution). the "I really want a hack" way would be to create dummy atoms on which to pin the bonds, the other (with a complexity which is half-way) is to create a shape type that is a list of vectors so it can draw many cylinders per frame. Still, it's strange that the file you created does not show any bond at all, it should work.

I think, considering my time frame, it makes sense to just learn something new and implement the "right thing". I am not in a rush, and I like the idea of contributing to this project.
I will submit a PR, probably in draft form with something to discuss at some point.
I agree that it is strange that that file fails to show any shape.

So #363 should fix the (two) issues related to using cylinders to display bonds.

so I have N shapes for the number of bonds, which have a list of vectors and positions for each structure.

I can see two other workarounds here: (a) you can create a single "custom" shape instead of cylinders, containing all bonds in the system (by manually building a mesh corresponding to all the cylinders) or (b) you can add multiple shapes and then add settings in your JSON file to always select them all by default, which removes the need to select them for people viewing the dataset.

That is great, thank you! So based on that fix, the file I sent should work (with the addition of the named shapes in settings)?

Yes, this file works with the linked PR. If you checkout the branch locally, you can run pip install . and use it from Python, or just npm start to get the website interface & load your dataset there.

This works a charm - I am happy to contribute the topology to shapes code as a utility once I make it more general if you are all interested. I still intend on doing the more complete method @Luthaf described but it may take some time.

There is an issue in my code for the example of this.
I think the settings need to be added to the second jupyter visualisation.

@andrewtarzia I was having a look. I really like the possibility of doing custom bonds, and it's great that you have now something you can use in your project. I'd really like however (if you have the bandwitdh) not to close this yet, and try to move towards a "cleaner" solution - in particular one in which you don't have to define a separate shape per bond.
I'm thinking of defining a collection shape type where you can define a base shape and then essentially add a dimension to the arrays that define the positions so you can make a single shape type that contains all bonds.

Hey both, I do agree. And now that I feel a bit more familiar with the underlying code, I would be willing to give it a go. I have some holidays coming up, so it won't be until after them. If it's ok to leave it open for now and I'll come back to it in a month or so?

Yes, this can wait!


stm32: nxstyle fixes

Summary
arch/arm/src/stm32/stm32_gpio.c
arch/arm/src/stm32/stm32_rcc.c
arch/arm/src/stm32/stm32_rcc.h
* nxstyle fixes, mostly long lines

Impact
Removes numerous nxstyle errors.
Testing
Passes nxstyle

Why is it saying that the macOS (mips-riscv-x86-xtensa) test was cancelled?

An other case, @btashton and @liuguo09 . Anyway let's merge the PR first.


Fix Notebooks in examples/

After the recent refactoring, the notebooks in examples/  might not apply anymore. Test and fix if needed.

Some of this has been fixed in PR #70

Closed with #97


Support XBRL taxonomy files

Please add support for XBRL Formula 1.0 taxonomy files.
https://specifications.xbrl.org/work-product-index-formula-formula-1.0.html

The focus of this extension is support for the XPath and XSLT languages. As such, XML functionality such as validation and auto-completion for XBRL is out of scope. If there are specific XPath or XSLT needs for XBRL then please expand on this.
The XML Language Support by Red Hat project might consider a request for general XBRL support if they don't already provide it.

Maybe it would be possible to tokenize xpath expressions inside specific XBRL attributes? No need to support XBRL per se, just recoginze xpath attributes and tokenize their values.

XPath specific syntax highlighting for XBRL formula 1.0 taxonomy files is an easier goal to start with. I will reopen this issue.


Enhancement: Merge the frontend and backend image by hosting frontend content from inside the backend

Suggestion: Host frontend files from the backend image
I do not know how hard it would by, but would it be possible to have the frontend static files added to the backend image so that a specific librephotos proxy is not required?

It is possible, but there needs to be some effort to ensure everything is backwards compatible to not break current environments. The proxy also hosts the media files and benchmarks on the performance are also needed.


BTRFS delete volume fails inside a contrainer

Required information

Distribution: Ubuntu
Distribution version: 16.04
The output of "lxc info" or if that fails:

Kernel version: 4.4.0-36-generic
LXC version: 2.0.4
LXD version: 2.0.4
Storage backend in use: btrfs (4.4)

Issue description
BTRFS delete volume fails inside a contrainer.
I'm trying to create a container inside container, but on remove I cannot removes the subvolume.
Because of this problem you cannot create new container with the same name, because the subvol/folder already exists.
The same happens if you create a btrfs subvolume in the container and try to delete it.
Steps to reproduce
Test 1. Just with btrfs

Create container with btrfs backend
btrfs subv create test in the container > OK
btrfs subv delete test in the container

Response: ERROR: cannot delete '/root/test': Operation not permitted
Test 2. Just with container inside container

Create container with btrfs backend
Create sub-container
Delete sub-container

Response: error: Error cleaning up /var/lib/lxd/containers/test: remove /var/lib/lxd/containers/test: operation not permitted

Create sub-container with the same name
Response: error: The container already exists

Information to attach

syslog (journalctl):

Sep 03 14:07:46 web lxd[315]: t=2016-09-03T14:07:46+0000 lvl=warn msg="subvolume delete failed" driver=storage/btrfs subvol=/var/lib/lxd/containers/test output="ERROR: cannot delete '/var/lib/lxd/containers/test': Operation not permitted\nDelete subvolume (no-commit): '/var/lib/lxd/containers/test'\n"
Sep 03 14:07:46 web lxd[315]: t=2016-09-03T14:07:46+0000 lvl=eror msg="ContainerDelete: failed" driver=storage/btrfs err="remove /var/lib/lxd/containers/test: operation not permitted" cPath=/var/lib/lxd/containers/test

Did you mount your btrfs filesystem with the option required for unprivileged subvolume deletion?

That's the "user_subvol_rm_allowed" mount option for btrfs in current kernels.

No, I have never heard of that option. Going to try it that.

Yes, that workt for my and I see that you updated the documentation. Great!
Thanks for the help.

I'm hitting this problem, even my btrfs is mounted with the option:
/dev/mapper/vg0-lxd on /var/lib/lxd type btrfs (rw,relatime,ssd,space_cache,user_subvol_rm_allowed,subvolid=5,subvol=/)

$ lxc delete --force openstack
rm: cannot remove '/var/lib/lxd/storage-pools/default/containers/openstack/rootfs/var/snap/conjure-up/common/lxd/storage-pools/default/containers/juju-d4fdec-0/rootfs/var/lib/docker/btrfs/subvolumes/83787ab6a3354805a13ea57af0d233d7d361da4e2fc2db2172a77d872d721c69': Operation not permitted
rm: cannot remove '/var/lib/lxd/storage-pools/default/containers/openstack/rootfs/var/snap/conjure-up/common/lxd/storage-pools/default/containers/juju-d4fdec-0/rootfs/var/lib/docker/btrfs/subvolumes/f5b06922b58e2f5726ec71fa24e1650e9b01a5f7ed1b28cd1a140d55973a7f27': Operation not permitted
rm: cannot remove '/var/lib/lxd/storage-pools/default/containers/openstack/rootfs/var/snap/conjure-up/common/lxd/storage-pools/default/containers/juju-d4fdec-0/rootfs/var/lib/docker/btrfs/subvolumes/195405de5be648893a65992ebf6ecca358ba1076ae2aef1970234b569dfbae80': Operation not permitted
rm: cannot remove '/var/lib/lxd/storage-pools/default/containers/openstack/rootfs/var/snap/conjure-up/common/lxd/storage-pools/default/containers/juju-d4fdec-0/rootfs/var/lib/docker/btrfs/subvolumes/6740da2f43eff7946d56cf65d63be73ea5de26f41f7fa7000e06fd4a9d0b7157': Operation not permitted
...

Can you show lxc info?

lxc info
config:
core.https_address: <IP_ADDRESS>:8443
api_extensions:

storage_zfs_remove_snapshots
container_host_shutdown_timeout
container_syscall_filtering
auth_pki
container_last_used_at
etag
patch
usb_devices
https_allowed_credentials
image_compression_algorithm
directory_manipulation
container_cpu_time
storage_zfs_use_refquota
storage_lvm_mount_options
network
profile_usedby
container_push
container_exec_recording
certificate_update
container_exec_signal_handling
gpu_devices
container_image_properties
migration_progress
id_map
network_firewall_filtering
network_routes
storage
file_delete
file_append
network_dhcp_expiry
storage_lvm_vg_rename
storage_lvm_thinpool_rename
network_vlan
image_create_aliases
container_stateless_copy
api_status: stable
api_version: "1.0"
auth: trusted
public: false
environment:
addresses:

<IP_ADDRESS>:8443
<IP_ADDRESS>:8443
architectures:
x86_64
i686
certificate: |
-----BEGIN CERTIFICATE-----
MIIFWTCCA0GgAwIBAgIRAOhz6GiDrC829pvcp6mft30wDQYJKoZIhvcNAQELBQAw
NjEcMBoGA1UEChMTbGludXhjb250YWluZXJzLm9yZzEWMBQGA1UEAwwNcm9vdEBo
ZXR6bmVyMjAeFw0xNzA2MjEyMTU2NDJaFw0yNzA2MTkyMTU2NDJaMDYxHDAaBgNV
BAoTE2xpbnV4Y29udGFpbmVycy5vcmcxFjAUBgNVBAMMDXJvb3RAaGV0em5lcjIw
ggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQCwunbXOPg2hrI577fWp1X3
oMaYXZltluMEpTjy85hESusWMMObZhReR1OueNHLWdlqQDNOVowovStUJBMHoWxP
O1mJL0mJ11qiydKOpkg2YiCCOYlfZm4xwtUOim+Anu1UyH1Dhnmi2QkVs4umc2mC
bbTCM6ObohOQf1IW0RtqfxL2VkeUZ1OtBIBwV602eYqUXG42AIOtRLueE2RmhhsL
+2Vi8xsBWN/yeto9fD4+4Bp/HbMOO1FfprUHo29kysIHT+cCtb86pSd6zLLuKac/
Fso+XtuLE0oWMkXUOJvo7G2fqeMkwZFDoCNFYe593umqXxO+/hzRCSo107PsSDUN
EhS4Z5Y0BSvNTV3MSzcewcnhnOOnBvA7bqcRA4l6CoYT8oKur+Wy09qGkHUDoLch
qUEt19cnj8YfRKbh87ursn3GSkednvKwZYuo68D7l6TYVJykyL+oQWuS745mbjBQ
IRGZMinB+VPnHpJAaLstQ8RN6INgTouMAmip0A06Y9+85oUx+F14GsIUJ1+MWrB6
jt4vaJ6r0mC+/axSkoJKtQOtntw5bARHZtTx8ney85SY5L3XnlLA32ZwuOAlWz9A
4wYd7ZpdfFgCzELS5mu/T6TtM86bb4YDTTBQu/XY3b7ecA/68U9+qiJMtjaP3QTW
aMagjtjQy0SGMqt5XEp7XQIDAQABo2IwYDAOBgNVHQ8BAf8EBAMCBaAwEwYDVR0l
BAwwCgYIKwYBBQUHAwEwDAYDVR0TAQH/BAIwADArBgNVHREEJDAigghoZXR6bmVy
MocEiPMo34cQKgEE+AISCNwAAAAAAAAAAjANBgkqhkiG9w0BAQsFAAOCAgEACkWW
q2U/BbWSFvMJJog2ulNDBkxk51s+GyJCFzgCKGm0v6o0iLbVGnzFZ7cQPED0Vbjf
yhgbG5ME6cyygIfnzkyOuv15X9LTe7g7EM/4bdpn6J95Wa3Ic5mtlFNzok7M1W7F
p9ZXR9Swd4QehgLaz59pB9ZhDFtPNTDuCOc+043/ZZSTyVian8lFktp2GGLZ2W5r
bb0mfVqv67QWdcDS1Q4q28PQqxOql2to4uK4Y5CQHo8Ov9TKVhfiJ66vQN3uVI0P
5LntD2DjMojaZeu1WMELxnc77X2aVfv5ZGkY5ve3ELbEH5cpPf++fE5sKuVCwjH6
YaGyOFp486JQLhgqLryTyds9TVTOtC5OSZXKDUhI+TQfvTCY1YBaFnVWssu4yGlC
Hgu4cEqUN2ozzGIk0e93yCuZtwNowVxW5XVtT0NMqk/6js1DNrAnmwjYD4KsrM/u
cpsWGVlGHcu5tJr9sQwDfBQNmGZL9zBvEExBlcOVCg4FstpVz051NTyPLQGC45aS
7Vslm5E6V7ZcILeB+pjr6V3UUqA9+6awt42ELwABF/uEZXmBHb+3m13NUbl0M7aU
CrCXH6YBLfMIycJBW1rPJK5aFgPWc5r6f88Ki/I1EdJCGLkVJ4oPTeLuzx03RJCA
DcjgI8uCiDy0CJ+xaObxEsrTENPpzP4Hc3kQCSY=
-----END CERTIFICATE-----
certificate_fingerprint: 30ff161614b8f591a65942463d174e1914fc8c4ba2bbdd1fe7ea9d2a1a7a6794
driver: lxc
driver_version: 2.0.7
kernel: Linux
kernel_architecture: x86_64
kernel_version: 4.10.0-21-generic
server: lxd
server_pid: 9544
server_version: "2.12"
storage: dir
storage_version: "1"

And I can wipe the subvolumes from outside the LXC container with this command:
btrfs subvolume delete /var/lib/lxd/storage-pools/default/containers/kubernetes/rootfs/var/snap/conjure-up/common/lxd/storage-pools/default/containers//rootfs/var/lib/docker/btrfs/subvolumes/
Then, I can delete the LXC container:
lxc delete kubernetes

If you still have such a broken container, can you post "btrfs subvolume list /var/lib/lxd/storage-pools/default/" prior to any attempt at deleting it?
That should give us enough information to reproduce this if it's a "simple" issue of subvolume ordering or subvolume detection.

I've reconstructed my container (I have it automated with Ansible, so can recreate it as many times as needed). Here's the output you requested:

ID 1238 gen 33863 top level 5 path storage-pools/default/containers/kubernetes/rootfs/var/snap/conjure-up/common/lxd/storage-pools/default/containers/juju-b89057-0/rootfs/var/lib/docker/btrfs/subvolumes/6657ea76babe687fbfb2ea256e9eae3bea966ed7241e3ab416f52eeb141cae9b
ID 1239 gen 33837 top level 5 path storage-pools/default/containers/kubernetes/rootfs/var/snap/conjure-up/common/lxd/storage-pools/default/containers/juju-b89057-0/rootfs/var/lib/docker/btrfs/subvolumes/0ceed4d8e980c95e4546cc16dcaa182f5ac345bfa1fc3ff2560d77c2acdb49a9
ID 1240 gen 33947 top level 5 path storage-pools/default/containers/kubernetes/rootfs/var/snap/conjure-up/common/lxd/storage-pools/default/containers/juju-b89057-0/rootfs/var/lib/docker/btrfs/subvolumes/50ab5b6751c052489988a011577dc953bd2d536a75e2a8ea06d670d002e35da9
ID 1243 gen 33841 top level 5 path storage-pools/default/containers/kubernetes/rootfs/var/snap/conjure-up/common/lxd/storage-pools/default/containers/juju-b89057-0/rootfs/var/lib/docker/btrfs/subvolumes/38ad17a8e8ba94cfd9febd36113d24941ae88044c95b4c54d0587cad9874283c-init
ID 1244 gen 33846 top level 5 path storage-pools/default/containers/kubernetes/rootfs/var/snap/conjure-up/common/lxd/storage-pools/default/containers/juju-b89057-0/rootfs/var/lib/docker/btrfs/subvolumes/38ad17a8e8ba94cfd9febd36113d24941ae88044c95b4c54d0587cad9874283c
ID 1245 gen 33843 top level 5 path storage-pools/default/containers/kubernetes/rootfs/var/snap/conjure-up/common/lxd/storage-pools/default/containers/juju-b89057-0/rootfs/var/lib/docker/btrfs/subvolumes/6b7371e461e7c12bf46c9f739c6ff3e09b940e6cb5d10e8f4c7326d5a2b12419-init
ID 1246 gen 33846 top level 5 path storage-pools/default/containers/kubernetes/rootfs/var/snap/conjure-up/common/lxd/storage-pools/default/containers/juju-b89057-0/rootfs/var/lib/docker/btrfs/subvolumes/6b7371e461e7c12bf46c9f739c6ff3e09b940e6cb5d10e8f4c7326d5a2b12419
ID 1247 gen 33845 top level 5 path storage-pools/default/containers/kubernetes/rootfs/var/snap/conjure-up/common/lxd/storage-pools/default/containers/juju-b89057-0/rootfs/var/lib/docker/btrfs/subvolumes/f66da0e38ead038c76f5a9672628a3b25406e0d5d3761a1f1c93694baee60f88-init
ID 1248 gen 33846 top level 5 path storage-pools/default/containers/kubernetes/rootfs/var/snap/conjure-up/common/lxd/storage-pools/default/containers/juju-b89057-0/rootfs/var/lib/docker/btrfs/subvolumes/f66da0e38ead038c76f5a9672628a3b25406e0d5d3761a1f1c93694baee60f88
ID 1249 gen 33847 top level 5 path storage-pools/default/containers/kubernetes/rootfs/var/snap/conjure-up/common/lxd/storage-pools/default/containers/juju-b89057-0/rootfs/var/lib/docker/btrfs/subvolumes/b2258311379ded0602f43b702fdafcf289b1893f3b28b7cc4081ac3be7b81ad6-init
ID 1250 gen 33848 top level 5 path storage-pools/default/containers/kubernetes/rootfs/var/snap/conjure-up/common/lxd/storage-pools/default/containers/juju-b89057-0/rootfs/var/lib/docker/btrfs/subvolumes/b2258311379ded0602f43b702fdafcf289b1893f3b28b7cc4081ac3be7b81ad6
ID 1251 gen 33849 top level 5 path storage-pools/default/containers/kubernetes/rootfs/var/snap/conjure-up/common/lxd/storage-pools/default/containers/juju-b89057-0/rootfs/var/lib/docker/btrfs/subvolumes/979525786fac66bcb37db1f7b4977d047fcfe336dfcecdf9ec2637a64ff3cb19-init
ID 1252 gen 33850 top level 5 path storage-pools/default/containers/kubernetes/rootfs/var/snap/conjure-up/common/lxd/storage-pools/default/containers/juju-b89057-0/rootfs/var/lib/docker/btrfs/subvolumes/979525786fac66bcb37db1f7b4977d047fcfe336dfcecdf9ec2637a64ff3cb19
ID 1253 gen 33922 top level 5 path storage-pools/default/containers/kubernetes/rootfs/var/snap/conjure-up/common/lxd/storage-pools/default/containers/juju-b89057-0/rootfs/var/lib/docker/btrfs/subvolumes/81457e94e79b14d172a88144350897a2c4574e42d1b537a4c8af10dfb1f795f4
ID 1254 gen 33852 top level 5 path storage-pools/default/containers/kubernetes/rootfs/var/snap/conjure-up/common/lxd/storage-pools/default/containers/juju-b89057-0/rootfs/var/lib/docker/btrfs/subvolumes/41226839f37f7538fc2da695041d854699b6945eb7fca71db5c69a7bf918eb65
ID 1255 gen 33853 top level 5 path storage-pools/default/containers/kubernetes/rootfs/var/snap/conjure-up/common/lxd/storage-pools/default/containers/juju-b89057-0/rootfs/var/lib/docker/btrfs/subvolumes/5e5c4dfe8c8935fad586b0453f3ac7b4e971b545e630a0f5915e33fa09070100-init
ID 1256 gen 33854 top level 5 path storage-pools/default/containers/kubernetes/rootfs/var/snap/conjure-up/common/lxd/storage-pools/default/containers/juju-b89057-0/rootfs/var/lib/docker/btrfs/subvolumes/5e5c4dfe8c8935fad586b0453f3ac7b4e971b545e630a0f5915e33fa09070100
ID 1257 gen 33905 top level 5 path storage-pools/default/containers/kubernetes/rootfs/var/snap/conjure-up/common/lxd/storage-pools/default/containers/juju-b89057-0/rootfs/var/lib/docker/btrfs/subvolumes/e93274350b0166008008917c3ee62bdc9eaf9eb393a8cdf80093041a3322534d
ID 1258 gen 33856 top level 5 path storage-pools/default/containers/kubernetes/rootfs/var/snap/conjure-up/common/lxd/storage-pools/default/containers/juju-b89057-0/rootfs/var/lib/docker/btrfs/subvolumes/f874590ee3a21769f5a235e6aae52f9d56bec088abaa71a7232e8895b18da2c8
ID 1259 gen 33857 top level 5 path storage-pools/default/containers/kubernetes/rootfs/var/snap/conjure-up/common/lxd/storage-pools/default/containers/juju-b89057-0/rootfs/var/lib/docker/btrfs/subvolumes/9bf04ba663c300d5c3309654080803951c77de358b2f0c7297cd9d4d5241783d
ID 1260 gen 33858 top level 5 path storage-pools/default/containers/kubernetes/rootfs/var/snap/conjure-up/common/lxd/storage-pools/default/containers/juju-b89057-0/rootfs/var/lib/docker/btrfs/subvolumes/0ff4362172615bf1744a7fdf58de60b28e9e0a514d1c2d98e77ed26d813f6444-init
ID 1261 gen 33859 top level 5 path storage-pools/default/containers/kubernetes/rootfs/var/snap/conjure-up/common/lxd/storage-pools/default/containers/juju-b89057-0/rootfs/var/lib/docker/btrfs/subvolumes/0ff4362172615bf1744a7fdf58de60b28e9e0a514d1c2d98e77ed26d813f6444
ID 1262 gen 33861 top level 5 path storage-pools/default/containers/kubernetes/rootfs/var/snap/conjure-up/common/lxd/storage-pools/default/containers/juju-b89057-0/rootfs/var/lib/docker/btrfs/subvolumes/31a85345eef2025f3846bafa71d3ca2f1d3a7ca22180591a9cae389acdedce9f
ID 1263 gen 33862 top level 5 path storage-pools/default/containers/kubernetes/rootfs/var/snap/conjure-up/common/lxd/storage-pools/default/containers/juju-b89057-0/rootfs/var/lib/docker/btrfs/subvolumes/b840530ad8b207bdfde16d70d712ca4219d9b628949424b170aca71f86391a32-init
ID 1264 gen 33914 top level 5 path storage-pools/default/containers/kubernetes/rootfs/var/snap/conjure-up/common/lxd/storage-pools/default/containers/juju-b89057-0/rootfs/var/lib/docker/btrfs/subvolumes/b840530ad8b207bdfde16d70d712ca4219d9b628949424b170aca71f86391a32
ID 1265 gen 33864 top level 5 path storage-pools/default/containers/kubernetes/rootfs/var/snap/conjure-up/common/lxd/storage-pools/default/containers/juju-b89057-0/rootfs/var/lib/docker/btrfs/subvolumes/ae4c2b43c52cdefc894d9fefc0a1b0e0acb68c6a830743ced27fdb875e42f44f
ID 1266 gen 33865 top level 5 path storage-pools/default/containers/kubernetes/rootfs/var/snap/conjure-up/common/lxd/storage-pools/default/containers/juju-b89057-0/rootfs/var/lib/docker/btrfs/subvolumes/f298316457c08403c41387c0bc3cb67194df51b073f8ba7dbcdeb850e3c3c941
ID 1267 gen 33866 top level 5 path storage-pools/default/containers/kubernetes/rootfs/var/snap/conjure-up/common/lxd/storage-pools/default/containers/juju-b89057-0/rootfs/var/lib/docker/btrfs/subvolumes/bf82b0333e3cba640d760958bc14b4aa384f8bf7e3fc982148dc32a85afa7c80
ID 1268 gen 33867 top level 5 path storage-pools/default/containers/kubernetes/rootfs/var/snap/conjure-up/common/lxd/storage-pools/default/containers/juju-b89057-0/rootfs/var/lib/docker/btrfs/subvolumes/1f0d502683355011d83550bf6f72984a26d3f3a612035454bdaf7bb8712dcd3c
ID 1269 gen 33868 top level 5 path storage-pools/default/containers/kubernetes/rootfs/var/snap/conjure-up/common/lxd/storage-pools/default/containers/juju-b89057-0/rootfs/var/lib/docker/btrfs/subvolumes/a5d8c7e220a51a4bec07fa13e1e99aa765f9783e237d0e1995393249aea0b4f0
ID 1270 gen 33869 top level 5 path storage-pools/default/containers/kubernetes/rootfs/var/snap/conjure-up/common/lxd/storage-pools/default/containers/juju-b89057-0/rootfs/var/lib/docker/btrfs/subvolumes/6cf688d7a5b7e9ceaf8521ef4e0cd4f6f610518483bb052485d6e53f0b6f516d-init
ID 1271 gen 33870 top level 5 path storage-pools/default/containers/kubernetes/rootfs/var/snap/conjure-up/common/lxd/storage-pools/default/containers/juju-b89057-0/rootfs/var/lib/docker/btrfs/subvolumes/6cf688d7a5b7e9ceaf8521ef4e0cd4f6f610518483bb052485d6e53f0b6f516d
ID 1272 gen 33871 top level 5 path storage-pools/default/containers/kubernetes/rootfs/var/snap/conjure-up/common/lxd/storage-pools/default/containers/juju-b89057-0/rootfs/var/lib/docker/btrfs/subvolumes/d8364af66abcd7fe217eac2791adf150476df4d536402ac9c477af45cacc859b
ID 1273 gen 33872 top level 5 path storage-pools/default/containers/kubernetes/rootfs/var/snap/conjure-up/common/lxd/storage-pools/default/containers/juju-b89057-0/rootfs/var/lib/docker/btrfs/subvolumes/6abf6881fc1774ef398eaa3aa198485110b9a64f6f6c485eda2bbca40f52fcf9
ID 1274 gen 33873 top level 5 path storage-pools/default/containers/kubernetes/rootfs/var/snap/conjure-up/common/lxd/storage-pools/default/containers/juju-b89057-0/rootfs/var/lib/docker/btrfs/subvolumes/7571ded50e5f15d4f2ecb24e811de220660d779db98ef218d5518ec6f17b511f
ID 1275 gen 33874 top level 5 path storage-pools/default/containers/kubernetes/rootfs/var/snap/conjure-up/common/lxd/storage-pools/default/containers/juju-b89057-0/rootfs/var/lib/docker/btrfs/subvolumes/6583a8b3432fc395ef2c78780a8d591df0c9efc74f7a57b3dd49dc7449108044
ID 1276 gen 33875 top level 5 path storage-pools/default/containers/kubernetes/rootfs/var/snap/conjure-up/common/lxd/storage-pools/default/containers/juju-b89057-0/rootfs/var/lib/docker/btrfs/subvolumes/61b2eaa3ca155f448ec5499fa9f84367d2086ca9247cf9f14b0eb156540875a6
ID 1277 gen 33876 top level 5 path storage-pools/default/containers/kubernetes/rootfs/var/snap/conjure-up/common/lxd/storage-pools/default/containers/juju-b89057-0/rootfs/var/lib/docker/btrfs/subvolumes/0b88c015a3f93b32fa7907b11b624c06c74148717de47de7359e57721f6977b6
ID 1278 gen 33877 top level 5 path storage-pools/default/containers/kubernetes/rootfs/var/snap/conjure-up/common/lxd/storage-pools/default/containers/juju-b89057-0/rootfs/var/lib/docker/btrfs/subvolumes/ccf9d92ade339cc089fa4e926a0ca80787925ff989bd4437a274bd41522146b1
ID 1279 gen 33878 top level 5 path storage-pools/default/containers/kubernetes/rootfs/var/snap/conjure-up/common/lxd/storage-pools/default/containers/juju-b89057-0/rootfs/var/lib/docker/btrfs/subvolumes/a12391d9e38f50049d5696da98b72909b47b19328babb3cd8948f2f1510118a7
ID 1280 gen 33879 top level 5 path storage-pools/default/containers/kubernetes/rootfs/var/snap/conjure-up/common/lxd/storage-pools/default/containers/juju-b89057-0/rootfs/var/lib/docker/btrfs/subvolumes/de32ff71163f8a2bd4ebd827b5a6362c052428f0f87bf4a86ed4a36440cd1a16
ID 1281 gen 33880 top level 5 path storage-pools/default/containers/kubernetes/rootfs/var/snap/conjure-up/common/lxd/storage-pools/default/containers/juju-b89057-0/rootfs/var/lib/docker/btrfs/subvolumes/c0d6283ac4047f55a8bd259a48615ac9f13f50a8726d1c167142cc26b1d42fe1
ID 1282 gen 33881 top level 5 path storage-pools/default/containers/kubernetes/rootfs/var/snap/conjure-up/common/lxd/storage-pools/default/containers/juju-b89057-0/rootfs/var/lib/docker/btrfs/subvolumes/f9c615cb0801a9fe9eca32b9508f6bea74504c1907c301348d42ab8e0ba5530e
ID 1283 gen 33882 top level 5 path storage-pools/default/containers/kubernetes/rootfs/var/snap/conjure-up/common/lxd/storage-pools/default/containers/juju-b89057-0/rootfs/var/lib/docker/btrfs/subvolumes/910df2fb1ff762f8f6a4dded2e24fbcbf7ea32c0c320a9d290b1e872a6fa9f0e
ID 1284 gen 33883 top level 5 path storage-pools/default/containers/kubernetes/rootfs/var/snap/conjure-up/common/lxd/storage-pools/default/containers/juju-b89057-0/rootfs/var/lib/docker/btrfs/subvolumes/1c182d417f50672db1883c3c50773afd0c1c158ba8255b98b1d978b215a632fe
ID 1285 gen 33884 top level 5 path storage-pools/default/containers/kubernetes/rootfs/var/snap/conjure-up/common/lxd/storage-pools/default/containers/juju-b89057-0/rootfs/var/lib/docker/btrfs/subvolumes/ab1917eaa57b7472562ca390c0ce858d17f72f3d390a71efb8939cc725ba53f3
ID 1286 gen 33885 top level 5 path storage-pools/default/containers/kubernetes/rootfs/var/snap/conjure-up/common/lxd/storage-pools/default/containers/juju-b89057-0/rootfs/var/lib/docker/btrfs/subvolumes/aeb847472210ac3fe693cfd6ea3a869f308050f5b7708eb75399d871f472c59f
ID 1287 gen 33886 top level 5 path storage-pools/default/containers/kubernetes/rootfs/var/snap/conjure-up/common/lxd/storage-pools/default/containers/juju-b89057-0/rootfs/var/lib/docker/btrfs/subvolumes/04df50681c02c69988dcbf487b90a895b1a41bebf00594e40037b0dd32124164-init
ID 1288 gen 37247 top level 5 path storage-pools/default/containers/kubernetes/rootfs/var/snap/conjure-up/common/lxd/storage-pools/default/containers/juju-b89057-0/rootfs/var/lib/docker/btrfs/subvolumes/04df50681c02c69988dcbf487b90a895b1a41bebf00594e40037b0dd32124164
ID 1289 gen 33955 top level 5 path storage-pools/default/containers/kubernetes/rootfs/var/snap/conjure-up/common/lxd/storage-pools/default/containers/juju-b89057-0/rootfs/var/lib/docker/btrfs/subvolumes/65721c750aaaf959597066e7e8f06592fe67ad5eae1b3eac71e409d2fd5f1e87
ID 1296 gen 33895 top level 5 path storage-pools/default/containers/kubernetes/rootfs/var/snap/conjure-up/common/lxd/storage-pools/default/containers/juju-b89057-0/rootfs/var/lib/docker/btrfs/subvolumes/ac77bd6794d02dcd4e9f21c2bca69712924a9d0373df302442b8e0beff5711c4
ID 1297 gen 33896 top level 5 path storage-pools/default/containers/kubernetes/rootfs/var/snap/conjure-up/common/lxd/storage-pools/default/containers/juju-b89057-0/rootfs/var/lib/docker/btrfs/subvolumes/54ad6ff423fe4b0f7788ecaead50246c57f500f29115d413acd3a6b24a9fb545
ID 1298 gen 33897 top level 5 path storage-pools/default/containers/kubernetes/rootfs/var/snap/conjure-up/common/lxd/storage-pools/default/containers/juju-b89057-0/rootfs/var/lib/docker/btrfs/subvolumes/6efb16ead015821085769be70786e3f65c038c36b208ea3de6beaa659d7ea341
ID 1299 gen 33898 top level 5 path storage-pools/default/containers/kubernetes/rootfs/var/snap/conjure-up/common/lxd/storage-pools/default/containers/juju-b89057-0/rootfs/var/lib/docker/btrfs/subvolumes/2c5e4f39b26bbfa72b0ff3179890d577708c86279ef368dfff4bf485d23e1047
ID 1300 gen 33899 top level 5 path storage-pools/default/containers/kubernetes/rootfs/var/snap/conjure-up/common/lxd/storage-pools/default/containers/juju-b89057-0/rootfs/var/lib/docker/btrfs/subvolumes/839e17fa7537da1d5c5604bce9a3be6d4af3f51d4534bb02767b7c4713826a3c
ID 1301 gen 33900 top level 5 path storage-pools/default/containers/kubernetes/rootfs/var/snap/conjure-up/common/lxd/storage-pools/default/containers/juju-b89057-0/rootfs/var/lib/docker/btrfs/subvolumes/5762770c2e14477b158302b3eaeb95a70faa18a88beed008517677c9a6e13ca3-init
ID 1302 gen 33957 top level 5 path storage-pools/default/containers/kubernetes/rootfs/var/snap/conjure-up/common/lxd/storage-pools/default/containers/juju-b89057-0/rootfs/var/lib/docker/btrfs/subvolumes/5762770c2e14477b158302b3eaeb95a70faa18a88beed008517677c9a6e13ca3
ID 1303 gen 33908 top level 5 path storage-pools/default/containers/kubernetes/rootfs/var/snap/conjure-up/common/lxd/storage-pools/default/containers/juju-b89057-0/rootfs/var/lib/docker/btrfs/subvolumes/c164c66d7d6d6119cc9ef74b7d4a51219170254f5f8e7885f0c439dd42a72518
ID 1307 gen 33910 top level 5 path storage-pools/default/containers/kubernetes/rootfs/var/snap/conjure-up/common/lxd/storage-pools/default/containers/juju-b89057-0/rootfs/var/lib/docker/btrfs/subvolumes/5deb22e6c7e49ae9d0de11c0feef84f3d956f6d166a147792c9dcb917ad639c0
ID 1308 gen 33911 top level 5 path storage-pools/default/containers/kubernetes/rootfs/var/snap/conjure-up/common/lxd/storage-pools/default/containers/juju-b89057-0/rootfs/var/lib/docker/btrfs/subvolumes/f0b4c52a7986a32ce3899d441047bca394f7785bbf5a0b6c0f97dfe61716bcc0
ID 1309 gen 33912 top level 5 path storage-pools/default/containers/kubernetes/rootfs/var/snap/conjure-up/common/lxd/storage-pools/default/containers/juju-b89057-0/rootfs/var/lib/docker/btrfs/subvolumes/a3e215e2f801b850d29791cf768da06248eda9b7616605cf299fac5051a8a68b
ID 1310 gen 33913 top level 5 path storage-pools/default/containers/kubernetes/rootfs/var/snap/conjure-up/common/lxd/storage-pools/default/containers/juju-b89057-0/rootfs/var/lib/docker/btrfs/subvolumes/d017f5e9085cc3a56b0af8c8bbd45545e0858ec9efdd5bb859b533e06f92a7d0-init
ID 1311 gen 33914 top level 5 path storage-pools/default/containers/kubernetes/rootfs/var/snap/conjure-up/common/lxd/storage-pools/default/containers/juju-b89057-0/rootfs/var/lib/docker/btrfs/subvolumes/d017f5e9085cc3a56b0af8c8bbd45545e0858ec9efdd5bb859b533e06f92a7d0
ID 1312 gen 33915 top level 5 path storage-pools/default/containers/kubernetes/rootfs/var/snap/conjure-up/common/lxd/storage-pools/default/containers/juju-b89057-0/rootfs/var/lib/docker/btrfs/subvolumes/9b0a2ae8b3e8043697ef38a2a80c89d1eb906bd059dcdb8d96425b5891310273
ID 1313 gen 33951 top level 5 path storage-pools/default/containers/kubernetes/rootfs/var/snap/conjure-up/common/lxd/storage-pools/default/containers/juju-b89057-0/rootfs/var/lib/docker/btrfs/subvolumes/ec62aab7ffad4a52e629af8abb0962a26f857f7b2fad70c3d9502a4779573173
ID 1320 gen 33923 top level 5 path storage-pools/default/containers/kubernetes/rootfs/var/snap/conjure-up/common/lxd/storage-pools/default/containers/juju-b89057-0/rootfs/var/lib/docker/btrfs/subvolumes/fd48d1ceb4615dc1578763ee40224433833995eba6d8cb2b90035be4c59d31d4
ID 1321 gen 33924 top level 5 path storage-pools/default/containers/kubernetes/rootfs/var/snap/conjure-up/common/lxd/storage-pools/default/containers/juju-b89057-0/rootfs/var/lib/docker/btrfs/subvolumes/462b0c13d0942037bef8aded77f56ed8ab0e164d990575413c36efe3f2bc9020-init
ID 1322 gen 33925 top level 5 path storage-pools/default/containers/kubernetes/rootfs/var/snap/conjure-up/common/lxd/storage-pools/default/containers/juju-b89057-0/rootfs/var/lib/docker/btrfs/subvolumes/462b0c13d0942037bef8aded77f56ed8ab0e164d990575413c36efe3f2bc9020
ID 1341 gen 33948 top level 5 path storage-pools/default/containers/kubernetes/rootfs/var/snap/conjure-up/common/lxd/storage-pools/default/containers/juju-b89057-0/rootfs/var/lib/docker/btrfs/subvolumes/9ff5eaed7e8b0a2e35fcef2606d0c23f5ceb2c71882a98aa3514f53a4a3a9b4e-init
ID 1342 gen 33949 top level 5 path storage-pools/default/containers/kubernetes/rootfs/var/snap/conjure-up/common/lxd/storage-pools/default/containers/juju-b89057-0/rootfs/var/lib/docker/btrfs/subvolumes/9ff5eaed7e8b0a2e35fcef2606d0c23f5ceb2c71882a98aa3514f53a4a3a9b4e
ID 1343 gen 33950 top level 5 path storage-pools/default/containers/kubernetes/rootfs/var/snap/conjure-up/common/lxd/storage-pools/default/containers/juju-b89057-0/rootfs/var/lib/docker/btrfs/subvolumes/28e113fb4c401d180458b28173a135136a6a0bc154699dfe06eb1b9b06d362f5-init
ID 1344 gen 33951 top level 5 path storage-pools/default/containers/kubernetes/rootfs/var/snap/conjure-up/common/lxd/storage-pools/default/containers/juju-b89057-0/rootfs/var/lib/docker/btrfs/subvolumes/28e113fb4c401d180458b28173a135136a6a0bc154699dfe06eb1b9b06d362f5
ID 1345 gen 33952 top level 5 path storage-pools/default/containers/kubernetes/rootfs/var/snap/conjure-up/common/lxd/storage-pools/default/containers/juju-b89057-0/rootfs/var/lib/docker/btrfs/subvolumes/9e9a5f963b49177246fb0400ab64f4936b3cc5081c1490594011af042779c16a-init
ID 1346 gen 33953 top level 5 path storage-pools/default/containers/kubernetes/rootfs/var/snap/conjure-up/common/lxd/storage-pools/default/containers/juju-b89057-0/rootfs/var/lib/docker/btrfs/subvolumes/9e9a5f963b49177246fb0400ab64f4936b3cc5081c1490594011af042779c16a
ID 1347 gen 33954 top level 5 path storage-pools/default/containers/kubernetes/rootfs/var/snap/conjure-up/common/lxd/storage-pools/default/containers/juju-b89057-0/rootfs/var/lib/docker/btrfs/subvolumes/42211b3f3ba44af07c310429b35328dd48e3d4062e8791b6122496837c5e9d6b-init
ID 1348 gen 33957 top level 5 path storage-pools/default/containers/kubernetes/rootfs/var/snap/conjure-up/common/lxd/storage-pools/default/containers/juju-b89057-0/rootfs/var/lib/docker/btrfs/subvolumes/42211b3f3ba44af07c310429b35328dd48e3d4062e8791b6122496837c5e9d6b
ID 1349 gen 33956 top level 5 path storage-pools/default/containers/kubernetes/rootfs/var/snap/conjure-up/common/lxd/storage-pools/default/containers/juju-b89057-0/rootfs/var/lib/docker/btrfs/subvolumes/f078f036488cb3cd8de519c5e4bd0eb18b9af20dbea71e7dff75d81779979e37-init
ID 1350 gen 33957 top level 5 path storage-pools/default/containers/kubernetes/rootfs/var/snap/conjure-up/common/lxd/storage-pools/default/containers/juju-b89057-0/rootfs/var/lib/docker/btrfs/subvolumes/f078f036488cb3cd8de519c5e4bd0eb18b9af20dbea71e7dff75d81779979e37

@falfaro, can you try and reproduce this behavior with LXD 2.14?

@brauner I looked at our changelog and I didn't see anything related to recursive btrfs deletion since 2.12, anything specific you have in mind?

@stgraber, I wonder whether this is a LXD that didn't handle the case when /var/lib/lxd is placed on a btrfs fs already. In that case it would e.g. have created a btrfs loop pool and it might actually not have mounted it with user_subvol_rm_allowed contrary to the /var/lib/lxd subvolume.
@lfaraone, can you show: lxc storage show default?

@brauner: wrong person? I'm a huge fan of LXD, but I use it on ZFS :)

haha, yeah, he probably meant @falfaro

Any progress on this? This is really annoying? I can't delete my container not the files associated with it. I'm seriously thinking of switching to ZFS :-)

# lxc storage show default
config:
  source: /var/lib/lxd/storage-pools/default
name: default
driver: dir
used_by:
- /1.0/containers/cache
- /1.0/containers/kubectl
- /1.0/containers/kubernetes
- /1.0/profiles/default

@falfaro this has nothing to do with btrfs itself. :) It seems that you have created a directory pool on a btrfs backend. Docker inside the container is using the btrfs filesystem to create subvolumes. LXD has no way of deleting these subvolumes. I'd suggest you:

remove Docker from inside the container. That should get rid of all the subvolumes.

then remove the container
Then you should upgrade your LXD instance to the newest version and create a new btrfs storage pool if you want, e.g.
lxc storage create btrfs-pool btrfs source=/var/lib/lxd/storage-pools/btrfs-pool

and then either set it as default for all new container:
lxc profile device set default root pool btrfs-pool

or only create specific container on that pool by passing
lxc launch images:ubuntu/xenial xen1 -s btrfs-pool


Architecture and Modularization of SIGTURK Library

Although we made robust & reasonable choices for programming and scripting of any code artifact we may manually or automatically produce with core guidelines (see https://sigturk.com/sigturk Code Guidelines), the discussion never went far into the architecture as we were to make prototype. Given the short amount of time, I propose that we should start with brainstorming collectively.
I would like to argue for a delicate balance of generality and specialization in consideration of historical trends of NLP, and how to specifically favor intaking data from linguistics for both processing of treatises related to Turkic and beyond, from reconstructions to attestations.
As a concrete point, I would like to exemplify with sequence of input. Obviously, we'll need to be containing than discriminating, hence, we can't have a single "chosen" way. But when doing this, an opportunity emerges: think of tokenization. Tokenization is seen as a separate task by norms, but if we make whether it is a tokenization a matter of metadata, we can have a general method named "transcribe" which takes a transcription method a, and converts to transcription method b, and it can have a shortest path to optimally go from one transcription to another, and treat tokenization as also a transcription method. Such an approach increases commonality by making a "normalize" shared. Imagine like the following diagram (just tentative sketch):
classDiagram
    class transcription {
        +Old Turkic
        +IPA
        +tiktoken_cl100k_base
    }
    class Old_Turkic {
        +transcribe()
    }
    class IPA {
        +transcribe()
    }
    class tiktoken_cl100k_base {
        +transcribe()
    }
    class normalization {
        +operate(transcription)
    }

    transcription --> Old_Turkic: contains
    transcription --> IPA: contains
    transcription --> tiktoken_cl100k_base: contains
    normalization --> transcription: operates on

Let's dialogue to make something that will increase productivity and have reasonable defaults.

Additional thought: any brainstorming on boundaries between transcription, transliteration, and translation for these blocks can have significant impact on trajectory

An inspiration source potentially: https://konlpy.org/en/latest/

From chat @j0ma : Spacy, Stanza
I also mentioned PyTorch Lightning

I was pondering a bit more and if we really want to simplify things by finding shortest path from one input to another output, not necessarily taking in pipeline from user, we might need to opt for a graph API like Taskflow or Tensorflow Graph mode. Given the eager mode's friendliness in REPL for notebooks it'd be critical to have a balance or be explicit about two ways coexisting.
For defaults such as transcribing or translating an input to another for better performance in pipeline, we could also use RLHF for productive defaults (initial scoring maybe only from officers team, no need to try to go to scale fttb imo).
session = ...;
task = session.add_taskgraph()
task.add_input(ty=Old_Uyghur_Script)
task.add_output(ty=Sentiment_Analysis)
session.solve(task)
task(...) // outputs some sort of sentiment analysis through any n-steps that might be needed to have good or valid results. steps should be printable at any time for reproduction purposes

Thinking a tiny more about design process (as we need to ramp things up), I think best way might be to just do TDD, test-driven development. Let's discuss on Monday

It seems like tabular data structuring from papers or other papers is an applicable method. We should probably have tabularize or extract_table methods in our graph system. From presentation of @defnecirci

We've also thought of a pipeline taking open-access publications from different languages (Turkish, Russian, Chinese, etc.) and then structuring them through the library


Open two buffers at the same window and then closing one, exits vim

Self-Diagnosis

[x] I have searched the issues for an answer to my question.
[x] I have reviewed the NERDTree documentation. :h NERDTree
[x] I have reviewed the Wiki.
[x] I have searched the web for an answer to my question.

Environment (for bug reports)

[x] Operating System: macOS 10.15.5
[ ] Vim/Neovim version :echo v:version: 802
[ ] NERDTree version, found on 1st line in NERDTree quickhelp ?: 6.7.13
[ ] vimrc settings

[ ] NERDTree variables: Default
Other NERDTree-dependent Plugins

[ ] jistr/vim-nerdtree-tabs
[ ] ryanoasis/vim-devicons
[ ] tiagofumo/vim-nerdtree-syntax-highlight
[ ] Xuyuanp/nerdtree-git-plugin
[ ] Others (specify):

[x] I've verified the issue occurs with only NERDTree installed.

Steps to Reproduce the Issue

Use a clean .vimrc file with Vim-plug
Use the minimal vimdc file:set nocompatible
filetype plugin indent on
call plug#begin('~/.vim/plugged')
Plug 'scrooloose/nerdtree'
call plug#end()

In terminal, create two files:$ touch file_a
$ touch file_b

Open vim
From NERDTree open file_a (or by using :edit file_a)
From NERDTree open file_b (or by using :edit file_b)
Close the top buffer at the window with either :bd or :bw
Vim exits. This is not normal behavior, because using vim -u NONE -U NONE -N and doing steps 3, 4, 5 & 6 (ofc with :edit), and 7, removes only the top buffer.

Current Result (Include screenshots where appropriate.)
Expected Result
Using vim -u NONE -U NONE -N and doing steps 3, 4, 5 & 6 (ofc with :edit), and 7, removes only the top buffer.
Even with
set nocompatible
filetype plugin indent on
call plug#begin('~/.vim/plugged')
call plug#end()

the behavior is same as with vim -u NONE -U NONE -N.
Finally, question is related to #301 but the solution proposed is to switch buffers and then delete. But:

This solution (i.e. using :bp <cr>:bd<cr>) has the same effect of vim exiting
I want to have the typical behavior with :bd and :bw.

I am not seeing this behavior. Your minimal vimrc file is working for me as you expect it to. I tried the following:

:edit file_a
:edit file_b
:bw  This closes file_b
Vim is still open with file_a showing in the editor.

Strange, but expected, behavior happens when I use NERDTree, but it still doesn't close vim:

:NERDTree
open both file_a and file_b
Keep NERDTree open.
Go to the file_b window.
:bw
Vim is still open, but the window with file_b in it was closed, leaving only NERDTree visible.

I also tried it by using Vim 8+ packages instead of vim-plug, and got the same results.
Try doing :debug bw, and see if any autocommands are causing the isssue.

@PhilRunninger

Vim is still open, but the window with file_b in it was closed, leaving only NERDTree visible.

Have you tried to have both files in the same window? Because this is when the problem happens. If the two files are in different windows, then the problem is not happening.

Yes, there were two windows: one for NERDTree, and the other displaying file_b. With the cursor in the file_b window, :bw deletes the buffer and closes the window just like the Vim documentation describes. The remaining window goes full screen with NERDTree in it.

Still, that is not what I'm describing.
You should have two windows. window 1 with NERDTree, and window 2 with two open buffers, for file_1 and file_2. That is, window_2 should have both file_1 and file_2. Then, if you do :bd or :bw to one of the buffers of file_1 or file_2, Vim will exit.

To describe again the scenario.

Open Vim.
If NERDTree is not open/toggled on, open it.
From NERDTree open one file, i.e. file_a, with 'o' in a window, i.e. window_1.
Again from NERDTree, open another file, i.e. file_b, again with 'o' (i.e. at the same window as file_a, the window_1).
While the cursor is at window_1, do :bw.

Vim will exit, which is not the expected behavior.

That's what I did. Vim does not exit. Try the :debug bw command. In the debugger, use the s command to step through the statements.  Take note of what autocommand or script is running when Vim exits.

I personally don't mind this, but it also happens for me. If I had to guess why it's happening. It's because of the standard auto command that nerdtree recommends to close vim if nerdtree is the only open buffer. When I remove this autocommand, I don't get this behavior anymore. Which would explain why you don't see this with his minimal vimrc.
autocmd BufEnter * if (winnr("$") == 1 && exists("b:NERDTree") && b:NERDTree.isTabTree()) | q | endif

My guess is that when you delete the top buffer, it begins opening the previous buffer, but winnr("$") will still report 1, because you are just entering the buffer from its perspective. So this would trigger the autocommand to quit.
Personally, I always switch to my previous buffer with a <c-^> mapping. Or I just use fzf to search for a buffer. But if this functionality is critical to your workflow, I guess you could modify the autocommand to count the open buffers or something.

@cxgslegend
Can you please tell me how to remove this autocommand? Because I cannot see it in my *rc file.

I think I found it.
It was another plugin, which (for some reason) when I removed it, I had to exit the terminal session and then open a new one in order for the effect of the problematic plugin to go away.
Plugin is the:
https://github.com/jistr/vim-nerdtree-tabs
When I installed it, the unexpected behavior appeared. If, in the same terminal session, I uninstalled the plugin, the behavior would not go away. I had to close the terminal session and open another. This is why I could not find that this was the problem and this is why @PhilRunninger could not see the effect.
Thank you both though. If I had not your feedback, I would not have searched it more.


PIP installing with /tmp mounted noexec

I have found that certain PIP packages won't mount if the /tmp directory is mounted with the noexec mount option.
Example:
1485888563,,ui,message,    default: Error: /Stage[main]/Role::Packer::Orchestration/Python::Pip[ansible]/Exec[pip_install_ansible]/returns: change from notrun to 0 failed: pip wheel --help > /dev/null 2>&1 && { pip wheel --version > /dev/null 2>&1 || wheel_support_flag='--no-use-wheel'; } ; { pip --log /tmp/pip.log install  $wheel_support_flag     ansible==1.9.4 || pip --log /tmp/pip.log install      ansible==1.9.4 ;} returned 1 instead of one of [0]
...
/Stage[main]/Role::Packer::Orchestration/Python::Pip[ansible]/Exec[pip_install_ansible]/returns: Command "/usr/bin/python -u -c "import setuptools%!(PACKER_COMMA) tokenize;__file__='/tmp/pip-build-KGpbhZ/pycrypto/setup.py';f=getattr(tokenize%!(PACKER_COMMA) 'open'%!(PACKER_COMMA) open)(__file__);code=f.read().replace('\r\n'%!(PACKER_COMMA) '\n');f.close();exec(compile(code%!(PACKER_COMMA) __file__%!(PACKER_COMMA) 'exec'))" install --record /tmp/pip-ENqJTX-record/install-record.txt --single-version-externally-managed --compile" failed with error code 1 in /tmp/pip-build-KGpbhZ/pycrypto/

It looks like we could make this work by adding a feature to access pip install --build see doco.

Ok, I realised this can be achieved with
# [*install_args*]
#  String. Any additional installation arguments that will be supplied
#  when running pip install.
#

Actually, I realise that people might be using $install_args for other purposes - e.g. passing in --upgrade to wheel.  If so, it becomes pretty difficult to globally set $install_args to --build /my/builddir. Maybe it would be useful to support an explicity build dir feature after all?


Develop layer which talks to clients

Create a ring/compojure layer, similar to the demo, for all routes
Unit test with mocking

This is fully implemented.


Semi overlapping “more” button and bug report dump expander conflicting

Hard to describe so here’s a screenshot:

Tapping blue button either does nothing, expands the bug report dump, or if I leave the VC and come back, it might take me to a web view saying it can’t open a tel URL.

Bug Report Dump (Auto-generated)

Version 1.26.0<PHONE_NUMBER>)
Device: iPhone X (iOS 12.1.1)
TestFlight: true

I think there is a known issue about the expand button and the bug report and it not always working in general
Sent with GitHawk

Probably my ticket on #2363?

Yup all dupes


Update OpenTelemetry semantic convention to 1.23.0

Updates our semantic convention to 1.23.0 along with all the tests.
Closes https://github.com/grafana/beyla/issues/418

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

Comparison is base (0087b2c) 79.55% compared to head (8190b85) 79.44%.
Report is 1 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #423      +/-   ##
==========================================
- Coverage   79.55%   79.44%   -0.11%
==========================================
  Files          61       61
  Lines        4892     4934      +42
==========================================
+ Hits         3892     3920      +28
- Misses        792      801       +9
- Partials      208      213       +5

Flag
Coverage Δ

integration-test
67.03% <89.24%> (+0.01%)
:arrow_up:

unittests
44.26% <63.44%> (+<0.01%)
:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.

Files
Coverage Δ

pkg/internal/export/otel/traces.go
82.12% <100.00%> (ø)

pkg/internal/export/prom/prom.go
94.14% <100.00%> (+0.32%)
:arrow_up:

pkg/internal/svc/svc.go
72.00% <ø> (ø)

pkg/internal/export/otel/metrics.go
75.56% <97.56%> (+0.56%)
:arrow_up:

pkg/internal/export/otel/common.go
68.38% <80.00%> (+2.00%)
:arrow_up:

... and 3 files with indirect coverage changes

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

ACK!  👏🏻


About Training Time

Thanks for your excellent work.
I have a question about the training time. Due to the batch size being uniformly set at 200 as mentioned in the paper, the training time seems excessively long for datasets with many edges. For instance, in my replication process, DyGFormer w/ patching at an Input Length of 512 takes about an hour and a half per epoch! However, in Table 17 of the appendix in the paper, the reported training time is 37 minutes. This has me puzzled—is that the time for one epoch or the entire training process? My setup is a Xeon Gold 6226R with a GeForce RTX 3090.
I'm not sure if I made an error in my replication process. Thank you very much for your response.
2024-06-09 16:20:47,398 - root - INFO - model name: DyGFormer, #parameters: 5830140 B, 5693.49609375 KB, 5.560054779052734 MB.
2024-06-09 18:07:32,207 - root - INFO - Epoch: 1, learning rate: 0.0001, train loss: 0.3743
2024-06-09 18:07:32,209 - root - INFO - train average_precision, 0.9090
2024-06-09 18:07:32,209 - root - INFO - train roc_auc, 0.9114
2024-06-09 18:07:32,210 - root - INFO - validate loss: 0.3974
2024-06-09 18:07:32,210 - root - INFO - validate average_precision, 0.9031
2024-06-09 18:07:32,210 - root - INFO - validate roc_auc, 0.9030
2024-06-09 18:07:32,210 - root - INFO - new node validate loss: 0.4103
2024-06-09 18:07:32,210 - root - INFO - new node validate average_precision, 0.9040
2024-06-09 18:07:32,210 - root - INFO - new node validate roc_auc, 0.8958
2024-06-09 18:07:32,211 - root - INFO - save model ./saved_models/DyGFormer/lastfm/DyGFormer_seed0/DyGFormer_seed0.pkl
2024-06-09 19:54:34,363 - root - INFO - Epoch: 2, learning rate: 0.0001, train loss: 0.3540
2024-06-09 19:54:34,364 - root - INFO - train average_precision, 0.9197
2024-06-09 19:54:34,365 - root - INFO - train roc_auc, 0.9209
2024-06-09 19:54:34,365 - root - INFO - validate loss: 0.3800
2024-06-09 19:54:34,365 - root - INFO - validate average_precision, 0.9077
2024-06-09 19:54:34,366 - root - INFO - validate roc_auc, 0.9085
2024-06-09 19:54:34,366 - root - INFO - new node validate loss: 0.3913
2024-06-09 19:54:34,366 - root - INFO - new node validate average_precision, 0.9091
2024-06-09 19:54:34,366 - root - INFO - new node validate roc_auc, 0.9028
2024-06-09 19:54:34,366 - root - INFO - save model ./saved_models/DyGFormer/lastfm/DyGFormer_seed0/DyGFormer_seed0.pkl

I think it is the training time for an epoch, training five times with five different random seeds, the whole training time cannot be this short.


Emmet not working with Brackets 1.11 release

I just downloaded the brackets 1.11 update and Emmet along with it, and I keep trying to install it but it keeps giving me the error: "Extension encounter starting up." Please fix this

any solution how to use emmet i have downloded emmet but not working give me solution


Remove unnecessary strcat function

Credit to #491 and @ElliotFriedman
Taking this one step further and just deleting the function

Pull Request Test Coverage Report for Build 8487

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

Totals

Change from base Build 8463:
0.0%

Covered Lines:
1465

Relevant Lines:
1465

💛  - Coveralls


Enhance Crypto Functionality: Enable Users to Specify Target Physical Currency

This pull request introduces an enhancement to the existing crypto functionality of our application. It primarily focuses on allowing users to specify a target physical currency when querying cryptocurrency prices. This feature adds a layer of flexibility and convenience, catering to a global user base with diverse currency preferences.
Changes Made:

Parameter Addition in Slash Command: Modified the CryptoSlashCommand method to include an additional parameter named physicalCurrency. This parameter allows users to specify the physical currency (e.g., USD, EUR, GBP) against which they want to compare or view the cryptocurrency prices.
Updated Command Descriptions: Enhanced the descriptions in the Option attribute for the slash commands. This update ensures that users are clearly informed about the purpose of each parameter, particularly the new physicalCurrency option.
Backend Logic Adjustment: Adjusted the backend logic to handle the conversion or comparison of cryptocurrency prices into the user-specified physical currency. This includes integrating with the relevant financial APIs and ensuring accurate and real-time data fetching.
Error Handling and Validation: Added robust error handling and validation for the new physicalCurrency parameter to ensure the application's stability and reliability.

Benefits:

User Convenience: Users can now view crypto prices in their local or preferred currency, enhancing the application's usability.
Global Accessibility: This feature makes our application more accessible to a global audience, catering to users from different regions with varying currency preferences.
Enhanced Flexibility: Adds an extra layer of flexibility to our crypto functionalities, allowing for a more personalized user experience.

Testing:
Comprehensive tests have been conducted to ensure the new functionality works as expected. This includes unit tests for the backend changes and user acceptance testing to validate the overall user experience.

Top muss dazu sagen hab es nie getestet.  Ich haue das dingen mal rein und update die Docker sachen. Dann steht erstmal nur noch das Lokalisation dingen an und dann reicht das auch erstmal und danach nur noch maintainen.