Add CodeMirror simple-mode addon

Allows extension developers to use CodeMirror's simple mode addon. Fixes #11267 and #10501

@sprintr have you tried adding a simple mode as a new language in Brackets with this?

@mackenza Yes, I added CodeMirror's handlebars mode as a language to brackets. It worked fine when I tested it against some handlebars strings.

This looks good. All unit and integration tests passed.
Merging. Thanks for this awesome contribution!

I've also added a note to the wiki page: https://github.com/adobe/brackets/wiki/Language-Support/_compare/2c83f4b3be9bb6cbe86e1ebd5d357d9ca5a2915f...d8aa32d203b7f4f20b9342ac7eb06818c50bde84

Great, you edit of the Language-Support page is already a first step, but to me it still sounds greek.
Would it be possible to have a more step by step help page to add a new language from scratch?
At this point such a feature might be a great thing that bracket does, so it is probably worth explaining to the people :)
Thanks a lot
Roberto

@foice Tracked as issue #11573.
Please head over there for any further suggestions

I have answered about @foice's issue in the brackets-dev group.
@MarcelGerber We can add a couple of examples of using defineMode and defineSimpleMode to the language support wiki page.

Yes I am looking now at Amin Ullah Khan main.js. It looks promising and will give it a try tomorrow.
Thanks to Amin Ullah Khan for sharing and to all of your for the support.

The example provided was very helpful. I think I have gone already a good way in coloring my code :)
Will think about extended features and maybe come back if I do not find documentation.
Cheers


Letters overlapping in the searchbar

The the look great, but my searchbar is a little bit wonky

Disable font ligature on your system or change your system font. I can't really do anything about this so closing this now. Goodluck!


helm lint with values.schema.json

Output of helm version:
version.BuildInfo{Version:"v3.11.0", GitCommit:"472c5736ab01133de504a826bd9ee12cbe4e7904", GitTreeState:"clean", GoVersion:"go1.19.5"}

Output of kubectl version:
Client Version: version.Info{Major:"1", Minor:"26", GitVersion:"v1.26.1", GitCommit:"8f94681cd294aa8cfd3407b8191f6c70214973a4", GitTreeState:"archive", BuildDate:"2023-01-18T22:38:55Z", GoVersion:"go1.19.5", Compiler:"gc", Platform:"linux/amd64"}
Kustomize Version: v4.5.7
Server Version: version.Info{Major:"1", Minor:"24", GitVersion:"v1.24.9", GitCommit:"9710807c82740b9799453677c977758becf0acbb", GitTreeState:"clean", BuildDate:"2022-12-08T10:08:06Z", GoVersion:"go1.18.9", Compiler:"gc", Platform:"linux/amd64"}

Cloud Provider/Platform (AKS, GKE, Minikube etc.): DIY

I found #10552, but that got closed?
I found https://github.com/helm/helm/issues/2347, but that's about the require function during gotpl
How can we set a required field in the schema without breaking linting?
We can't set a working default, as that would defeat the purpose, see #2347

It isn't very clear what is being asked here. But I think the answer is to pass the required values to helm lint
e.g. helm list --set domain-name=dev.mydom.com

It isn't very clear what is being asked here. But I think the answer is to pass the required values to helm lint
e.g. helm list --set domain-name=dev.mydom.com

I understand that's a possibility, but that's not very flexible, especially when using tools like https://github.com/helm/chart-testing
required errors should be ignored like they are for the required function in my opinion

I understand that's a possibility, but that's not very flexible, especially when using tools like https://github.com/helm/chart-testing

Unsure what you mean by "not very flexible"? And unless I'm mistaken, ct supports passing values for linting (in fact if I understand, it supports linting against multiple *-values.yaml files)

required errors should be ignored like they are for the required function in my opinion

