Identity-apps PR-builder lint checker is passing even though there are lint warnings

Describe the issue:

When running the lint step in PR-builder in batches, the script does not fail with exit code 1 if only the first batch contains lint errors, but subsequent batches do not.
Ref: https://github.com/wso2/identity-apps/actions/runs/9691452427/job/26742965321?pr=6485

How to reproduce:

Create a Pull Request:

Submit a pull request with changes in 31 files. (Current batch threshold is 30)
Introduce lint mistakes in any of the first 30 files.
Ensure the 31st file does not contain any lint mistakes.

Expected behavior:

The linter script should fail with an exit code of 1 if any lint mistakes are present in any of the files being linted.

Fixed with:

https://github.com/wso2/identity-apps/pull/6485


Cleanup extra ']' bracket in documentation markdown

+1 looks great to me
@charleswhchan I merged this into master keep up the good work.


rife-ncnn-vulkan: Add version 20220330

https://github.com/nihui/rife-ncnn-vulkan
342 stars
the Author nihui's other repo has 2.1k stars and merged in https://github.com/ScoopInstaller/Main/blob/master/bucket/waifu2x-ncnn-vulkan.json

[x] I have read the Contributing Guide.

/verify


Improve Fuse start script

Fix https://github.com/Alluxio/alluxio/issues/11282
Improve echo messages

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/9184/
Test PASSed.

@ZacBlanco  PTAL. thanks

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/9202/
Test FAILed.

jenkins, test this please

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/9203/
Test PASSed.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/9206/
Test PASSed.

alluxio-bot, merge this please

alluxio-bot, cherry-pick this to branch-2.2 please


Triage process for Keras - Tensorflow issues

Hi Gabriel,
I'm part of Tensorflow Dev Support team and we started triaging Tensorflow related issues in the Keras Github repository. As part of this, we are going to follow below steps(drafted on a high level) using the appropriate labels. Hence we are going to create new labels(mentioned below) as per our regular standards we follow for other Tensorflow repositories (like Core, Models, TFX etc).
Creating this message to keep you posted on this and please take a look. Feel free to add your thoughts on this. Thank you !
Steps we follow for triaging :

Pick an issue related to TF backend and add label type:tensorflow
If it is a question for Stack Overflow, add the label "type:support", close the issue and redirect the user to stack overflow.
If the user doesn't provide a code snippet to reproduce the error, ask him/her to provide the same.
If the issue persists with tf.keras, apply the label "stat:cross-posting to TF" and post it in the Tensorflow core repo.(Once it's triaged there, both the issues in TF core and keras repo can be closed)
If the issue doesn't persist with tf.keras, it is assigned to the Keras person based on the Round Robin rotation.
Once the issue is fixed, it can be closed.

New labels we are going to create :
stat:awaiting response  -> When triage/Dev person asks some information and waiting for the user to respond
stat:awaiting tensorflower -> When assigned to a Developer and waiting for his/her response
stat:contributions welcome -> When a feature is open for external contributions
stat:cross-posting to TF -> when the issue persists with tf.keras
type:bug/performance -> When it is a bug or any performance related issue
type:docs -> Issue related to any changes to be made in the documents or in the examples page of the site
type:support -> When a question is asked by user or when user seeks consultation(no bug/feature request) then we close the issue asked the user to post in Stack Overflow and mark it with this label.
type:build/install -> anything related to build or installation
type:feature -> If a user asks for a new feature
type:tensorflow -> For all TF related issues.
@dksb @fchollet @karmel   -  Hi, feel free to add your inputs.

First of all, thank you for the support :)
Since I'm already putting tags on issues, here are the labels that I'll put:
type:tensorflow
type:support (previously question)
stat:contributions welcome (previously help wanted)
type:bug
type:performance
type:docs (previously documentation)
type:install/build
type:feature (previously feature request)
announcement
to investigate (when we don't know if it's a bug or a user error, which happens often. Ideally should be converted into user error or type:bug or type:performance)
good first issue (very useful for newcomers so that they can get into the codebase progressively, this tag proved itself very effective recently)
Also for consistency, I'll use the same labels for tensorflow, theano and cntk issues. The only difference will be the tag type: tensorflow.
One question that I have, do we really have to use type: tensorflow or stat: contribution welcome? Isn't Tensorflow or Contribution welcome explicit enough? What's the added value of those prefixes? Is it for bots?

@gabrieldemarmiesse  Hi Gabriel, as you know GitHub doesn't do a great job on organizing issues. We have categories of labels that we prefix with category type (like type:, stat:). Since we support more than one repo, prefix helps us easily know what labels belong to a type of category for that repo. It helps standardize the metrics reporting and the bot based tooling.

Yes, that sounds good to us. We will pickup issues that are labelled type:tensorflow and triage them further. Also, we can mutually revisit this approach if it doesn't work as well as we want.

Hello,
First of all thanks for your support! We managed to lower the issue count to 500 last year or so, but it came back >1500 during the summer.
Since most issues on Keras are actually questions and we don't strictly force PR to close the related issues. I think we can lower the issue count quite easily.
Just one quick note: don't forget to redirect users to our Slack/google-group/Stackoverflow. The Slack is quite active and most people can find help there.
My saved response for redirect
Hi!
This issue isn't related to a bug/enhancement/feature request or other accepted types of issue.
To ask questions, please see the following resources :

https://keras.io/
https://keras.io/#support
https://gitter.im/Keras-io/Lobby

Thanks!
If you think I made a mistake, please open another issue.
Saved response for minimal exemple
Hi,
We could work on this better if you could provide a standalone reproducible example.
Some advices:

Don't use custom data or custom paths.
Use random arrays or even np.ones, np.zeros.
The example should run with Keras (and deps) alone.
Should be Python3 compatible.
Should not be OS specific.
The file should reproduce the bug with *high fidelity.
Link to a gist would be appreciated.

Thanks!
Dref360

Also, would this help if we shared with your team ours "areas of interest" so that you can assign keras-team's members issues?

For the minimal example, I suggest this:

Make a network as small as possible while keeping the bug present.

Also, would this help if we shared with your team ours "areas of interest" so that you can assign keras-team's members issues?

I do agree. Round robin is suboptimal since we surely have preferences.

@gabrieldemarmiesse  - Thanks for adding the labels. As we are following specific color code for all the labels, we will change the font and color of the labels accordingly.


Electrum on tailsOS with EPS/Core on different PC

Hey.
Im trying to get a connection to my core server from tails, ive done this before so I know it works but I cant get it working again.
Server has Core + EPS and on the same PC electrum connects fine.
From tails i do :
ssh x@x -L 50002:localhost:50002
electrum —oneserver --server localhost:50002:s
But cant get the connection to work on electrum..ideas?
Edit: I have a pruned node now, is that the problem?
Cheers

I doubt that pruning is the problem.
Try reading the debug log of EPS which might provide useful information. Its full path is printed to the terminal when EPS starts up (for example, on linux its usually /tmp/electrumpersonalserver.log)
Check if the EPS port is actually open by running netstat -l (on linux, on another OS the command might be different)


KAFKA-2787: Refactor gradle build

This is a first pass. I stopped here given its already a decent amount of change.
I can follow up with more in another pull request in the future if this is received well.
What was done:

Move gradle "script plugins" into /gradle folder
Update rat plugin grgit dep (can update since java 1.6 support was dropped)
De-duplicate common test deps and configs by moving to subprojects config
De-duplicate common Checkstyle deps by moving to subprojects config

Fix Checkstyle on java in core

Centralize dependencies/versions in dependencies.gradle
Setup Scala version dependencies to be more flexible (could support 2.12)
De-duplicate common artifact definitions
Fix examples Checkstyle
Remove javadoc modification except where needed
Fix docs paths when calling from subproject
Move release orchestartion into separate file

Closing until rebased and cleaned up a bit. Will re-open soon.


Boss parsing offset

🐛 Bug Report
The parsing for bosses is now wrong, off by 1. I expect this is relevant to the new RC boss.
I expect Jagex extended the boss CSV list and the delimiters are not reflecting it appropriately.
For example, stats and info for Vorkath are now parsed as Kree'Ara due to the offset issue.

This has still yet to be published...


Fix terminal size problem for windows

Trying to fix https://github.com/Wilfred/difftastic/issues/71

This also works for Powershell - https://github.com/Wilfred/difftastic/issues/71#issuecomment-998421047

Nice library! I've rebased this pull request as #78, but we can't merge this until https://github.com/jessesna/any-terminal-size/issues/2 is fixed.

Thanks! And sorry for the broken build. Forgot to reference libc. Tested it on a vm this time :)

I should have based the PR on a branch from the beginning; sorry.
To maybe make it easier, i created one now, rebased and combined a few commits: https://github.com/jessesna/difftastic/tree/any_terminal_size

Thanks for taking the time to look at this. I'm afraid I don't have much experience with Windows development, and I want to limit dependencies to more established libraries. I'm going to close this, as I don't think the dependency is a great fit for difftastic right now.

Thanks for taking the time to look into this.
I understand your concerns and hope that either any_terminal_size will grow in popularity or another, already popular library, maybe even term_size which you're using atm, will incorporate it.
Since i like difftastic and am using it actively but also want to provide a easy solution for window users (some of my coworkers at least) without having to set env vars i released the fork which uses any_terminal_size under the name difftastic_mod_for_windows. If you don't like this in general or would suggest changes, please let me know.

That sounds like a great solution :)


Error pages

Bringing the error pages into line with those on the buyer app.

Please note there is an issue currently where API errors cause an internal server error to be displayed NOT the error template.

This is because whilst rendering a template Flask-Login tries to confirm the user - fails (API error) and throws an error - preventing the template rendering.

Propose we merge this (as this issue is preexisting) and I'll add a story to fix in another way.

https://www.pivotaltracker.com/story/show/95235942

I broke stuff and it looks nice.


Error when the package is used right after initialize

