TabBar tabs hover effect isn't clipping to container

Steps to reproduce
1: Create a Scaffold which contains a Row with a SizedBox(width: 100) and an Expanded TabBar which has isScrollable: true, and enough tabs to scroll, as the children
2: Scroll so the one of the tabs is half visible
3: Hover the mouse over the tab
Expected results
The Hover effect is clipped to the containing area
Actual results
The hover effect is still visible outside of the containing area.
Code sample
Code sample
import 'package:flutter/material.dart';

const Color darkBlue = Color.fromARGB(255, 18, 32, 47);

void main() {
  runApp(MyApp());
}

class MyApp extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      theme: ThemeData.dark().copyWith(
        scaffoldBackgroundColor: darkBlue,
      ),
      debugShowCheckedModeBanner: false,
      home: Scaffold(
        body: Center(
          child: MyWidget(),
        ),
      ),
    );
  }
}

class MyWidget extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return Row(
      mainAxisSize: MainAxisSize.max,
      children: [
        const SizedBox(width: 200),
        Expanded(
          child: DefaultTabController(
            length: 20,
            child: TabBar(
              isScrollable: true,
              tabs: List.generate(
                20,
                (index) => Tab(text: 'Tab Index $index'),
              ).toList(),
              tabAlignment: TabAlignment.start,
            ),
          ),
        ),
      ],
    );
  }
}

Screenshots or Video

Screenshots / Video demonstration

Flutter Doctor output
Doctor output
[√] Flutter (Channel stable, 3.16.5, on Microsoft Windows [Version 10.0.22621.2861], locale en-GB)
    • Flutter version 3.16.5 on channel stable at C:\tools\flutter
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision 78666c8dc5 (3 weeks ago), 2023-12-19 16:14:14 -0800
    • Engine revision 3f3e560236
    • Dart version 3.2.3
    • DevTools version 2.28.4

[√] Windows Version (Installed version of Windows is version 10 or higher)

[√] Android toolchain - develop for Android devices (Android SDK version 34.0.0)
    • Android SDK at C:\Users\lpick\AppData\Local\Android\sdk
    • Platform android-34, build-tools 34.0.0
    • Java binary at:
      C:\Users\lpick\AppData\Local\JetBrains\Toolbox\apps\AndroidStudio\ch-0\223.8836.35.2231.10406996\jbr\
      bin\java
    • Java version OpenJDK Runtime Environment (build 17.0.6+0-b2043.56-10027231)
    • All Android licenses accepted.

[X] Chrome - develop for the web (Cannot find Chrome executable at .\Google\Chrome\Application\chrome.exe)
    ! Cannot find Chrome. Try setting CHROME_EXECUTABLE to a Chrome executable.

[√] Visual Studio - develop Windows apps (Visual Studio Community 2019 16.11.17)
    • Visual Studio at C:\Program Files (x86)\Microsoft Visual Studio\2019\Community
    • Visual Studio Community 2019 version 16.11.32630.194
    • Windows 10 SDK version 10.0.19041.0

[√] Android Studio (version 2022.2)
    • Android Studio at
      C:\Users\lpick\AppData\Local\JetBrains\Toolbox\apps\AndroidStudio\ch-0\222.4459.24.2221.10121639
    • Flutter plugin version 75.0.1
    • Dart plugin version 222.4582
    • Java version OpenJDK Runtime Environment (build 17.0.6+0-b2043.56-9586694)

[√] Android Studio (version 2022.3)
    • Android Studio at
      C:\Users\lpick\AppData\Local\JetBrains\Toolbox\apps\AndroidStudio\ch-0\223.8836.35.2231.10406996
    • Flutter plugin version 76.3.2
    • Dart plugin version 223.8977
    • Java version OpenJDK Runtime Environment (build 17.0.6+0-b2043.56-10027231)

[√] VS Code (version 1.85.1)
    • VS Code at C:\Users\lpick\AppData\Local\Programs\Microsoft VS Code
    • Flutter extension version 3.80.0

[√] Connected device (2 available)
    • Windows (desktop) • windows • windows-x64    • Microsoft Windows [Version 10.0.22621.2861]
    • Edge (web)        • edge    • web-javascript • Microsoft Edge 120.0.2210.121

[√] Network resources
    • All expected network resources are available.

! Doctor found issues in 1 category.

@lpickford-pixelbeard
It is a known issue with Ink:
You can wrap it with Material widget to crop as desired

import 'package:flutter/material.dart';

const Color darkBlue = Color.fromARGB(255, 18, 32, 47);

void main() {
  runApp(MyApp());
}

class MyApp extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      theme: ThemeData.dark().copyWith(
        scaffoldBackgroundColor: darkBlue,
      ),
      debugShowCheckedModeBanner: false,
      home: Scaffold(
        body: Center(
          child: MyWidget(),
        ),
      ),
    );
  }
}

class MyWidget extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return Row(
      mainAxisSize: MainAxisSize.max,
      children: [
        const SizedBox(width: 200),
        Expanded(
          child: DefaultTabController(
            length: 20,
            child: Material(
              color: Colors.transparent,
              child: TabBar(
                isScrollable: true,
                tabs: List.generate(
                  20,
                  (index) => Tab(text: 'Tab Index $index'),
                ).toList(),
                tabAlignment: TabAlignment.start,
              ),
            ),
          ),
        ),
      ],
    );
  }
}

Note: You can follow for updates:  https://github.com/flutter/flutter/issues/73315 & https://github.com/flutter/flutter/issues/86584
cc:danagbemava-nc

I think this is similar to issues @sharabiddin pointed out. The Material can work around this, but I think this can be kept open as a separate issue for TabBar as it doesn't use ListView internally.

flutter doctor -v (stable and master)
[✓] Flutter (Channel stable, 3.16.6, on macOS 14.1 23B74 darwin-x64, locale en-VN)
    • Flutter version 3.16.6 on channel stable at /Users/huynq/Documents/GitHub/flutter
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision 46787ee49c (28 hours ago), 2024-01-09 14:36:07 -0800
    • Engine revision 3f3e560236
    • Dart version 3.2.3
    • DevTools version 2.28.4

[✓] Android toolchain - develop for Android devices (Android SDK version 34.0.0)
    • Android SDK at /Users/huynq/Library/Android/sdk
    • Platform android-34, build-tools 34.0.0
    • ANDROID_HOME = /Users/huynq/Library/Android/sdk
    • Java binary at: /Applications/Android Studio.app/Contents/jbr/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build 17.0.6+0-17.0.6b802.4-9586694)
    • All Android licenses accepted.

[✓] Xcode - develop for iOS and macOS (Xcode 15.0.1)
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Build 15A507
    • CocoaPods version 1.14.3

[✓] Chrome - develop for the web
    • Chrome at /Applications/Google Chrome.app/Contents/MacOS/Google Chrome

[✓] Android Studio (version 2023.1)
    • Android Studio at /Applications/Android Studio Hedgehog.app/Contents
    • Flutter plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/6351-dart
    • Java version OpenJDK Runtime Environment (build 17.0.7+0-17.0.7b1000.6-10550314)

[✓] Android Studio (version 2022.2)
    • Android Studio at /Applications/Android Studio.app/Contents
    • Flutter plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/6351-dart
    • android-studio-dir = /Applications/Android Studio.app/
    • Java version OpenJDK Runtime Environment (build 17.0.6+0-17.0.6b802.4-9586694)

[✓] VS Code (version 1.85.1)
    • VS Code at /Applications/Visual Studio Code.app/Contents
    • Flutter extension version 3.80.0

[✓] Connected device (3 available)
    • RMX2001 (mobile) • EUYTFEUSQSRGDA6D • android-arm64  • Android 11 (API 30)
    • macOS (desktop)  • macos            • darwin-x64     • macOS 14.1 23B74 darwin-x64
    • Chrome (web)     • chrome           • web-javascript • Google Chrome 120.0.6099.216

[✓] Network resources
    • All expected network resources are available.

• No issues found!

[!] Flutter (Channel master, 3.19.0-3.0.pre.49, on macOS 14.1 23B74 darwin-x64, locale en-VN)
    • Flutter version 3.19.0-3.0.pre.49 on channel master at /Users/huynq/Documents/GitHub/flutter_master
    ! Warning: `flutter` on your path resolves to /Users/huynq/Documents/GitHub/flutter/bin/flutter, which is not inside your current Flutter SDK checkout at /Users/huynq/Documents/GitHub/flutter_master. Consider adding /Users/huynq/Documents/GitHub/flutter_master/bin to the front of your path.
    ! Warning: `dart` on your path resolves to /Users/huynq/Documents/GitHub/flutter/bin/dart, which is not inside your current Flutter SDK checkout at /Users/huynq/Documents/GitHub/flutter_master. Consider adding /Users/huynq/Documents/GitHub/flutter_master/bin to the front of your path.
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision 085aaa5d63 (55 minutes ago), 2024-01-10 21:13:27 -0500
    • Engine revision 42e3e02361
    • Dart version 3.4.0 (build 3.4.0-15.0.dev)
    • DevTools version 2.31.0
    • If those were intentional, you can disregard the above warnings; however it is recommended to use "git" directly to perform update checks and upgrades.

[✓] Android toolchain - develop for Android devices (Android SDK version 34.0.0)
    • Android SDK at /Users/huynq/Library/Android/sdk
    • Platform android-34, build-tools 34.0.0
    • ANDROID_HOME = /Users/huynq/Library/Android/sdk
    • Java binary at: /Applications/Android Studio.app/Contents/jbr/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build 17.0.6+0-17.0.6b802.4-9586694)
    • All Android licenses accepted.

[✓] Xcode - develop for iOS and macOS (Xcode 15.0.1)
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Build 15A507
    • CocoaPods version 1.14.3

[✓] Chrome - develop for the web
    • Chrome at /Applications/Google Chrome.app/Contents/MacOS/Google Chrome

[✓] Android Studio (version 2023.1)
    • Android Studio at /Applications/Android Studio Hedgehog.app/Contents
    • Flutter plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/6351-dart
    • Java version OpenJDK Runtime Environment (build 17.0.7+0-17.0.7b1000.6-10550314)

[✓] Android Studio (version 2022.2)
    • Android Studio at /Applications/Android Studio.app/Contents
    • Flutter plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/6351-dart
    • android-studio-dir = /Applications/Android Studio.app/
    • Java version OpenJDK Runtime Environment (build 17.0.6+0-17.0.6b802.4-9586694)