For a narrow set of charts, I think this could work. But if a chart actually requires a given value to correctly render/template, it would confusingly fail linting by producing invalid yaml (by ignoring that a required value wasn't given). It seems reasonable that "required" values are actually required IMHO.

Unsure what you mean by "not very flexible"? And unless I'm mistaken, ct supports passing values for linting (in fact if I understand, it supports linting against multiple *-values.yaml files)

As far as I can see, at least in ct lint --help, there is no way to specify an additional values yaml. It does support linting multiple values files, but these are linted separately, whereas these required fields need to be specified for all values yaml files, especially the main values.yaml.

For a narrow set of charts, I think this could work. But if a chart actually requires a given value to correctly render/template, it would confusingly fail linting by producing invalid yaml (by ignoring that a required value wasn't given).

I see what you are getting at, but this is the way it's handled with the required function, no? So the same problem applies there.

It seems reasonable that "required" values are actually required IMHO.

Yes, of course! But this breaks linting.
As far as I can see, we currently have to choose between linting and having required fields.

It's usually good practice to include the required fields in your values.yaml. If you want to ensure those fields are changed from the default, you usually add some sort of validation in a named template.

Not necessarily. There are plenty of reasons to require keys, sometimes conditionally: if auth.enabled is true, then require userSecretRef, etc.

Not necessarily.

It will definitely, if I provide a default value for a required field the schema will always validate successfully (except the user explicitly sets the field to null or something like that)

There are plenty of reasons to require keys, sometimes conditionally: if auth.enabled is true, then require userSecretRef, etc.

Of course, but even here, if I require something conditionally, this will fail linting, just conditionally, or will not force the user to set the value
If you can come up with an example where you make this work, only using the schema, which

fails if the user doesn't set a value
doesn't fail the linting

I'll be most glad and take everything back. But I've tried to get this working for a couple of hours now and I can't find a way 🤷♂

If you want to ensure those fields are changed from the default, you usually add some sort of validation in a named template.

And I'd you meant all this in the context of "just use templating ifs", then we're talking about different things.

This is still relevant

As far as I can see, at least in ct lint --help, there is no way to specify an additional values yaml. It does support linting multiple values files, but these are linted separately, whereas these required fields need to be specified for all values yaml files, especially the main values.yaml.

From ct help lint
Charts may have multiple custom values files matching the glob pattern
'*-values.yaml' in a directory named 'ci' in the root of the chart's
directory. The chart is linted for each of these files. If no custom
values file is present, the chart is linted with defaults.

The behavior is well established and according to hip-0004 cannot be changed in helm 3.
Since there are valid ways of testing required fields and not specifying a required field should fail, I'm going to go ahead and close this. If you need help with configuring ci values for ct, please open a new issue.

Please reopen this, I don't consider this resolved in any way.

Since there are valid ways of testing required fields

I don't see a good way and the only way I can think of is having a ci script merge some values into all the values.yamls which is ugly, hard to maintain, not really user friendly and forces all developers to also use the script instead of relying on standard tooling.

not specifying a required field should fail

Most definitely, but I think it shouldn't fail hard during linting just as the required function doesn't fail the lining.

If you need help with configuring ci values for ct, please open a new issue.

Adding such a functionality into ct could work, but I'd also want helm lint to work this way


Model Not Found Error

A model not found exception is thrown when you run php artisan datatable:controller ControllerName App\Model\ModelName

Model Class should be created. If Model File is not found than it throws exception.
Please again install
composer require sagaryonjan/vue-datatable
I have fixed some issue it will work perfectly if you install it  again
or update


Create Comment Component

[ ] Create the Comment Input box to add the comment
[ ] Create comment message component to show case the comment of any user
[ ] Add comment Upvote and downvote functionalities to it

[x]  Create the Comment Input box to add the comment
[x]  Create comment message component to show case the comment of any user
[x]  Add comment Upvote and downvote functionalities to it


[0.18] Crash on Startup

I get this an error whenever, log file attached.
Disabling the mod makes it work fine, but this is one of my favorite mods so I was wondering if you could take a look at it
factorio-current.log

Which mods create and modify undarl-gas-deuterium-barrel?

Should now skip over invalid/unsupported energy strings.
Resulting fuel values WILL be wrong.

Yeah it's been fixed, wow that was fast. Thanks!


enha: save historic events to files instead of sending them to kafka

PR Type
Enhancement

Description

Replaced Kafka event streaming with file-based event storage
Implemented daily event batching and file saving
Added progress bars for better visibility of processing status
Refactored code for improved readability and maintainability
Removed Kafka-related configurations and dependencies
Made UnixTimeRocksdb field public for easier access

Changes walkthrough 📝
Relevant filesEnhancement

historic_events_processor.rsRefactor historic events processor to save events to files

src/bin/historic_events_processor.rs
Removed Kafka-related code and configurations  Added functionality to save events to files instead of sending to Kafka  Implemented progress bars for tracking block and transaction processing  Refactored main function and extracted helper functions for better organization

+60/-47

unix_time.rsMake UnixTimeRocksdb field public

src/eth/storage/rocks/types/unix_time.rs

Made the u64 field of UnixTimeRocksdb struct public

+1/-1

💡 PR-Agent usage: Comment /help "your question" on any pull request to receive relevant information

Final benchmark:
RPS Stats: Max: 980.00, Min: 694.00, Avg: 839.56, StdDev: 53.51
TPS Stats: Max: 980.00, Min: 694.00, Avg: 839.23, StdDev: 52.91
Plot: View Plot


Local Pictures not resizing when cover is selected

pretty much what it says in the title, the pictures will resize during transitions, but afterwards it seems to switch to contain

I'm seeing this as well, but with any parameter passed to size, i.e. cover, contain, or auto. It also happens whether crossfade is set to true or false.
Here's my module config, if it's useful:
{
module: "MMM-Wallpaper",`
position: "fullscreen_below",
config: { // See "Configuration options" for more information.
source: "local:/mnt/nfs/...snip.../",
size: "cover",
slideInterval: 30 * 1000 // Change slides every minute
}
},

Hi there,
i really like this module, but im experiencing a similar misbehaviour.
On the first cycle, alle images are shown perfectly sized.
After the first cycle, pictures are no longer sized on time, BUT they are sized to monitorsize while being show.
Its always missing a part on the right side. ( I can see the previous image behind it ).
a fix would be SO lovely :)

Same issue on my RPi 4...

You can see that the next image is not resized correctly.
This happens sometimes.
How can we fix this issue?

Can you try the dom-refactor branch?  It removes the elements from the normal module hierarchy, which should mean that I can control the size better.

Hi, @kolbyjack
Yeah, dom-refactor branch doesn't have that issue! :+1:
By the way, is there any tip to improve the performance on 4K display?
The image transition is very choppy and the current second of the time module stops increasing for 2~3s.
Thanks!

You could try setting crossfade: false in the config, that usually helps some.  Closing this ticket for now since the reported issue appears to be resolved


WiMSE icon added

The icon is required in media so that it can show up in the documentation.

I don't like that we are putting the icon in the core media folder when we are going to use it for all schemas.  It is odd that we're putting this icon in the bis schemas repo but I understand we need a place to put it.
I think the script will grab any media folder so long as it's not in the docs directory.  So maybe the right thing to do is to add a new media folder in the root.  What do you think @naveedkhan8067 and @diegoalexdiaz

I don't like that we are putting the icon in the core media folder when we are going to use it for all schemas. It is odd that we're putting this icon in the bis schemas repo but I understand we need a place to put it.
I think the script will grab any media folder so long as it's not in the docs directory. So maybe the right thing to do is to add a new media folder in the root. What do you think @naveedkhan8067 and @diegoalexdiaz

I share the odd feeling about this icon needed to go in the bis-schemas repo, even in a new media folder in the root. I don't know any implementation details behind the script but my initial expectation is for this icon to be stored in the sample place as the script.
If such script is in the bis-schemas repo, could it go in the sub-folder where it is and be deployed to the right place by the script when it runs?

I don't like that we are putting the icon in the core media folder when we are going to use it for all schemas. It is odd that we're putting this icon in the bis schemas repo but I understand we need a place to put it.
I think the script will grab any media folder so long as it's not in the docs directory. So maybe the right thing to do is to add a new media folder in the root. What do you think @naveedkhan8067 and @diegoalexdiaz

I was also first thinking to create a new media folder for that but I think at least its better than this.

I don't like that we are putting the icon in the core media folder when we are going to use it for all schemas. It is odd that we're putting this icon in the bis schemas repo but I understand we need a place to put it.
I think the script will grab any media folder so long as it's not in the docs directory. So maybe the right thing to do is to add a new media folder in the root. What do you think @naveedkhan8067 and @diegoalexdiaz

I share the odd feeling about this icon needed to go in the bis-schemas repo, even in a new media folder in the root. I don't know any implementation details behind the script but my initial expectation is for this icon to be stored in the sample place as the script.
If such script is in the bis-schemas repo, could it go in the sub-folder where it is and be deployed to the right place by the script when it runs?

That python script is actually part of our YAML file at: https://github.com/iTwin/bis-schemas/tree/master/tools/MarkdownGeneration/generate-docs.yaml but in this case the icon will become part of the tools folder and also I have to check whether this script  ignores this directory or not.

I don't like that we are putting the icon in the core media folder when we are going to use it for all schemas. It is odd that we're putting this icon in the bis schemas repo but I understand we need a place to put it.
I think the script will grab any media folder so long as it's not in the docs directory. So maybe the right thing to do is to add a new media folder in the root. What do you think @naveedkhan8067 and @diegoalexdiaz

I share the odd feeling about this icon needed to go in the bis-schemas repo, even in a new media folder in the root. I don't know any implementation details behind the script but my initial expectation is for this icon to be stored in the sample place as the script.
If such script is in the bis-schemas repo, could it go in the sub-folder where it is and be deployed to the right place by the script when it runs?

That python script is actually part of our YAML file at: https://github.com/iTwin/bis-schemas/tree/master/tools/MarkdownGeneration/generate-docs.yaml but in this case the icon will become part of the tools folder and also I have to check whether this script ignores this directory or not. What do you suggest to put it in that folder or create a media folder at root?

What if the image was included in the ecjson2md package and it copied the image to a media folder the same directory as the output md files

I don't like that we are putting the icon in the core media folder when we are going to use it for all schemas. It is odd that we're putting this icon in the bis schemas repo but I understand we need a place to put it.
I think the script will grab any media folder so long as it's not in the docs directory. So maybe the right thing to do is to add a new media folder in the root. What do you think @naveedkhan8067 and @diegoalexdiaz

I share the odd feeling about this icon needed to go in the bis-schemas repo, even in a new media folder in the root. I don't know any implementation details behind the script but my initial expectation is for this icon to be stored in the sample place as the script.
If such script is in the bis-schemas repo, could it go in the sub-folder where it is and be deployed to the right place by the script when it runs?

That python script is actually part of our YAML file at: https://github.com/iTwin/bis-schemas/tree/master/tools/MarkdownGeneration/generate-docs.yaml but in this case the icon will become part of the tools folder and also I have to check whether this script ignores this directory or not. What do you suggest to put it in that folder or create a media folder at root?

What if the image was included in the ecjson2md package and it copied the image to a media folder the same directory as the output md files

I think it should be possible. I will try this out.

I don't like that we are putting the icon in the core media folder when we are going to use it for all schemas. It is odd that we're putting this icon in the bis schemas repo but I understand we need a place to put it.
I think the script will grab any media folder so long as it's not in the docs directory. So maybe the right thing to do is to add a new media folder in the root. What do you think @naveedkhan8067 and @diegoalexdiaz

I share the odd feeling about this icon needed to go in the bis-schemas repo, even in a new media folder in the root. I don't know any implementation details behind the script but my initial expectation is for this icon to be stored in the sample place as the script.
If such script is in the bis-schemas repo, could it go in the sub-folder where it is and be deployed to the right place by the script when it runs?

That python script is actually part of our YAML file at: https://github.com/iTwin/bis-schemas/tree/master/tools/MarkdownGeneration/generate-docs.yaml but in this case the icon will become part of the tools folder and also I have to check whether this script ignores this directory or not. What do you suggest to put it in that folder or create a media folder at root?

What if the image was included in the ecjson2md package and it copied the image to a media folder the same directory as the output md files

I think it should be possible. I will try this out.

I have added that logo in the same PR which was already open for logo related task in the ecjson2md repository: https://github.com/iTwin/ecjson2md/pull/10
Also, I have updated the YAML pipeline here for copying the logo to the media directory.


Backport to older mc versions

Like 1.18.x or 1.17.x or even 1.16.x

should be doable
potentially it might also just work with other versions (if you use a dependency override / edit the fabric.mod.json in the .jar)

it works on 1.18.2
it also works on 1.16.5 if you use java 17

I'll make a release which works with these versions out of the box soon


[Question][DORA] About the logic of ‘Median Lead Time for Changes‘

Question
I had some questions about this calculation logic when using devlake for DORA metrics calculations.
https://devlake.apache.org/docs/Metrics/LeadTimeForChanges
This document describes the calculation of 'Median Lead Time for Changes' using PR cycle time. However, the example only mentions the case where one PR corresponds to one deployment.
My question is if we have multiple PRs in one deployment, should all of them be calculated in Lead Time for Changes.
For example i have multiple PRs in one deployment:  PR1 (commit1,commit2), PR2 (commit3,commit4), PR3 (commit5)
'Lead Time for Change' should calculate the time cover all commit1.... ...commit5 or Median(PR1,PR2,PR3 to deploy)
Screenshots
If applicable, add screenshots to help explain.
Additional context
Add any other context here.

But PR1,PR2 are not really deployed until PR3 is completed, does that make sense to calculate?

From what I can tell, the Median Lead Time for Changes is calculated by:

Select deployments within the time range
Select all PRs belonging to those deployments
Calculate the Median from all Cycle Times of those PRs

So, if the deployment gets selected in the first step, then yes, all 3 PRs would be included.

But PR1,PR2 are not really deployed until PR3 is completed, does that make sense to calculate?

Why is that? You said the following in the issue description:

For example i have multiple PRs in one deployment: PR1 (commit1,commit2), PR2 (commit3,commit4), PR3 (commit5)"

If  I understand the statement correctly, it means: They were deployed together in one go.

But PR1,PR2 are not really deployed until PR3 is completed, does that make sense to calculate?

Why is that? You said the following in the issue description:

For example i have multiple PRs in one deployment: PR1 (commit1,commit2), PR2 (commit3,commit4), PR3 (commit5)"

If I understand the statement correctly, it means: They were deployed together in one go.

Yes, the 3 PRS are included in a single deployment.

From what I can tell, the Median Lead Time for Changes is calculated by:

Select deployments within the time range
Select all PRs belonging to those deployments
Calculate the Median from all Cycle Times of those PRs

So, if the deployment gets selected in the first step, then yes, all 3 PRs would be included.

So in my example, the lead time for change for this deployment is from P1 start time to go live time, P2, P3 time need not be double counted right?
While calculating median we need to calculate as per deployment not PR. Am i right?

@DevYoungHulk No, I don't think so.
It is called "Lead Time for Changes", Changes refer to PRs. In other words, time spent for a PR from creation to production.
So the metric is calculated per PR while deployments are merely a way to select all deployed PRs.
Hence, "Median Lead Time for Changes" is a metric to determine the overall velocity of PRs cycle time (created to deployed).
Imagine we have a couple of developers working on different features, the "Median Lead Time for Changes" metric suggests how fast the team shipping feature.

@klesh  Sorry I still have doubts.
We should calculate the delivery time for each PR. This can differentiate the delivery rate of different developers which I agree with.
I see from this code (backend/plugins/dora/tasks/change_lead_time_calculator.go) :
cycleTime = PrCodingTime + prDuring + PrDeployTime
PrDeployTime = computeTimeSpan(pr.MergedDate, deployment.FinishedDate)
But in PR1's PrDeployTime includes PR1's merging time and waiting time for PR2 and PR3. PR1 developer's CLT becomes longer, but he doesn't do anything, his time is wasted by waiting. This is not favorable for PR1's developer. Should we exclude the time of P2 P3?
Of course the example I gave is our particular business process. Due to some gaps in development and business testing directly. we tend to have a centralized batch of requirements for overall delivery, which is not generic.

@DevYoungHulk Ahh, I see. I think you take it all wrong, DORA is not for measuring developer's productivity but to help you improve the overall efficiency of the team.
Now, if what you are saying is true, you should try to change/improve the operation to avoid the developer of PR1 from waiting.
Say, deploy them separately.

@klesh
Thank you for your patience. This is very helpful to me.


Error when Create dbTechViaLayerRule in odb

Describe the bug
When using odb::dbTechViaLayerRule_create command, I found an error tagged as "signal 6". It doesn't allow me to create new dbTechViaLayerRule. Maybe this is an error.
Expected Behavior
dbTechViaLayerRule got created successfully
Environment
[WARNING] Your current OpenROAD version is outdated.
It is recommened to pull the latest changes.
If problem persists, file a github issue with the re-producible test case.
kernel: Linux 3.10.0-1160.88.1.el7.x86_64
os: CentOS Linux 7 (Core)
cmake version 3.24.2
-- The CXX compiler identification is GNU 12.1.0
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/local/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- OpenROAD version: v2.0-7480-g8a4065b09
-- System name: Linux
-- Compiler: GNU 12.1.0
-- Build type: RELEASE
-- Install prefix: /usr/local
-- C++ Standard: 17
-- C++ Standard Required: ON
-- C++ Extensions: OFF
-- Could NOT find GTest (missing: GTEST_LIBRARY GTEST_INCLUDE_DIR GTEST_MAIN_LIBRARY)
-- The C compiler identification is GNU 12.1.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/local/bin/gcc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Found Python: /usr/local/bin/python3.10 (found version "3.10.2") found components: Interpreter
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Failed
-- Looking for pthread_create in pthreads
-- Looking for pthread_create in pthreads - not found
-- Looking for pthread_create in pthread
-- Looking for pthread_create in pthread - found
-- Found Threads: TRUE
-- Performing Test C_COMPILER_SUPPORTS__-Wall
-- Performing Test C_COMPILER_SUPPORTS__-Wall - Success
-- Performing Test CXX_COMPILER_SUPPORTS__-Wall
-- Performing Test CXX_COMPILER_SUPPORTS__-Wall - Success
-- Performing Test C_COMPILER_SUPPORTS__-Wno-array-bounds
-- Performing Test C_COMPILER_SUPPORTS__-Wno-array-bounds - Success
-- Performing Test CXX_COMPILER_SUPPORTS__-Wno-array-bounds
-- Performing Test CXX_COMPILER_SUPPORTS__-Wno-array-bounds - Success
-- Performing Test C_COMPILER_SUPPORTS__-Wno-nonnull
-- Performing Test C_COMPILER_SUPPORTS__-Wno-nonnull - Success
-- Performing Test CXX_COMPILER_SUPPORTS__-Wno-nonnull
-- Performing Test CXX_COMPILER_SUPPORTS__-Wno-nonnull - Success
-- Performing Test C_COMPILER_SUPPORTS__-Wno-maybe-uninitialized
-- Performing Test C_COMPILER_SUPPORTS__-Wno-maybe-uninitialized - Success
-- Performing Test CXX_COMPILER_SUPPORTS__-Wno-maybe-uninitialized
-- Performing Test CXX_COMPILER_SUPPORTS__-Wno-maybe-uninitialized - Success
-- Performing Test C_COMPILER_SUPPORTS__-Wno-format-overflow
-- Performing Test C_COMPILER_SUPPORTS__-Wno-format-overflow - Success
-- Performing Test CXX_COMPILER_SUPPORTS__-Wno-format-overflow
-- Performing Test CXX_COMPILER_SUPPORTS__-Wno-format-overflow - Success
-- Performing Test C_COMPILER_SUPPORTS__-Wno-unused-variable
-- Performing Test C_COMPILER_SUPPORTS__-Wno-unused-variable - Success
-- Performing Test CXX_COMPILER_SUPPORTS__-Wno-unused-variable
-- Performing Test CXX_COMPILER_SUPPORTS__-Wno-unused-variable - Success
-- Performing Test C_COMPILER_SUPPORTS__-Wno-unused-function
-- Performing Test C_COMPILER_SUPPORTS__-Wno-unused-function - Success
-- Performing Test CXX_COMPILER_SUPPORTS__-Wno-unused-function
-- Performing Test CXX_COMPILER_SUPPORTS__-Wno-unused-function - Success
-- Performing Test C_COMPILER_SUPPORTS__-Wno-write-strings
-- Performing Test C_COMPILER_SUPPORTS__-Wno-write-strings - Success
-- Performing Test CXX_COMPILER_SUPPORTS__-Wno-write-strings
-- Performing Test CXX_COMPILER_SUPPORTS__-Wno-write-strings - Success
-- Performing Test C_COMPILER_SUPPORTS__-Wno-sign-compare
-- Performing Test C_COMPILER_SUPPORTS__-Wno-sign-compare - Success
-- Performing Test CXX_COMPILER_SUPPORTS__-Wno-sign-compare
-- Performing Test CXX_COMPILER_SUPPORTS__-Wno-sign-compare - Success
-- Performing Test C_COMPILER_SUPPORTS__-Wno-deprecated
-- Performing Test C_COMPILER_SUPPORTS__-Wno-deprecated - Success
-- Performing Test CXX_COMPILER_SUPPORTS__-Wno-deprecated
-- Performing Test CXX_COMPILER_SUPPORTS__-Wno-deprecated - Success
-- Performing Test C_COMPILER_SUPPORTS__-Wno-c++11-narrowing
-- Performing Test C_COMPILER_SUPPORTS__-Wno-c++11-narrowing - Failed
-- Performing Test CXX_COMPILER_SUPPORTS__-Wno-c++11-narrowing
-- Performing Test CXX_COMPILER_SUPPORTS__-Wno-c++11-narrowing - Failed
-- Performing Test C_COMPILER_SUPPORTS__-Wno-register
-- Performing Test C_COMPILER_SUPPORTS__-Wno-register - Failed
-- Performing Test CXX_COMPILER_SUPPORTS__-Wno-register
-- Performing Test CXX_COMPILER_SUPPORTS__-Wno-register - Success
-- Performing Test C_COMPILER_SUPPORTS__-Wno-format
-- Performing Test C_COMPILER_SUPPORTS__-Wno-format - Success
-- Performing Test CXX_COMPILER_SUPPORTS__-Wno-format
-- Performing Test CXX_COMPILER_SUPPORTS__-Wno-format - Success
-- Performing Test C_COMPILER_SUPPORTS__-Wno-reserved-user-defined-literal
-- Performing Test C_COMPILER_SUPPORTS__-Wno-reserved-user-defined-literal - Failed
-- Performing Test CXX_COMPILER_SUPPORTS__-Wno-reserved-user-defined-literal
-- Performing Test CXX_COMPILER_SUPPORTS__-Wno-reserved-user-defined-literal - Failed
-- Performing Test C_COMPILER_SUPPORTS__-fpermissive
-- Performing Test C_COMPILER_SUPPORTS__-fpermissive - Failed
-- Performing Test CXX_COMPILER_SUPPORTS__-fpermissive
-- Performing Test CXX_COMPILER_SUPPORTS__-fpermissive - Success
-- Performing Test C_COMPILER_SUPPORTS__-x
-- Performing Test C_COMPILER_SUPPORTS__-x - Failed
-- Performing Test CXX_COMPILER_SUPPORTS__-x
-- Performing Test CXX_COMPILER_SUPPORTS__-x - Failed
-- Performing Test C_COMPILER_SUPPORTS__c++
-- Performing Test C_COMPILER_SUPPORTS__c++ - Failed
-- Performing Test CXX_COMPILER_SUPPORTS__c++
-- Performing Test CXX_COMPILER_SUPPORTS__c++ - Failed
-- Performing Test C_COMPILER_SUPPORTS__-Wno-unused-but-set-variable
-- Performing Test C_COMPILER_SUPPORTS__-Wno-unused-but-set-variable - Success
-- Performing Test CXX_COMPILER_SUPPORTS__-Wno-unused-but-set-variable
-- Performing Test CXX_COMPILER_SUPPORTS__-Wno-unused-but-set-variable - Success
-- TCL library: /usr/lib64/libtcl.so
-- TCL header: /usr/include/tcl.h
-- TCL readline library: /usr/lib64/libtclreadline.so
-- TCL readline header: /usr/include
-- Found SWIG: /usr/bin/swig (found suitable version "4.1.0", minimum required is "3.0")
-- Using SWIG >= 4.1.0 -flatstaticmethod flag for python
-- Found Boost: /usr/local/lib/cmake/Boost-1.72.0/BoostConfig.cmake (found version "1.72.0")
-- boost: 1.72.0
-- Found Python3: /usr/local/include/python3.10 (found version "3.10.2") found components: Development Development.Module Development.Embed
-- Found ZLIB: /usr/lib64/libz.so (found version "1.2.7")
-- spdlog: 1.8.1
-- Found BISON: /usr/bin/bison (found version "3.0.4")
-- Found Doxygen: /usr/bin/doxygen (found version "1.8.5") found components: doxygen dot
-- STA version: 2.4.0
-- STA git sha: 882681a674e7089e5f02de4ba2050c6be32b6cd1
-- System name: Linux
-- Compiler: GNU 12.1.0
-- Build type: RELEASE
-- Build CXX_FLAGS: -O3 -DNDEBUG
-- Install prefix: /usr/local
-- Found FLEX: /usr/bin/flex (found version "2.5.37")
-- TCL library: /usr/lib64/libtcl.so
-- TCL header: /usr/include/tcl.h
-- Check if compiler accepts -pthread
-- Check if compiler accepts -pthread - yes
-- SSTA: 0
-- STA executable: /home/wentian/Desktop/OpenROAD1/OpenROAD-flow-scripts/tools/OpenROAD/src/sta/app/sta
-- GPU is not enabled
-- Found re2: /opt/or-tools/lib64/cmake/re2/re2Config.cmake (found version "9.0.0")
-- Found Clp: /opt/or-tools/lib64/cmake/Clp/ClpConfig.cmake (found version "1.17.7")
-- Found Cbc: /opt/or-tools/lib64/cmake/Cbc/CbcConfig.cmake (found version "2.10.7")
-- Found Eigen3: /usr/local/share/eigen3/cmake/Eigen3Config.cmake (found version "3.3.9")
-- Found SCIP: /opt/or-tools/lib/cmake/scip/scip-config.cmake (found version "8.0.1")
-- GUI is enabled
-- Found Boost: /usr/local/lib/cmake/Boost-1.72.0/BoostConfig.cmake (found version "1.72.0") found components: serialization
-- Found OpenMP_CXX: -fopenmp (found version "4.5")
-- Found OpenMP: TRUE (found version "4.5")
-- Could NOT find VTune (missing: VTune_LIBRARIES VTune_INCLUDE_DIRS)
-- Found Boost: /usr/local/lib/cmake/Boost-1.80.0/BoostConfig.cmake (found suitable version "1.80.0", minimum required is "1.78")
-- Found Boost: /usr/local/lib/cmake/Boost-1.80.0/BoostConfig.cmake (found version "1.80.0") found components: serialization system thread
-- TCL readline enabled
-- Tcl Extended disabled
-- Python3 enabled
-- Configuring done
-- Generating done
-- Build files have been written to: /tmp/tmp.JxZ6h8l13a

To Reproduce
set db [ord::get_db]
set tech [$db getTech]
set block [ord::get_db_block]
odb::dbTechViaLayerRule_create [odb::dbTechNonDefaultRule_create $block aa] [$tech findLayer mcon]
Relevant log output
/opt/rh/devtoolset-8/root/usr/include/c++/8/bits/stl_vector.h:932: std::vector<_Tp, _Alloc>::reference std::vector<_Tp, _Alloc>::operator[](std::vector<_Tp, _Alloc>::size_type) [with _Tp = odb::dbId<odb::_dbTechViaLayerRule>; _Alloc = std::allocator<odb::dbId<odb::_dbTechViaLayerRule> >; std::vector<_Tp, _Alloc>::reference = odb::dbId<odb::_dbTechViaLayerRule>&; std::vector<_Tp, _Alloc>::size_type = long unsigned int]: Assertion '__builtin_expect(__n < this->size(), true)' failed.
Signal 6 received
Stack trace:
 0# 0x0000000000CBB787 in openroad
 1# 0x00007FEB0DA7E400 in /lib64/libc.so.6
 2# gsignal in /lib64/libc.so.6
 3# abort in /lib64/libc.so.6
 4# odb::dbTechViaLayerRule::create(odb::dbTechNonDefaultRule*, odb::dbTechLayer*) in openroad
 5# 0x000000000118A0F1 in openroad
 6# 0x00007FEB12867EB2 in /lib64/libtcl8.5.so
 7# 0x00007FEB128AC36C in /lib64/libtcl8.5.so
 8# 0x00007FEB128B4647 in /lib64/libtcl8.5.so
 9# TclEvalObjEx in /lib64/libtcl8.5.so
10# 0x00007FEB128EF27F in /lib64/libtcl8.5.so
11# 0x00007FEB12867EB2 in /lib64/libtcl8.5.so
12# 0x00007FEB128AC36C in /lib64/libtcl8.5.so
13# 0x00007FEB128B4647 in /lib64/libtcl8.5.so
14# TclEvalObjEx in /lib64/libtcl8.5.so
15# 0x00007FEB1286F1D0 in /lib64/libtcl8.5.so
16# 0x00007FEB12867EB2 in /lib64/libtcl8.5.so
17# 0x00007FEB128AC36C in /lib64/libtcl8.5.so
18# 0x00007FEB128B4647 in /lib64/libtcl8.5.so
19# TclEvalObjEx in /lib64/libtcl8.5.so
20# 0x00007FEB12872F00 in /lib64/libtcl8.5.so
21# 0x00007FEB12867EB2 in /lib64/libtcl8.5.so
22# 0x00007FEB128AC36C in /lib64/libtcl8.5.so
23# TclObjInterpProcCore in /lib64/libtcl8.5.so
24# 0x00007FEB12867EB2 in /lib64/libtcl8.5.so
25# 0x00007FEB128AC36C in /lib64/libtcl8.5.so
26# TclObjInterpProcCore in /lib64/libtcl8.5.so
27# 0x00007FEB12867EB2 in /lib64/libtcl8.5.so
28# 0x00007FEB128AC36C in /lib64/libtcl8.5.so
29# 0x00007FEB128B4647 in /lib64/libtcl8.5.so
30# TclEvalObjEx in /lib64/libtcl8.5.so
31# 0x00007FEB128EF27F in /lib64/libtcl8.5.so
32# 0x00007FEB12867EB2 in /lib64/libtcl8.5.so
33# 0x00007FEB128AC36C in /lib64/libtcl8.5.so
34# 0x00007FEB128B4647 in /lib64/libtcl8.5.so
35# TclEvalObjEx in /lib64/libtcl8.5.so
36# 0x00007FEB1286F1D0 in /lib64/libtcl8.5.so
37# 0x00007FEB12867EB2 in /lib64/libtcl8.5.so
38# 0x00007FEB128AC36C in /lib64/libtcl8.5.so
39# 0x00007FEB128B4647 in /lib64/libtcl8.5.so
40# TclEvalObjEx in /lib64/libtcl8.5.so
41# 0x00007FEB12872F00 in /lib64/libtcl8.5.so
42# 0x00007FEB12867EB2 in /lib64/libtcl8.5.so
43# 0x00007FEB128AC36C in /lib64/libtcl8.5.so
44# TclObjInterpProcCore in /lib64/libtcl8.5.so
45# 0x00007FEB12867EB2 in /lib64/libtcl8.5.so
46# 0x00007FEB128AC36C in /lib64/libtcl8.5.so
47# TclObjInterpProcCore in /lib64/libtcl8.5.so
48# 0x00007FEB12867EB2 in /lib64/libtcl8.5.so
49# 0x00007FEB12868F1E in /lib64/libtcl8.5.so
50# Tcl_EvalEx in /lib64/libtcl8.5.so
51# Tcl_Eval in /lib64/libtcl8.5.so
52# sta::sourceTclFile(char const*, bool, bool, Tcl_Interp*) in openroad
53# ord::tclAppInit(Tcl_Interp*) in openroad
54# Tcl_Main in /lib64/libtcl8.5.so
55# main in openroad
56# __libc_start_main in /lib64/libc.so.6
57# 0x0000000000CB5F14 in openroad
Elapsed time: 0:00.49[h:]min:sec. CPU time: user 0.33 sys 0.08 (83%). Peak memory: 83408KB.

Screenshots
No response
Additional Context
No response

Can you provide a way to reproduce this crash?

That doesn't work as dbTechViaLayerRule_create  doesn't take a dbTechNonDefaultRule as an argument
Error: foo.tcl, 10 Wrong number or type of arguments for overloaded function 'dbTechViaLayerRule_create'.
  Possible C/C++ prototypes are:
    odb::dbTechViaLayerRule::create(odb::dbTech *,odb::dbTechViaRule *,odb::dbTechLayer *)
    odb::dbTechViaLayerRule::create(odb::dbTech *,odb::dbTechViaGenerateRule *,odb::dbTechLayer *)

That doesn't work as dbTechViaLayerRule_create doesn't take a dbTechNonDefaultRule as an argument
Error: foo.tcl, 10 Wrong number or type of arguments for overloaded function 'dbTechViaLayerRule_create'.
  Possible C/C++ prototypes are:
    odb::dbTechViaLayerRule::create(odb::dbTech *,odb::dbTechViaRule *,odb::dbTechLayer *)
    odb::dbTechViaLayerRule::create(odb::dbTech *,odb::dbTechViaGenerateRule *,odb::dbTechLayer *)

I see. It works now, I will close the issue


[SR-11540] Fix ambiguos overload apply to argument for contextual closure

This fixes SR-11540 by just disfavoring overloads to closures with anonymous var that are function types with more than one argument that matches arguments of no-arg function types.
The first approach was to not accept cases like func foo(<T, R>(action: (T) -> R) -> Void {}) match foo(action: { return }, in a way that:
func foo<T, R>(action: (T) -> R) -> Void {}
foo(action: { return }) // expected-error {{contextual type for closure argument list expects 1 argument, which cannot be implicitly ignored}}
// expected-error@-1 {{generic parameter 'T' could not be inferred}} expected-error@-1{{generic parameter 'R' could not be inferred}}

// Is expected to be foo(action: { _ in return })

But since it broke few tests(that was actually accepting this syntax) and I was not sure if this would be a source-compatible change... so opting to just disfavor the overload disambiguate seemed like a better option :)
cc @xedin @hborla

Resolves SR-11540.

@LucianoPAlmeida Do you know where T := () binding comes from for <T, R>(action: (T) -> R) overload?

Hey @xedin :)

@LucianoPAlmeida Do you know where T := () binding comes from for <T, R>(action: (T) -> R) overload?

Not really, I thought that for closures with implicit parameters, it automatically always tried to bind an empty tuple '()' by default ...
For the
func SR11540_1<T, R>(action: (T) -> R) -> Void {}
SR11540_1(action: { return }) // OK

The source locator binding points to the call expr ...
Resolved overloads:
  selected overload set choice SR11540_1: $T0 == (($T1) -> $T2) -> Void

Opened types:
  locator@0x11b8dae00 [DeclRef@/Users/lucianoalmeida/Documents/Programming/swift-lang/swift/test/expr/closure/sr9839.swift:12:1] opens τ_0_1 -> $T2, τ_0_0 -> $T1
  ($T3 involves_type_vars bindings={(subtypes of) ($T1) -> $T2})
  Initial bindings: $T3 := ($T1) -> $T2
  (attempting type variable $T3 := ($T1) -> $T2
    (increasing score due to disfavored overload)
    ($T1 potentially_incomplete bindings={(subtypes of) ()})
    ($T4 involves_type_vars bindings={(supertypes of) ()})
    Initial bindings: $T1 := ()
    (attempting type variable $T1 := ()
(lldb) p srcLocator->getAnchor()
(swift::Expr *) $2 = 0x000000011b8d4cb0
(lldb) p srcLocator->getAnchor()->dump()
(call_expr type='<null>' arg_labels=action:
  (declref_expr type='<null>' decl=sr9839.(file).SR11540_1(action:)@/Users/lucianoalmeida/Documents/Programming/swift-lang/swift/test/expr/closure/sr9839.swift:7:6 function_ref=single)
  (tuple_expr type='<null>' names=action
    (closure_expr type='<null>' discriminator=0 single-expression
      (parameter_list range=[/Users/lucianoalmeida/Documents/Programming/swift-lang/swift/test/expr/closure/sr9839.swift:12:19 - line:12:19])
      (tuple_expr implicit type='()'))))
(lldb) p Binding.isDefaultableBinding()
(bool) $3 = false
(lldb) p dstLocator->getAnchor()->dump()
(declref_expr type='<null>' decl=sr9839.(file).SR11540_1(action:)@/Users/lucianoalmeida/Documents/Programming/swift-lang/swift/test/expr/closure/sr9839.swift:7:6 function_ref=single)
(lldb) p Binding.BindingType->dump()
(tuple_type num_elements=0)

I think this is a side-effect of one of the hacks for SE-0110. Solver shouldn't be inferring bindings for parameters unless they are either used in the body, come from context or explicitly specified in closure declaration. Overload of (T) -> R matches neither situation so we really need to figure out how parameter gets to be inferred as ().

I think this is a side-effect of one of the hacks for SE-0110. Solver shouldn't be inferring bindings for parameters unless they are either used in the body, come from context or explicitly specified in closure declaration.

This situation should be caught at matchFunctionTypes I think ... but currently, because of some of that logic of imploding parameters (maybe SE-0110), a function type ()-> $T0 is matching correctly with a ($T1) -> $T2 for an ArgumentConversion, that's why I implemented such logic, because I thought that a closure function type with a least one param and with anonymous variables shouldn't be able to convert to an empty param function type. Really not sure about it ... I'm just going back to this right now ... let me see If I can find something else :)

Hummm maybe the binding is coming from context of the closure ...
So ... if we take that
let c = { return }
// c is infered as () -> ()

// so the generic types T and R on  SR11540_1(action: { return })
func SR11540_1<T, R>(action: (T) -> R) -> Void {}

Are infered by the type of closure of the param, that's where the T := () bind maybe comming from :))

This situation should be caught at matchFunctionTypes I think...

That's exactly what needs to happen and it's not happening because canImplodeParams doesn't check the case of empty parameter list. Which, I think, is unfortunately intentional, we can increase a score upon trying to implode something into an empty list, that's going to be a much more narrow fix for this situation.

Or maybe go all in and actually increase SK_FunctionConversion score on any implode we have to do to support SE-0110 edge cases.

Or maybe go all in and actually increase SK_FunctionConversion score on any implode we have to do to support SE-0110 edge cases.

Awesome! Let's try this ... I'll ping you in a moment with the changes :))

Right, just increase the score whenever we have to implode the parameters 👍 @xedin

@swift-ci please test

@swift-ci please test source compatibility

Seems like a test broke ... let me check that

Build failed
Swift Test Linux Platform
Git Sha - a65366ebe6ed024d3fea73a7199a1efa8b59a0c4

Build failed
Swift Test OS X Platform
Git Sha - a65366ebe6ed024d3fea73a7199a1efa8b59a0c4

Just adjusted the test case that was failing. Now local tests are OK :)

Sounds good! Make sense to me that it would type-check.

@swift-ci please smoke test

@swift-ci please test source compatibility

Thank you @xedin :)

No problem! :)


API testing - update webv readme

Add a link / short writeup to webv readme based on the story Eddie shared in chat. Good chance to document how we run 7x24 with observability so that we know when something changes
Another example of why we were so detailed on our api test and the exact reason why web validate exists!!
https://devops.com/how-api-testing-can-save-you-thousands/

@alfredoihernandez - can you PR this into /microsoft/webvalidate early this week so that we can complete the 1.3.1 release?

webvalidate early this week so that we can complete the 1.3.1 release?

Sure, I don't see microsoft/webvalidate repo so I've placed draft changes in retaildevcrews/webvalidate


[IDE] Ensure every walkToPre call is matched with a walkToPost call in SemaAnnotator

We had some unbalanced calls of walkTo*Pre and walkTo*Post in SemaAnnotator, causing the new test case to crash in assert builds.
The main fix was to set Cancelled to true if traversal is being stopped in walkToExprPre.
While I was at it, I also

Added some more checks, ensuring that no more walkTo* calls are issued after Cancelled has been set to true.
Added some comments, describing the intended traversal behaviour.
Fixed a case where we were returning true (i.e. visit children) although we were setting Cancelled to false
Moved walkToExprPost to be place right after walkToExprPre

Resolves rdar://64139829 [SR-12957]

@swift-ci Please smoke test

@swift-ci Please smoke test

@swift-ci Please smoke test Windows

@swift-ci Please smoke test Linux


Update to egui 0.25

Just bumping the egui version and also the egui-gizmo version.
If this can be published to crates.io, that would be great.

Thanks!


[4.3 Dev 3] Undo in Script Editor is dangerously dysfunctional (OK in 4.2)

Tested versions

Reproducible in 4.3 Dev 3, not in 4.3

System information
Mac OS Sonoma 14.2.1, Intel processor
Issue description
Undo at least sometimes undoes something back in history other than the most recent change.  It seems to ignore text changes and go back to a recent structural change.
Steps to reproduce
In the editor, create a Node2D.  Add a script to the Node2D and, in the script editor, type in a second "pass" operation on the _ready method.  Hit Cmd-Z.
In earlier versions, the second "pass" is deleted.  In 4.3 Dev 3, the whole script is deleted from the Node2D
Minimal reproduction project (MRP)
N/A

Please test 4.3-dev4, I've seen report of such an issue fixed in that snapshot.

Yes.
On Sat, Mar 2, 2024 at 6:27 AM Riteo @.***> wrote:

not in 4.3
Did you mean 4.2? :P
—
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/89060#issuecomment-1974797045,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AANACTLOD5ZRKGO3C7BKZXLYWHHS5AVCNFSM6AAAAABECIJ6C2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNZUG44TOMBUGU
.
You are receiving this because you authored the thread.Message ID:
@.***>

@akien-mga just tested in 4.3-dev4, can't reproduce.

Closed as fixed in 4.3-dev4. @daviesaz Please let us know if you still reproduce the issue in that version or later ones.

I've got no clue what was going on here, but both dev5 and master have been very problematic for me. I can't get the script editor to undo, nor can I even close the current script. Even if I remap the Close Scene shortcut (why was it changed??) all that CMD+W does is stop inspecting the current resource. Very unfortunate, I'm liking the other GUI changes that I've noticed in 4.3, but there's something seriously wrong with the script editor.

Closed as fixed in 4.3-dev4. @daviesaz Please let us know if you still reproduce the issue in that version or later ones.

I just tried 4.3-dev4, and everything works as expected with it. Even 4.3-dev3 has better behavior than 4.3-dev5, as at least I can close the script in that version, but it's otherwise the same deal as 4.3-dev3. There must have been some regression between 4.3-dev4 and 4.3-dev5.

@caimantilla It looks like the Close Scene shortcut was changed in https://github.com/godotengine/godot/pull/88913
The undo problem sounds like it is different and a new issue can be opened for it. It seems to work fine for me on windows, and it may be related to https://github.com/godotengine/godot/pull/85325.

@caimantilla It looks like the Close Scene shortcut was changed in #88913 The undo problem sounds like it is different and a new issue can be opened for it. It seems to work fine for me on windows, and it may be related to #85325.

From what I remember, close script didn't even work after I changed the close scene keybind back to the old one. Just think the script editor isn't receiving shortcuts at all

Also seeing this, the bug from 4.3dev3 where undo in the script editor instead undid changes in open scenes was fixed in 4.3dev4, but is now back again in 4.3dev5. Interestingly it seems specific to undo/redo. Other keyboard shortcuts like copy/paste correctly target the active script editor.

Confirmed. In a fresh project, create a Node2D and then a child Node2D.  Add an internal script to the child.  Duplicate the pass command in the _ready method.  Hit Cmd-Z (on a Mac) to undo. The effect is to remove the child rather than the text just typed.

On Mar 18, 2024, at 1:23 AM, Lars @.***> wrote:
Also seeing this, the bug from 4.3dev3 where undo in the script editor instead undid changes in open scenes was fixed in 4.3dev4, but is now back again in 4.3dev5. Interestingly it seems specific to undo/redo. Other keyboard shortcuts like copy/paste correctly target the active script editor.
—
Reply to this email directly, view it on GitHub https://github.com/godotengine/godot/issues/89060#issuecomment-2003178969, or unsubscribe https://github.com/notifications/unsubscribe-auth/AANACTMGM4X52XYXHTE6JWLYY2QA3AVCNFSM6AAAAABECIJ6C2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMBTGE3TQOJWHE.
You are receiving this because you were mentioned.

...And now it seems to be fixed.

...And now it seems to be fixed.

It looks like it was mentioned on another issue and then fixed.

fixed in https://github.com/godotengine/godot/pull/89953


#15809: Add SW Support for Coordinate Virtualization on WH

Ticket
Link to Github Issue
Problem description
Wormhole and Blackhole NOC Hardware supports coordinate virtualization, which allows us to abstract away the effects of harvesting.
On WH this feature works out of the box. On BH, we are waiting for Syseng support. This PR adds SW support for Coordinate Virtualization on WH.
From a Runtime perspective, this feature unlocks:

Offline Compilation: Kernel Binaries, Runtime Args and Fast Dispatch Commands for Program Dispatch can be generated offline, given a system descriptor (ex: N150 vs N300)
The ability to reuse programs across different chips with the same number of rows harvested. This is required for broadcasting Programs (a key feature in TT-Mesh).

NOC Hardware supports Virtual Coordinates only for Tensix and Ethernet cores. The table below displays the current status of Virtual Coordinate Hardware support across architectures and endpoints.

Grayskull
Wormhole
Blackhole

Tensix
Unsupported
Supported
Unsupported

Ethernet
NA
Supported
Unsupported

DRAM
Unsupported
Unsupported
Unsupported

PCIe
Unsupported
Unsupported
Unsupported

On architectures where coordinate virtualization is entirely unsupported (GS and temporarily BH), Virtual Coordinates are equivalent to Physical Coordinates. The main side effect here is that the features unlocked by this PR are disabled on BH until Syseng releases Virtualization FW.
As part of this change, users are only exposed to Virtual and Logical Coordinates. Thus, all APIs exposing Physical Coordinates have either been deprecated or modified to support Virtual Coordinates. Additionally, since Virtual Coordinates are not supported for DRAM, all APIs exposing Physical DRAM coordinates (ex: Buffer::noc_coordinates) have been removed. Users can only interact with logical DRAM coordinates (Bank IDs) and must rely on logical to physical translation APIs on device (ex: get_noc_addr_from_bank_id). Please see the attached ticket for a detailed API Migration Table.
Under the hood, Host Runtime still uses Physical Coordinates for creating address generator tables, accessing PCIe endpoints and assigning worker cores to DRAM banks.
What's changed
NOC APIs, Fast Dispatch Command Generation, TTNN Ops, Debug Tools, Slow Dispatch, TT-Metal Tests and Programming Examples were modified to support Virtual Coordinates.
The API Migration Table from the ticket was followed, and Ops were modified to use the new APIs (Virtual for Tensix and Ethernet + Logical only for DRAM).
Navigating this PR
A significant number of changes in this PR modify TT-Metal tests to use the updated APIs. These changes can effectively be ignored. The main change to this infra allows tests to transition away from the Buffer::noc_coordinates API and rely on Bank IDs instead, keeping in line with the new APIs.
Feedback on the following would be appreciated:
TT-Metal Device Side Changes

Changes to architecture specific NOC Parameters and NOC APIs, to support virtualization
The new get_noc_addr_from_bank_id DataFlow API for resolving NOC Coordinates given a Buffer Bank ID
Changes to risc_common.h modifying the values assigned to the my_x and my_y fields, depending on whether Coordinate Virtualization is supported

TT-Metal Host Side Changes

Changes to Fast Dispatch Command Generation in command_queue.cpp and program.cpp. These changes are fairly straightforward and simply swap out the Physical Coordinate APIs with their Virtual counterparts.
Virtual Coordinate APIs added to tt_cluster.cpp. These APIs allow deriving Virtual Coordinates from Logical and Physical Coordinates, deriving attributes such as the CoreType or  profiler_flat_id  from a coordinate in Virtual Space and performing reads/writes to coordinates in the Virtual Space. tt_cluster can essentially be considered a query layer that understands Virtual Coordinates.
Additional APIs added to the HAL: is_coordinate_virtualization_enabled(), get_virtual_worker_start_x() and get_virtual_worker_start_y()
Changes to device.cpp: Mostly supporting the use of Virtual Coordinate APIs and adding APIs to get unicast and multicast NOC encodings, given a Virtual Coordinate
New File added:  core_assignment.cpp. This file exposes APIs to get the optimal DRAM Bank to worker core assignment. Under the hood, these APIs rely on physical coordinates, to account for harvesting when deriving the worker core placement. This logic has been copied from matmul_op_multi_core_reuse_mcast_dram_sharded_program_factory.cpp and is exposed through the Device::get_optimal_dram_bank_to_logical_worker_assignment top level API.

Debug Tool Changes

Changes made to NOC Sanitize (host and device) to support Virtual Coordinates. Device side sanitization needs to account for both Virtual and physical coordinates, since NOC HW reprograms registers with physical coordinates after a txn is issued (this breaks stateful API sanitization, if only a single coordinate system is tracked). The core_info_msg_t struct was modified to track Virtual Non-Worker cores and harvested rows
Changes to Performance Profiler, Watcher and DPRINT to rely on Virtual Coordinates.

TTNN Op Infra Changes

CCL and Conv Ops modified to use Virtual Coordinates on host
Reshard modified to use Bank IDs + get_noc_addr_from_bank_id, since it interfaces with DRAM and was previously using physical coordinates (no longer supported)
DRAM Sharded Matmul modified to use Device::get_optimal_dram_bank_to_logical_worker_assignment instead of using Physical Coordinates to manually derive the core assignment

Checklist

[ ] Post commit CI passes
[ ] Blackhole Post commit (if applicable)
[ ] Model regression CI testing passes (if applicable)
[ ] Device performance regression CI testing passes (if applicable)
[ ] New/Existing tests provide coverage for changes

Passing Pipelines:
Post Commit: https://github.com/tenstorrent/tt-metal/actions/runs/12227609942
BH: https://github.com/tenstorrent/tt-metal/actions/runs/12216583694
Model Perf (Single Card): https://github.com/tenstorrent/tt-metal/actions/runs/12226829247
T3K Unit Tests: https://github.com/tenstorrent/tt-metal/actions/runs/12226821278
T3K Frequent Tests: https://github.com/tenstorrent/tt-metal/actions/runs/12226823077

Can we get device perf CI on this as well.
https://github.com/tenstorrent/tt-metal/actions/workflows/perf-device-models.yaml.
Thanks

Running Device Perf here: https://github.com/tenstorrent/tt-metal/actions/runs/12239903110
Running Microbenchmark Pipeline here: https://github.com/tenstorrent/tt-metal/actions/runs/12239908904

@yugaoTT Microbenchmark pipelines pass here: https://github.com/tenstorrent/tt-metal/actions/runs/12239908904
@mo-tenstorrent Single Device Perf fails but this is unrelated to my changes, seems like noise: https://github.com/tenstorrent/tt-metal/actions/runs/12239903110


Fix missing wrapper in simple type descriptor node recovery

Purpose
$subject.
Approach
N/A
Samples
N/A
Remarks
N/A
Check List

[x] Read the Contributing Guide
[ ] Updated Change Log
[ ] Checked Tooling Support (#)
[ ] Added necessary tests

[ ] Unit Tests
[ ] Spec Conformance Tests
[ ] Integration Tests
[ ] Ballerina By Example Tests

[ ] Increased Test Coverage
[ ] Added necessary documentation

[ ] API documentation
[ ] Module documentation in Module.md files
[ ] Ballerina By Examples

Codecov Report

Merging #24045 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master   #24045   +/-   ##
=======================================
  Coverage   14.59%   14.59%
=======================================
  Files          51       51
  Lines        1411     1411
  Branches      219      219
=======================================
  Hits          206      206
  Misses       1189     1189
  Partials       16       16

Continue to review full report at Codecov.

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


Sink connector is stucked without any log messages if Zeebe is unavailable

Hi team!
While testing locally, it seems that the connector gets stuck if we provide invalid value to connect to Zeebe. If I deploy a connector locally, without having Zeebe running, I can observe that the thread is blocked indefinitely on https://github.com/zeebe-io/kafka-connect-zeebe/blob/master/src/main/java/io/zeebe/kafka/connect/sink/ZeebeSinkTask.java#L58.
My connector configuration is:
{
  "name": "zeebe",
  "config": {
    "connector.class": "io.zeebe.kafka.connect.ZeebeSinkConnector",
    "tasks.max": "1",
    "key.converter": "org.apache.kafka.connect.storage.StringConverter",
    "value.converter": "org.apache.kafka.connect.storage.StringConverter",
    "topics": "kafka-to-zeebe",
    "zeebe.client.broker.contactPoint": "<IP_ADDRESS>:26500",
    "zeebe.client.security.plaintext": true,
    "message.path.messageName": "$.eventType",
    "message.path.correlationKey": "$.orderId",
    "message.path.variables": "$.['amount', 'orderId']"
  }
}

If I enable DEBUG log, I can only see:
ESC[36mconnect            |ESC[0m [2020-05-05 15:29:36,527] DEBUG Evaluating path: $['eventType'] (com.jayway.jsonpath.internal.path.CompiledPath)
ESC[36mconnect            |ESC[0m [2020-05-05 15:29:36,527] DEBUG Evaluating path: $['timeToLive'] (com.jayway.jsonpath.internal.path.CompiledPath)
ESC[36mconnect            |ESC[0m [2020-05-05 15:29:36,527] TRACE No timeToLive found, ignoring (io.zeebe.kafka.connect.sink.message.JsonRecordParser)
ESC[36mconnect            |ESC[0m [2020-05-05 15:29:36,527] DEBUG Evaluating path: $['amount','orderId'] (com.jayway.jsonpath.internal.path.CompiledPath)
ESC[36mconnect            |ESC[0m [2020-05-05 15:29:36,528] DEBUG Publishing message io.zeebe.kafka.connect.sink.message.Message@1573292e (io.zeebe.kafka.connect.sink.ZeebeSinkTask)

While looking at the thread, I can see that the thread of the connector is indeed stucked:

I understand that the root cause is my invalid configuration, but the fact that there is no log at all, even in DEBUG or TRACE, makes it really hard to debug. Having to open VisualVM to understand that there is a typo in the configuration is fun, but time-consuming ;)

I think i am having a similar issue. Then checked Kafka Connect logs, I see following error

2020-10-15 09:03:18,938] INFO [Consumer clientId=connector-consumer-Zeebe_Sink_Connector-0, groupId=connect-Zeebe_Sink_Connector] Subscribed to topic(s): zeebe (org.apache.kafka.clients.consumer.KafkaConsumer)
[2020-10-15 09:03:18,939] INFO ZeebeSinkConnectorConfig values:
message.path.correlationKey = $.correlationKey
message.path.messageName = $.messageName
message.path.timeToLive = timeToLive
message.path.variables = variables
zeebe.client.broker.contactPoint = host.docker.internal:26500
zeebe.client.cloud.clientId = null
zeebe.client.cloud.clientSecret = null
zeebe.client.cloud.clusterId = null
zeebe.client.requestTimeout = 10000
zeebe.client.security.plaintext = true
(io.zeebe.kafka.connect.sink.ZeebeSinkConnectorConfig)
[2020-10-15 09:03:18,940] ERROR WorkerSinkTask{id=Zeebe_Sink_Connector-0} Task threw an uncaught and unrecoverable exception (org.apache.kafka.connect.runtime.WorkerTask)
java.lang.NoClassDefFoundError: Could not initialize class io.grpc.netty.NettyChannelBuilder
at io.zeebe.client.impl.ZeebeClientImpl.buildChannel(ZeebeClientImpl.java:122)
at io.zeebe.client.impl.ZeebeClientImpl.(ZeebeClientImpl.java:78)
at io.zeebe.client.impl.ZeebeClientBuilderImpl.build(ZeebeClientBuilderImpl.java:267)
at io.zeebe.kafka.connect.util.ZeebeClientHelper.buildClient(ZeebeClientHelper.java:62)
at io.zeebe.kafka.connect.sink.ZeebeSinkTask.start(ZeebeSinkTask.java:48)
at org.apache.kafka.connect.runtime.WorkerSinkTask.initializeAndStart(WorkerSinkTask.java:302)
at org.apache.kafka.connect.runtime.WorkerSinkTask.execute(WorkerSinkTask.java:193)
at org.apache.kafka.connect.runtime.WorkerTask.doRun(WorkerTask.java:185)
at org.apache.kafka.connect.runtime.WorkerTask.run(WorkerTask.java:235)
at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:834)
[2020-10-15 09:03:18,943] ERROR WorkerSinkTask{id=Zeebe_Sink_Connector-0} Task is being killed and will not recover until manually restarted (org.apache.kafka.connect.runtime.WorkerTask)


docs: fix switch and reactive props examples

rename index to tabIndex
fix reactive props examples

Thank you!


No match for any font generic names or substituted names

Warning (in usvg::text::convert:424): No match for 'Courier,monospace' font-family
Warning (in usvg::text::convert:424): No match for 'Helvetica,Arial,sans-serif' font-family.
Warning (in usvg::text::convert:424): No match for 'sans-serif' font-family.

The warnings are kind of correct, but also wrong. There are no fonts with these names installed on the system. However, FontConfig is set up with substitutions for all the named fonts, and it has defaults for the generic font names defined. This is the default in most Linux distributions. I’m not sure what further details you need.
Fedora Linux 35, resvg 0.19.0

Fontconfig is not supported and not planned. C API is a minefield and not thread-safe (afaik) and Rust version is not available.
Also, it looks like a parsing error. Warning should contain a single family name. Can you send me the file or at east the font-family attribute?

Anyway, you basically have to configure resvg's fontdb yourself. Not sure if you're are using resvg as a library or a executable, but both have extensive API for defining fonts.

I’m using the executable.
Adding --sans-serif-family "Nimbus Sans" --monospace-family "Nimbus Mono" arguments make the error go away. Linux doesn’t have the default fonts you specify.

Fontconfig is not supported and not planned. C API is a minefield and not thread-safe (afaik) and Rust version is not available.

Fair enough. Would you be willing to add the default font substitutions to fontdb, though? By default, I mean the PostScript level 1 fonts every platform is supposed to support. I wrote an article about these a few months back.
The operating systems perform these when substitutions when you use their APIs or something like FontConfig. But I guess you need to hardcode them as resvg is doing it’s own thing entirely.
Windows:

Helvetica => Arial
Times => Times New Roman
Courier=>Courier New

Linux:

Helvetica=>Nimbus Sans
Times=>Nimbus Roman
Courier=>Nimbus Mono

Linux (Windows compatibility, not PostScript):

Arial=>Liberation Sans
Times New Roman=>Liberation Serif
Courier New=>Liberation Mono

Mac just ships the PostScript fonts by default. The Nimbus/Liberation fonts are both metrically compatible. Both are equal options for substitutions, but the above is FontConfig’s default set up. Most Linux distributions ship in full or in part either or both Nimbus and Liberation.
This should fix the defaults you’ve set for the generic names on most Linux distributions.

Also, it looks like a parsing error. Warning should contain a single family name. Can you send me the file or at east the font-family attribute?

It’s set to exactly what’s shown in the warnings, so e.g. Helvetica,Arial,sans-serif.
But you’re logging the entire attribute, not just the parts of it. So, not a bug.
https://github.com/RazrFalcon/resvg/blob/7c89269337d0fb4ff673d2a196cffe8926399d81/usvg/src/text/convert.rs#L424

Linux doesn’t have the default fonts you specify.

Linux doesn't have default fonts do begin with. This is oxymoron. So without full FontConfig support, hardcoded values are the next best thing.
Proper fonts resolution is a low priority issue, because you should not rely on fallback fonts to begin with.

This should fix the defaults you’ve set for the generic names on most Linux distributions.

My linux distro, gentoo, doesn't have any of those fonts.

By default, I mean the PostScript level 1 fonts every platform is supposed to support.

You also probably want to change the defaults to the PostScript font names instead of Microsoft’s we-refuse-to-pay-the-licenses-on-these-fonts lookalikes. Name substitutions can sot them back in again.

resvg uses family names, not PostScript names. As per CSS spec.
The main problem here is that fonts resolving is not specified and every browser, app, framework, etc are doing their own thing. There is no correct behaviour.

Not a bug.


Fix typo 'securityOptions' => 'secureOptions'

PR Checklist:
(No code was changed; this was a minor typo in the README.)

[ ] I have run npm test locally and all tests are passing.
[ ] I have added/updated tests for any new behavior.

[ ] If this is a significant change, an issue has already been created where the problem / solution was discussed: [N/A, or add link to issue here]

PR Description
I think this is a typo (https://github.com/nodejs/node-v0.x-archive/issues/8608 and elsewhere in the request codebase). Passing in as 'securityOptions' would probably be a no-op, at least from first glance.

Could this get merged? It's just a doc update.


Question: combining components with different props

Assume I have two components, both stateless (for simplicity), both have their own props and actions:
-- widget.purs
widget :: Spec _ _ WidgetProps WidgetAction
widget = simpleSpec performWidgetAction renderWidget

Now I want to add the widget into some sort of a panel:
-- panel.purs
panel :: Spec _ _ PanelProps PanelAction
panel = simpleSpec performPanelAction renderPanel

It is OK for a panel to "know" about the widget (and other components inside it), but I want the widget to be completely unaware of the panel so it can be composed into other things.
I also want the panel to "react" on what happens in the widget. Should it be handling WidgetAction or should WidgetProps declare some sort of a callback - I don't know what is be the better way, and it is also a part of my question.
Is there an example showing how to compose two components with different props and actions so one "subscribes" to the "events" of another?
Or what is the way to do it with purescript-react/thermite?
Regards,
Alexey.

Thermite doesn't do much with props, only state. Right now, you can read props in render, or convert to a React component spec, and do stuff with the props there before finally converting to a component class.
The tricky thing is that props aren't as nicely composable as the state from Thermite's point of view, in the sense that the parent is responsible for updating props, not the current component. On the other hand, we can share parts of state between parent and child easily.

Yes, I see that I could manage it through state, but React itself is moving more and more away from the concept of stateful components, and the current version even introduces a new syntax:
var Aquarium = (props) => {
  var fish = getFish(props.species);
  return <Tank>{fish}</Tank>;
};

which is actually a function from props to component, so I thought that maybe there is a way to embrace props rather than fighting them...
The fact that the parent is responsible for providing props and not the current component corresponds to the fact that the caller is responsible for providing function arguments and not the function itself. Not sure if it should be a problem for composition.

This is probably relevant: https://github.com/purescript-contrib/purescript-react/pull/52

Oh, thank you! I will definitely check it out. Does it still work with the latest purescript-thermite?

Yes, I've updated Thermite to use the latest version.

Thanks a lot! I'll close this issue and give it a go.


mosaic view should center slices or use equal space between slices to make use of full canvas width

Currently, the niivue mosaic view uses a left justified layout like this:

However, it would look nicer (and better on various device widths) if the slices could have equal space between them while occupying the full width of the canvas. Alternatively, they could have equal "space around" on the left and right most slices so that the mosaic is centered.

@hanayik I have added boolean property which defaults to nv.centerMosaic = false. If set to true, the mosaic is centered. I leave it in your capable hands on how to proceeed:

If you want to make centered the only or default behavior, you need to update regression tests like niivue-demo-file-mosaics-html-chromium.png.
If you want to allow developers to decide if a mosaic is centered, this needs to be stored in the document, and the definition should probably be in nvdocument.ts.

To illustrate the new (experimental) behavior, I have added a center checkbox to the mosaic demo:


Year dropdown scroll defaults to center of list

I'm using the showYearDropdown prop and maxDate prop on the datepicker but when I click the year dropdown, it will always start at the center of list. Is there a way to set the default value of the dropdown to the current year?
How it opens now:

How it is expected to be opened:

Same behavior is happening for me too
@AbilityMaster any solution so far?

@anas510 , @AbilityMaster
Is there a solution to this problem?

@anas510 , @AbilityMaster Is there a solution to this problem?

I'm affraid it's because of yearDropdownItemNumber, it doesn't adjust the height using scroll option. If you remove that prop, it centers.

@AbilityMaster helped with the solution of this problem


Integration Test - Release - 2019/02/13 18:42:35

Auto create for integration test. IssueCommandFlow

@adunndevster : Thanks for your contribution! The author, @v-caxian, has been notified to review your proposed change.


[Bugfix] Bind remote test server to port 0

Potential alternate solution for #8204--I saw that asyncio will use a default port of 0 in the context of create_server() if no port is given in the config. Binding to port 0 with socket.socket.bind() apparently means the OS will pick an available port for you, which I think functions similarly to get_open_port(): https://github.com/vllm-project/vllm/blob/47790f3e328f1fbf250d8f858b6390496c1e61c0/vllm/utils.py#L532-L541
But instead of choosing the port first and binding it later after the engine starts, choosing as the port is bound may resolve potential conflicts with Ray picking the same port?
FIX #8204
BEFORE SUBMITTING, PLEASE READ THE CHECKLIST BELOW AND FILL IN THE DESCRIPTION ABOVE

 PR Checklist (Click to Expand)
Thank you for your contribution to vLLM! Before submitting the pull request, please ensure the PR meets the following criteria. This helps vLLM maintain the code quality and improve the efficiency of the review process.
PR Title and Classification
Only specific types of PRs will be reviewed. The PR title is prefixed appropriately to indicate the type of change. Please use one of the following:

[Bugfix] for bug fixes.
[CI/Build] for build or continuous integration improvements.
[Doc] for documentation fixes and improvements.
[Model] for adding a new model or improving an existing model. Model name should appear in the title.
[Frontend] For changes on the vLLM frontend (e.g., OpenAI API server, LLM class, etc.)
[Kernel] for changes affecting CUDA kernels or other compute kernels.
[Core] for changes in the core vLLM logic (e.g., LLMEngine, AsyncLLMEngine, Scheduler, etc.)
[Hardware][Vendor] for hardware-specific changes. Vendor name should appear in the prefix (e.g., [Hardware][AMD]).
[Misc] for PRs that do not fit the above categories. Please use this sparingly.

Note: If the PR spans more than one category, please include all relevant prefixes.
Code Quality
The PR need to meet the following code quality standards:

We adhere to Google Python style guide and Google C++ style guide.
Pass all linter checks. Please use format.sh to format your code.
The code need to be well-documented to ensure future contributors can easily understand the code.
Include sufficient tests to ensure the project to stay correct and robust. This includes both unit tests and integration tests.
Please add documentation to docs/source/ if the PR modifies the user-facing behaviors of vLLM. It helps vLLM user understand and utilize the new features or changes.

Adding or changing kernels
Each custom kernel needs a schema and one or more implementations to be registered with PyTorch.

Make sure custom ops are registered following PyTorch guidelines: Custom C++ and CUDA Operators and The Custom Operators Manual
Custom operations that return Tensors require meta-functions. Meta-functions should be implemented and registered in python so that dynamic dims can be handled automatically. See above documents for a description of meta-functions.
Use torch.libary.opcheck() to test the function registration and meta-function for any registered ops.  See tests/kernels for examples.
When changing the C++ signature of an existing op, the schema must be updated to reflect the changes.
If a new custom type is needed, see the following document: Custom Class Support in PT2.

Notes for Large Changes
Please keep the changes as concise as possible. For major architectural changes (>500 LOC excluding kernel/data/config/test), we would expect a GitHub issue (RFC) discussing the technical design and justification. Otherwise, we will tag it with rfc-required and might not go through the PR.
What to Expect for the Reviews
The goal of the vLLM team is to be a transparent reviewing machine. We would like to make the review process transparent and efficient and make sure no contributor feel confused or frustrated. However, the vLLM team is small, so we need to prioritize some PRs over others. Here is what you can expect from the review process:

 After the PR is submitted, the PR will be assigned to a reviewer. Every reviewer will pick up the PRs based on their expertise and availability.
 After the PR is assigned, the reviewer will provide status update every 2-3 days. If the PR is not reviewed within 7 days, please feel free to ping the reviewer or the vLLM team.
 After the review, the reviewer will put an  action-required label on the PR if there are changes required. The contributor should address the comments and ping the reviewer to re-review the PR.
 Please respond to all comments within a reasonable time frame. If a comment isn't clear or you disagree with a suggestion, feel free to ask for clarification or discuss the suggestion.

Thank You
 Finally, thank you for taking the time to read these guidelines and for your interest in contributing to vLLM. Your contributions make vLLM a great tool for everyone!

but then how does the caller know which port to connect to the api server?

one way is to read and parse the output, like Uvicorn running on http://<IP_ADDRESS>:40243 . but it is not elegant.

I'm curious why I don't see any users complaining about this. And I think the answer is, users use port 8000 by default. It does not overlap with dynamically allocated ports.
for normal os, when we ask for a random port, it is not really a random port. it is chosen from some range, e.g.
$ cat /proc/sys/net/ipv4/ip_local_port_range
32768   60999

And given the fact that we never launch multiple api servers, we might solve this issue by directly assign one specific port for it, say 8001 😄

@youkaichao Oh I see. So even though this issue is for automated testing, sometimes users would still want to connect to this test server manually to debug or something? And they just happened to rarely run into a situation where port 8000 was taken, and have to check 8001 or 8002.

So even though this issue is for automated testing, sometimes users would still want to connect to this test server manually to debug or something?

for testing, we cannot just start the server and then kill it. we need to use a client to connect to the server and let it run something.

@youkaichao Ok, I see where my confusion was now with the client needing to know the server's port. I think I'll actually try recreating the issues seen in the CI locally, and then try out some of these other solutions to verify they work. Thanks!

Also, would you rather I create a new PR, or is it ok if I just modify this same draft?

Just modify this one and change the title

see https://github.com/vllm-project/vllm/blob/3724d5f6b59d9859e5b47c047535bb8edc124eab/tests/utils.py#L144-L162
the self.port is used to creat a client.

the result looks promising! can you resolve the conflict so that we can merge?

merge as error is unrelated


Ensures docker pull happens before push and polishes release files

going to cut a patch after that, so that latest and greatest is available (ex armeria) prior to announcing the already released 2.23


Adding type of waste per date

We need to add a certain way to set which type of waste needs to be put outside/inside for a building on a certain date.
Might be a good idea to see/set all of the wast types in the building page per week.

Point 1 was already present. Point 2 is now added to the building page issue.


fetch and display new line/route info with correct tz

@consindo sorry don't quite understand your aversion to route_id preference
https://github.com/dymajo/waka-server/blob/master/src/waka-worker/lines/regions/generic.ts#L12..L31
https://github.com/dymajo/waka-server/blob/master/src/waka-worker/stops/station.ts#L359..L377
all props needed to perform fetch by route_id are already supplied

fine.


OTHER HTTPS METHOD

How to using node-rest-client-promise with other methods such as POST, DELETE, PUT, GET with request data,... I can't find docs or references anywhere. Thanks in advance

As the documentation states, this is just a promisified wrapper for node-rest-client, which has methods like client.get which become client.getPromise here. This means, that client.post becomes client.postPromise here and so on.


Error regarding MaAsLin2 log ratios

Context
I tried running Qadabra on some prokaryotic species-level cluster (PSLC) counts data recently and ran into the error below. At first I thought it could have had something to do with the formatting of the index names in the .biom file I used as the table, but when I re-ran it I encountered the same error.
Specifically, there seems to be something awry when it comes to the calculation of log ratios for MaAsLin2. From what I could tell, there were 2 errors regarding the log_ratio function used to create results/environment_comparisons/ml/maaslin2/log_ratios/log_ratios.pctile_15.tsv and its pctile_20 counterpart (shown in the error message). The log_ratios.pctile_20.tsv file has 274 out of 687 total PSLCs in my original dataset/table, but the error message states that 137 are not in the columns (I'm not sure which columns it's referring to). I'm having trouble locating the tmpflekjq_3.get_log_ratios.py script mentioned in the error message so I figured I'd report this and ask to see if something like this has come up before.
My questions

I pasted the header of the the log_ratios.pctile_20.tsv file at the bottom; are the values of the 3 rightmost columns supposed to be the same regardless of the feature_id? I don't know if that's causing the error but I figured I'd check.
How can I find the script that's mentioned in the error message so I can find out what the columns it's referring to are? When I ls -a the .snakemake/scripts/ directory (looking for tmpflekjq_3.get_log_ratios.py) I don't see anything in it.
Have you encountered a similar issue?

Thank you and I'm happy to provide more info if needed.
Code
Adding the dataset:
(qadabra_env) aphilliplt-osx:differential_abundance_analysis aphillip$ qadabra add-dataset \
> --workflow-dest my_qadabra \
> --table my_qadabra/data/slc_prok.biom \
> --metadata my_qadabra/data/environment_metadata.tsv \
> --name environment_comparisons\
> --factor-name group \
> --target-level sediment \
> --reference-level water \
> --verbose

Running the workflow:
(qadabra_env) aphilliplt-osx:differential_abundance_analysis aphillip$ cd my_qadabra/
(qadabra_env) aphilliplt-osx:my_qadabra aphillip$ snakemake --use-conda --cores 4

Portion of the error message:
Activating conda environment: .snakemake/conda/398bc325f983272b15d35276018e95bd_
Traceback (most recent call last):
  File "/Users/aphillip/Library/CloudStorage/Desktop/Projects/counts_tables/differential_abundance_analysis/my_qadabra/.snakemake/scripts/tmpflekjq_3.get_log_ratios.py", line 41, in <module>
    lr_df = log_ratio(table, top_feats, bot_feats).reset_index()
...
File "/Users/aphillip/Library/CloudStorage/Desktop/Projects/counts_tables/differential_abundance_analysis/my_qadabra/.snakemake/conda/398bc325f983272b15d35276018e95bd_/lib/python3.11/site-packages/pandas/core/indexes/base.py", line 6176, in _raise_if_missing
    raise KeyError(f"None of [{key}] are in the [{axis_name}]")
KeyError: "None of [Index(['PSLC.198', 'PSLC.643', 'PSLC.340', 'PSLC.357', 'PSLC.32', 'PSLC.662',\n       'PSLC.38', 'PSLC.375', 'PSLC.389', 'PSLC.23',\n       ...\n       'PSLC.53', 'PSLC.668', 'PSLC.39', 'PSLC.40', 'PSLC.1', 'PSLC.270',\n       'PSLC.303', 'PSLC.291', 'PSLC.195', 'PSLC.683'],\n      dtype='object', length=137)] are in the [columns]"
[Fri Jan 12 17:30:38 2024]
Error in rule log_ratios:
    jobid: 143
    input: /Users/aphillip/Library/CloudStorage/Desktop/Projects/counts_tables/differential_abundance_analysis/my_qadabra/data/slc_prok.biom, results/environment_comparisons/ml/maaslin2/pctile_feats/pctile_20.tsv
    output: results/environment_comparisons/ml/maaslin2/log_ratios/log_ratios.pctile_20.tsv
    log: log/environment_comparisons/log_ratios.maaslin2.pctile_20.log (check log file(s) for error details)
    conda-env: /Users/aphillip/Library/CloudStorage/Desktop/Projects/counts_tables/differential_abundance_analysis/my_qadabra/.snakemake/conda/398bc325f983272b15d35276018e95bd_

RuleException:
CalledProcessError in file /Users/aphillip/anaconda3/envs/qadabra_env/lib/python3.10/site-packages/qadabra/workflow/rules/ml.smk, line 55:
Command 'source /Users/aphillip/anaconda3/bin/activate '/Users/aphillip/Library/CloudStorage/Desktop/Projects/counts_tables/differential_abundance_analysis/my_qadabra/.snakemake/conda/398bc325f983272b15d35276018e95bd_'; set -euo pipefail;  python /Users/aphillip/Library/CloudStorage/Desktop/Projects/counts_tables/differential_abundance_analysis/my_qadabra/.snakemake/scripts/tmpflekjq_3.get_log_ratios.py' returned non-zero exit status 1.
  File "/Users/aphillip/anaconda3/envs/qadabra_env/lib/python3.10/site-packages/qadabra/workflow/rules/ml.smk", line 55, in __rule_log_ratios
  File "/Users/aphillip/anaconda3/envs/qadabra_env/lib/python3.10/concurrent/futures/thread.py", line 58, in run
Traceback (most recent call last):
  File "/Users/aphillip/Library/CloudStorage/Desktop/Projects/counts_tables/differential_abundance_analysis/my_qadabra/.snakemake/scripts/tmppagdql8a.get_log_ratios.py", line 41, in <module>
    lr_df = log_ratio(table, top_feats, bot_feats).reset_index()
...
File "/Users/aphillip/Library/CloudStorage/Desktop/Projects/counts_tables/differential_abundance_analysis/my_qadabra/.snakemake/conda/398bc325f983272b15d35276018e95bd_/lib/python3.11/site-packages/pandas/core/indexes/base.py", line 6176, in _raise_if_missing
    raise KeyError(f"None of [{key}] are in the [{axis_name}]")
KeyError: "None of [Index(['PSLC.198', 'PSLC.643', 'PSLC.340', 'PSLC.357', 'PSLC.32', 'PSLC.662',\n       'PSLC.38', 'PSLC.375', 'PSLC.389', 'PSLC.23',\n       ...\n       'PSLC.52', 'PSLC.665', 'PSLC.318', 'PSLC.685', 'PSLC.276', 'PSLC.349',\n       'PSLC.309', 'PSLC.632', 'PSLC.630', 'PSLC.359'],\n      dtype='object', length=103)] are in the [columns]"
[Fri Jan 12 17:30:39 2024]
Error in rule log_ratios:
    jobid: 122
    input: /Users/aphillip/Library/CloudStorage/Desktop/Projects/counts_tables/differential_abundance_analysis/my_qadabra/data/slc_prok.biom, results/environment_comparisons/ml/maaslin2/pctile_feats/pctile_15.tsv
    output: results/environment_comparisons/ml/maaslin2/log_ratios/log_ratios.pctile_15.tsv
    log: log/environment_comparisons/log_ratios.maaslin2.pctile_15.log (check log file(s) for error details)
    conda-env: /Users/aphillip/Library/CloudStorage/Desktop/Projects/counts_tables/differential_abundance_analysis/my_qadabra/.snakemake/conda/398bc325f983272b15d35276018e95bd_

RuleException:
CalledProcessError in file /Users/aphillip/anaconda3/envs/qadabra_env/lib/python3.10/site-packages/qadabra/workflow/rules/ml.smk, line 55:
Command 'source /Users/aphillip/anaconda3/bin/activate '/Users/aphillip/Library/CloudStorage/Desktop/Projects/counts_tables/differential_abundance_analysis/my_qadabra/.snakemake/conda/398bc325f983272b15d35276018e95bd_'; set -euo pipefail;  python /Users/aphillip/Library/CloudStorage/Desktop/Projects/counts_tables/differential_abundance_analysis/my_qadabra/.snakemake/scripts/tmppagdql8a.get_log_ratios.py' returned non-zero exit status 1.
  File "/Users/aphillip/anaconda3/envs/qadabra_env/lib/python3.10/site-packages/qadabra/workflow/rules/ml.smk", line 55, in __rule_log_ratios
  File "/Users/aphillip/anaconda3/envs/qadabra_env/lib/python3.10/concurrent/futures/thread.py", line 58, in run
[Fri Jan 12 17:30:40 2024]
Finished job 92.
57 of 152 steps (38%) done
[Fri Jan 12 17:32:03 2024]
Finished job 9.
58 of 152 steps (38%) done
Shutting down, this might take some time.
Exiting because a job execution failed. Look above for error message
Complete log: .snakemake/log/2024-01-12T171542.544654.snakemake.log

Header of the log_ratios.pctile_20.tsv file:
feature_id	location	pctile	num_feats
PSLC.198	numerator	20	137
PSLC.643	numerator	20	137
PSLC.340	numerator	20	137
PSLC.357	numerator	20	137

Update: It seems like it was an issue with the original index names in the biom table, which had hyphens in them. I re-ran the workflow a third time in a completely new workflow directory and it made it further along (77% done instead of 38%) before encountering a different error related to the use of iteritems on a Series. I'll open a separate issue for that since I believe iteritems is deprecated now.


Alignment of lv_mem_alloc() wrong for LV_MEM_CUSTOM==1 on 64bit architectures

Hi!
I had tried arround with LV_MEM_CUSTOM==1 and using generic malloc/free, and the address sanitizer found the following problem:
At least on 64bit architectures, malloc returns 8 byte aligned memory blocks such that the memory can be cast to any built-in type. But because of the lv_mem_ent_t header struct that is allocated inside lv_mem_alloc() in front of the block, the return pointer is only 4 byte aligned.
When you compile with the undefined behavior sanitizer -fsanitize=undefined -lubsan) and run the simulator on a 64 PC, you will get lots of warnings like this:
[...] runtime error: member access within misaligned address 0x60d0000cfd34 for type 'struct lv_style_t', which requires 8 byte alignment
I am not sure if this header has any useful purpose. But if you want to have it, you must ensure that the pointer, lv_mem_alloc returns, has the correct alignment depending on the architecture. Otherwise  "defined behavior" can occur...

Hi,
Thank you for the report and the great description.
I pushed an update to dev-5.2 branch.


permalink from branch/tag blob view

eg to grab a permalink from:
https://github.com/sindresorhus/refined-github/blob/master/source/content.ts
You have to click:

History (https://github.com/sindresorhus/refined-github/commits/master/source/content.ts)
See object at this point in history (https://github.com/sindresorhus/refined-github/blob/870a4727ab4f677cef5a5864b2ffb1377cc660be/source/content.ts)

I'd like a 1 click version, and I'd rather link to the latest commit in the branch (https://github.com/sindresorhus/refined-github/blob/0b2400511c28c9e22edbfc18770f113eafcecfc4/source/content.ts) rather than the latest commit including that blob reachable from the selected branch

Perhaps the option should go into the ref switcher dropdown as a "trees" tab

turns out I can just press 'y'


Added additional type constraint for findFormatter function parameter

I've added added additional type constraint for formatter in ILinterOptionsRaw interface and findFormatter function parameter name as it accepts the type Function, but was constrained to string only.

/cc https://github.com/palantir/tslint/issues/1427#issuecomment-235954435

Looks good to me, thanks @DovydasNavickas!


Error when running tests

I've been trying to run the tests using Node 18 and am getting the following error:
  console.error
    Error: Error: connect ECONNREFUSED <IP_ADDRESS>:80
        at Object.dispatchError (/home/mhall/Projects/pybricks-code/node_modules/jsdom/lib/jsdom/living/xhr/xhr-utils.js:63:19)
        at Request.<anonymous> (/home/mhall/Projects/pybricks-code/node_modules/jsdom/lib/jsdom/living/xhr/XMLHttpRequest-impl.js:655:18)
        at Request.emit (node:events:525:35)
        at ClientRequest.<anonymous> (/home/mhall/Projects/pybricks-code/node_modules/jsdom/lib/jsdom/living/helpers/http-request.js:121:14)
        at ClientRequest.emit (node:events:513:28)
        at Socket.socketErrorListener (node:_http_client:502:9)
        at Socket.emit (node:events:513:28)
        at emitErrorNT (node:internal/streams/destroy:151:8)
        at emitErrorCloseNT (node:internal/streams/destroy:116:3)
        at processTicksAndRejections (node:internal/process/task_queues:82:21) {
      type: 'XMLHttpRequest'
    }

      at VirtualConsole.<anonymous> (node_modules/jest-environment-jsdom/build/index.js:60:23)
      at Object.dispatchError (node_modules/jsdom/lib/jsdom/living/xhr/xhr-utils.js:66:53)
      at Request.<anonymous> (node_modules/jsdom/lib/jsdom/living/xhr/XMLHttpRequest-impl.js:655:18)
      at ClientRequest.<anonymous> (node_modules/jsdom/lib/jsdom/living/helpers/http-request.js:121:14)

  console.error
    Error: Error: connect ECONNREFUSED <IP_ADDRESS>:80
        at Object.dispatchError (/home/mhall/Projects/pybricks-code/node_modules/jsdom/lib/jsdom/living/xhr/xhr-utils.js:63:19)
        at Request.<anonymous> (/home/mhall/Projects/pybricks-code/node_modules/jsdom/lib/jsdom/living/xhr/XMLHttpRequest-impl.js:655:18)
        at Request.emit (node:events:525:35)
        at ClientRequest.<anonymous> (/home/mhall/Projects/pybricks-code/node_modules/jsdom/lib/jsdom/living/helpers/http-request.js:121:14)
        at ClientRequest.emit (node:events:513:28)
        at Socket.socketErrorListener (node:_http_client:502:9)
        at Socket.emit (node:events:513:28)
        at emitErrorNT (node:internal/streams/destroy:151:8)
        at emitErrorCloseNT (node:internal/streams/destroy:116:3)
        at processTicksAndRejections (node:internal/process/task_queues:82:21) {
      type: 'XMLHttpRequest'
    }

      at VirtualConsole.<anonymous> (node_modules/jest-environment-jsdom/build/index.js:60:23)
      at Object.dispatchError (node_modules/jsdom/lib/jsdom/living/xhr/xhr-utils.js:66:53)
      at Request.<anonymous> (node_modules/jsdom/lib/jsdom/living/xhr/XMLHttpRequest-impl.js:655:18)
      at ClientRequest.<anonymous> (node_modules/jsdom/lib/jsdom/living/helpers/http-request.js:121:14)

 FAIL  src/mpy/sagas.test.ts
  ✕ compiler works (1039 ms)
  ✕ compiler error works (1010 ms)

  ● compiler works

    TypeError: Network request failed

      at node_modules/whatwg-fetch/dist/fetch.umd.js:535:18
      at Timeout.task [as _onTimeout] (node_modules/jsdom/lib/jsdom/browser/Window.js:519:19)

  ● compiler works

    timed out

      59 |             // completed later
      60 |             return new Promise((resolve, reject) => {
    > 61 |                 const timeout = setTimeout(reject, 1000, new Error('timed out'));
         |                                                          ^
      62 |
      63 |                 this.takers.push({
      64 |                     put: (a: AnyAction): void => {

      at test/index.tsx:61:58
      at AsyncSaga.take (test/index.tsx:60:20)
      at Object.take (src/mpy/sagas.test.ts:13:31)

  ● compiler error works

    TypeError: Network request failed

      at node_modules/whatwg-fetch/dist/fetch.umd.js:535:18
      at Timeout.task [as _onTimeout] (node_modules/jsdom/lib/jsdom/browser/Window.js:519:19)

  ● compiler error works

    timed out

      59 |             // completed later
      60 |             return new Promise((resolve, reject) => {
    > 61 |                 const timeout = setTimeout(reject, 1000, new Error('timed out'));
         |                                                          ^
      62 |
      63 |                 this.takers.push({
      64 |                     put: (a: AnyAction): void => {

      at test/index.tsx:61:58
      at AsyncSaga.take (test/index.tsx:60:20)
      at Object.take (src/mpy/sagas.test.ts:27:31)

Am I missing something in my test setup? Any suggestions as to the root cause? Then I can go looking and see if I can fix it.

We currently use node 16 so I would suggest sticking with that for now (unless you really want to spend time digging into this problem). We probably need to mock a fetch() somewhere so that it isn't trying to make a network connection during tests.

I'm happy to go digging a bit. Any suggestions as to where I should start?

Looking at it closer now, it looks like it has to do with the compiler. This uses the mpy-cross executable from MicroPython to compile Python code to a .mpy file. The executable is compiled from C to WASM using Emscripten. There is some "magic" in the code generated by Emscripten to handle Node environments vs the web. On Node, it should load the .wasm file from the file system while on the web it uses fetch(). It sounds like this may have broke in Node 18?
The source for the mpy-cross package is at https://github.com/pybricks/pybricks-micropython/tree/master/npm/mpy-cross.

That sounds like a likely cause, because it runs just fine and the issue only seemed to appear in the tests. I'll investigate.
Sent from ProtonMail mobile
-------- Original Message --------
On 9 Mar 2023, 19:37, David Lechner wrote:

Looking at it closer now, it looks like it has to do with the compiler. This uses the mpy-cross executable from MicroPython to compile Python code to a .mpy file. The executable is compiled from C to WASM using Emscripten. There is some "magic" in the code generated by Emscripten to handle Node environments vs the web. On Node, it should load the .wasm file from the file system while on the web it uses fetch(). It sounds like this may have broke in Node 18?
The source for the mpy-cross package is at https://github.com/pybricks/pybricks-micropython/tree/master/npm/mpy-cross.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.Message ID: @.***>


Fix dips, nimble file handling, and gitops

This PR started to work on https://github.com/nim-lang/atlas/issues/117 but uncovered a few other items which needed cleaned up or fixed.
Changes:

Combine multiple ways to search for Nimble files into one place
fixes some edge cases in handling finding Nimble files
fixes issue with writing default config file and handling the deps cli option
unit tests for various nimble file states (missing, ambiguous, etc)
unit tests for parsing PkgUrl's
merges adhoc git execs to use the gitops module, restoring logging etc
cleanup for setting up triple-name on conflicts

Option[string] is actually worse than string if s.len == 0 is already an errornous state. You added yet another error state on top of the one we already have.

It does introducing another possible error state, but that can be handled by ensuring the code that finds the nimble files doesn't return some(""). It's not ideal granted to be able to make an invalid state but it's localized to that single proc so should be easy to vet.
Mainly I found it useful in documenting elsewhere in the codebase that the Nimble file might not be found yet and that using .get will result in an easier to trace defect vs an empty string which might go unchecked.

This seems like a good PR. Any status on it ?