Describe the bug
After I run my app, I get some data using FutureBuilder. But instead of the easyLoading showing up, I get the next error.
[ERROR:flutter/runtime/dart_vm_initializer.cc(41)] Unhandled Exception: 'package:flutter_easyloading/src/easy_loading.dart': Failed assertion: line 425 pos 7: 'overlayEntry != null': You should call EasyLoading.init() in your MaterialApp
Flutter/Dart info
please run flutter doctor then put it here.
Doctor summary (to see all details, run flutter doctor -v):
[√] Flutter (Channel stable, 3.3.6, on Microsoft Windows [Version 10.0.19044.2130], locale nl-BE)
[√] Android toolchain - develop for Android devices (Android SDK version 32.1.0-rc1)
[√] Chrome - develop for the web
[√] Visual Studio - develop for Windows (Visual Studio Community 2022 17.3.6)
[√] Android Studio (version 2021.3)
[√] VS Code (version 1.72.1)
[√] Connected device (3 available)
[√] HTTP Host Availability

• No issues found!

Screenshots
If applicable, add screenshots to help explain your problem.
This is my set up for the builder in my MaterialApp:
builder: EasyLoading.init(
          builder: (context, widget) {
            return FutureBuilder(
              future: context.read<DataProvider>().updateData(),
              builder: (BuildContext context, AsyncSnapshot<dynamic> snapshot) {
                return SafeArea(
                  child: Scaffold(
                    body: snapshot.hasData ? widget : Container(),
                  ),
                );
              },
            );
          },
        ),

Inside the updateData() function of the DataProvider I make use of the EasyLoading functions.
This is an issue only when the app first loads, on other pages it seems to work.

I solved this by changing the builder in my MaterialApp to something like this:
builder: (context, widget) {
        return EasyLoading.init()(
          context,
          FutureBuilder(
            future: context.read<DataProvider>().updateData(),
            builder: (BuildContext context, AsyncSnapshot<dynamic> snapshot) {
              return SafeArea(
                child: Scaffold(
                  body: snapshot.hasData ? widget : Container(),
                ),
              );
            },
          ),
        );
      },

In short:
builder: (context, widget) {
    return EasyLoading.init()(context, YourWidgetThatUsesEasyLoading())
}