[✓] VS Code (version 1.85.1)
    • VS Code at /Applications/Visual Studio Code.app/Contents
    • Flutter extension version 3.80.0

[✓] Connected device (3 available)
    • RMX2001 (mobile) • EUYTFEUSQSRGDA6D • android-arm64  • Android 11 (API 30)
    • macOS (desktop)  • macos            • darwin-x64     • macOS 14.1 23B74 darwin-x64
    • Chrome (web)     • chrome           • web-javascript • Google Chrome 120.0.6099.216

[✓] Network resources
    • All expected network resources are available.

! Doctor found issues in 1 category.


Enh 2451 skip conditionals

Reference Issues or PRs

What does this implement/fix?
Put a x in the boxes that apply

[ ] Bug fix (non-breaking change which fixes an issue)
[ x] New feature (non-breaking change which adds a feature)
[ ] Breaking change (fix or feature that would cause existing features not to work as expected)
[ ] Documentation Update
[ ] Code style update (formatting, renaming)
[ ] Refactoring (no functional changes, no API changes)
[ ] Build related changes
[ ] Other (please describe):

Testing

[ ] Did you test the pull request locally?
[ ] Did you add new tests?

Any other comments?

This PR is related to the issue stated in ENH: #2451
I have added a job to the integration test related github actions. This job acts as a mediary for a boolean environment variable and a conditional statement added to integration test job at it's top level. This was made so that a user with a fork of nebari who do not have access to the credentials for the cloud resources the job needs.
This method was chosen for the following reasons:

In testing, booleans on the step level did not prevent a failing of attempting to access the credentials.
In testing, environment variables could not be used to do a boolean on the job at large.
A flag that was not branch specific was requested by a few users (not stated in ticket) and this solution could provide this.
This avoids adding "push:" statements to the YAML (as opposed to using ignore-branches) which will keep the workflow inherently manual or on a cron job as dictated thus far.

Hi, @BrianCashProf. All looks good, but I am curious about the extra steps of  check-for-credentials_***: I noticed you use it to calculate the output used for the extra conditional in the steps later in the pipeline.
I don't see a problem with that, but if possible, we could instead use the env you set up in the beginning to control it directly, e.g.:
  test-aws-integration:
    runs-on: ubuntu-latest
    if: env.NO_PROVIDER_CREDENTIALS_aws == "false"
    permissions:
      id-token: write

Hi, @BrianCashProf. All looks good, but I am curious about the extra steps of check-for-credentials_***: I noticed you use it to calculate the output used for the extra conditional in the steps later in the pipeline.
I don't see a problem with that, but if possible, we could instead use the env you set up in the beginning to control it directly, e.g.:
  test-aws-integration:
    runs-on: ubuntu-latest
    if: env.NO_PROVIDER_CREDENTIALS_aws == "false"
    permissions:
      id-token: write

That was my initial idea, but the Environment variables were not accessible when doing a boolean at the first level of the job.
if: env.NO_PROVIDER_CREDENTIALS_aws == "false" will produce an error that states it cannot read the env variables.
Next I tried adding the check on the token step itself, but it wouldn't stop the job from reaching out to a resource it did not have and erroring out.
With those not being possible, I thought of what variables could be read at that top level. Given that a job output could be read in the boolean, I used the environment variable to create a job output that could then be read in the boolean statement.

Indeed, it looks like the available contexts for the jobs.<id>.if conditional are only github, needs, vars, inputs

This will be merged after the upcoming July release.

@BrianCashProf, sorry for being pedantic here, but could you add a small comment in the new job explaining why it's in there? This way, we can easily track that in future maintenance of these files.


Support multiline strings

Hi, this is adding support for multiline strings :)

Thanks for the contribution, very nice PR :)


Investment table for heat and electricity technologies does not include hydrogen burners

Let's fix this before the June deploy.

Fixed by: https://github.com/quintel/etmodel/pull/2814/commits/edd4fe5e7bf0996e46182cf7094cef2ba67a9458
The script generating this table is updated as well


Test error-level code inspection.

Merging this myself to avoid conflicts. Basically enforces the rules we have (mostly) decided on. Feel free to take issue up with anything you don't agree with in issues for further discussion.


Added missing "s" to "makes"

The asterisk around the paragraph makes it more readable.

[x] I have read freeCodeCamp's contribution guidelines.
[x] My pull request has a descriptive title (not a vague title like Update index.md)
[x] My pull request targets the master branch of freeCodeCamp.
[x] None of my changes are plagiarized from another source without proper attribution.
[x] My article does not contain shortened URLs or affiliate links.

If your pull request closes a GitHub issue, replace the XXXXX below with the issue number.
Closes #XXXXX

Nice catch @joruchan, thanks for contributing to freeCodeCamp!


Metallicity support for Sonora Bobcat models

Eventually the Sonora-Bobcat models will have metallicity, C/O ratio, and possibly other dimensions like f_sed.  We want to be able to read in those future metallicity grids, while maintaining support for the extant solar-metallicity grid.
Future grids may have irregular sampling in the grid parameters.  Irregular sampling is a smart strategy for grappling with high dimensional spaces, but it does add some complexity to how we read in the data and how to make the dashboard sliders identify and "snap-to" the closest gridpoint.
@astrocaroline has provided some pre-release grids with metallicity for development and evaluation purposes.  To read in this grid we may want to move towards a glob and filename comprehension approach to identify eligible grid points rather than pre-specify the grid points.  I am starting an experimental feature branch in anticipation that these changes may be backwards breaking...

Hmmm, I just looked at the metallicity and C/O grids provided by Caroline.  There are a few small but pesky differences: the directory is compressed but the individual files are not, the file name extensions have C/O listed listed only if it is different from 1.0.  These are all subtle differences, but they add up to finite coding overhead, and all of that effort is destined be supplanted when the paper is released with the final version anyways.
Other innovations will need to happen.  It currently takes ~30 seconds to read in the solar-metallicity Sonora grids.  We will multiply that file I/O by a factor of 4, so up to 2.5 minutes to read in the whole grid.  There are definitely ways to speed this I/O up.
I am almost inclined to wait on adding metallicity until the final grid is actually public, or its final form can be provided in advance.  This may seem nitpick-y, and it sort of is, but there is a diminishing returns to investing lots of time in dealing with formatting that will vanish in a few weeks or month.  On the other hand, if the final grids won't be public for months, maybe it is worth taking an early look.  Thoughts welcome.

Hooray! The full Sonora models are public on Zenodo.  We will accomplish this once we get support for reading in the whole new model grid.

This task is assigned to @jiayi-cao and is part of our JOSS Submission milestone.

Closed by PR #30


Can't get through

Challenge inherit-styles-from-the-body-element has an issue.
User Agent is: Mozilla/5.0 (Windows NT 5.1; rv:48.0) Gecko/20100101 Firefox/48.0.
Please describe how to reproduce this issue, and include links to screenshots if possible.

Hello World

    ```

Please describe how to reproduce this issue, and include links to screenshots if possible.

Happy Coding


Greedy IPFS ate unreasonable lots of RAM and CPU

Hi.
Please consider screenshot below. After 1 day uptime IPFS occupy 30% of CPU and hold 3Gb of memory. Any way to keep it more thrifty?

May be we can restrict it by systemd, what do you think @strdn?

Currently for using IPFS is only one decision: 4GB of RAM, but we are working on Rust IPFS integration into Robonomics node.


Creation of influenza-bioinfo-solutions.md

Influenza guidance doc has converted to markdown and uploaded to the docs section.
Images will be added shortly.

Please wait to merge this. There are missing citations, figure numbers, and formatting inconsistencies that need to be addressed. The readme also needs to be updated.

Hey Emily,Yes, I explained to Gultekin that it will cause too much confusion for me to also work on this. Frank still had the doc on his patch branch anyway, so submitting to the main branch won’t solve anything.So, I’ll wait for him to resolve the issues on his end.Thanks for the fair warning though. On 08 May 2024, at 21:16, Emily Smith @.***> wrote:
Please wait to merge this. There are missing citations, figure numbers, and formatting inconsistencies that need to be addressed. The readme also needs to be updated.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: @.***>

will create a new PR from dev branch and linking the correct issue


HOMEBREW_AUTO_UPDATE_SECS doesn't seem to have any effect

[x] are reporting a bug others will be able to reproduce and not asking a question. If you're not sure or want to ask a question do so on our Discourse: https://discourse.brew.sh
[x] ran a brew command and reproduced the problem with multiple formulae? If it's a problem with a single, official formula (not cask) please file this issue at Homebrew/homebrew-core: https://github.com/Homebrew/homebrew-core/issues/new/choose. If it's a brew cask problem please file this issue at https://github.com/Homebrew/homebrew-cask/issues/new/choose. If it's a tap (e.g. Homebrew/homebrew-php) problem please file this issue at the tap.
[x] ran brew update and can still reproduce the problem?
[x] ran brew doctor, fixed all issues and can still reproduce the problem?
[x] ran brew config and brew doctor and included their output with your issue?

What you were trying to do (and why)
Setting HOMEBREW_AUTO_UPDATE_SECS doesn't appear to have any effect, as best I can tell. I am trying to speed up brew install and brew upgrade invocations by setting it in my shell environment.
What happened (include command output)
When installing or upgrading formulae, a brew update is performed automatically even if homebrew has been updated more recently than the configured number of seconds.
$ time env HOMEBREW_AUTO_UPDATE_SECS=86400 brew update
Updated 1 tap (homebrew/cask).
No changes to formulae.
        8.34 real         1.39 user         1.72 sys
$ time env HOMEBREW_AUTO_UPDATE_SECS=86400 brew install xz
Updating Homebrew...
==> Downloading https://homebrew.bintray.com/bottles/xz-5.2.4.mojave.bottle.tar.
Already downloaded: /Users/stephen/Library/Caches/Homebrew/downloads/f041c42abd74f027d1745193fe8c4d82d7df407e498726e107a3d3a165b6f16a--xz-5.2.4.mojave.bottle.tar.gz
==> Pouring xz-5.2.4.mojave.bottle.tar.gz
🍺  /usr/local/Cellar/xz/5.2.4: 92 files, 1MB
        8.79 real         2.22 user         1.92 sys

What you expected to happen
If HOMEBREW_NO_AUTO_UPDATE is set, the auto-update is skipped as expected:
$ time env HOMEBREW_NO_AUTO_UPDATE=true brew install xz
==> Downloading https://homebrew.bintray.com/bottles/xz-5.2.4.mojave.bottle.tar.
Already downloaded: /Users/stephen/Library/Caches/Homebrew/downloads/f041c42abd74f027d1745193fe8c4d82d7df407e498726e107a3d3a165b6f16a--xz-5.2.4.mojave.bottle.tar.gz
==> Pouring xz-5.2.4.mojave.bottle.tar.gz
🍺  /usr/local/Cellar/xz/5.2.4: 92 files, 1MB
        2.52 real         1.76 user         1.02 sys

I would expect equivalent behavior from brew when HOMEBREW_AUTO_UPDATE_SECS set, after a fresh brew update:
$ time env HOMEBREW_AUTO_UPDATE_SECS=86400 brew update
Updated 1 tap (homebrew/cask).
No changes to formulae.
        8.34 real         1.39 user         1.72 sys
$ time env HOMEBREW_AUTO_UPDATE_SECS=86400 brew install xz
==> Downloading https://homebrew.bintray.com/bottles/xz-5.2.4.mojave.bottle.tar.
Already downloaded: /Users/stephen/Library/Caches/Homebrew/downloads/f041c42abd74f027d1745193fe8c4d82d7df407e498726e107a3d3a165b6f16a--xz-5.2.4.mojave.bottle.tar.gz
==> Pouring xz-5.2.4.mojave.bottle.tar.gz
🍺  /usr/local/Cellar/xz/5.2.4: 92 files, 1MB
        2.52 real         1.76 user         1.02 sys

Step-by-step reproduction instructions (by running brew commands)
The brew commands above should suffice.
brew config && brew doctor

`brew config` and `brew doctor` output

$ brew config
HOMEBREW_VERSION: 2.1.11
ORIGIN: https://github.com/Homebrew/brew
HEAD: 37714b5ce1e4909d4d61de2af98343c7012f7cd9
Last commit: 6 weeks ago
Core tap ORIGIN: https://github.com/Homebrew/homebrew-core
Core tap HEAD: 54e9311c86e88194b4f5a90fbfe2c0e590664e20
Core tap last commit: 77 minutes ago
HOMEBREW_PREFIX: /usr/local
HOMEBREW_AUTO_UPDATE_SECS: 86400
HOMEBREW_NO_ANALYTICS_THIS_RUN: 1
CPU: 16-core 64-bit kabylake
Homebrew Ruby: 2.3.7 => /System/Library/Frameworks/Ruby.framework/Versions/2.3/usr/bin/ruby
Clang: 11.0 build 1100
Git: 2.23.0 => /usr/local/bin/git
Curl: 7.54.0 => /usr/bin/curl
macOS: 10.14.6-x86_64
CLT: <IP_ADDRESS>.1.1562985497
Xcode: 11.0
$ brew doctor
Your system is ready to brew.

Everything for this ticket should be in order.

The HOMEBREW_AUTO_UPDATE_SECS works by setting the modification time for each Git repository when it is checked and if it has been checked recently avoid checking the GitHub API or running git fetch for that repository but still e.g. checks out the right branches etc. The Updating Homebrew... messaging is printed if any part of the update process (including e.g. checking the modification times) takes more than ~3 seconds.
I'm closing this for now because this is working as implemented so is more of a feature request than a bug but I'd love thoughts from @stouset and @Homebrew/maintainers about whether this logic should be simpler (e.g. HOMEBREW_AUTO_UPDATE_SECS sets a single, global timestamp and skips running any update/branch checkout at all if it's recent enough).

Honestly, that behavior seems surprising to me. I would expect that the purpose of the HOMEBREW_AUTOUPDATE_SECS flag would be to dramatically speed up brew install and brew upgrade in the event that you know you've done a brew update recently.
It sounds like that's not what it does, but it's unclear to me if its current behavior is actually adding much value. Consider:
$ time brew install xz
Updating Homebrew...
==> Downloading https://homebrew.bintray.com/bottles/xz-5.2.4.mojave.bottle.tar.
Already downloaded: /Users/stephen/Library/Caches/Homebrew/downloads/f041c42abd74f027d1745193fe8c4d82d7df407e498726e107a3d3a165b6f16a--xz-5.2.4.mojave.bottle.tar.gz
==> Pouring xz-5.2.4.mojave.bottle.tar.gz
🍺  /usr/local/Cellar/xz/5.2.4: 92 files, 1MB
        9.88 real         2.26 user         1.93 sys

$ brew uninstall xz
Uninstalling /usr/local/Cellar/xz/5.2.4... (92 files, 1MB)

$ time env HOMEBREW_AUTO_UPDATE_SECS=86400 brew install xz
Updating Homebrew...
==> Downloading https://homebrew.bintray.com/bottles/xz-5.2.4.mojave.bottle.tar.gz
Already downloaded: /Users/stephen/Library/Caches/Homebrew/downloads/f041c42abd74f027d1745193fe8c4d82d7df407e498726e107a3d3a165b6f16a--xz-5.2.4.mojave.bottle.tar.gz
==> Pouring xz-5.2.4.mojave.bottle.tar.gz
🍺  /usr/local/Cellar/xz/5.2.4: 92 files, 1MB
        7.85 real         2.49 user         2.03 sys

That's a 20% difference, but it's still nowhere near as performant as
time env HOMEBREW_NO_AUTO_UPDATE=true brew install xz
==> Downloading https://homebrew.bintray.com/bottles/xz-5.2.4.mojave.bottle.tar.gz
Already downloaded: /Users/stephen/Library/Caches/Homebrew/downloads/f041c42abd74f027d1745193fe8c4d82d7df407e498726e107a3d3a165b6f16a--xz-5.2.4.mojave.bottle.tar.gz
==> Pouring xz-5.2.4.mojave.bottle.tar.gz
🍺  /usr/local/Cellar/xz/5.2.4: 92 files, 1MB
        2.64 real         1.87 user         1.10 sys

Why shouldn't there be an environment setting that prevents any sort of update logic from happening if a brew update is recent-enough?

Honestly, that behavior seems surprising to me. I would expect that the purpose of the HOMEBREW_AUTOUPDATE_SECS flag would be to dramatically speed up brew install and brew upgrade in the event that you know you've done a brew update recently.

@stouset You have convinced me that this needs to change. As a result I've opened https://github.com/Homebrew/brew/pull/6532 to change the functionality to (I think) what you'd expect. Let me know what you think and thanks again!

Awesome, thank you!


Lua 5.4

How should compat-5.3 be updated for Lua 5.4?
At least to allow projects to compile against 5.4 we need something like:
diff --git a/vendor/compat53/c-api/compat-5.3.h b/vendor/compat53/c-api/compat-5.3.h
index 8e10893..fb6cc25 100644
--- a/vendor/compat53/c-api/compat-5.3.h
+++ b/vendor/compat53/c-api/compat-5.3.h
@@ -397,11 +397,11 @@ COMPAT53_API void luaL_requiref (lua_State *L, const char *modname,

 /* other Lua versions */
-#if !defined(LUA_VERSION_NUM) || LUA_VERSION_NUM < 501 || LUA_VERSION_NUM > 503
+#if !defined(LUA_VERSION_NUM) || LUA_VERSION_NUM < 501 || LUA_VERSION_NUM > 504

-#  error "unsupported Lua version (i.e. not Lua 5.1, 5.2, or 5.3)"
+#  error "unsupported Lua version (i.e. not Lua 5.1, 5.2, 5.3, or 5.4)"

-#endif /* other Lua versions except 5.1, 5.2, and 5.3 */
+#endif /* other Lua versions except 5.1, 5.2, 5.3, and 5.4 */

However, maybe we should be deprecating the compat-5.3 project and creating a compat-5.4?

I haven't had a closer look at the API changes, yet, but my first impression is that we can't do much about 5.4. I've seen:

lua_version has changed
lua_resume has an extra parameter
we could try to emulate multiple uservalues (at some performance cost)
 lua_pushfail is trivial
maybe something about the new warning system
luaL_addgsub
luaL_argexpected
luaL_buffaddr
luaL_buflen
luaL_bufsub
luaL_tolstring is slightly stricter
luaL_typeerror

For now, the newly released version should work for Lua 5.4.

Thanks for allowing this to run on Lua 5.4 systems. Can we get release on Luarocks too? Pretty please with a cherry?

Aaha I see you did a Luarocks release for compat53, but can we get a matching one for bit32?

I've added the bit32 library to this repository. I hope it works as intended ...

Not really, but it's complicated to test because of this luarocks issue
Even when that is sorted out though I think there is going to be a problem with the bit32 module itself. Lua 5.3 by default included this this, so the bit32 load being a noop was sort of correct. But it didn't include it if you disabled the Lua 5.2 compatibility flag. Lua 5.4 doesn't include it at all.
In other words for code to be compatible with Lua 5.2, the bit32 module needs to stop being a noop and start actually providing something for 5.1 and 5.4, plus check 5.3 for whether the module exists already.

I found an ugly but functional workaround for the luarocks bit32 issue in time for the recent luaposix release with Lua 5.4 support, here:
https://github.com/luaposix/luaposix/commit/898831b66ae5c0bcd6bfa5d8294320c239e1beba

Only add bit32 to the rockspec dependencies when _ENV doesn't change the environment (i.e. Lua 5.1)... because 5.2 has it in the vm so doesn't need the external module, and for 5.3 and 5.4 use this:

https://github.com/luaposix/luaposix/commit/5d5e06e750833b422b408b466f1535c756486048

Where we pcall(require) a bit32 API compatible internal file which uses the Lua 5.3+ only infix bitwise operators, and if that fails load the bit32 module we installed in step 1. So one codebase will provide a library that works in Lua 5.1 through 5.4.

Cheers,
Gary

On Jul 9, 2020, at 2:42 PM, Caleb Maclennan<EMAIL_ADDRESS>wrote:

Not really, but it's complicated to test because of this luarocks issue
Even when that is sorted out though I think there is going to be a problem with the bit32 module itself. Lua 5.3 by default included this this, so the bit32 load being a noop was sort of correct. But it didn't include it if you disabled the Lua 5.2 compatibility flag. Lua 5.4 doesn't include it at all.
In other words for code to be compatible with Lua 5.2, the bit32 module needs to stop being a noop and start actually providing something for 5.1 and 5.4, plus check 5.3 for whether the module exists already.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

use this: luaposix/luaposix@5d5e06e

Be very careful with such code; different bit libraries (and the operators) all behave differently in regards to signedness, overflow and other properties. See https://github.com/daurnimator/lua-http/blob/47225d081318e65d5d832e2dd99ff0880d56b5c6/http/bit.lua#L3-L7

@alerque I'm not sure I can follow. The bit32 backport in this repo compiles and works (according to my very primitive tests) for Lua 5.1 and Lua 5.4. The module should be unnecessary for Lua 5.2 and Lua 5.3 because those versions contain a native version of bit32, and LuaRocks will favor this native version automatically.

and LuaRocks will favor this native version automatically.

That's what should happen, but it isn't what Luarocks 3.3.1 actually does. Even when Lua 5.3 is compiled without 5.2 compatibly flags it assumes that it has a bit32 module internally and refuses to install the rock on the grounds that it's provided by the VM ... even though it hasn't actually checked that is the case.

Lua 5.3 without compatibility does provide a builtin bit32 module -- it just throws an error when loaded. Even if LuaRocks installed the rock, Lua 5.3 would still use the builtin, error-throwing one. Also, bit32 is a compatibility library, so it makes sense to assume that you either built with compatibility (which is the default) and you already have it, or you explicitly disabled compatibility and thus you don't want the non-error-throwing one.

However, maybe we should be deprecating the compat-5.3 project and creating a compat-5.4?

Makes sense to me!

I haven't had a closer look at the API changes, yet, but my first impression is that we can't do much about 5.4.

Hopefully the changes are not too drastic, then?

we could try to emulate multiple uservalues (at some performance cost)

What do you have in mind? I guess a weak-keys table in the registry mapping userdata to arrays would do the trick?

maybe something about the new warning system

Even something super basic like this would be nice as a start:
do
   local warnings_on = false
   function warn(msg, ...)
      if msg == "@on" and select("#", ...) == 0 then
         warnings_on = true
      elseif msg == "@off" and select("#", ...) == 0 then
         warnings_on = false
      elseif warnings_on then
         io.stderr:write("Lua warning: ", msg, ...)
         io.stderr:write("\n")
      end
   end
end

...though of course it could get fancier if it was to support the C API side of it as well. For user-produced warnings looks that would be doable. I don't think a library author cares about the Lua-generated warnings added in 5.4; those are the concern of whoever is embedding Lua, and if they care about warnings for these failure conditions they'll be probably embedding 5.4 anyway.

For now, the newly released version should work for Lua 5.4.

This is great, thank you! :)
Looking at the library incompatibilities list for the Lua standard library side of things, I think one possible change in compat-5.4 would be to pick the new lutf8lib.c which adds the lax argument.

However, maybe we should be deprecating the compat-5.3 project and creating a compat-5.4?

Makes sense to me!

I haven't had a closer look at the API changes, yet, but my first impression is that we can't do much about 5.4.

Hopefully the changes are not too drastic, then?

we could try to emulate multiple uservalues (at some performance cost)

What do you have in mind? I guess a weak-keys table in the registry mapping userdata to arrays would do the trick?

maybe something about the new warning system

Even something super basic like this would be nice as a start:
do
   local warnings_on = false
   function warn(msg, ...)
      if msg == "@on" and select("#", ...) == 0 then
         warnings_on = true
      elseif msg == "@off" and select("#", ...) == 0 then
         warnings_on = false
      elseif warnings_on then
         io.stderr:write("Lua warning: ", msg, ...)
         io.stderr:write("\n")
      end
   end
end

...though of course it could get fancier if it was to support the C API side of it as well. For user-produced warnings looks that would be doable. I don't think a library author cares about the Lua-generated warnings added in 5.4; those are the concern of whoever is embedding Lua, and if they care about warnings for these failure conditions they'll be probably embedding 5.4 anyway.

For now, the newly released version should work for Lua 5.4.

This is great, thank you! :)
Looking at the library incompatibilities list for the Lua standard library side of things, I think one possible change in compat-5.4 would be to pick the new lutf8lib.c which adds the lax argument.


Remove extra about page for British Indian Ocean Territory

We have recently updated the base_path for the "about us" worldwide corporate information pages.
Because of this, we have seen a bunch of UnpublishableInstanceErrors for this particular worldwide organisation as it has two "about us" pages and therefore two of the same base_paths. The "about us" page that is not in use has very minor changes (compared to the one that is) and we have decided as a team that it can be removed.
We plan to do further work to identify where other worldwide organisations have multiples of the same type of CIP, including adding validation where it is missing so that this issue can be prevented in future.

⚠ This repo is Continuously Deployed: make sure you follow the guidance ⚠
Follow these steps if you are doing a Rails upgrade.

We reverted the "about" page in question to draft via the UI instead!


Feature Request/Question: yFiles Hierarchic layout

First off, thanks for this awesome repo. Was wondering what the best way is to use a yFiles layout in dash-cyto. In particular, I find their hierarchic layout really useful but can't seem to find anything that comes close among the builtins or the "external layouts".
I'm open to any hacks that you would suggest/endorse perhaps using cytoscape's API or py2cytoscape that would facilitate this in the meantime?
Are there any guidelines for how to go about implementing a custom "external layout" somewhere?
Thanks again!

Hi @manihamidi! yFiles hierarchical layout looks pretty neat! I think there's two ways to approach this:

Write the logic in Javascript, then create a script called yFilesHierachical.js in src/lib. Then, import it in extra_index.js. For an example, see cola.js.
Create a function in Python that can algorithmically generate the coordinate of each node based on nodes/edges specifications. For an example, see usage-phylogeny, and focus on this snippet:

https://github.com/plotly/dash-cytoscape/blob/b18fd799de48a05db8ef704d6024684b9e627771/demos/usage-phylogeny.py#L80-L85


Bright sky residuals on 20230407/175383 tileid 22746

We had poor sky residuals on 20230407/175383 tileid 22746.  We should mark this exposure as bad and reprocess.  Currently marked unsure.

Hi @schlafly
Thanks Eddie, I have marked that exposure as bad and re-ran the nightqa. Closing the issue now :)


Explore cargo-dist for CI

It's designed to make distribution CI release stuff easier. That's nice! I'd like to make more native (non-desktop) builds for platforms. This could help.
https://github.com/axodotdev/cargo-dist/

Since I'm already using tauri-apps/tauri-action@v0 and taiki-e/upload-rust-binary-action@v1 for the same purpose. I think switching over will mostly be more work, and has no real benefits. If I'd start from scratch, it would probably be a good pick!


Dark mode

As I am currently in the process of "upgrading" CVFY mostly for personal use, i will push few smaller changes to original repo maybe someone finds those useful.
This PR is the tailwindcss dark mode for editor only (print remains the same). It adds dark variant classes for text/backgrounds and lighter variant of colors used in the project, although color shade choice was random and probably requires attention.
It also adds composable to switch between light and dark mode and save to localstorage. I used separate key cvSettings-darkmode as current project for some reason saves separate options for each language (that probably should be changed) to remain consistent for all languages. I also added toggle button fixed to top right of the preview window.
The one thing i changed for print are the technical skills "tags" as they don't look good in gray
It's my first PR to open source so it would be nice to know if I made a mistake somewhere ;)

Hi!
Even though dark mode is not a priority right now and probably it would take some time to implement, I thank you for your hard work and ideas! Just a few things to add and think about.
I agree that dark mode colour palette needs more thinking as the contrast doesn't seem good enough for accessibility and colours looks a bit off.
For setting the dark mode, I think the approach with Tailwind CSS dark selector is a bit chaotic and hard to maintain (although it may make sense with the way the colour styles are organise now). In my opinion, using prefers-color-scheme media in a CSS stylesheet could be a better way to set the two different colour palettes. We can create each theme using Tailwind colour values with Tailwind's theme() function. This would need some re-factoring but I could work on that beforehand. We would still need JavaScript to for the switch button component and take into account the user preference (it is missing in the composable).
Also, I don't think is a good idea to apply the dark mode to the CV preview as this is an exact representation of the PDF. However, we could reduce the brightness and contrast with CSS filter() function for the dark mode.
This and this are some articles that mention the above and explain the implementation I think is cleaner and more maintainable.
I did it before for my portfolio website if you would like to check for the implementation in Nuxt/Vue (without Tailwind though):

CSS stylesheet with the light and dark themes.
Switch mode button

Regarding the button placement, it overlaps with the "Buy me a coffee" button in smaller screens so it needs some fixing and maybe more thinking into the design.
Let me know what you think about this!


Add pause feature

For example pressing "P" key, for pause?

Ok, but maybe let's use Esc key instead. Later on, we will probably need to add "are you sure" prompt but that's a different issue for a different milestone

I would use esc key as 'quit game', maybe it's good idea for new issue?

Yeah, one of the missing basic features is the ability to close the game "normally". For now esc just pausing the game will be fine and we can create a new issue about quitting the game.

Couple of tips how to easily achieve this

in Main.cpp, line 20, we have our main game loop. In order to pause the game, we simply need to suspend it, specifically the three calls to scene in 33. In order to unpause, we need to resume their execution
To do that, you can have a bool flag that will be checked when calling scenes, for example

if(!isPaused)
{
    scene.Update(dt);
    scene.CheckCollisions();
    scene.Draw();
}

You can enable/disable it by reacting to a KeyReleased event in the event loop in 27. This article will explain everything you need
https://www.sfml-dev.org/tutorials/2.5/window-events.php

A very easy way to toggle a bool value is to simply assign it's negation to itself :)

isPaused = !isPaused;

And I think that's it :D any questions let us know, via Q&A or DC


Improve responsive on desktop

The design is implemented mobile-first, and the desktop interface does not scale well.
The layout should also change to take advantage of the larger screen size.

Added in 6ab7c3bf0ad6c4842e972ac669a3d63e9a6df5ba

For the moment the layout just resizes to be comfortable to use, it does not use the extra width for side bar etc...


Unable to sign request on s3 when making chunks request

Type of issue

[ ] Bug report
[ ] Feature request
[1] Support request

Uploader type

[ ] Traditional
[1] S3
[ ] Azure

Bug Report
Fine Uploader version
{example: 5.5.1}
Browsers where the bug is reproducible
{example: "Firefox" and "IE11"}
Operating systems where the bug is reproducible
{example: "iOS 9.1.0" and "Windows 8.1"}
Exact steps required to reproduce the issue
For example:

Select 3 files
Pause the 2nd file before it completes, but after it has started.
Attempt to resume the paused file.

All relevant Fine Uploader-related code that you have written
{simply copy and paste the JS used to control Fine Uploader browsers-ide}
{also include your template HTML if related to a UI issue}
Your Fine Uploader template markup (if using Fine Uploader UI and the issue is UI-related)
{simply copy and paste your template markup}
Detailed explanation of the problem
{describe the bug here}

Feature Request
Feature request details
{why is this feature important, not just for you, but for many others?}

Support Request
Fine Uploader version
{example: 5.5.1}
Question
When we are making a chunk request to upload on s3 its giving error "SignatureDoesNotMatch" and 403 Forbidden. But if we are disabling chunks then its working correctly.
Please find our configuration in code below.
Can you please help me out on this, that where we doing something wrong?
Related code
var s3Uploader = new qq.s3.FineUploader({
debug: false,
autoUpload: true,
element: document.getElementById('fine-uploader-s3'),
template: 'add-art-template',
request: {
endpoint: "https://s3-ap-southeast-1.amazonaws.com/dauble-****-upload",
accessKey: "**C7B6A",
region: 'ap-southeast-1',
forceMultipart: true
},
signature: {
endpoint: "http://<IP_ADDRESS>:2000/v1/upload/s3/signature",
version: 4
},
objectProperties: {
region: 'ap-southeast-1',
bucket: 'dauble--upload',
host: 's3-ap-southeast-1.amazonaws.com'
},
uploadSuccess: {
endpoint: "http://<IP_ADDRESS>:2000/v1/upload/success",
params: {
isBrowserPreviewCapable: qq.supportedFeatures.imagePreviews
}
},
multiple: false,
cors: {
expected: true
},
chunking: {
enabled: true,
concurrent: {
enabled: false
},
partSize: 510241024
},
maxConnections: 5,
resume: {
enabled: true
},
retry: {
enableAuto: false,
maxAutoAttempts: 2,
autoAttemptDelay: 10
},
validation: {
allowedExtensions: [
'jpeg', 'jpg', 'png', 'zip'
]
// ,
// itemLimit: 5,
// sizeLimit: 30 *1024 *1024, // 50 kB = 50 * 1024 bytes,
// allowEmpty: false
},
callbacks: {
onComplete: function(id, name, response) {
if (response.success) {
$scope.imgLink = 'https://s3-ap-southeast-1.amazonaws.com/dauble-bulk-upload/' + response.data;
launchEditor($scope.imgLink);
}
},
onError: function(id, name, reason, xhrCache) {
console.log(reason);
// moveUpload({from: 'active', to: 'error', hash: activeUpload.hash}).then(() => bad(new Error('upload error - ' + reason)));
},
onUploadChunk : function (id,name,chunkData) {
console.log(id,name,chunkData);
// s3Uploader.uploadChunk(id,name,chunkData);
}
}
});

Sorry, but I can't understand the issue here at all. Take some time time to clean this up and I'll consider reopening


Sustain pedal realism

Hi there, Ever since I got into Linux audio for playing the piano with my MIDI keyboard, I noticed a unique, subtle trait of LinuxSampler together with SFZ soundfonts that made it feel distinctly more natural. With a sustain pedal, LinuxSampler allows for sustaining the residual resonance even after releasing all the keys.  LinuxSampler faithfully reproduces this behavior (only with SFZ and GIG soundfonts, the SF2 spec apparently doesn't support it EDIT: Actually it works with SFZ, GIG, and SF2), and to my knowledge it's the only free SFZ sampler that does this. Sfizz does not. Even the Sforzando player for Windows which is generally regarded as the standard for free SFZ players doesn't do this. Apart from LinuxSampler, the only thing on my system that also has proper sustain behavior is the commercial Pianoteq app. But the problem is that LinuxSampler doesn't seem to exist as a Linux VST (only for Windows apparently?) so it's hard to use it with other DAWs and synthesizer apps. Would it be possible to implement this behavior on Sfizz? Thanks a lot!

Do you have any example piano sample set in sfz for that description to share? Afaik, not every piano samples included its resonance samples, so it couldn't bd achieved. Or maybe I'm wrong.
I'm curious to check what piano sample set can do that

I saw your post on reddit, and I tried on my electronic piano this morning (casio px5s) and indeed there is this behavior. I'll investigate and compare more, and I'm definitely okay to improve this in sfizz. However, since sforzando doesn't do it, there's also a good chance that it's not really a standard, expected behavior. Let's see what we can dig out 🤗

@kinwie Hi there, thanks a lot for the response! In my experience almost all sample libraries have at least minimal resonance. The Salamander Grand is probably the best, but LinuxSampler offers the same behavior with these and these and these. Some SF2 libraries sound weird with LinuxSampler, in which case I use Polyphone to convert them to SFZ.

@paulfd Hi, thanks for the reply, and thanks for confirming that. Yes, I wouldn't be surprised if this was a "beneficial bug" of LinuxSampler. :-) But it makes all the difference in the world for me, with all other samplers I immediately start hearing unnatural cut-offs of chords that would normally be sustained on a real piano. It must be my particular (non-professional) playing style that particularly brings to light this trait.

Okay, good catch!
I just tested this in LinuxSampler and there is indeed this behavior.

Awesome, thanks a lot @kinwie for looking into this!

I tested it too, compared to a real piano the output is a bit crude as you would have a stronger dampening of the note even when pressing the pedal quickly after lifting your fingers. Matching this behavior, I think, would require "cancelling" the release phase and getting back into sustain. However, I think we'd need to reset all EGs to sustain, and not just the amplitude. It's also a bit ill-defined for the more complex EGs, but I guess these would not happen on a piano.
If/when we add this, I think it should be an optional, disabled-by-default thing as this does not match the reference behavior. However, it is a good candidate for evolving the SFZ spec, adding release_cancel=1 or something of the sort, possibly with a dampening value for more realism.

I have a proof of concept in #898 that you can try in the meanwhile.

Yes, tested #898 and it's working good

@kinwie Could you give some tips on how you built it? I'd love to test it, but I'm not proficient with git and the build process.

What distro are you using?

Yeah, Paul can help you more.
I'm also not familiar with git stuff.
I got the Windows x86 build with the help from a friend.

Hi @paulfd , I'm using openSUSE Tumbleweed.

@geckolinux the build documentation is on the website, but in this case you need to checkout the Paul's fork instead:
git clone --recursive https://github.com/paulfd/sfizz.git
cd sfizz
git checkout release-sustain

or just wait a while to make it merged and build from develop.
You also need to install the required dependencies, but IDK the exact names in OpenSuse, you can check the ones used on Debian/Ubuntu.

For opensuse you might need zypper si sfizz, assuming you have the repositories from OBS
This will install the build dependencies, I think. I don't know much about opensuse.

I'm going to merge it soon, you will be able to get the develop package from OBS anyway :)

Perfect, thank to everyone for the help! Yeah, I was actually going to try to clone the sfizz package in OBS to build it anyway, not on my local computer, but I wasn't sure how to get the right branch or commit point. But if @paulfd is going to merge this then I'll just wait for that. If you could make a quick post here when that happens I'd appreciate it. Thanks again for being responsive to making this improvement, I'm excited to test it!

Note that you can get notifications directly from GitHub for the current and future PRs by clicking on the subscribe button in the related page.

Hi there, I just tested the packages from this OBS repo, but they don't seem to have the sustain pedal improvements discussed in this thread.

Let's reopen it.
At least I've just checked the OBS build of this version of openSUSE and they're OK.
(although a few others are suffering some build problems following updates of steinberg code)

@geckolinux the behavior is disabled by default, maybe that's why. Try adding hint_sustain_cancels_release=on in a <control> block at the beginning of your files. I don't think this should be enabled by default considering this is not really an expected behavior in the most common implementations, but we could probably make it a GUI option on top of a hint one.

@paulfd Ahhh, I see, thanks for the tip. How would I enable that flag when loading it in Carla? (Specifically it would be the VST3 version, as the sustain pedal doesn't work at all with the Sfizz LV2 plugin.) A GUI option would also be appreciated.

To be clearer, the behavior right now has to be enabled per file, by adding the following line at the top of the sfz file you want to load:
<control> hint_sustain_cancels_release=on

I'll see about the GUI option before the next release hopefully :)

@paulfd I loaded the OBS version of Sfizz quite a few weeks ago in Carla and modified one of my favorite SFZ files with <control> hint_sustain_cancels_release=on . It's extremely good now. Testament to how well it behaves it the fact that I've just left it since whenever I loaded it and haven't felt the need to change anything, just happily playing it with no distractions whatsoever. Well done! Without this improvement I would almost immediately be distracted by truncated notes. So a GUI option to enable this improvement without having to modify the SFZ files would be great so that it gets the attention it deserves. Thanks again for all your hard work!

Thanks again @paulfd !

Makes sense, thanks for the heads-up.


"context canceled" when cloning

Using the latest master, I get this error when a Github hook triggers a clone of a new repo:

13:43:13.093455 Running [/usr/bin/git clone --mirror --bare git://github.com/haskell-lang/haskell-lang.git /gitmirror/haskell-lang.git] in /tmp
13:43:13.093473 Error running [/usr/bin/git clone --mirror --bare git://github.com/haskell-lang/haskell-lang.git /gitmirror/haskell-lang.git] in /tmp:  context canceled

This looks like it was introduced in 9631bce1d13ba59d0118cfecc05def03dfbd0f1a.  When I switched to the previous commit (eff6bf33146ed1c067b3a1fa1f6e1efdb8386a29) this error no longer occurred.

Ah, you're doing background syncing, aren't you?  I could see how that could fail.

Let me know if this doesn't fix it.

Thanks, that worked!
You seemed surprised that I'd be using background syncing in the GitHub webhook.  Do you recommend against  background syncing for this case?

Nope, I think I do the same.  It just hasn't affected me because I hadn't
done any initial clones lately.
On Thu, Mar 23, 2017 at 8:09 AM Emanuel Borsboom<EMAIL_ADDRESS>wrote:

Thanks, that worked!
You seemed surprised that I'd be using background syncing in the GitHub
webhook. Do you recommend against background syncing for this case?
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/dustin/gitmirror/issues/12#issuecomment-288750016,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAAG8zbm1VsJSniEX2OCt9qJySlIRfmHks5roos6gaJpZM4MlP52
.


upgrade to ja4 TLS fingerprint

In https://github.com/komuw/ong/issues/95 (https://github.com/komuw/ong/pull/244) we implemented a TLS fingerprint inspired by ja3.
ja4+ has been released[1]. ja4+ has a number of different fingerprints;
JA4 — TLS Client
JA4S — TLS Server Response
JA4H — HTTP Client
JA4L — Light Distance/Location
JA4X — X509 TLS Certificate
JA4SSH — SSH Traffic
More fingerprints are in development and will be added to the JA4+ family

ja4+ (specifically, ja4 TLS client fingerprint)  is replacing the JA3 TLS fingerprinting[1].
ja4 TLS client fingerprint is released under BSD 3-Clause[3] while the others have some commercial license.
This means that we can implement ja4 TLS client fingerprint  for ong but not the others.

https://blog.foxio.io/ja4-network-fingerprinting-9376fe9ca637
https://github.com/FoxIO-LLC/ja4

https://github.com/gospider007/fp

https://hub.docker.com/r/thatcherthornberry/nginx-ja4


💡 Add a default system-wide monospace font

Summary
There's no default monospace font in manjaro sway. In many places RobotoMono Nerd Font is used but wherever it isn't there's this /usr/share/fonts/gnu-free/FreeMono.otf which is used as replacement or the actual default.
Examples:
Drawbacks
A more uniformly themed system?
Implementation idea
Adding this to  /etc/sway/config.d/90-enable-gtk-theme.conf :
gsettings set org.gnome.desktop.interface monospace-font-name "$term-font"

Will you be able to contribute a PR for this?

[X] Yes I will be able to get that feature a lot quicker.

Good catch!


🐛Bug: Is disabling clicks (but not pointer events) outside dialogs the expected behavior?

Describe the bug
On mobile, I have a BottomSheet component that opens behind the header, the component is using the dialog builder with closeOnOutsideClick: false. When it's open, I can't click any link on my header, however clicking on elements with on:pointerup works as expected.
To Reproduce
Steps to reproduce the behavior:

Go to https://www.sveltelab.dev/d4mrlmmcg8rsh8j
Click on 'Open dialog'
Click on 'pointerup works' (alert is fired)
Click on 'home' (nothing happens)
See error

Expected behavior
A system alert dialog should be fired when clicking on the 'home' link. Also, both links should work as well but they doesn't because page navigation might be handled by a click events under the hood and they're disabled when dialog is open.
Screenshots
If applicable, add screenshots to help explain your problem.
Desktop (please complete the following information):

OS: Windows 11
Browser: Chrome 118.0.5993.118 (Official build) (64 bits)

Additional context
I realized about this when trying to click on the logo link to go home and it didn't do anything.

First workaround is to add on:click|preventDefault and on:pointerup={() => goto('/') to all links in the header, but this is not ideal.
~Second workaround is to set closeOnOutsideClick: true but I need to control click outside, so this is less ideal for me.~

Edit: it turns out that second workaround doesn't work

+1 to this. I'm trying to allow the user to download a file from within the modal. Doing so requires I create an invisible <a> tag and append it to the body. I've tried several workarounds, but most of them result in some rough side effects (i.e. the modal closing as it registers the click of the a as an outside click). The hardest one to debug was to try and understand why all the click events were just getting absorbed and the download wasn't being queued at all. Would love a simpler way to accomplish this. Open to brainstorming!

Definitely a mistake on our end. Thanks for raising this issue, will look into it!


UnicodeEncodeError: 'charmap' codec can't encode characters in position 0-79: character maps to

safety version: 1.7.0
Python version: Python 3.6.1
Operating System: Windows-10-10.0.16299-SP0, AMD64

Description

Trying to use safety check
Same error always results: UnicodeEncodeError: 'charmap' codec can't encode characters in position 0-79: character maps to <undefined>

What I Did
safety check -r simple-requirements.txt

Contents of simple-requirements.txt
safety

There are absolutely no unicode characters in this file

Traceback
$ safety check -r simple-requirements.txt
Warning: unpinned requirement 'safety' found in simple-requirements.txt, unable to check.
Traceback (most recent call last):
  File "c:\users\nicholas\appdata\local\programs\python\python36\Lib\runpy.py", line 193, in _run_module_as_main
    "__main__", mod_spec)
  File "c:\users\nicholas\appdata\local\programs\python\python36\Lib\runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "C:\Users\nicholas\.virtualenvs\pybotics-d30fj9Hx\Scripts\safety.exe\__main__.py", line 9, in <module>
  File "c:\users\nicholas\.virtualenvs\pybotics-d30fj9hx\lib\site-packages\click\core.py", line 722, in __call__
    return self.main(*args, **kwargs)
  File "c:\users\nicholas\.virtualenvs\pybotics-d30fj9hx\lib\site-packages\click\core.py", line 697, in main
    rv = self.invoke(ctx)
  File "c:\users\nicholas\.virtualenvs\pybotics-d30fj9hx\lib\site-packages\click\core.py", line 1066, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "c:\users\nicholas\.virtualenvs\pybotics-d30fj9hx\lib\site-packages\click\core.py", line 895, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "c:\users\nicholas\.virtualenvs\pybotics-d30fj9hx\lib\site-packages\click\core.py", line 535, in invoke
    return callback(*args, **kwargs)
  File "c:\users\nicholas\.virtualenvs\pybotics-d30fj9hx\lib\site-packages\safety\cli.py", line 66, in check
    key=key
  File "c:\users\nicholas\.virtualenvs\pybotics-d30fj9hx\lib\site-packages\click\termui.py", line 420, in secho
    return echo(style(text, **styles), file=file, nl=nl, err=err, color=color)
  File "c:\users\nicholas\.virtualenvs\pybotics-d30fj9hx\lib\site-packages\click\utils.py", line 259, in echo
    file.write(message)
  File "c:\users\nicholas\.virtualenvs\pybotics-d30fj9hx\lib\encodings\cp1252.py", line 19, in encode
    return codecs.charmap_encode(input,self.errors,encoding_table)[0]
UnicodeEncodeError: 'charmap' codec can't encode characters in position 0-79: character maps to <undefined>

Similar Issues

https://github.com/pyupio/safety/issues/22

That's odd. I tried to reproduce this locally on different windows environments but wasn't able to.
It looks like the output is the problem here: https://github.com/pyupio/safety/blob/master/safety/formatter.py#L48

This is a dup of https://github.com/pyupio/safety/issues/22
and is fixed by https://github.com/pyupio/safety/pull/36

@nnadeau, is this fixed for you now?

I'll check asap when I get access to a Windows PC

I had the same issue when I used git bash insted of CMD. With CMD it works fine.

I'm seeing this error using Miniconda on AppVeyor. See the build log.
You can inspect the repo and configuration here.

I'm hitting the same issue on Python 3.7.4 when running MinGW (GitBash) and also in cygwin bash but in that instance only when running it in a sub-shell as $(safety check -r requirements.txt)

In my case, export PYTHONIOENCODING=UTF-8 solved my issue.

Still not fixed, but the workaround from @shahha works for me as well

I know this has been around for quiet a while now, but I would need another feedback from anyone who is still experiencing this with latest version.

Still experience this error
Using safety 1.8.7
On a github windows-latest runner (https://github.com/actions/virtual-environments/blob/master/images/win/Windows2019-Readme.md)
I get the following:
Traceback (most recent call last):
  File "c:\hostedtoolcache\windows\python\3.7.6\x64\lib\runpy.py", line 193, in _run_module_as_main
    "__main__", mod_spec)
  File "c:\hostedtoolcache\windows\python\3.7.6\x64\lib\runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "C:\hostedtoolcache\windows\Python\3.7.6\x64\Scripts\safety.exe\__main__.py", line 7, in <module>
  File "c:\hostedtoolcache\windows\python\3.7.6\x64\lib\site-packages\click\core.py", line 829, in __call__
    return self.main(*args, **kwargs)
  File "c:\hostedtoolcache\windows\python\3.7.6\x64\lib\site-packages\click\core.py", line 782, in main
    rv = self.invoke(ctx)
  File "c:\hostedtoolcache\windows\python\3.7.6\x64\lib\site-packages\click\core.py", line 1259, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "c:\hostedtoolcache\windows\python\3.7.6\x64\lib\site-packages\click\core.py", line 1066, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "c:\hostedtoolcache\windows\python\3.7.6\x64\lib\site-packages\click\core.py", line 610, in invoke
    return callback(*args, **kwargs)
  File "c:\hostedtoolcache\windows\python\3.7.6\x64\lib\site-packages\safety\cli.py", line 89, in check
    click.secho(output_report, nl=False if bare and not vulns else True)
  File "c:\hostedtoolcache\windows\python\3.7.6\x64\lib\site-packages\click\termui.py", line 548, in secho
    return echo(message, file=file, nl=nl, err=err, color=color)
  File "c:\hostedtoolcache\windows\python\3.7.6\x64\lib\site-packages\click\utils.py", line 272, in echo
    file.write(message)
  File "c:\hostedtoolcache\windows\python\3.7.6\x64\lib\encodings\cp1252.py", line 19, in encode
    return codecs.charmap_encode(input,self.errors,encoding_table)[0]
UnicodeEncodeError: 'charmap' codec can't encode characters in position 0-79: character maps to <undefined>

@janusheide thank you very much for such details. That confirmed my hypothesis. This stack trace confirms the error was dumping a report to standard output:
  File "c:\hostedtoolcache\windows\python\3.7.6\x64\lib\site-packages\safety\cli.py", line 89, in check
    click.secho(output_report, nl=False if bare and not vulns else True)

Our JSON Formater is using a special character to draw the framing that is not being mapped properly. This console session shows the issue:
In [1]: import codecs

In [2]: codecs.encode('═' * 7, encoding='cp1252')
---------------------------------------------------------------------------
UnicodeEncodeError                        Traceback (most recent call last)
<ipython-input-2-4656467a13d4> in <module>
----> 1 codecs.encode('═' * 7, encoding='cp1252')

/usr/lib/python3.7/encodings/cp1252.py in encode(self, input, errors)
     10
     11     def encode(self,input,errors='strict'):
---> 12         return codecs.charmap_encode(input,errors,encoding_table)
     13
     14     def decode(self,input,errors='strict'):

UnicodeEncodeError: 'charmap' codec can't encode characters in position 0-6: character maps to <undefined>

So, we need some code that will either decode properly or just change that ASCII art to not use non-ASCII characters. My preference is towards the second option, which should cause less issues.

Thanks for you quick response and shedding some light on the problem! To me just using a conforming character is the simpler, faster and more future prof approach, so that would get my vote :)
If there is something I can do to help, please let me know.


Localhuman rpc4

Unless anyone feels strongly otherwise, this should be the final functionality needed in the JSONRPC implementation for us to merge into development.
What current issue(s) does this address?, or what feature is it adding?

add implementation of sendrawtransaction

How did you make sure your solution works?

tests

Did you add any tests?

tests

Are there any special changes in the code that we should be aware of?

no

Did you run make lint and make test?

yes

Coverage increased (+0.1%) to 75.21% when pulling 6b925cf73ff60fb45d7b63ec5c21c80da6539c92 on localhuman-rpc4 into a27870880fb180ab070fac37aacf9ed17316a6f6 on jsonrpc1.


Laravel Passport setup

Closes #41
Upgrade steps
All local environments that have been set up before this pull request has been merged and need to run php artisan passport:keys to create the encryption keys for Laravel Passport. New environments can use the setup.sh script.

Codecov Report

Merging #51 (d3baf2e) into acceptance (806f8a3) will increase coverage by 0.57%.
The diff coverage is 83.33%.

:exclamation: Current head d3baf2e differs from pull request most recent head 9d296b4. Consider uploading reports for the commit 9d296b4 to get more accurate results

@@               Coverage Diff                @@
##             acceptance      #51      +/-   ##
================================================
+ Coverage         70.66%   71.24%   +0.57%
- Complexity          101      103       +2
================================================
  Files                38       38
  Lines               300      306       +6
================================================
+ Hits                212      218       +6
  Misses               88       88

Impacted Files
Coverage Δ

app/Http/Middleware/EnsureEmailIsVerified.php
0.00% <0.00%> (ø)

app/Models/AuthorizedUser.php
75.00% <ø> (ø)

...ontrollers/Auth/AuthenticatedSessionController.php
100.00% <100.00%> (ø)

...Http/Controllers/Auth/RegisteredUserController.php
100.00% <100.00%> (ø)

app/Http/Requests/Auth/RegisterRequest.php
100.00% <100.00%> (ø)

app/Models/Group.php
100.00% <100.00%> (ø)

app/Models/ReparationRequest.php
100.00% <100.00%> (ø)

app/Models/Reservation.php
100.00% <100.00%> (ø)

app/Providers/AuthServiceProvider.php
100.00% <100.00%> (ø)

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 806f8a3...9d296b4. Read the comment docs.


Hovertool datetime shows as percentage.

Code:
import pandas as pd
import numpy as np

pd.set_option("plotting.backend", "pandas_bokeh")
np.random.seed(42)
df = pd.DataFrame({"Google": np.random.randn(1000)+0.2,
                   "Apple": np.random.randn(1000)+0.17},
                   index=pd.date_range('1/1/2000', periods=1000))
df = df.cumsum()
df = df + 50

df.plot()

Result:

Relevant versions:
bokeh==2.0.0
pandas==1.0.1
pandas-bokeh==0.4.2

Hi @epa095,
Thanks for reporting this issue. I guess that happened with the release of bokeh 2.0. I have to look in the code to see what happens here.
Best Patrik

Hi @epa095,
the problem was indeed related to Bokeh >= 2.0. With the Bokeh=0.5 Release the issue is fixed and Bokeh >= 2.0 is enforced. For now, please use Bokeh=1.4 if possible.
Best Patrik


healthcheck status for all sub-component

https://github.com/zebrunner/jenkins-master/issues/307
https://github.com/zebrunner/jenkins-slave/issues/26
https://github.com/zebrunner/mcloud/issues/67
https://github.com/zebrunner/selenoid/issues/6
https://github.com/zebrunner/reporting/issues/2259

closing as all subtasks are closed as well (some of them with won't fix resolution)


manifest: Bump mbedtls from 3.0 to 3.1

Bump mbedtls from 3.0 to 3.1.
Signed-off-by: Sebastian Bøe<EMAIL_ADDRESS>

PR posted to evaluate the work involved in bumping mbedtls.

Closing.
TF-M 1.5 appears to be incompatible with 3.1.
There are also some other breaking changes (documented in release note) showing up in CI.
This will have to be done at a later time. When priorities and resources allow it.


Provide minimal boost version with limited functionality

Feature description
Provide a minimal boost version. Functionality that requires more boost parts than provided should not be built. This currently affects some functions in the file epidemiology/state_age_function.h.
Discussion: Where should the minimal boost version be stored? Ideally not as .tar.gz in the repository as before.
Additional context
No response
Checklist

[x] Attached labels, especially loc:: or model:: labels.
[x] Linked to project.

Maybe we can use FetchContent instead of a zip file:
https://stackoverflow.com/questions/72913306/how-to-use-boost-libraries-directly-from-github-using-cmake-fetchcontent-or-any
This could also work for the full download as well, by just changing the included libraries. If FetchContent is fast enough, I would prefer it over providing a binary archive. The zip archive obscures the dependency, and as far as I can tell from a quick search the opinion on how to handle dependencies in git(hub) is not to.
Anyways, github does have a solution for large file storage, which we could use for storing an archive.
Further, there is a cache action to reuse dependencies across runs, but I am not sure whether it applies to us, since we do not use a dependency manager like npm.

I think that version downloads all of boost, in the stackoverflow link they seem to only download some of the boost libraries. It might be worth a try.

@reneSchm

Daniel had been playing around with caching here: https://github.com/SciCompMod/memilio/issues/305
GitLFS is for several reasons probably not the right solution. It has to be paid for space and traffic.

In short: boost is huge, and cache space is limited, so unless the cached version can be used for all builds, there is not enough space.

As I see it, the biggest problem of the CI regarding build time comes from downloading all of boost for every build. Could we reduce that time by caching a .tar.gz (or .zip) of that download?
We then could extract it before the generation step and point cmake to it. The archive is platform independent, and b2 (which will figure out the platform stuff) should run fast enough to keep it in.

As I see it, the biggest problem of the CI regarding build time comes from downloading all of boost for every build. Could we reduce that time by caching a .tar.gz (or .zip) of that download?

If that's the biggest issue, that should be easy to solve with a cache. Are we currently cloning a git repo or downloading an archive? Downloading a tar would probably be easier and more efficient, both because it's faster to download one file than thousands with git, and because extracting the archive to get the source code is faster than compressing it for caching.

We are downloading a tagged release:
FetchContent_Declare(boost
    GIT_REPOSITORY https://github.com/boostorg/boost.git
    GIT_TAG boost-${MEMILIO_BOOST_VERSION})

I am pretty sure this just downloads the repo, but FetchContent can use URLs, so we could use the download from the boost homepage: "https://archives.boost.io/release/1.85.0/source/boost_1_85_0.tar.gz"

I just tried FetchContent with URL. It is quite fast, much faster than with a repository. The source code in the archive also has correct include paths, so bootstrapping doesn't seem to be necessary. I would guess it's also less traffic for github. Is there some drawback to downloading the tar or did we just miss that before? I think we don't need to worry about the cache at all then.

We might have missed it, but can we still use the version number with URL?

I found this commit (https://github.com/SciCompMod/memilio/commit/52d0303db27b3fc406435be1d305c938b8c6e435) where we switched from archive to repository for Eigen3. But we are still using archive for jsoncpp. So maybe the problem with Eigen3 is just a problem for gitlab or it was temporary.

can we still use the version number with URL?

the archive URL follows a naming scheme (see https://github.com/boostorg/boost/tags) that includes the version number and downloads are available for older tags as well, so that should work.


Comments counter test

Hello @AndreaM2429 , I present to you my new feature for your review to merge these changes into the develop branch. This merge implements a function to test the countComents function on the counterComments.js file.
Description
This branch adds unit tests for the comments counter function using Jest.
Changes Made

[x] Added the commentsCounter.test.js file that contains the unit tests for the commentsCounter.js module.

Additional Considerations

[x] Provide test coverage for different cases and scenarios of the countComments function.
[x] Ensure the correct number of comments is returned, even in situations where there are no comments or when there are non-comment elements in the container.

Related Tasks

[x] Add unit tests for the comments counter function

Since I was only responsible for implementing the tests for one case, it is possible to see failures when getting the results in the console, however, if the test you performed is added, then everything works as expected. I appreciate your time and comments in reviewing this feature.

Thank you @AndreaM2429 !!


ATTACH

Hi!
Does DuckDB support any equivalent of the sqlite ATTACH functionality?

This is not supported at the moment, sorry.

No worries, thank you for the reply!
In terms of motivation (for context), ATTACH in sqlite provides some big benefits in my use case:

query across independent datasets (files) at runtime with minimal overhead (given ATTACH is fast)
version data easily using the file container to store data versioned together, then access the desired version of runtime by ATTACH-including the desired version

Depending on the implementation, perhaps there may be query performance benefits from parallel IO if the dbs being accessed are are stored on separate storage. Certainly there are major performance benefits from being able to load/prepare the independent datasets in parallel (as separate files).
To replicate this ability to runtime query across independently versioned tables, it would seem to be necessary to first load all the data combinations into a duckdb db container each time?
For someone new to the project, do you think ATTACH would be difficult to add?

I think this should be rather straightforward for read-only queries on the "attached" databases via a table-producing function. Changes to the attached databases, especially if transactions span multiple of them would be far more challenging. It depends on your use case whether this is acceptable to you.

I have recently run into a data engineering use case for this feature. Maybe there is another way to approach the problem that you recommend that I could accomplish without it! I am using the Python API.
I'm downloading 500 million rows in chunks from Teradata in order to do recursive queries on the data that will benefit from DuckDB's vectorisation.
Because my queries are recursive, eventually all of the data must be in the same table. I had hoped to insert into the same DuckDB from multiple processes, but DuckDB only uses a single writer.
So, I can pull this data in parallel and store it in separate DuckDB's (or separate Parquet files, etc.). However, what is the fastest way to combine that data together into a single DuckDB?

If you have separate parquet files a UNION ALL between multiple SELECT * FROM parquet_scan() queries should work well enough.

Ok, that sounds good! Will the new multi-thread feature allow multiple threads to work on those tasks at once?

Currently I believe UNION ALL is not yet parallelized, but it is rather easy to do so and will be added later on for sure. Another idea we had before was to add a read_duckdb function, similar to the read_csv and read_parquet functions, that allow you to read a table from a different database (e.g. SELECT * FROM read_duckdb('test.db', 'integers'). That might solve the problem for your use case as well.
For now I recommend using Parquet files over the DuckDB storage for anything persistent, however. The DuckDB storage is not stable yet and is changing in every release, which means upgrading the system to a newer version will break compatibility with any previous storage versions. We will stabilize the storage when version 1.0 is released, but it will likely take another year or so to get to that point.

Thank you both for the great advice! I am now using Parquet to download my data in parallel, and then loading it into a DuckDB from those parquet files sequentially. I'm doing those read into duckdb operations one file at a time since I already have individual parquet files, but further down the road, having a parallel union all would let me speed things up by doing several of those at a time! I will say that it is pretty speedy already.
In the 1.0 timeframe, a read_duckdb function would definitely meet my use case (but I'll use Parquet for now based on your suggestion). I think that would also solve the IO parallelization opportunity that was mentioned earlier in this thread. Sounds like most of the benefits of attach without most of the complexity.

Hi Guys!
As a quick follow-up, for read-only queries on "attached" tables emulated via the table-emitting function approach, would it be accurate to say that queries could benefit from filter pushdown but would not benefit from any indexes?


Fixed #28239 in master -- Small documentation error

Thanks for the report. I pushed an update in 0ea321193a1d7f857544760e12058303edd51362. I don't think a bullet list is needed for one item.


make cmd_merge use multiple threads again

implements the fix suggested here: https://github.com/google-research/deduplicate-text-datasets/issues/19

This should be fixed by a separate commit.


Make sure XSS is impossible

Since we're going to be using nostr-editor to render notes from other people, we should be sure XSS isn't possible. I'm unclear from the docs whether this is the case. See also https://github.com/ueberdosis/tiptap/pull/5160

Indeed, I also got rid of our own link extension in favor of extending tiptap link-extension because of that, and apparently tiptap already handles it https://github.com/chroth/tiptap/blob/main/tests/cypress/integration/extensions/link.spec.ts#L74
Also tiptap-markdown uses markdown-it under the hood https://github.com/markdown-it/markdown-it/security
Planning to add some more unit/e2e tests soon


[Figma File Search] Could not load pages

Extension
https://www.raycast.com/michaelschultz/figma-files-raycast-extension
Description
Everything is setup correctly. All of a sudden it stopped working. I cannot search my Figma files anymore. I've tried to create a new token in Figma, in case the token would be expired (the setting is set to not expire at all), but that didn't work either.
Steps To Reproduce
The config is setup correctly. Personal Access Token and Team ID is correct. When I run the extension it says: could not load pages.

Current Behaviour
No response
Expected Behaviour
No response

@mustafakurt I haven't seen this issue before. I'll try to reproduce it. Can you maybe give me some more information on anything that may have changed before you received this error? Do you use multiple team IDs by any chance?


docs: small fix, grammar and readability improvement in globals.rst

Issue #251
Description of changes:

Fixed outdated reference to supported resources
Improved grammar and readability in Maps section
Improved grammar and readability in Lists section

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

I've accidentally pushed another change to the same branch (ece1878), just a second, I'll fix this.


fix: Fix the typo of the file in the modules folder

Corrected the typos of some files in the modules folder, including audio, bridge, calibration, canbus, canbus_vehicle, common, common_msgs, contrib, control, and data folders. Hope to improve the readability of the code and make it easier for developers to maintain.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


MM-36109: Hide markdown preview link when user cannot post.

Summary
Hid the markdown preview link when user cannot post.
Ticket Link
https://mattermost.atlassian.net/browse/MM-36109
Related Pull Requests
n/a
Screenshots
Before:

After:

Release Note
Hid the markdown preview link when the user cannot post.

/update-branch

Error trying to update the PR.
Please do it manually.

/update-branch


What you need to Modify the current develop version to get ensemble results

Currently Clipper can only serve result from a single model that is linked to an application where a REST end point is set. however, most functions needed for serving results from multiple models are implemented in the code and I guess it is for the future revision that might enable clipper to select optimized models among all linked models according to a policy chosen.
As per the issue #579 and others, there are some requirements to use multiple models linked to a single application, that is, an ensemble method. However, since it is only possible to get a single model result, at one REST request, to implement ensemble model, users must program their own method, and this was annoying.
Below is slight modifications of the code to let clipper to serve multiple model results at one REST request. To do that,
it changes

code that disables to run functions if there exists more thatn a model linked to an application
output return types of data
process multiple output result iteratively
post-process for multi model outputs

it uses the default policy, such that a single model result can still be served
it currently merges data from models and returns, but if you want ensembles of results,
you can implement your own ensemble methods in 'query_frontend.cpp'
below are what you need to fix in the Clipper
you can also check it from my fork : https://github.com/coldtomatojuice/clipper (Branch: ensemble)
[clipper_admin.py]
in the function 'def link_model_to_app(self, app_name, model_name)'
get argument 'model_name' as a string list (not a string)
so that, it can pass REST API a model name list
line:285
req_json = json.dumps({
            "app_name": app_name,
            "model_names": model_name
        })

[datatypes.cpp]
Change the output return type
Output output -> std::vector output
line:238
Response::Response(Query query, QueryId query_id, const long duration_micros,
                   std::vector<Output> output, const bool output_is_default,
                   const boost::optional<std::string> default_explanation)

[datatypes.hpp]
Change the output return type
Output output -> std::vector output
line:284
Response(Query query, QueryId query_id, const long duration_micros,
           std::vector<Output> output, const bool is_default,
           const boost::optional<std::string> default_explanation);

Change the output return type
line:300
std::vector<Output> output_;
[query_processor.cpp]
Get a vector return from combine_predictions
Output -> vector
line:138
std::pair<vector<Output>, bool> final_output = current_policy->combine_predictions(
        selection_state, query, *outputs_ptr);

[selection_policies.hpp]
Modify a parameter for the 'combine_predictions'
line:67
virtual const std::pair<std::vector<Output>, bool> combine_predictions(
      const std::shared_ptr<SelectionState>& state, Query query,
      std::vector<Output> predictions) const = 0;

line:137
  const std::pair<std::vector<Output>, bool> combine_predictions(
      const std::shared_ptr<SelectionState>& state, Query query,
      std::vector<Output> predictions) const override;

[selection_policies.cpp]
Make below as a comment
line:75
//    if (num_candidate_models > 1) {
//      log_error_formatted(LOGGING_TAG_SELECTION_POLICY,
//                          "{} candidate models provided for query with label "
//                          "{}. Picking the first one.",
//                          num_candidate_models, query.label_);
//    }

Generate multiple objects
line:81
//    tasks.emplace_back(query.input_, query.candidate_models_.front(), 1.0,
//                       query_id, query.latency_budget_micros_);
    for(auto candidate_model : query.candidate_models_){
      tasks.emplace_back(query.input_, candidate_model, 1.0, query_id, query.latency_budget_micros_);
    }

Make below as a comment
line:101
//    log_error_formatted(LOGGING_TAG_SELECTION_POLICY,
//                        "DefaultOutputSelectionPolicy only expecting 1 "
//                        "output but found {}. Returning the first one.",
//                        predictions.size());

Make the return type as a vector
line:90
const std::pair<std::vector<Output>, bool> DefaultOutputSelectionPolicy::combine_predictions(
Modify original single output to a vector output
line:94
    return std::make_pair(std::move(predictions), false);
line:99
    return std::make_pair(std::move(predictions), false);
[query_front.hpp]
Push back models iteratively
line:693
versioned_models.push_back(clipper::VersionedModelId(m, requested_version));
Formatting output string. you can fix this part.
line:490
//    std::string y_hat_str = parse_output_y_hat(query_response.output_.y_hat_);
    std::string y_hat_str ("");
    for(auto output_ele : query_response.output_){
      y_hat_str += parse_output_y_hat(output_ele.y_hat_);
    }
    y_hat_str += "]";
    y_hat_str = "[" + y_hat_str;

you can simply get ensembled results such as average, min, max, by using custom functions here.
however, I think it is more recommended to program policies to make such results, rather than just merging results

@coldtomatojuice , Great works! Could you please create a pull request that includes all your work?

@withsmilo Sure, I will

@simon-mo : Does Clipper have a plan about selection policy?

@withsmilo @coldtomatojuice Clipper has worked on selection policies before; however, we decided not to implement native selection policies because they require containers to hold state. We have worked on creating a flask app that sits on top of Clipper for A/B, smoke and Blue Green testing.

I think we need some discussion about merging this into our develop right now.
This is a naive way of supporting ensemble results, so instead of merging into develop directly, it might be better creating a new branch for this (for more features). Also, we should take care of some backward compatibility as well as unit tests. If the flask app works well, we probably don't need to have this feature on Query Frontend.
We will get back to this around the end of May. And also thank you for the tips and PR @coldtomatojuice!

Yes, I fully understand the plan what you guys have on upcoming clipper versions, so I issued this first to let people know the way they can modify clipper instantly to get ensemble results from multiple models.
if there are more requirements regarding this feature, it would be better to develop some instant ensemble features, not to make conflict with flask apps, I reckon.
Thank you for your comment! @rkooo567 @withsmilo

@RehanSD @rkooo567 @coldtomatojuice
Thank you for your comments.
My opinion is that implementing some selection policies in Clipper can make the query_frontend a bottleneck in very high traffic environments and make error handling very difficult because the response times of ensemble models are various and may not have a uniform pattern. When using Clipper at the production level, I think bottlenecks should occur in the model service, not the query_frontend, and should scale the model service as much as possible.
So I agree to create a flask app that implements the selection policy in front of the Clipper. It will be very nice if the flask app could support both real-time and batch updates to the selection policy. I'm also designing a flask app that implements a variety of MAB algorithms, and I'll share it when it comes to performance.
@coldtomatojuice , I am really sorry that I could not give good news despite the great contribution.

@withsmilo @coldtomatojuice  I am planning to update our contribution doc in a few week. I will add this issue as a tip until our flask app is successfully merged.

@coldtomatojuice Thanks for the contribution again! I will add this link to the new contribution doc. Also, please feel free to contribute other features if you have!

Hi @rkooo567, where can we find the "flask app"? Would it be possible to share it somewhere (even if it is on a very early stage) so that we can test on it? Thank you.

I believe adding a Flask app in front of Clipper is not a good idea. Python is a garbage collected language and using it as a proxy may result in expected latency, which goes against the goal of Clipper.
Could you explain why you think implementing the feature in query would make it a bottleneck @withsmilo ? I think the only problem here lies in the statefulness of Clipper Query. I believe this problem should be addressed separately.
Overall, I think that adding this feature in Query makes more sense.

Also, have you considered using Lua for implementing those policies ? @coldtomatojuice

@jeffjunzhang Currently, there's no progress in this because every contributors are busy.
@antoinesauray That's correct. The reason why we thought about an additional layer is because query frontend is designed to stateless to be easily scaled (But we also found out query frontend has long-lived TCP connection with model containers, so it is technically not stateless now). Flask app was a hypothetical idea because it was the quickest way to develop prototype implementation. Our plan was to implement proof of concept using Flask, see the result, and implement with a different language if the result is not suitable for Clipper.