Create MoveDocument model and creation handler [delivers #158768207]

Description
In anticipation of building out the office document uploader, this creates a model that encapsulates a MoveDocument, which connects many types of (1 for now) Document to a Move.
Reviewer Notes
I added an index to the move_documents table to enforce uniqueness across move_id and document_id, but I didn't do anything special to handle that case gracefully. I don't expect the client to be implemented in a way that would lead to this happening, but this can be amended if that becomes a thing. Part of the reason I left it is to give more time to think about the right way to handle it. Do we return an error? Do we just return the MoveDocument that matches what they were trying to create?
Code Review Verification Steps

[ ] All tests pass.
[ ] Code follows the guidelines for Logging
[ ] The requirements listed in
Querying the Database Safely
have been satisfied.
[ ] Any migrations/schema changes also update the diagram in docs/schema/dp3.sqs
[ ] There are no aXe warnings for UI.
[ ] This works in IE.
Any new client dependencies (Google Analytics, hosted libraries, CDNs, etc) have been:

[ ] Communicated to @willowbl00
[ ] Added to the list of network dependencies

[ ] Request review from a member of a different team.
[ ] (TRIAL) Have the Pivotal acceptance criteria been met for this change?

References

Pivotal story for this change

We did talk about turning name into a typed enum, but @ntwyman also talked about how documents are supposed to be generic, which to me implies that the type enum should be on the MoveDocument. Otherwise document isn't that generic, it has to be one of a few things.


The sheet starts at wrong place if the content size changes dynamically

see the recording:
https://www.youtube.com/watch?v=py30LHdFwpM&feature=youtu.be

@molikto Can I get the code for browsing photos and videos smoothly like you have done?

@molikto please try the latest master and see if that resolves the issue

Should be fixed in v1.5.0, which is available on JCenter now


Have both html and text in messages

Currently for my package, linter-manager, I have my own custom views for messages.
However, some linters create messages using html that only works for this package's views.
Would it be possible to add an extra property to messages such as htmlText that could be used as an alternative to message html? Otherwise, is it possible to make having both html and text properties on a message valid?

I think a better solution would be for linter-manager to support both text and html attributes, it's super simple to support both. If you have any reasons not to, please do state them.
Here's how we do it https://github.com/atom-community/linter/blob/master/lib/ui/message-element.js#L65-L81

My issue with just supporting html is that people create these custom elements with only your views in mind. For the majority of custom elements, this is fine, but it isn't a guarantee.
I'd prefer having the choice of just displaying text since it's more reliable.

@benjaminRomano this way I mentioned above isn't really exclusive to custom elements, they work the same with normal divs like
someDiv = document.createElement('div') // or document.getElementById('someDiv')
if (message.html) {
  someDiv.appendChild(typeof message.html === 'string' ? document.createTextNode(message.html) : message.html)
} else if (message.text) {
  someDiv.textContent = message.text
}

This is simple DOM manipulation with JS, really, nothing related to custom elements here

I guess I misspoke, I meant custom styling more so than custom elements.
It seems like the chance of having the html break my view is very low, so I'll just support it.


Removed Project dependency from User component

Coverage decreased (-0.03%) to 88.56% when pulling ea2e1e3642d5052d854e820c016ede8c058bc4fc on refactor/remove-project-from-user into 3240cca9b81d1843b18cecb3930e66642c5311da on master.

Coverage decreased (-0.03%) to 88.56% when pulling ea2e1e3642d5052d854e820c016ede8c058bc4fc on refactor/remove-project-from-user into 3240cca9b81d1843b18cecb3930e66642c5311da on master.


FX Test

Did you want to keep this PR, @mvaligursky? 😄

yes I might get back to this one day.

yes I might get back to this one day.


Physical Web Chrome App

This PR contains the initial version on the Physical Web Chrome App. It supports currently only SSDP protocol. Please refer to chrome/README.md and SSDP PR for more details.

This client is ONLY SSDP so we're reluctant to check it in as it will cause confusion. If it were to also support BLE, we'd accept it.

Scott: How do we feel about just linking to user contributions like this, instead of merging them into this repo?
If we merge them into our repo, we should probably also support them, without understanding exactly how they are implemented.
I think we could create a page which links out to contributor apps like Louay's, and be clear that they aren't vetted.  Then we needn't worry as much about limitations.

I would agree. I'd be happy to link to this.

Thx @scottjenson @mmocny for your comments. Yes I can put it somewhere on our git and you can link to it. but let me first check if I can add mdns using the chrome.mdns API.
Regarding BLE, we need to wait until the required BLE chrome APIs for beacon scan are available.
PS: I see this app is more for experimentation purposes. For best user experience, it makes more sense to implement it as en extension that shows a (physical-web) icon as Browser Action, but the required chrome APIs (UDP, mdns, BLE) are not available for extensions.

Well Done!

Hello


Intermittent hangs

Firstly, thank you for sharing your work :heart:
Inside a tokio async main, I'm using it like this:
use futures_buffered::BufferedStreamExt;

let mut stream = framed_read_stream
    .map(|x| do_stuff(x))
    .buffered_ordered(4096);

while let Some(recvd) = stream.next().await {
}

It just seems to hang, like 80% of the time (i.e., 80% of the time I run the program). How do I debug this?

Curious.

Although it shouldn't matter here, there is a bug with BufferedOrdered I've just found where the size_hint is incorrec:
https://github.com/conradludgate/futures-buffered/blob/2384ae2170edfa32a0bf4b2ba116bcfce39dbae7/src/buffered/ordered.rs#L77

do_stuff creates a tx rx pair, spawns tasks into a rayon global thread pool giving it the tx, then returns the rx.
So stream is a Stream of Receivers.

I think I found a subtle race condition in the waker implementation. Just published a potential fix

Still stalls :(
Works with buffered(1) but you might expect that to work already.

Hmm. Unfortunate. I guess I'll keep digging


Time series

Can this be applied to a time series? So that each token will represent a different point in time, and within each token there will be all the embeddings for all the features in this single time event? And that padding token is a 'missing' time event.

Any time series solution that uses tranformers + numerical features?

Not sure that I understand the question

I mean, is there a similar solution to FFT, that is adapted to time series?

I am sure that there are projects with Transformer-like models for time series data, but I am not sure if there are specifically adaptations of FT-Transformer.
In fact, if you simply want to apply Transformer to your data as you described, I think the shortest path is to implement it yourself. Basically, you need to encode your data to the shape (batch_size, window_size, d_embedding) and pass it to rtdl.Transformer or even to the built-in implementation: link.
Regarding easy-to-use packages, I am not very familiar with the relevant ecosystem, but here is one of the recent Transformer-like models: https://github.com/yuqinie98/PatchTST At the beginning of README, there are some libraries mentioned. So maybe this project and those libraries can be a starting point for your search.

Feel free to reopen the issue if needed!


[Feature] Add an item to graph but exclude from pie

What problem does this feature solve?
Hello,
found your great and powerfull echart plugin, now i have to do a simple chart and i spend a lot of hours to find the right configuration but every solution i found have any problem :(
I use the default template for a pie with 4 lines with a graph below.
Now i want just to add one simple bar to show avg BUT the AVG has ben excluded from the pie me and a friend we can't find a working configuration :(
At least we working with a sourc.map and filter but the collors then are wrong, we are use defined colors but will not work and be overwritten =(
I hope anyone can help me =(
Thank you
What does the proposed API look like?
My code i tryed:
var myChart = echarts.init(document.getElementById('testchart')),
option = {
    // theme: 'dark', // not working how we can toogle darkmode ?
    legend: {
        data: ['LvL 3','LvL 4','LvL 5','LvL 6','AVG']
    },
    tooltip: {
      trigger: 'axis',
      showContent: false
    },
    dataset: {
      source: [
        ['horses', '9/23', '10/23', '11/23', '12/23', '1/24', '2/24'],
        ['LvL 3', 56.5, 82.1, 88.7, 70.1, 53.4, 85.1],
        ['LvL 4', 51.1, 51.4, 55.1, 53.3, 73.8, 68.7],
        ['LvL 5', 40.1, 62.2, 69.5, 36.4, 45.2, 32.5],
        ['LvL 6', 25.2, 37.1, 41.2, 18, 33.9, 49.1],
        ['AVG', 8.0, 7.3, 7.9, 8.6, 9.6, 9.6]
      ]
    },
    xAxis: { type: 'category' },
    yAxis: { gridIndex: 0 },
    grid: { top: '55%' },
    series: [
     {
        name: 'LvL 3',
        type: 'line',
        smooth: true,
        seriesLayoutBy: 'row',
        emphasis: { focus: 'series' }
      },{
        name: 'LvL 4',
        type: 'line',
        smooth: true,
        seriesLayoutBy: 'row',
        emphasis: { focus: 'series' }
      },{
        name: 'LvL 5',
        type: 'line',
        smooth: true,
        seriesLayoutBy: 'row',
        emphasis: { focus: 'series' }
      },{
        name: 'LvL 6',
        type: 'line',
        color: '#ee6666',
        smooth: true,
        seriesLayoutBy: 'row',
        emphasis: { focus: 'series' }
      },{
        name: 'AVG', // Show on the legend and graph (bottom) but not on the pie
        type: 'bar',
        color: 'pink', // color in pie is blue and not pink -,-
        smooth: true,
        seriesLayoutBy: 'row',
        emphasis: { focus: 'series' },
        label: {
          show: true,
          position: 'top',
          valueAnimation: true
        }
      },{
        type: 'pie',
        id: 'pie',
        radius: '30%',
        center: ['50%', '25%'],
        emphasis: {
          focus: 'self'
        },
        label: {
          formatter: '{b}: {@9/23} ({d}%)'
        },
        encode: {
          itemName: 'horses',
          value: '9/23',
          tooltip: '9/23'
        },
      }
    ]
  };

myChart.on('updateAxisPointer', function(event){
  const xAxisInfo = event.axesInfo[0];
  if (xAxisInfo) {
    const dimension = xAxisInfo.value + 1;
    // const source = option.dataset.source.filter(row => row[0] !== 'AVG');
    // const newData = source.map(row => ({
    //   name: row[0],
    //   value: row[dimension]
    // }));

    myChart.setOption({
      series: [{
        id: 'pie',
        // data: newData
        label: {
            formatter: '{b}: {@[' + dimension + ']} ({d}%)'
        },
        encode: {
        value: dimension,
        tooltip: dimension
        }
      }]
    });
  }
});
myChart.setOption(option);

//   function initializePieChart(){
//     const initialDimension = 1;
//     const source = option.dataset.source.filter(row => row[0] !== 'AVG');
//     const newData = source.map(row => ({
//       name: row[0],
//       value: row[initialDimension]
//     }));

//     myChart.setOption({
//       series: [{
//         id: 'pie',
//         // data: newData
//       }]
//     });
//   }

//   initializePieChart();

You can use a second dataset for the bar series or specify the data for each series individually.
Example

You can use a second dataset for the bar series or specify the data for each series individually.
Example

Hello, thank you so much, best solution at the moment BUT as i said every solution has any problem.

If you hover a "date" the pie has to update to the curent date the mouse is on, it will not more work now =(
This was the update event and the pie has ben changed when mous was hover of a col (date)
myChart.on('updateAxisPointer', function( event ){
    const xAxisInfo = event.axesInfo[0];
    if( xAxisInfo ){
        console.log('info', xAxisInfo);
      const dimension = xAxisInfo.value + 1;

      myChart.setOption({
        series: {
          id: 'pie',
          label: {
            formatter: '{b}: {@[' + dimension + ']} ({d}%)'
          },
          encode: {
            value: dimension,
            tooltip: dimension
          }
        }
      });
    }
});

As i said, i want exactly the same from the default demo just add the bar without to pie, thats all and dont have working configuration :(
Maybe we can fix it, then would it perfect.
Its important i can see pie on the different data`s
Best regards
Stefan

You can use a second dataset for the bar series or specify the data for each series individually.
Example

Hello, thank you for your help, now i have a working configuration.
But i have a problem with colors, it i say, any problem exist always :(
Legende and lines are correct but the pie show wrong colors, maybe you can help me again to fix it, would love it.
Example


Remove TSDX

Codecov Report
Patch coverage: 88.88% and project coverage change: +6.85 :tada:

Comparison is base (e75a12b) 50.59% compared to head (b12dd31) 57.44%.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
Additional details and impacted files
@@            Coverage Diff             @@
##           master     #119      +/-   ##
==========================================
+ Coverage   50.59%   57.44%   +6.85%
==========================================
  Files          54       47       -7
  Lines         919      933      +14
  Branches      288      291       +3
==========================================
+ Hits          465      536      +71
+ Misses        449      397      -52
+ Partials        5        0       -5

Impacted Files
Coverage Δ

src/helpers/delay.ts
33.33% <0.00%> (ø)

src/helpers/enum-to-select-list.ts
20.00% <0.00%> (ø)

src/helpers/has-sub-array.ts
50.00% <0.00%> (ø)

src/helpers/image-file-to-base64.ts
16.66% <0.00%> (ø)

src/helpers/name-of.ts
100.00% <ø> (ø)

src/helpers/round-number.ts
8.33% <0.00%> (ø)

src/helpers/toggle-array.ts
10.00% <0.00%> (-1.12%)
:arrow_down:

src/helpers/global-exists.ts
50.00% <50.00%> (ø)

src/formatting/format-distance.ts
85.71% <85.71%> (-6.60%)
:arrow_down:

src/formatting/format-duration.ts
93.33% <93.33%> (ø)

... and 6 more

... and 8 files with indirect coverage changes

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


Testing slack bot events to our chatbot in Python

Issue: We are currently unable to receive the payloads from the Slackbot. We reached out to Slack Support via Feedback and Aubrey from the support desk executed a test and they notified us about below:
Your configured Event Subscriptions Request URL endpoint is not successfully acknowledging the Slack event callbacks meaning that even after receiving the event callback, your endpoint is not sending back the expected HTTP 200 status code, but rather it's sending back HTTP 403 which indicates that the callback requests were "Forbidden" so it seems that your endpoint is rejecting our event callbacks.
Goal: Our goal is for the slack events to be registered properly in the chatbot, currently we are not receiving it so we are also exploring other ways to be able to test this and identify what is wrong.
The slack_bolt version
slack==0.0.2
slack-bolt==1.6.0
slack-sdk==3.18.4
slackblocks==0.2.5
slackclient==2.7.2
slackeventsapi==3.0.1
Python runtime version
Python 3.7.11
OS info
#1 SMP Sat Aug 27 02:44:20 EDT 2022
Problem: The chatbot does not seem to receive the payload from slack.
Current situation: Once we attempt to trigger an event, the chatbot remains the same saying "⚡Bolt App is Running"
What we have tried:
•	Reinstalling the application to ensure that all my changes were saved and were reflected properly in my Slack Environment
•	Testing the communication by curling through to the URL (it responded with challenge parameter).
•	Testing the communication by entering some text via DM / channel communication and opening the homepage.
Since we wanted to test the below events, we tried executing appropriate actions for these:

app_home_opened
message.channels
message.groups
message.im

For the items that the team asked us for earlier, it is included below:
•	Slack API ID: A043X1Y2MK6
•	URL of Slack Workspace: https://docomo-data-strategy.slack.com/
•	What event type are you expecting to get? We subscribed to below events. We wanted to try app_home_opened, message.im, message.channels, etc.
Requirements
Please read the Contributing guidelines and Code of Conduct before creating this issue or pull request. By submitting, you are agreeing to those rules.

Hi @jdimapilis02, thanks for asking the question.
First off, bolt-python's framework code can send any of 200, 401, 500 but it never sends 403 HTTP status responses. Thus, I cannot tell anything further from a bolt-python maintainer's perspective.
If your code built on top of bolt-python also does not respond with 403 at all, the only cause that I can think of is, perhaps, your load balancer, proxy, WAF(Web Application Firewall), or something equivalent in front of the bolt-python app process might be rejecting HTTPS requests from Slack. Here is a simple diagram that describes what I'm guessing:

Slack API server -(internet)-> Your public endpoint https://{your domain}/slack/events -> ??? -> bolt-python app server instance

I would suggest checking what's happening at the ??? part by adding more tracing logs on your infra. I hope this was helpful to you.


visualstudio2017: support upgrade scenarios

Use the VS Installer upgrade command.

This has been implemented for almost a year now.


⚠ ClamAV has degraded performance

In c77c677, ClamAV (https://spamassassin.apache.org/) experienced degraded performance:

HTTP code: 200
Response time: 68 ms

Resolved: ClamAV performance has improved in 754947e.


Create 2015-02-04-open-data-camp.md

Open Data Camp sponsorship press release

Also removes photo competition from the front page.
@giacecco can you sanity check and merge? Comms are lined up to promote the sponsorship announcement.


Persistent subscription: ACK issue

…mers

Please would it be possible to grant me write access to your repo, so I can push changes (specifically to merge in the latest changes to pin Poetry version to 1.5.1)?

Continuing the discussion in #8, there was a bug. For performance reasons, N/ACKs are sent to the server in batches and buffered in the client. However, in the scenario you expressed, the N/ACKs weren't being sent before the subscription exited, and so those N/ACKs weren't being sent at all. Hence subsequent consumers received events again. I've adjusted the code so that all remaining buffered N/ACKs are sent to the server when the subscription is stopped. The nice test you wrote now passes.
Many thanks for raising this issue. I'm sorry for the delay in responding, which was due to an extended summer break (cycling in Europe).

Thx for fixing it!

 These changes have just been published as version 0.18 (and 1.0b3):
https://pypi.org/project/esdbclient/0.18/
https://pypi.org/project/esdbclient/1.0b3/


Derive clone, hash, eq for KeyRange to allow it to be stored in a map.

Title.

Please rebase against the master branch.

Rebased


Title Style

This patch updates the title which gets a little bit more space while
using the available white-space more effective. This also protects
against overly long title which are ended in a horizontal ellipsis,
ensuring that they never get more than a single line.

Preview:

ensuring that they never get more than a single line.

If I try really hard, I can get the presenter names to slide below the title.

Sorry, that wasn't clear. I meant a single line per element. That title and author break into two lines is something I wanted to achieve (imaging a portrait mode smartphone later)


Utilizing a large number of streams

The wiki says:

Aeron assumes some operational conditions, such as:
Low number of Streams. As each Term is a buffer for the Media Driver, and a Stream has a number of terms, the number of assumed Streams is assumed to be less than 1000 or even less than 100.

What are some of the effects that we can expect to see if we start utilizing a large number of streams?
What if we have 100 streams? 500 streams? 1000 streams? 5000 streams?

The Sender has to linearly search over streams for sending the data and the subscribers will do similar when receiving data. The higher this number then the larger the latency.
I've seen customers run with 100s or even a 1000 streams and be happy with the results.


Streaming video output blur when moving camera with CameraX API

Hello there,
May I know if there're any possible way to prevent streaming video output blur when moving camera with cameraX api?
Thank

Hello,
If you only have that blur in the stream result you can try using a higher bitrate in prepareVideo method but if the blur is also in the preview you will need check your cameraX code because maybe the problem is related with your autofocus. You have a guide about bitrate here:
https://support.google.com/youtube/answer/2853702?hl=en

I have this problem only while streaming. So if i'm try using higher bitrate in prepareVideo method, it mean that it required fast internet connection. While I used high bitrate, streaming video output blur when internet connection is slow.

So what should I do when I have slow internet connection?
Do I have to set bitrate on fly?

Thank

You can't solve it. This is the way an encoder works.
If you have a low bitrate you will have that blur or pixelate while moving device.
setBitrateOnFly is used to avoid skip video frames using slow connections because lose a bit of quality is better than lose frames producing freezing.
The main idea about the bitrate is maintain all time as possible a good bitrate and reduce bitrate if the internet speed is slow to avoid freezing the stream. While you have a low bitrate you can notify to the user that internet connection is poor to know that the quality is reduced and should go to a site with good connection
You can reduce the bitrate using with H265 or AV1 (recommended H265 because AV1 is not available in most of devices) because this codec need a lower bitrate to get a good quality (you can reduce like 20-30% the bitrate and get a similar quality than H264 depend of you device codec implementation)

Okay thank you @pedroSG94. So If there're a way to choose encoder H265 as I use StreamBase Class? The idea is that we want to choose H265 if it's available if not we choose H264.
Thank

You can use H265 like this:
    rtmpCamera?.setVideoCodec(VideoCodec.H265)

If your device can't use H265 prepareVideo method return false

Remember that your media server need support H265

Okay thank you so much @pedroSG94.


sloped_curb=yes - is it really safe to assume kerb=lowered?

See https://github.com/openstreetmap/id-tagging-schema/blob/main/data/deprecated.json#L1451
Note that at least some values of sloped_curb are mapping to rather flush.
Is it safe to assume that sloped_curb=yes means kerb=lowered rather than for example flush?

I don't know how people applied this tag in every circumstance, but it felt safe to assume "sloped" means there's a slope involved and therefore these aren't flush by default. People added a few values like sloped_curb=at_grade that would seem to indicate kerb=flush, and iD accounts for them.
Since lowered and flush are both assumed to be wheelchair-accessible, and since wheelchair access is the main point of tagging these, and since updating these manually would require thousands of on-the-ground surveys, I'm confident in leaving the existing behavior even if it's not 100% accurate.


[Workspace] Avoid reloading already loaded manifests

This provides major win when there are shared dependencies in the
package graph.

@swift-ci please smoke test


Drop support for Swift 5.8

Motivation
We only support the last three Swift released versions which are at this time 5.9, 5.10 and 6.
Modification
This PR drops anything related to Swift 5.8.
Result
Version support aligned.

@glbrntt I kept the _scheduleCallback underscored since there is another scheduleCallback method on EL already that would conflict otherwise. That methods actually calls the underscored method.


How can I preload Todos while only selecting username?

Your Question
am trying to preload todos while only selecting username from the user doing this query:
type User struct {
   gorm.Model
   Username string
   Name     string
   Todos    []Todo
}
users := new([]User)
db.Preload("Todos").Select("username").Find(users)

am only getting the username and not the Todos, am not sure if this is a bug or the intended behavior for gorm.

The document you expected this should be explained

Expected answer
I expect the way to get the preload Todos while still only selecting Username.

I had to select the foreign key of the relation, it works like expected, am closing this issue.


comp(buttons) Fixed disabled buttons module tests

added fakeAsync and tick calls to force change detection work in tests

Codecov Report

:exclamation: No coverage uploaded for pull request base (development@8f4a9d4). Click here to learn what that means.

@@              Coverage Diff               @@
##             development    #1604   +/-   ##
==============================================
  Coverage               ?   85.14%
==============================================
  Files                  ?       85
  Lines                  ?     2323
  Branches               ?      299
==============================================
  Hits                   ?     1978
  Misses                 ?      245
  Partials               ?      100

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 8f4a9d4...43163dc. Read the comment docs.

Awesome


"psp std demo" notebook example does not work

Executing the first line in file psp-std.ipynb fails in Jupyter notebook:
interpreter.init("-Yno-imports", "-Yno-predef")
The error output is:
Main.scala:24: value init is not a member of ammonite.api.Interpreter
Obviously, it seems that interpreter object does not expose init method (anymore).
The environment into which jupyter-scala was installed is WinPython <IP_ADDRESS> 64-bit under Windows 10 Pro 64-bit.

I'm on it, that should be fixed in ammonium. That was lost in the recent big update.

Closing, as the upcoming version is around the corner (currently on the develop branch).


v2.3 service failing to start. Complaining about SQL Alchemy.

First, help us help you by providing the following information when opening an issue.

[2.3] Which version of Forseti Security you're using (look in google/cloud/security/__init__.py in your installation).
[forseti-security ] Which module(s) (inventory, scanner, enforcer, explain) you're having trouble with.

Can you log into the VM (assuming server) and try to do the following?  Please let me know if that works.
pip install SQLAlchemy

If that works, then please restart your VM again.
I have tested this on my end and it works, as well as rebooting my VM.  It should install version 1.2.12.


Fix data transformer integration

Closes #2588
Introduced changes

Previous data transformer integration used --calldata argument (along with the old serialized input) and used () to indicate data used for transformation. () are special characters in bash so it did not work in most shells, requiring wrapping in '' anyway. This PR changes this integration so data for transformation is passed as a single string to a new --arguments argument and doesn't require any special wrapping.

Changed the syntax of data transformer so it works better with shells
Introduced new --arguments argument to sncast to distinguish data transformation
Fixed support for shortstrings in data transformer
Added tests using .sh scripts for data transformation

Checklist

[x] Linked relevant issue
[x] Updated relevant documentation
[x] Added relevant tests
[x] Performed self-review of the code
[x] Added changes to CHANGELOG.md

Could you also provide a more granular description on what has been changed and what was causing the problem?

@franciszekjob Added to description.


[Analytics-Data] Oauth2 Authentication

Hi,
We can use already authorised oAuth2 credentials for Analytics Reporting API v4 or v3 with this GA4 property data fetch?
Or we need to use service account strictly?
Thanks,

Moved from https://github.com/googleapis/php-analytics-data/issues/4
cc @chiragvels

The following seems to work for oAuth authentication wise:
        $client = new \Google\Analytics\Data\V1beta\BetaAnalyticsDataClient([
            'credentials' => \Google\ApiCore\CredentialsWrapper::build([
                'keyFile' => [
                    'type' => 'authorized_user',
                    'client_id' => $clientId),
                    'client_secret' => $clientSecret,
                    'access_token' => $accessToken,
                    'refresh_token' => $refreshToken,
                    'scopes' => \Google\Analytics\Data\V1beta\BetaAnalyticsDataClient::$serviceScopes,
                ]
            ])
        ]);

Still working on getting the first report to show up though...

Hi @Mark-H ,
Ok, Let me try when time permits.
May be you have pointed to same #3975 issue. Or Is there any docs as well?
Thanks,

Whoops - meant to link to this PR instead: https://github.com/googleapis/php-analytics-data/pull/2. Long night. ;)
Here's a sample (app-specifics redacted) of how I got it working. And yes, v3 oauth tokens are valid for v4 too.
First creating an OAuth2 instance with as much relevant tokens as are available that'll be used in different places:
use Google\Auth\OAuth2;

public function getOAuth2 ()
{
        $this->OAuth2 = new OAuth2([
            'scope' => 'https://www.googleapis.com/auth/analytics.readonly',
            'tokenCredentialUri' => 'https://oauth2.googleapis.com/token',
            'authorizationUri' => 'https://accounts.google.com/o/oauth2/auth',
            'redirectUri' => 'urn:ietf:wg:oauth:2.0:oob', // I'm using "offline"/"out of band" oauth, so this asks the user to copy/paste the auth code back into the app, this may also be a full whitelisted URL to redirect back to your oauth login
            'clientId' => $clientId,
            'clientSecret' => $clientSecret,
        ]);

        // If the scope doesn't already have the refresh token, but we do have it, set it
        if (!$this->OAuth2->getRefreshToken()) {
            $refreshToken = $refreshToken;
            if (!empty($refreshToken)) {
                $this->OAuth2->setRefreshToken($refreshToken);
            }
        }

        // If the scope doesn't already have the access token...
        if (!$this->OAuth2->getAccessToken()) {
            // If we have it in cache and it's the right (array) format, set it
            $accessToken = ... get access token from cache or session or something...
            if (is_array($accessToken)
                && array_key_exists('access_token', $accessToken)
                && !empty($accessToken['access_token'])
            ) {
                $this->OAuth2->updateToken($accessToken);
            }
            // If we don't have the access token, but we do have a refresh token, fetch a new auth token
            elseif ($this->OAuth2->getRefreshToken()) {
                $accessToken = $this->OAuth2->fetchAuthToken();
                // ... write it to cache or session or something ...
            }
        }
        return $this->OAuth2;
}

And using those credentials for running a minimal report and parsing that into a somewhat usable associative array structure dumped to screen:
use Google\Analytics\Data\V1beta\BetaAnalyticsDataClient;

public function run()
{
        $oauth = $this->getOAuth2();
        $client = new BetaAnalyticsDataClient(['credentials' => $oauth]);
        $property = '123456789';

        $response = $client->runReport([
            'property' => 'properties/' . $property,
            'dateRanges' => [
                new DateRange([
                    'start_date' => '28daysAgo',
                    'end_date' => 'today',
                ]),
            ],
            'dimensions' => [
                new Dimension([
                    'name' => 'date',
                ])
            ],
            'metrics' => [
                new Metric([
                    'name' => 'sessions',
                ]),
                new Metric([
                    'name' => 'screenPageViews',
                ]),
            ],
            'orderBys' => [
                new OrderBy([
                    'dimension' => new DimensionOrderBy([
                        'dimension_name' => 'date'
                    ])
                ])
            ]
        ]);

        $metricHeaders = [];
        $dimensionHeaders = [];
        $data = [];

        /** @var \Google\Analytics\Data\V1beta\MetricHeader $metricHeader */
        foreach ($response->getMetricHeaders() as $metricHeader) {
            $metricHeaders[] = $metricHeader->getName();
        }

        /** @var \Google\Analytics\Data\V1beta\DimensionHeader $dimensionHeader */
        foreach ($response->getDimensionHeaders() as $dimensionHeader) {
            $dimensionHeaders[] = $dimensionHeader->getName();
        }

        /** @var \Google\Analytics\Data\V1beta\Row $row */
        foreach ($response->getRows() as $row) {
            $rowData = [];

            /** @var \Google\Analytics\Data\V1beta\DimensionValue $dimensionValue */
            foreach ($row->getDimensionValues() as $idx => $dimensionValue) {
                $rowData[$dimensionHeaders[$idx]] = $dimensionValue->getValue();
                print $dimensionValue->getValue() . ' => ';
            }

            /** @var \Google\Analytics\Data\V1beta\MetricValue $metricValue */

            foreach ($row->getMetricValues() as $idx => $metricValue) {
                $rowData[$metricHeaders[$idx]] = $metricValue->getValue();
                print '[' . $metricHeaders[$idx] . '] ' . $metricValue->getValue() . ' ';
            }

            $data[] = $rowData;
            print PHP_EOL;
        }

        var_dump($data);
}

As my use case lets a user choose the profile to show reports for, it's also using the google/analytics-admin package to access accounts and GA4 properties. This re-uses the same OAuth2 object and doesn't require other scopes or anything.
        $admin = new AnalyticsAdminServiceClient(['credentials' => $oauth]);

        /** @var \Google\Analytics\Admin\V1alpha\AccountSummary[] $summaries */
        $summaries = $admin->listAccountSummaries();
        foreach ($summaries as $summary) {
            print $summary->getDisplayName() . PHP_EOL;

            /** @var \Google\Analytics\Admin\V1alpha\PropertySummary[] $properties */
            $properties = $summary->getPropertySummaries();
            foreach ($properties as $property) {
                $propNum = substr($property->getProperty(), strlen('properties/'));
                print "\t- " . $property->getDisplayName() . ' [' . $propNum . ']' . PHP_EOL;
            }
        }

I haven't finished upgrading the authorization step yet (this is an upgrade from the previous API so I already had a valid refresh_token to use and it was really late last night), but from what I've gathered so far that'll start with creating the auth url:
$oauth = $this->getOAuth2();
$authUrl = $oauth->buildFullAuthorizationUri();
// ... redirect to authUrl/open in a popup from the client side

Then providing the code to the oauth object and calling fetchAuthToken which will exchange the code for a refresh and access token available via their setters to persist somewhere in the app.
$code = $_POST['code'];
$oauth = $this->getOAuth2();
$oauth->setCode($code);
$credentials = $oauth->fetchAuthToken();
// save $credentials['access_token'] and $credentials['refresh_token'] somewhere in the app

I have no idea if this is all the officially recommended approach as the documentation is spotty at best, but it does seem to work.

I think this is answered now. closing


Support for Runtime Descriptor Arrays

Depends on https://github.com/vulkano-rs/vulkano/pull/1680
* Entries for Vulkano changelog:
    - **BREAKING** BufferAccess now requires Send + Sync. This cascades into TypedBufferAccess, BufferSlice, ImmutableBufferInitialization, ImmutableBuffer, DeviceLocalBuffer, CpuBufferPoolSubbuffer, CpuBufferPoolChunk, CpuAccessibleBuffer, and BufferView now requiring their types to be Send + Sync
    - **BREAKING** Descriptor sets reworked to allow for runtime arrays
        - e.g. `layout(set = 0, binding = 0) uniform sampler2D textures[];`
        - **BREAKING** `PersistentDescriptorSet` has been rewritten & `FixedSizeDescriptorSetsPool`  has been replaced by `SingleLayoutDescSetPool`.
            - These two sets are built internally from the same builder. This builder differs from the previous implementation.
                 - Methods now return `&mut Self` instead of `Self`.
                 - Methods now take values wrapped in an `Arc` instead of a plain trait.
                 - Builder type remains the same through the entire build process allowing for conditional building.

This pull request replaces the current descriptor set creation. PersistentDescriptorSet & FixedSizeDescriptorSetsPool. to allow for runtime arrays. e.g. layout(set = 0, binding = 0) uniform sampler2D textures[];

If you have some idea of what a common length is, you can always use SmallVec instead of Vec.

Did some testing with SmallVec it seems to be much slower if you account for a sensible limit to what a user might have in a set. My testing included 8 possible bindings and 32 total writes. The test case my tidal app caldera with basalt has 4 bindings, with the variable one having 2 currently.
Doing some pre-calculations with the context provided having Vec use with_capacity where possible yielded the best results. I personally have nothing against using Vec. In my testing the latest commit improves performance about 13% over the previous. Using SmallVec in place of Vec decreased performance by 223%. It should be worthy of note that this isn't a considerable amount of time to begin with. Previous commit took on average 5.9 microseconds whereas the current commit takes 5.1 microseconds. The SmallVec implementation took 13.2 microseconds.
I have it so when the user starts the builder they can specify the variable array capacity as a hint. Nothing bad happens if you go over that currently, but I am thinking ahead to when I do the pool implementation. If the user provides a capacity should it be an error if it goes over? I currently have the partial bound flag enabled which would allow us to allocate the capacity for each set and therefor have a consistent size and should in theory reach the same performance as fixed size set.
In the case of the user not specifying a capacity it could start off with say 8 and if the next allocation requires more it'd increase a power of 2 say for example. This would allow the user to not have to think about capacity and still be somewhat efficient in set reuse.

Interesting and surprising! Maybe the use of SmallVec in other parts of Vulkano ought to be re-evaluated at some point then!

I think at one point in time SmallVec may have been faster in Rust's earlier days where optimization may have not been as good, but now days the compiler is probably pretty good at keeping things on the stack. This is beyond my level of comprehension though and maybe other cpu's could be different. This is using a ryzen 5600x.
One area to look at would be vulkano/src/descriptor_set/sys.rs:
        let mut buffer_descriptors: SmallVec<[_; 64]> = SmallVec::new();
        let mut image_descriptors: SmallVec<[_; 64]> = SmallVec::new();
        let mut buffer_views_descriptors: SmallVec<[_; 64]> = SmallVec::new();

        let mut raw_writes: SmallVec<[_; 64]> = SmallVec::new();
        let mut raw_writes_img_infos: SmallVec<[_; 64]> = SmallVec::new();
        let mut raw_writes_buf_infos: SmallVec<[_; 64]> = SmallVec::new();
        let mut raw_writes_buf_view_infos: SmallVec<[_; 64]> = SmallVec::new();

For most cases that is a lot of extra allocation.

Implementation of the pool is now complete.

Pool creation takes runtime_array_capacity argument used as the base capacity for the runtime array descriptor.

UnsafeDescriptorPool creation uses a layout where the array_count member of DescriptorDesc for the runtime arrray desc or variable count descriptor is set to the runtime_array_capacity.

If a set is built where the array_count of the runtime array exceeds the runtime_array_capacity used to create UnsafeDescriptorPool then the runtime_array_capacity is multiplied by two until it is able to fit this new count and a new pool is created.
If a set is built and there are no available sets from the UnsafeDescriptorPool, then UnsafeDescriptorPool is recreated where the max_sets is equal to double the previous.

This pool implementation is specific to a layout similar to the fixed size pool implementation. In my testing creating a set from the runtime pool instead of a persistent runtime set is about 27% faster. (4.55 microseconds versus 6.21 microseconds also with much less jitter in timing)

It may be worth reviewing if this new runtime variant should replace the existing PersistentDescriptorSet and FixedSizeDescriptorSetsPool as the performance may be on par or better. This would be breaking however but would remove some similar code, so less upkeep. The new builder style returns an &mut instead of self. Also the builder takes values contained inside of an Arc instead of a reference. This is more favorable for having conditional building as it removes the weird type wonkyness.

I assumed that your new version would replace the old one eventually. Other than compatibility, what reasons can you think of for having both?

I thought originally it'd be slower than the existing implementation, but it seems it may be faster possibly. Also the time here seems pretty negligible.
In the latest commit for adding support for buffer views I had to make some breaking changes. BufferAccess now requires Send + Sync. This cascades into TypedBufferAccess, BufferSlice, ImmutableBufferInitialization, ImmutableBuffer, DeviceLocalBuffer, CpuBufferPoolSubbuffer, CpuBufferPoolChunk, CpuAccessibleBuffer, and BufferView now requiring their types to be Send + Sync. This change was required for how this implementation stores resources. I think publicly for people using vulkano provided types this isn't that breaking, but for someone implementing their own this could potentially be fairly breaking.

I think things are mostly finalized aside from removal of the old implementations. I am keeping these here for now as I plan to do some performance regression testing tomorrow.
@Rua have any thoughts possible improvements or anything that is out of spec? I think everything should good spec wise.

I haven't looked in too much detail, but what's in the changelog seems ok. I notice a bit of inconsistency in the pool module, with the type named "DescriptorSetPool" but many docs and comments calling it "DescriptorSetsPool" with an extra s. Also, it may be worth noting in the documentation of either the module or the type, that a DescriptorSetPool is a convenience wrapper provided by Vulkano, and that it shouldn't be confused with a DescriptorPool, which is a raw Vulkan object type with a very different function.

Only found a single instance of DescriptorSetPool with an extra s. That is a good point about the name though. For someone coming from vulkan that may be confusing. I added some further clarification to the doc for DescriptorSetPool.
/// `DescriptorSetPool` is a convenience wrapper provided by Vulkano not to be confused with
/// `VkDescriptorPool`. Its function is to provide access to pool(s) to allocate `DescriptorSet`'s
/// from and optimizes for a specific layout. For a more general purpose pool see `descriptor_set::pool::StdDescriptorPool`.

I have thought about another name, but I think it'd just make it more confusing. Before it was FixedSizeDescriptorSetPool which in itself was a bit deceiving. There was nothing really fixed about it other than the layout being fixed.

There is some performance regression in the current state:
Old PersistentDescriptorSet                4.022 microseconds
FixedSizeDescriptorSetPool                 0.933 microseconds
New PersistentDescriptorSet Fixed Array    5.700 microseconds
New PersistentDescriptorSet Runtime Array  6.389 microseconds
DescriptorSetPool Fixed Array              4.971 microseconds
DescriptorSetPool Runtime Array            5.461 microseconds

Test Layout: 2 input attachments, array of 4 sampled images

latest commit avoids recreation of DescriptorSetLayout. This doesn't effect PersistentDescriptorSet, but does however improve performance of DescriptorSetPool. This still is 3x the time of the old FixedSizeDescriptorSetPool.
DescriptorSetPool Fixed Array    3.090 microseconds  38% improved from previous
DescriptorSetPool Runtime Array	 2.933 microseconds  46% improved from previous

To remove possible confusion and some name spacing issues with the current pool mod, thinking it'd be better to rename DescriptorSetPool. Possible names I could think of would be:

FixedLayoutDescriptorSetPool

May suggest the layout is truly fixed which isn't the case for runtime arrays. Those generate different layouts depending on capacity.

LayoutDependentDescriptorSetPool

Kind of weird if I am going to be honest. Would suggest that the Pool depends on the layout which I guess is sort of true.

LayoutOptimizedDescriptorSetPool

May suggest other layouts are supported, which is false.

LayoutDescriptorSetPool

Pretty generic yet, gets the point across that this pool implementation only uses an single layout.

SingleLayoutDescriptorSetPool maybe?

That seems to be better than any of my suggestions. I guess that is kind of a given when I say "LayoutDescriptorSetPool ... only uses an single layout"

I think things are mostly finalized here. The performance I think is decent unless you are wanting frame rates in excess of 100k which I think you'll become bound in other ways. I have yet to check the examples those might need some changes.

@AustinJ235 I will take a closer look today evening or tomorrow(bringing it into my project and do some tests too), but I don't want to block the PR merging too, so If you want to proceed please go ahead. Just a couple of briefly things that probably you noticed too:

Tests are failing. It looks like there are actual bugs in the code.
Is returning &mut instead of owned really necessary? Not too critical, but having owned values IMO was more convenient. Again, this is not a critical part, but anyway.
There is no example of descriptor arrays(did I miss something?). Would be nice to have one to demonstrate this new feature and show to the users on how to utilize it.
To the log entries I would also add a general description of the changes purpose("support of runtime descriptor arrays").

Tests are failing. It looks like there are actual bugs in the code.

Seems a merge brought in another test that used the old descriptor set.

Is returning &mut instead of owned really necessary? Not too critical, but having owned values IMO was more convenient. Again, this is not a critical part, but anyway.

This mimics how we build command buffers now. It makes building things conditionally easier i.e.
let mut builder = ...

for image in my_images {
    builder.add_image(image);
}

Users may find other ways to utilize this. It adds a couple lines of code. The alternative would be having an plural form of the functions, but this would then require the user to collect all their types which need to be generic. Say you have an array of different types of images, i.e. a StorageImage and an ImmutableImage you'd have to first cast them into Arc<ImageViewAbstract + ...> before adding them.

There is no example of descriptor arrays(did I miss something?). Would be nice to have one to demonstrate this new feature and show to the users on how to utilize it.

Runtime arrays work exactly the same as normal arrays in use.

To the log entries I would also add a general description of the changes purpose("support of runtime descriptor arrays").

I think it is better to break out the changes for this a bit more as it will help users migrating from previous versions.

I'll look into the regression. Not exactly sure how that happens as the new implementation copies a large amount of code from the previous.

The image_match_desc method in descriptor_set/builder.rs is basically a direct copy from the original which was changed in https://github.com/vulkano-rs/vulkano/pull/1680. The only things that differs is that the errors types are converted. I am guessing that is the original source of the regression.
Investigating the code now.

@Rua I think this regression should be solved in commit ae3e278; however, I did not test it.

Don't merge yet.... Seems things might be broken.

Issue is with binding descriptor sets, bind_descriptor_sets. The pipeline layout needs to contain the correct amount of descriptors for a set in other words it needs to use the DescriptorSetLayout from the created Set.
Available options I can think of:

Provide PipelineLayout::replace_descriptor(&self binding: u32, desc: Arc<DescriptorSetLayout>) -> PipelineLayout

Requires the user to recreate the pipeline layout before using bind_descriptor_sets if they are using runtime arrays. The one provided by pipeline.layout().descriptor_set_layouts() is invalid for this use case.

Remove pipeline_layout argument from bind_descriptor_sets() and make the DescriptorSet trait be able to provide the layout. This requires the descriptor set constructors to use the entire PipelineLayout with an binding index instead. This is how was previous done I believe. The old docs, which are actually still in place, describe that behavior.

This would artificially limit use of runtime arrays to one set.
Kind of quirky when it comes to which layout to use from which set in the backend.

Maybe the best? Set the descriptor count to the limit of the device for descriptors with variable count.

Is there memory implications of this?

Commit 42a0341 provides a solution.
I am not sure if it is the correct one. The ash version of DescriptorSetLayout now defines descriptor_count as the limit of the device for DescriptorDesc that are variable_count. I am unsure if this will lead to excess memory usage. Allocation of descriptor sets will still use a separate count provided by DescriptorSetLayout::descriptors_count, so memory usage isn't a concern allocation wise. This method will panic if the DescriptorSetLayout is created a variable_count DescriptorDesc that does not define its descriptor_count. This value defaults to 0 from vulkano-shaders. This should only be possible if the end user is implementing their own allocation and descriptor sets hence why I opt'd for an assert! in the descriptors_count method to check if this count is undefined.
Another point of concern is that the layout used for allocations and ultimately provided to sets is technically different from what is created in the pipelines and ultimately in the bind commands. These I would assume are compatible.

I'm not sure if I understand what's going on, but I'll try to say something useful anyway. As far as I can tell, DescriptorsCount is used for allocating descriptors from a pool. I'm not sure, but I assume that if you have a variable count, then the number of descriptors that's actually in a descriptor set will vary for each individual set, and not depend on the layout? If that's the case, then perhaps DescriptorsCount should become Option<DescriptorsCount>, or DescriptorsCount should only contain a minimum guaranteed count of descriptors, with the variable part left out and needing to be calculated from each descriptor set. The latter option means that as much of the work as possible counting descriptors is done up front, and only the variable counts need to be calculated when creating a descriptor set.
In your example, you correctly enable the two features needed for this to work, but these features only became part of core Vulkan in version 1.2, and require an extension for earlier versions. When creating the instance, you specify 1.2, but this is a maximum (note the documentation!), so you're simply promising not to use any features above 1.2. Whether the device itself supports it is another matter, so when enumerating physical devices, you need to require that devices either have an api_version of least 1.2, or support the ext_descriptor_indexing extension (which you must then add to device_extensions).

I'm not sure if I understand what's going on, but I'll try to say something useful anyway. As far as I can tell, DescriptorsCount is used for allocating descriptors from a pool. I'm not sure, but I assume that if you have a variable count, then the number of descriptors that's actually in a descriptor set will vary for each individual set, and not depend on the layout? If that's the case, then perhaps DescriptorsCount should become Option<DescriptorsCount>, or DescriptorsCount should only contain a minimum guaranteed count of descriptors, with the variable part left out and needing to be calculated from each descriptor set. The latter option means that as much of the work as possible counting descriptors is done up front, and only the variable counts need to be calculated when creating a descriptor set.

This is a bit tricky how this all works.
Descriptors with a variable count act exactly the same as normal arrays do mostly (Aside from the extra pNext data in DescriptorSetLayout. This applies to layout creation, allocation, and binding. Both the persistent and the pool use the layout from the shader as a base. I have it so the descriptor_count coming from the shaders is set to 0. Obviously you can't figure this out at runtime, so setting it to zero basically inhibits creation of sets without recreating of the DescriptorSetDesc. Both the pool and persistent recreate DescriptorSetDesc. In the persistent variant this is a fixed count set exactly the length. And in the pool recreates this every time the capacity changes. The pool allocates all of the capacity each time and partially binds descriptors too it. It'll will automatically adjust the capacity if a set is to be created in length that exceed the capacity. This all works good and I believe works to spec; however the tricky part comes to binding. Normally the binding methods take the layout directly from shader. It is kind of odd that we create this layout at shader creation as "most" seem to do this at the same time as descriptor set creation. PipelineLayout ideally needs to be recreated whenever the capacity of a any set changes (actually it true length, capacity as I have been talking about it). I can't think of a way that makes this possible without some overhauling to how DescriptorSetLayout is handled overall. This would probably include removal of its creation in the ShaderModule and then be created at runtime along with descriptor sets.

In your example, you correctly enable the two features needed for this to work, but these features only became part of core Vulkan in version 1.2, and require an extension for earlier versions. When creating the instance, you specify 1.2, but this is a maximum (note the documentation!), so you're simply promising not to use any features above 1.2. Whether the device itself supports it is another matter, so when enumerating physical devices, you need to require that devices either have an api_version of least 1.2, or support the ext_descriptor_indexing extension (which you must then add to device_extensions).

I believe this only really works well with vulkan 1.2, so I think we'd go that route. I think the extension may work, but I believe there are some quirks with it. Didn't know that was the maximum though, so yeah should probably check that then.

Obviously you can't figure this out at runtime, so setting it to zero basically inhibits creation of sets without recreating of the DescriptorSetDesc. Both the pool and persistent recreate DescriptorSetDesc.

This part I don't understand. Why do you need to recreate DescriptorSetDesc? What part of it are you changing? According to the spec, "VK_DESCRIPTOR_BINDING_VARIABLE_DESCRIPTOR_COUNT_BIT indicates that this descriptor binding has
a variable size that will be specified when a descriptor set is allocated using this layout. The
value of descriptorCount is treated as an upper bound on the size of the binding." Note that the tweak method is explicitly used for aspects of a descriptor set layout that can't be inferred from shaders, but must be provided explicitly by the user. Currently this includes specifying which buffers are dynamic, but this upper bound is definitely also one of these things. I suggest renaming tweak to set_dynamic_buffer, and add a set_variable_descriptor_count(binding: u32, descriptor_count: u32) method. This can be used by the user to explicitly set descriptor count, and should error out for non-variable bindings.

PipelineLayout ideally needs to be recreated whenever the capacity of a any set changes (actually it true length, capacity as I have been talking about it). I can't think of a way that makes this possible without some overhauling to how DescriptorSetLayout is handled overall.

Does this relate to the same stuff as above? Recreating pipeline layouts definitely seem excessive, and I don't know what in Vulkan actually requires it.

@AustinJ235 ah, sorry I missed to check provided example. And it is failing on my machine:
Using device: AMD RADV VEGAM (LLVM 10.0.0) (type: DiscreteGpu)
thread 'main' panicked at 'internal error: entered unreachable code', vulkano/src/descriptor_set/pool/standard.rs:125:67

A panic is happening on descriptor set creation unwrapping exactly: let set = Arc::new(set_builder.build().unwrap());

@Rua

DescriptorSetDesc now has set_variable_descriptor_count method.
DescriptorSetLayout is no recreated within the pool or persistent.
When building a set the length must not exceed descriptor_count, but does not need be the correct length. (runtime arrays only)

I however did not rename the tweak method. Kind of seems like a needless breaking change? Although the name is sort of misleading.

Looks good! Does that solve the issues you were having?

@Rua I mean the commit before did solve it, just in a brute force way... 🤣. I will say this feels more in line to what it should be. I still think creating a PipelineLayout manually is still ugly. Perhaps in the future we could create a builder, but I think this is probably outside the scope of this pull request.

The GraphicsPipelineBuilder::with_auto_layout function takes a list of dynamic buffer indices that are then passed to the tweak method. This same principle could be applied to variable counts as well. That way, the builder does it for you automatically and you don't have to be creating pipelines manually. But instead of adding more and more parameters to the function for each kind of "tweak", I wonder if there's a generic solution that could work for any number of tweaks. Perhaps something with a user-provided closure that gets fed with &mut [DescriptorSetDesc] and can then make whatever tweaks it likes.

@Eliah-Lakhin I think this should work on your system now. The panic you were getting is suppose to be unreachable code, but I think the brute force method didn't fair your device well...
@Rua I was think more along the lines of something like this:
PipelineLayoutBuilder::start(...)
	.add_entry_point(vs.main_entry_point())
	.unwrap()
	.add_entry_point(fs.main_entry_point())
	.unwrap()
	.set_dynamic_buffers(0, 0, buffers)
	.unwrap()
	.set_variable_desc_count(1, 0, 4)
	.unwrap()
	.build()
	.unwrap()

add_entry_point would add all the shaders entry points you'd be using for this layout, you might not bind every descriptor in each shader (kind of awkward to merge these manually). The builder would make sure these shaders are compatible in terms of binding. The methods like set_dynamic_buffers and set_variable_desc_count would take a set number, and a binding number.

@Eliah-Lakhin This is ready for merge, I just want to make sure you don't have issues yet. I was unable to reproduce the issue on the commit that you had the issue on. I think it was just the brute force fix, but I am not sure.
This pull request works as intended on my systems:

AMD Frontier Edition on Void Linux (Kernel 5.13 with RADV)
Nvidia RTX 3060 Ti on Windows 11 (Build 22000)

@AustinJ235 Thank you for fixing it. Yes, your fix resolved the issue on my end too. All works fine. This is ready for merge. :+1:

@Eliah-Lakhin what about the issues I pointed out?

@Rua, @AustinJ235  Do you think guys, it would be reasonable to address these issues in dedicated PR?

I'm ok with making a separate PR for it.

@AustinJ235 why did you add the Send + Sync requirement to BufferAccess in this PR?

@Rua I believe I tried to work around this, but I couldn't find a solution to keeping the trait as is. Can't remember the specifics of it, but ultimately it led to BufferAccess requiring Send + Sync. Is there a usage out there that this change would break?

Since this PR requires an Arc around its resources, I was thinking about making that a general requirement across Vulkano. I wondered if the Send + Sync requirement was a part of that. But I realise now that ImageViewAbstract didn't require Send + Sync in your PR, so there must be some other reason?

Think there was some quirkiness with BufferView that required BufferAccess to have Send + Sync. Noteworthy though is that I require Send + Sync with ImageViewAbstract provided, so one you could simply have that trait require that. I think most of the code ultimately assumes it to be Send + Sync as requirement. Even in the previous state of vulkano, is it even possible to have an image or a buffer not be Send + Sync and then use it?
I am most certainly not against a change to make this a requirement and in fact it probably should be done anyways. Vulkan itself is inherently multithreaded.


The PHP_INI_SCAN_DIR can be set to multiple directories (it breaks run script)

When trying to include custom directory within a source which include the custom .ini file, users have to set the PHP_INI_SCAN_DIR=/opt/app-root/src/php:/etc/opt/rh/rh-php56/php.d
This is supported by PHP and works, problem is this line in the run script: https://github.com/openshift/s2i-php/blob/master/5.6/s2i/bin/run#L22
this will explode and opcache will not be saved... however the httpd will run ;-)

If pr #96 is merged,  It seems simpler and consistent to use default value to ":/opt/app-root/etc/php.d" and drop this line (and save 10-opcache.ini  there)

So:
export PHP_INI_SCAN_DIR=${PHP_INI_SCAN_DIR:-:/opt/app-root/etc/php.d}

envsubst < /opt/app-root/etc/php.ini.template > $PHPRC
envsubst < /opt/app-root/etc/php.d/10-opcache.ini.template > /opt/app-root/etc/php.d/10-opcache.ini

@remicollet I will make the fix to run script in #96


Add PyPy2 v5.4.1

👍

Thanks! I'll wait to merge this until I'm ready to build and push it up into production — shouldn't be long!

I've updated the pypy version to the v5.4.1 bugfix release

I've updated the pypy version to the new v5.6.0 release
v5.6.0 includes the upstream stdlib from CPython 2.7.12 (was previously 2.7.10)

Thanks! I plan to do this week.

released!


Gap in code blocks in 0.27.0 with Starlight

In trying to update in this PR, the code blocks in the preview have a margin between the frame header and the content.

This is a Starlight-specific issue that is created by this Starlight CSS rule (taken from your preview) that introduces margins between adjacent siblings:
.content:where(.astro-ml6ntd6l) :not(a,strong,em,del,span,input,code)+:not(a,strong,em,del,span,input,code,:where(.not-content *)) {
    margin-top: 1.5rem;
}

You can see the fix for this behavior in my PR to add Expressive Code to Starlight:
https://github.com/withastro/starlight/pull/742/files#diff-beb0bce82b7f4b09c96906f85bed4c5ff5f3968064121f03ae605f8b06295c58R53-R60
In short, we need to add the CSS class not-content to the rendered blocks to avoid the adjacent sibling margin rule from matching.
Until the Starlight integration PR has been merged, you can add the same trick to your astro.config.mjs:
import { default as expressiveCode, addClassName } from 'astro-expressive-code';

// (your other code)

/** @type {import('astro-expressive-code').AstroExpressiveCodeOptions} */
const expressiveCodeOptions = {
  theme: ["github-light", "github-dark"],
  frames: {
    removeCommentsWhenCopyingTerminalFrames: true,
  },
  plugins: [{
    name: 'Starlight Plugin',
    hooks: {
      postprocessRenderedBlock: ({ renderData }) => {
        addClassName(renderData.blockAst, 'not-content');
      },
    },
  }],
};

Just a note on why this is happening since v0.27: Previous versions of Expressive Code used CSS selectors of higher specificity to style the code blocks.
While the old CSS selectors included a dynamic hash and looked like .ec.ec-s1gwf .frame, the new selectors don't need this hash anymore - they are now static and look like .expressive-code .frame, which is one class selector less than before. This seems to be the reason why the Starlight adjacent sibling margin selector now "wins" and interferes with the code block styling.
I could theoretically add a second (static) class back in again to counteract this, but I wanted to first see if the not-content solution works well enough.

This is fixed now with the release of Starlight v0.13 (how to update). You can have at the release notes to see how to migrate your Expressive Code configuration into the new integration built into Starlight.


Product Pages: Fix the implementation of menu options block

Currently there are multiple restaurants which have different columns in the menu options block.
They can have 2, 3, 4, or 5 columns.
Figure out a way to handle all the edge cases.

also this error in the browser console
failed to load module for menu-options DOMException: Failed to execute 'replaceChild' on 'Node': The node to be replaced is not a child of this node.     at http://localhost:3000/caesars-palace/blocks/menu-options/menu-options.js:15:17     at NodeList.forEach (<anonymous>)     at http://localhost:3000/caesars-palace/blocks/menu-options/menu-options.js:14:14     at Array.forEach (<anonymous>)     at Module.decorate (http://localhost:3000/caesars-palace/blocks/menu-options/menu-options.js:10:6)     at http://localhost:3000/caesars-palace/scripts/lib-franklin.js:360:32


UVI Request

--- UVI JSON ---
{
  "vendor_name": "Linux",
  "product_name": "Kernel",
  "product_version": "versions from v2.6.30 to before v5.10.46",
  "vulnerability_type": "unspecified",
  "affected_component": "unspecified",
  "attack_vector": "unspecified",
  "impact": "unspecified",
  "credit": "",
  "references": [
    "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=bdbe6fbc6a2f2ccfb384b141b257677d2a8d36fb",
    "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=5946fbf48355f5a8caeff72580c7658da5966b86"
  ],
  "extended_references": [
    {
      "type": "commit",
      "value": "bdbe6fbc6a2f2ccfb384b141b257677d2a8d36fb",
      "note": "introduced"
    },
    {
      "type": "commit",
      "value": "5946fbf48355f5a8caeff72580c7658da5966b86",
      "note": "fixed"
    }
  ],
  "reporter": "joshbressers",
  "reporter_id": 1692786,
  "notes": "",
  "description": "net: rds: fix memory leak in rds_recvmsg\n\nThis is an automated ID intended to aid in discovery of potential security vulnerabilities. The actual impact and attack plausibility have not yet been proven.\nThis ID is fixed in Linux Kernel version v5.10.46 by commit 5946fbf48355f5a8caeff72580c7658da5966b86, it was introduced in version v2.6.30 by commit bdbe6fbc6a2f2ccfb384b141b257677d2a8d36fb. For more details please see the references link."
}
--- UVI JSON ---

This issue has been assigned UVI-2021-1000978


Support creating dictionary at runtime for an existing column

OSS issue: https://github.com/apache/pinot/issues/9348
Label: Feature
Document
With this PR, we add support to enable dictionary on a raw column for immutable segments during segment Reload. This support is added for both SV and MV columns.
Added Unit Tests. As the PR is being reviewed, I'm planning to add an integration test where we query on a column where dictionary is enabled.

Codecov Report

Merging #9678 (c2ba236) into master (63c6438) will decrease coverage by 0.30%.
The diff coverage is 81.00%.

@@             Coverage Diff              @@
##             master    #9678      +/-   ##
============================================
- Coverage     68.71%   68.41%   -0.31%
+ Complexity     4971     4881      -90
============================================
  Files          1939     1950      +11
  Lines        103671   104417     +746
  Branches      15727    15816      +89
============================================
+ Hits          71242    71441     +199
- Misses        27350    27869     +519
- Partials       5079     5107      +28

Flag
Coverage Δ

integration1
25.29% <0.00%> (-0.50%)
:arrow_down:

unittests1
67.50% <81.00%> (+0.12%)
:arrow_up:

unittests2
15.68% <0.00%> (+0.08%)
:arrow_up:

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

Impacted Files
Coverage Δ

...ocal/segment/index/loader/ForwardIndexHandler.java
83.14% <79.76%> (+12.14%)
:arrow_up:

...t/creator/impl/SegmentIndexCreationDriverImpl.java
81.52% <100.00%> (-0.20%)
:arrow_down:

...ocal/segment/index/loader/IndexHandlerFactory.java
100.00% <100.00%> (ø)

...ocal/segment/index/loader/SegmentPreProcessor.java
83.49% <100.00%> (+0.66%)
:arrow_up:

...pinot/core/data/manager/realtime/TimerService.java
0.00% <0.00%> (-100.00%)
:arrow_down:

...ent/creator/IntermediateSegmentStatsContainer.java
0.00% <0.00%> (-100.00%)
:arrow_down:

...lugin/stream/kafka20/KafkaStreamLevelConsumer.java
0.00% <0.00%> (-88.34%)
:arrow_down:

...data/manager/realtime/DefaultSegmentCommitter.java
0.00% <0.00%> (-80.00%)
:arrow_down:

...manager/realtime/HLRealtimeSegmentDataManager.java
0.00% <0.00%> (-74.08%)
:arrow_down:

...n/stream/kafka20/KafkaStreamLevelStreamConfig.java
0.00% <0.00%> (-68.75%)
:arrow_down:

... and 169 more

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more

Let's add e2e query execution tests as well (need not be in integration but one of the subclasses of BaseQueriesTest)

Decided to merge this in the interest of unblocking @somandal 's reload support work on https://github.com/apache/pinot/issues/6473
Main work is done here. @vvivekiyer is going to follow-up immediately with

More tests (Called out above)
Sorted column handling check


feat: add ability to specify application root

Add ability to specify a working directory for running electron-builder. Helps when developing an electron application inside a monorepo. Should be none breaking. First action contribution, open to suggestions on everything. Not sure how to test the script, would be willing to try and document process.

Looks good to me. Have you been able to test the action?


[feature] stdout writing

Adds support for setting the output to stdout.
Interface isn't great and is not very "UNIX"y, however, it works.
For example, you can specify output like this:
fluid-noveltyfeature -source infile.wav -features stdout

This will write the values out with commas inbetween them.

Why?
The major benefit of this format is that you don't need to manage, cleanup and parse an intermediary file if you have the CLI tools embedded elsewhere. My selfish reason is to remove those needs from ReaCoMa. It would also facilitate viewing results more easily in the terminal if you want to prototype there fast.

That seems relatively painless. Would suggest using -- as the marker for using std out, to be more unixy. And we should think about whether we'd want to enable input from stdin for pipey goodness.

That seems relatively painless. Would suggest using -- as the marker for using std out, to be more unixy. And we should think about whether we'd want to enable input from stdin for pipey goodness.

stdin is an idea! I think it would let you do, for example, ffmpeg -> flucomathing. In terms of using -- do you mean instead of stdout? AFAIK, and I am likely to be wrong here, -- signifies "don't read any more args" rather than stdout.


plugin install seems to be broken

Hi There, I have tryed to install via homebridge plugin install and it gets stuck at
"fetchMetadata: sill resolveWithNewModule @kiddkai/homebridge-xi"
Would you mind having a look please? i'd like to try it out.
Regards
Rob

Hey, I am no longer maintaining the plugin, I have been migrated to HA for quite a while. Feel free to fork the project and publish your own plugin.


Fix issue templates wrong directory name

Gotta love these things that can only be tested on the main brannch.

Isn't main protected?

Not from --force


FileOutput can't be imported in console app

I'm not sure what is happening. Can you include some console output, or some other indication of what exactly is not working?

Sorry, my bad. I'm unable to import FileOutput in my console Dart app. It's just not visible to me. Seems like it's not exported properly.

That doesn't sound right. Could you provide me with some minimal example showing the behaviour? Or some code snippets? Thanks!

Simply try to import FileOutput into your console app. That won't work.
Seems like the reason is in this line of logger.dart:
export 'src/log_output.dart'
    if (dart.library.io) 'src/outputs/file_output.dart';

I've looked into the issue and it is weird. I believe this has something to do with the Dart LSP server. The code as you wrote it works (but crashes because you didn't pass a File instance). Only the IDE is confused. I'm sure it has something to do with the conditional import but this seems a rabbit hole I'm unwilling to touch ATM.
The correct call would be final fileLogger = Logger(output: FileOutput(file: File('/tmp/sheep.log')));.
Lemme know if this works.

Hi all,
FileOutput is not found for me. This shows read, but Logger is fine. Weird:
  var logger = Logger(output: FileOutput(()));
Thanks.

I encountered this problem yesterday.  Reading around it seems to require a -D constant being set to activate the import.  It's unclear to me if this works in Dart 2.0.  I worked around the problem by importing the implementation file and living with the subsequent warning.

Same issue here, we ended up rolling with our own implementation which isn't great.

Same problem.


Updated documentation of the focus option from the modal component.

@cvrebert, did you get a chance to take a look at this PR? If you have any suggestions, I would be glad to take them into account :smile:


trinket slot doesnt work with BetterEnd's armored elytra

idk who's side it's on, posted an issue at the BetterEnd mod and they said not a vanilla slot->problem not on our side.
you can equip it in the trinket slot(shift clicking prioritizes it even), just cant actually open it(and with mods that show durability, doesnt even register as equipped)

Trinkets is a standard accessory api, other mods are responsible for providing compat if they desire it.


Grammar fix

PR will fix the grammatical error on reviews.md
What does this PR do?
"no extra cost you to" is grammatically incorrect
Change will add "at no extra cost to you" instead of the incorrect line
The change is grammatically appropriate for the sentence considered
You can check the correctness of the change using the link at no extra cost to you

Can you please add hacktoberfest accepted label, I am participating in Hacktoberfest 2021

I don't think this should count for Hacktoberfest, as it's just a minor change. 😅

As a beginner Open Source Contributor , even a small change has great importance at least for me , so I urge you to add the label


Closing the Theming Menu resets settings to defaults.

Closing the Theming Menu using the close button in the titlebar resets the theme to Core Foundry Theme rather than cancelling any changes and returning to the previously configured setting. This occurs even when a preset theme (such as Cobalt) is selected.

I actually know about this one, I will look into seeing what I can do to resolve it.

I was messing around with the code for Custom Nameplates and managed to introduce a similar glitch before by removing some lines of code in the nameplate-config.html file.
I gave up on the project fairly quickly as I realised it was above my level of complexity fairly early on, but the code seemed relatively simple. Looking at it might be able to help you figure out the sorts of calls that are available to fix the issue.
Alternatively Whetstone, which is a similar module to yours, manages this and was published under the MIT license, so in the best case scenario you may even be able to lift/borrow code directly from the project to resolve your issue.

I actually did some further testing of this earlier, it appears that it doesn't actually revert to the default setting at all, but rather it resets to whatever theme was set when the server was launched.
Perhaps simply refreshing the browser/window when a new setting is saved would resolve this bug as it doing so also seems to fix issue #4
Many other modules do this when important settings are changed and it seems to be a relatively quick and easy fix for two issues.


Add support for Helm Hub and Arftifactory Hub as distribution targets

Hey at all,
I think we could improve also the downloads of this helm chart. During under the current circumstances the stable repo
Phase 1

Create a place where your Helm chart can live for a longer time.
Probably a good idea is to use Github Pages for this case.
Publish your Helm Chart with an Automatic Workflow to your GitHub pages account.

For more information have a look at https://helm.sh/docs/topics/chart_repository/#github-pages-example
Phase 2
Publishing your Helm Repositories to popular places.
Helm Hub
Helm Hub

Do a Pull Request on https://github.com/helm/hub for contributing the questdb helm repo

Artifact Hub
The Artifact Hub is another place you can list your repos. To do that, you login (or create an account), create an organization, and list your repository. You can link it to a user or organization.

I agree with you, the visibility of our chart is not great, adding it to Helm Hub is a great idea.
I will look into this soon and keep this issue updated ;)

Update on this:
Phase 1:
Done. Documentation updated too, the PR is now pending.
Phase 2:
Currently working on it.

Update:

A PR is pending for Helm Hub: https://github.com/helm/hub/pull/445

https://artifacthub.io is currently processing our repository.
I will close this issue when both are finished.

see previous comment


Add implementation of - Fig 19.8  Minimal-Consistent-Det

Fig 19.8  Minimal-Consistent-Det

Original issue reported on code.google.com by<EMAIL_ADDRESS>on 23 Oct 2009 at 3:06

Resolved in #414.