Add check for a JSON element before attempting to match a string

This has previously caused massive performance issues, especially in packs that frequently match non text elements. (see https://spark.lucko.me/R6fJJ3zXOJ and the massive amounts of the trace that is taken up by JsonSyntaxExceptions and MalformedJsonExceptions that trace back to this line)
This patch first does a sanity check on the text element to see if it ever could be a JSON element.

Very similar to #311 and has some of the same issues such as:

Does not take into account json texts with array root elements
Introduces an unnecessary regex based matching which although together is faster than attempting to match every string; still causes unneeded lag.

Also a note about code style which is that var is used unnecessarily which is far from the code style used within the project, if it's just a String, let it be a String.
As I said in #311, I appreciate you bringing this to my attention and I will be looking into optimizing this section.


RFC-0036 / RFC-0039 / RFC-0051

Coordinate with https://github.com/NixOS/rfcs/blob/master/rfcs/0036-review-process.png
final version of marvin might actually update RFC-0036
See also:

https://github.com/NixOS/rfcs/blob/master/rfcs/0039-unprivileged-maintainer-teams.md
https://github.com/NixOS/rfcs/blob/master/rfcs/0051-mark-stale-issues.md
https://github.com/NixOS/rfcs/blob/master/rfcs/0055-retired-committers.md

Marvin is basically a trial run of rfc 30. What is the intention of this issue? Is there something actionable?
The maintainer teams in 39 help for requesting reviews, but not everyone is in those teams. Stalebot might eventually be replaced, but thats way off into the future. The two can happily co-exist, there is just little point to stalebot with marvin. 55 seems unrelated.

What is the intention of this issue?

Help materializing the mental map of third party by-sailors (and myself) out of somewhat fragmented information.

Is there something actionable?

Not directly.

55 seems unrelated.

I put it since marvin might eventually choose to adopt general maintainers listings as it graduates, in that case it can also reflect the emeritus status.

final version of marvin might actually update RFC-0036

36 is about the RFC process, unrelated to PR reviews.

I put it since marvin might eventually choose to adopt general maintainers listings as it graduates, in that case it could also reflect the emeritus / retired status.

I don't think it will ever pull reviewers from the maintainers list, if that is what you mean. As mentioned previously, I'd rather have people review who actively signed up for it (and set a rate limit). ofBorg already pings maintainers.
Also even if we were to do that, we wouldn't have to take any action regarding 55 since we could just pull from the team.

Help materializing the mental map of third party by-sailors (and myself) out of somewhat fragmented information.

It might be a good idea to mention RFC 30, maybe also 51 in the README. Feel free to open a PR if you like. I'll close the issue for now, since this is probably not the best place to make the RFCs discoverable. I'd rather keep the issue tracker actionable.

Nice and actionable suggestion. Thanks for clarification, this might help others as well to wrap their head around.


Add cray module to load singularity

The check ContainerMpichOSUTest fails on Pilatus in the daily run of the regression test suite:
Lmod Warning: Failed to find the following module(s):
"singularity/3.5.3-eiger" in your MODULEPATH

Try:
    $ module spider singularity/3.5.3-eiger
to see if the module(s) are available across all compilers and MPI implementations.

The reason is that the module cray is not loaded, since the module singularity is not created in a toolchain with a PrgEnv modulefile: therefore I am adding the request to load the module cray in the initialization of the check.

The CI still fails with the same error message, I am likely missing something in the fix: could you please have a look @teojgo?

I have changed the configuration file of Pilatus following @teojgo's advice, now the CI passed.


Financial Data not fetched

My code:
import yfinance as yf
msft = yf.Ticker('msft')
msft.financials
It returns empty dataframe:
Empty DataFrame
Columns: [Open, High, Low, Close, Adj Close, Volume]
Index: []
This is same for:

msft.financials
msft.quarterly_financials
msft.balance_sheet
msft.quarterly_balance_sheet
msft.cashflow
msft.quarterly_cashflow
msft.earnings
msft.quarterly_earnings

I am also experiencing this issue.

There is a bug in the code where the URL is configured wrongly.
The issue is found here in base.py
data = utils.get_json(url+'/financials', proxy)
just replace with the code below and it should work!
url = "{}/{}/financials".format(self._scrape_url, self.ticker)
data = utils.get_json(url, proxy)

scraping is slow. Use query2 instead of query1. Basically yfinance is technically deprecated.

Check this out: https://query2.finance.yahoo.com/v10/finance/quoteSummary/escorts.ns?modules=balanceSheetHistory

Having the same issue.

scraping is slow. Use query2 instead of query1. Basically yfinance is technically deprecated.

ohno.  Is there some alternative ways to get historical financial data through API?

Fixed it myself: https://pypi.org/project/yahfin

Fixed it myself: https://pypi.org/project/yahfin

Hi @theonlyanil - why not contribute to yfinance and add your code via pull request?

Hi @theonlyanil - why not contribute to yfinance and add your code via pull request?

Why are we using query1 instead of 2?
I have faced issues with some stocks being outdated because of it.

@vrnvorona - The difference between query1 and query1 is that query1 used HTTP/1.0 while query2 uses HTTP/1.1. The data is the same.
In any case - v. 0.1.61 used query2 as its faster when using proxy or persistent connections :)


NestedScrollView does not allow nested scrolling when content extent is less than 2 x viewport height.

Steps to Reproduce
A NestedScrollView containing a CustomScrollView (oer perhaps any scrolling view) with content less than twice the viewportDimension (screen height) will not permit scrolling.
One possible source for this behavior seems to be _NestedScrollPosition.updateCanDrag, which compares the totalExtent it receives (which is derived from maxScrollExtent) with viewportDimension (which has already been subtracted from the maxScrollExtent in RenderViewport.performLayout around line 1279). Replacing viewportDimension with 0.0 in updateCanDrag fixes my observed issue, but might have other side effects I'm not aware of.
Tested on 1.10.7 and master (v1.12.17-pre.67). Same behavior for debug/emulator as for release/device.
A simple example to demonstrate (though this can also be observed by using the example from the NestedScrollView documentation, by reducing the number of items from 30 to something extending just beyond the screen):
import 'package:flutter/material.dart';

void main() => runApp(MaterialApp(home: NestedScrollProblem()));

class NestedScrollProblem extends StatelessWidget {
  @override
  Widget build(BuildContext context) => Scaffold(
    body: NestedScrollView(
      headerSliverBuilder: (BuildContext context, bool innerBoxIsScrolled) => <Widget>[ ],
      body: SingleChildScrollView(
        child: Container(
          margin: EdgeInsets.all(8.0),
          alignment: Alignment.center,
          color: Colors.red,
          constraints: BoxConstraints.tight(MediaQuery.of(context).size + Offset(0.0, 100.0)),
          child: Text("This should be scrollable"),
        ),
      ),
    ),
  );
}

Target Platform: Android/iOS
Logs
[√] Flutter (Channel master, v1.12.17-pre.67, on Microsoft Windows [Version 10.0.18362.476], locale en-US)
    • Flutter version 1.12.17-pre.67 at C:\flutter
    • Framework revision 3ea8c87ce9 (4 hours ago), 2019-12-04 13:27:23 +0100
    • Engine revision 1cdfc99314
    • Dart version 2.7.0 (build 2.7.0-dev.2.1 2a13b1fe26)

[√] Android toolchain - develop for Android devices (Android SDK version 29.0.2)
    • Android SDK at C:\Users\****\AppData\Local\Android\sdk
    • Android NDK location not configured (optional; useful for native profiling support)
    • Platform android-29, build-tools 29.0.2
    • Java binary at: C:\Program Files\Android\Android Studio\jre\bin\java
    • Java version OpenJDK Runtime Environment (build 1.8.0_202-release-1483-b03)
    • All Android licenses accepted.

[√] Android Studio (version 3.5)
    • Android Studio at C:\Program Files\Android\Android Studio
    • Flutter plugin version 41.1.2
    • Dart plugin version 191.8593
    • Java version OpenJDK Runtime Environment (build 1.8.0_202-release-1483-b03)

[√] VS Code (version 1.40.2)
    • VS Code at C:\Users\****\AppData\Local\Programs\Microsoft VS Code
    • Flutter extension version 3.6.0

[√] VS Code, 64-bit edition
    • VS Code at C:\Program Files\Microsoft VS Code
    • Flutter extension version 3.6.0

[√] Connected device (1 available)
    • Android SDK built for x86 • emulator-5554 • android-x86 • Android 10 (API 29) (emulator)

• No issues found!

May be solved by using this https://github.com/flutter/flutter/issues/32563#issuecomment-593343499

code sample
import 'package:flutter/material.dart';

void main() => runApp(MaterialApp(home: NestedScrollProblem()));

class NestedScrollProblem extends StatelessWidget {
  @override
  Widget build(BuildContext context) => Scaffold(
        body: NestedScrollView(
          headerSliverBuilder:
              (BuildContext context, bool innerBoxIsScrolled) => <Widget>[],
          body: SingleChildScrollView(
            child: Container(
              margin: EdgeInsets.all(8.0),
              alignment: Alignment.center,
              color: Colors.red,
              constraints: BoxConstraints.tight(
                  MediaQuery.of(context).size + Offset(0.0, 100.0)),
              child: Text("This should be scrollable"),
            ),
          ),
        ),
      );
}

flutter doctor -v
[✓] Flutter (Channel stable, 1.22.5, on macOS 11.1 20C69 darwin-x64, locale en-GB)
    • Flutter version 1.22.5 at /Users/tahatesser/Code/flutter_stable
    • Framework revision<PHONE_NUMBER> (6 weeks ago), 2020-12-10 11:54:40 -0800
    • Engine revision ae90085a84
    • Dart version 2.10.4

[✓] Android toolchain - develop for Android devices (Android SDK version 30.0.3)
    • Android SDK at /Volumes/Extreme/SDK
    • Platform android-30, build-tools 30.0.3
    • ANDROID_HOME = /Volumes/Extreme/SDK
    • Java binary at: /Applications/Android Studio.app/Contents/jre/jdk/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build 1.8.0_242-release-1644-b3-6915495)
    • All Android licenses accepted.

[✓] Xcode - develop for iOS and macOS (Xcode 12.3)
    • Xcode at /Volumes/Extreme/Xcode.app/Contents/Developer
    • Xcode 12.3, Build version 12C33
    • CocoaPods version 1.10.1

[!] Android Studio (version 4.1)
    • Android Studio at /Applications/Android Studio.app/Contents
    ✗ Flutter plugin not installed; this adds Flutter specific functionality.
    ✗ Dart plugin not installed; this adds Dart specific functionality.
    • Java version OpenJDK Runtime Environment (build 1.8.0_242-release-1644-b3-6915495)

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

[✓] Connected device (1 available)
    • Android SDK built for x86 (mobile) • emulator-5554 • android-x86 • Android 10 (API 29) (emulator)

! Doctor found issues in 1 category.

[✓] Flutter (Channel master, 1.26.0-2.0.pre.402, on macOS 11.1 20C69 darwin-x64, locale en-GB)
    • Flutter version 1.26.0-2.0.pre.402 at /Users/tahatesser/Code/flutter_master
    • Framework revision 2a188eeca3 (10 hours ago), 2021-01-17 19:27:00 -0800
    • Engine revision 609036f2bf
    • Dart version 2.12.0 (build 2.12.0-236.0.dev)

[✓] Android toolchain - develop for Android devices (Android SDK version 30.0.3)
    • Android SDK at /Volumes/Extreme/SDK
    • Platform android-30, build-tools 30.0.3
    • ANDROID_HOME = /Volumes/Extreme/SDK
    • Java binary at: /Applications/Android Studio.app/Contents/jre/jdk/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build 1.8.0_242-release-1644-b3-6915495)
    • All Android licenses accepted.

[✓] Xcode - develop for iOS and macOS
    • Xcode at /Volumes/Extreme/Xcode.app/Contents/Developer
    • Xcode 12.3, Build version 12C33
    • CocoaPods version 1.10.1

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

[✓] Android Studio (version 4.1)
    • 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
    • Java version OpenJDK Runtime Environment (build 1.8.0_242-release-1644-b3-6915495)

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

[✓] Connected device (3 available)
    • Android SDK built for x86 (mobile) • emulator-5554 • android-x86    • Android 10 (API 29) (emulator)
    • macOS (desktop)                    • macos         • darwin-x64     • macOS 11.1 20C69 darwin-x64
    • Chrome (web)                       • chrome        • web-javascript • Google Chrome 87.0.4280.141

• No issues found!

code sample
import 'package:flutter/material.dart';

void main() => runApp(MaterialApp(home: NestedScrollProblem()));

class NestedScrollProblem extends StatelessWidget {
  @override
  Widget build(BuildContext context) => Scaffold(
        body: NestedScrollView(
          headerSliverBuilder:
              (BuildContext context, bool innerBoxIsScrolled) => <Widget>[],
          body: SingleChildScrollView(
            child: Container(
              margin: EdgeInsets.all(8.0),
              alignment: Alignment.center,
              color: Colors.red,
              constraints: BoxConstraints.tight(
                  MediaQuery.of(context).size + Offset(0.0, 100.0)),
              child: Text("This should be scrollable"),
            ),
          ),
        ),
      );
}

flutter doctor -v
[✓] Flutter (Channel stable, 1.22.5, on macOS 11.1 20C69 darwin-x64, locale en-GB)
    • Flutter version 1.22.5 at /Users/tahatesser/Code/flutter_stable
    • Framework revision<PHONE_NUMBER> (6 weeks ago), 2020-12-10 11:54:40 -0800
    • Engine revision ae90085a84
    • Dart version 2.10.4

[✓] Android toolchain - develop for Android devices (Android SDK version 30.0.3)
    • Android SDK at /Volumes/Extreme/SDK
    • Platform android-30, build-tools 30.0.3
    • ANDROID_HOME = /Volumes/Extreme/SDK
    • Java binary at: /Applications/Android Studio.app/Contents/jre/jdk/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build 1.8.0_242-release-1644-b3-6915495)
    • All Android licenses accepted.

[✓] Xcode - develop for iOS and macOS (Xcode 12.3)
    • Xcode at /Volumes/Extreme/Xcode.app/Contents/Developer
    • Xcode 12.3, Build version 12C33
    • CocoaPods version 1.10.1

[!] Android Studio (version 4.1)
    • Android Studio at /Applications/Android Studio.app/Contents
    ✗ Flutter plugin not installed; this adds Flutter specific functionality.
    ✗ Dart plugin not installed; this adds Dart specific functionality.
    • Java version OpenJDK Runtime Environment (build 1.8.0_242-release-1644-b3-6915495)

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

[✓] Connected device (1 available)
    • Android SDK built for x86 (mobile) • emulator-5554 • android-x86 • Android 10 (API 29) (emulator)

! Doctor found issues in 1 category.

[✓] Flutter (Channel master, 1.26.0-2.0.pre.402, on macOS 11.1 20C69 darwin-x64, locale en-GB)
    • Flutter version 1.26.0-2.0.pre.402 at /Users/tahatesser/Code/flutter_master
    • Framework revision 2a188eeca3 (10 hours ago), 2021-01-17 19:27:00 -0800
    • Engine revision 609036f2bf
    • Dart version 2.12.0 (build 2.12.0-236.0.dev)

[✓] Android toolchain - develop for Android devices (Android SDK version 30.0.3)
    • Android SDK at /Volumes/Extreme/SDK
    • Platform android-30, build-tools 30.0.3
    • ANDROID_HOME = /Volumes/Extreme/SDK
    • Java binary at: /Applications/Android Studio.app/Contents/jre/jdk/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build 1.8.0_242-release-1644-b3-6915495)
    • All Android licenses accepted.

[✓] Xcode - develop for iOS and macOS
    • Xcode at /Volumes/Extreme/Xcode.app/Contents/Developer
    • Xcode 12.3, Build version 12C33
    • CocoaPods version 1.10.1

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

[✓] Android Studio (version 4.1)
    • 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
    • Java version OpenJDK Runtime Environment (build 1.8.0_242-release-1644-b3-6915495)

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

[✓] Connected device (3 available)
    • Android SDK built for x86 (mobile) • emulator-5554 • android-x86    • Android 10 (API 29) (emulator)
    • macOS (desktop)                    • macos         • darwin-x64     • macOS 11.1 20C69 darwin-x64
    • Chrome (web)                       • chrome        • web-javascript • Google Chrome 87.0.4280.141

• No issues found!


revert connection name

Change the base Connection class name back to WorkspaceConnection.

API change check
APIView has identified API level changes in this PR and created following API reviews.
azure-ai-ml


Segmentation fault occurs on libarrow load when using the pyarrow 17.0.0 arm64 wheel

Describe the bug, including details regarding any error messages, version, and platform.
Under some very specific set of circumstances, importing pyarrow 17.0.0 from an arm wheel triggers a segmentation fault. The error comes from the jemalloc function background_thread_entry that is statically linked into libarrow.so. I can see libarrow.so being opened via strace, and when I run under gdb I see the following backtrace:
[Detaching after vfork from child process 895]
[New Thread 0xfffe18fff1d0 (LWP 960)]
--Type <RET> for more, q to quit, c to continue without paging--c

Thread 128 "jemalloc_bg_thd" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xfffe18fff1d0 (LWP 960)]
0x0000fffe1b2d2844 in background_thread_entry () from /pyenv/versions/3.12.6/lib/python3.12/site-packages/pyarrow/libarrow.so.1700

(gdb) backtrace
#0  0x0000fffe122f1844 in background_thread_entry () from /pyenv/versions/3.12.6/lib/python3.12/site-packages/pyarrow/libarrow.so.1700
#1  0x0000ffff94a3a624 in start_thread (arg=0xfffe122f17e0 <background_thread_entry>) at pthread_create.c:477
#2  0x0000ffff94b3562c in thread_start () at ../sysdeps/unix/sysv/linux/aarch64/clone.S:78
(gdb) bt full
#0  0x0000fffe122f1844 in background_thread_entry () from /pyenv/versions/3.12.6/lib/python3.12/site-packages/pyarrow/libarrow.so.1700
No symbol table info available.
#1  0x0000ffff94a3a624 in start_thread (arg=0xfffe122f17e0 <background_thread_entry>) at pthread_create.c:477
        ret = <optimized out>
        pd = <optimized out>
        unwind_buf = {cancel_jmp_buf = {{jmp_buf = {281466655208940,<PHONE_NUMBER>41168,<PHONE_NUMBER>41166,<PHONE_NUMBER>42112,<PHONE_NUMBER>41167,<PHONE_NUMBER>52256,
<PHONE_NUMBER>09680,<PHONE_NUMBER>07888,<PHONE_NUMBER>46208,<PHONE_NUMBER>07888,<PHONE_NUMBER>05808,<PHONE_NUMBER>94287181, 0,<PHONE_NUMBER>03213793, 0, 0, 0,
                0, 0, 0, 0, 0}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
        not_first_call = <optimized out>
#2  0x0000ffff94b3562c in thread_start () at ../sysdeps/unix/sysv/linux/aarch64/clone.S:78
No locals.

This error is quite difficult to reproduce. In addition to only observing this this particular issue with the pyarrow 17.0.0 release (the issue vanishes I downgrade to an earlier version) and only when testing on arm architectures, it is also highly sensitive to the exact order of prior operations. In my application I load multiple Python extension modules before importing pyarrow, and the order of those imports affects whether or not this issue manifests. The cases where the issue arises do manifest reliably, so it is not a flaky error, but simply adding an unrelated extra import or reordering unrelated imports is often sufficient to make the problem vanish. I attempted to rebuild libarrow.so using the same flags used to build the wheel (I can't be sure that I got them all right though, I based my compilation on the flags in https://github.com/apache/arrow/blob/main/ci/scripts/python_wheel_manylinux_build.sh). and then preload the library, but that too caused the segmentation fault to disappear, so it's also unlikely that I can get debug symbols into the build in any useful way. I am attempting to reduce this to an MWE in https://github.com/rapidsai/cudf/pull/17022, but I am not very hopeful in it being reduced all that far.
Component(s)
Python

Could you also share thread apply all bt full result?
Is there any other Python extension module that also uses jemalloc?

The output is quite large, so I've attached it in a file.
gdb.txt
None of the extensions that I built use jemalloc, but it's possible that something else being loaded into the environment does (e.g. numpy or scipy).

Thanks but sorry.
I couldn't find any hints in the thread apply all bt full result...

Hi @vyasr , jemalloc_bg_thd is a jemalloc thread. When searching online, there seem to be issues with jemalloc on Linux aarch64, see https://github.com/jemalloc/jemalloc/issues/467 for example.
I would recommend you switch to mimalloc instead of jemalloc, see https://arrow.apache.org/docs/cpp/memory.html#default-memory-pool
Note that mimalloc becomes the default in 18.0.0 as well (see #43254).
On our side, perhaps we should simply disable jemalloc on Linux aarch64 wheels? @raulcd

Thanks but sorry.
I couldn't find any hints in the thread apply all bt full result...

No problem @kou, I know these kinds of issues can be a huge pain to track down, especially from this limited information.
If it helps, you can see the error in this GHA run on this PR.

When searching online, there seem to be issues with jemalloc on Linux aarch64, see https://github.com/jemalloc/jemalloc/issues/467 for example.

@pitrou thanks for finding that! That makes sense since it certainly seems like the underlying issue comes from jemalloc and is not arrow-specific.

I would recommend you switch to mimalloc instead of jemalloc

Good idea, at least for testing. I'm testing that now in this GH workflow. The arm wheel-tests-cudf job is the one to look out for, let's see if using mimalloc bypasses the issue. That being said:

Note that mimalloc becomes the default in 18.0.0 as well (see https://github.com/apache/arrow/issues/43254). On our side, perhaps we should simply disable jemalloc on Linux aarch64 wheels?

This seems like the right long-term solution if your suggestion to try mimalloc works for me above. pyarrow is a common enough dependency that a user could end up having pyarrow loaded in their environment without even realizing it, and if the import alone is sufficient to trigger the seg fault it would be quite challenging for the average user to debug. Making mimalloc the default seems sufficient to me since IMHO it's reasonable to expect a user explicitly setting the allocator to recognize this as a potential cause, but I wouldn't be opposed to disabling jemalloc altogether on arm either.

Hmm, @pitrou I still see segfaults in the job that I linked above. Am I configuring the allocator in the correct way in https://github.com/rapidsai/cudf/pull/17022/commits/635b5e0eceeb63460bd28c1d3655b6bd83a49cc1? If so, that suggests that there is an issue with jemalloc that occurs by simply loading the relevant parts of the binary even if no allocation subroutine is invoked, in which case building aarch64 wheels without jemalloc is definitely the way to go because this is beyond the realm of user configuration.

It seems that the https://github.com/jemalloc/jemalloc/issues/467 problem was solved by https://github.com/apache/arrow/pull/10940 .

Could you try nightly wheel that use mimalloc by default?
https://arrow.apache.org/docs/developers/python.html#installing-nightly-packages

If so, that suggests that there is an issue with jemalloc that occurs by simply loading the relevant parts of the binary even if no allocation subroutine is invoked, in which case building aarch64 wheels without jemalloc is definitely the way to go because this is beyond the realm of user configuration.

Ah, that might be the case indeed, if the crash occurs right when importing PyArrow :(

It seems that the jemalloc/jemalloc#467 problem was solved by #10940 .

Ouch, that change was lost along the way.
We have a CMake variable named ARROW_JEMALLOC_LG_PAGE, but it's only passed for the conda recipes currently :-(

@vyasr is there any way to validate the issue has gone away with the nightly wheels?
https://anaconda.org/scientific-python-nightly-wheels/pyarrow/files

I am happy to test out a nightly wheel, but unfortunately I'm not confident that it will tell us anything conclusive. As I mentioned above, in my use case I had a lot of difficulty constructing a true MWE because even small changes like defining a new variable, moving around my imports, or moving imports from one file into another but preserving the order (which still has some effect due to the logic for loading the importing module itself) were sufficient to change whether the error appeared or not, which suggests that some sort of process memory corruption is occurring when the DSO is loaded. As a result, since I assume the nightly wheels will have accumulated many changes since the 17.0.0 release, even if I don't observe the same error it may just be that the error is now simply being hidden by other changes. I can try a few different iterations with different modifications to my scripts to see what happens, though.

Er, are you telling us that it's not simply import pyarrow that triggers the crash?

If you're asking whether python -c "import pyarrow" will trigger the crash, then no, that does not crash for me. Quoting from above:

This error is quite difficult to reproduce. In addition to only observing this this particular issue with the pyarrow 17.0.0 release (the issue vanishes I downgrade to an earlier version) and only when testing on arm architectures, it is also highly sensitive to the exact order of prior operations. In my application I load multiple Python extension modules before importing pyarrow, and the order of those imports affects whether or not this issue manifests. The cases where the issue arises do manifest reliably, so it is not a flaky error, but simply adding an unrelated extra import or reordering unrelated imports is often sufficient to make the problem vanish.

None of the modules that I directly control do any sort of relevant stateful initialization on import, but I cannot guarantee that the same is true for the other modules, so it is entirely possible that something in the stack (e.g. scipy) is doing some sort of initialization of a memory pool that introduces conflicting jemalloc symbols, or some other similar problem (it wouldn't actually be a symbol collision since IIUC libarrow does not make any of its jemalloc symbols publicly visible, but that's illustrative of the class of problems I mean). So roughly speaking, I have
import foo
import bar
... # Other imports
import pyarrow # this seg faults

and changing the sequence of import foo and import bar can change whether the seg fault appears.

So, perhaps there's nothing particular that we should do in PyArrow?

(at least if you could git bisect and find out when precisely the issue starts happening with PyArrow, that could perhaps give a clue)

Well OK, to my (pleasant) surprise upgrading to the latest nightly did not make the error vanish (well I suppose not pleasant that I have a seg fault, but at least pleasant that there's something reproducible happening):
root@g242-p33-0009:/repo# python -c "import cupy; import cudf;"
Segmentation fault (core dumped)
root@g242-p33-0009:/repo# python
iPython 3.12.7 (main, Oct  4 2024, 15:35:43) [GCC 9.4.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import pyarrow
>>> pyarrow.__version__
'18.0.0.dev445'
>>>

The backtrace is the same, still in jemalloc_bg_thd.

So, perhaps there's nothing particular that we should do in PyArrow?

I think compiling out jemalloc or recompiling using the appropriate page size for arm could still make sense. While I haven't been able to reduce my example much further yet, the fact that pyarrow < 17.0.0 works while 17.0.0 and 18 alphas both fail indicate that something meaningful has changed there in the pyarrow binary and anyone could hit it.

(at least if you could git bisect and find out when precisely the issue starts happening with PyArrow, that could perhaps give a clue)

I would be happy to try that, but I would also need to be able to build pyarrow wheels that are equivalent to the build process you have. As I mentioned above

attempted to rebuild libarrow.so using the same flags used to build the wheel (I can't be sure that I got them all right though, I based my compilation on the flags in https://github.com/apache/arrow/blob/main/ci/scripts/python_wheel_manylinux_build.sh). and then preload the library, but that too caused the segmentation fault to disappear

Since the latest pyarrow nightlies fail for me, that suggests that I was indeed not compiling exactly equivalent C++ to what you produce (or perhaps I was but there's also something in the Python build that's relevant since I simply LD_PRELOADed libarrow.so). The nightly index linked above unfortunately doesn't go back far enough for me to install nightlies in between 16.1 and 17 to see where the issue might have arisen.

Could you try https://github.com/ursacomputing/crossbow/actions/runs/11285538259#artifacts (download the "wheel" artifact) that disables jemalloc?

Also, can you tell us which hardware exactly you're using, and what the default page size is?
And it would be nice if you could try to disassemble at the point of the crash.

I am re-running some CI jobs but this is currently the only blocker to create the initial Release Candidate for 18.0.0. Should we merge disabling jemalloc by default on ARM and create the first RC? Should I create the first RC and potentially add this as a patch release if it solves the issue? @kou @pitrou ?

Let's merge GH-44380 and create the first RC!

Note that, for now, this is the only report about segfaults on Linux aarch64, so we're not sure if it's really a problem in general or specific to that use case. Ideally I would like answers to the questions in https://github.com/apache/arrow/issues/44342#issuecomment-2407679240 specifically :-)
It's probably ok to disable jemalloc at least for 18.0.0, though.

Issue resolved by pull request 44380
https://github.com/apache/arrow/pull/44380

Also, can you tell us which hardware exactly you're using, and what the default page size is?

Here is some information, let me know if you would like anything else. The page size is 4kb, so https://github.com/jemalloc/jemalloc/issues/467 doesn't immediately seem to be implicated to me, but I haven't done much more than skim that issue.
root@g242-p33-0009:/repo# lscpu
Architecture:                       aarch64
CPU op-mode(s):                     32-bit, 64-bit
Byte Order:                         Little Endian
CPU(s):                             80
On-line CPU(s) list:                0-79
Thread(s) per core:                 1
Core(s) per socket:                 80
Socket(s):                          1
NUMA node(s):                       1
Vendor ID:                          ARM
Model:                              1
Model name:                         Neoverse-N1
Stepping:                           r3p1
Frequency boost:                    disabled
CPU max MHz:                        3000.0000
CPU min MHz:                        1000.0000
BogoMIPS:                           50.00
L1d cache:                          5 MiB
L1i cache:                          5 MiB
L2 cache:                           80 MiB
NUMA node0 CPU(s):                  0-79
Vulnerability Gather data sampling: Not affected
Vulnerability Itlb multihit:        Not affected
Vulnerability L1tf:                 Not affected
Vulnerability Mds:                  Not affected
Vulnerability Meltdown:             Not affected
Vulnerability Mmio stale data:      Not affected
Vulnerability Retbleed:             Not affected
Vulnerability Spec rstack overflow: Not affected
Vulnerability Spec store bypass:    Mitigation; Speculative Store Bypass disabled via prctl
Vulnerability Spectre v1:           Mitigation; __user pointer sanitization
Vulnerability Spectre v2:           Mitigation; CSV2, BHB
Vulnerability Srbds:                Not affected
Vulnerability Tsx async abort:      Not affected
Flags:                              fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp ssbs
root@g242-p33-0009:/repo# getconf PAGE_SIZE
4096

And it would be nice if you could try to disassemble at the point of the crash.
Here is the gdb disassembly output. I don't know enough about jemalloc to debug this without spending a bit more time to familiarize myself unfortunately, but perhaps it will be meaningful to you.

Hmm, I've tried to understand the disassembly output (not an expert, sorry). I think the crash is happening in this function:
https://github.com/jemalloc/jemalloc/blob/02251c0070969e526cae3dde6d7b2610a4ed87ef/include/jemalloc/internal/tsd.h#L119-L135
Perhaps you could try look for similar issues in the jemalloc issue tracker, and/or to open an issue there? Feel free to notify me.

I took a look through the issue tracker but didn't see any that really seemed quite right. I'll take another look tomorrow and if I can't find anything I will open a new issue, link here, and tag you.

I opened https://github.com/jemalloc/jemalloc/issues/2739 for further discussion on the jemalloc side.

Just stumbled over this. In conda-forge we build with
CMAKE_ARGS="${CMAKE_ARGS} -DARROW_JEMALLOC_LG_PAGE=16"

and that seems to work fine? I remember @xhochy mentioning that we cannot unvendor jemalloc in conda-forge due to "special options" being required. After reading some of the references here, I'm now assuming this is due to https://github.com/jemalloc/jemalloc/issues/467.

We already pass ARROW_JEMALLOC_LG_PAGE=16 when building Aarch64 wheels, so I don't think that one is the explanation.


1013 Too many connections

Hi
For our tests we are using a free license, the initial tests worked fine after activating the licenses. However, lately, we've started noticing the '1013 Too many connections' error.
The strange thing is that we only have one stream open simultaneously so if our understanding is correct this error should not be happening?
What is the trigger for the 1013 Too many connections error? How to resolve this issue?
BR
Alex

Hi,
We tracked down the issue to our own application which did not
dispose the webviews correctly, keeping some streams open in the background.
The issue seems to be resolved for now!
BR
Alex


Transition metrics to own package

What does this PR do?
find . -type f -name "*.py" -print0 | xargs -0 sed -i '' -e 's/pytorch_lightning.metrics/torchmetrics/g'

Hello @teddykoker! Thanks for updating this PR.

In the file pl_examples/basic_examples/conv_sequential_example.py:

Line 34:13: E226 missing whitespace around arithmetic operator

In the file pytorch_lightning/core/step_result.py:

Line 25:13: E226 missing whitespace around arithmetic operator

In the file pytorch_lightning/trainer/connectors/logger_connector/metrics_holder.py:

Line 19:13: E226 missing whitespace around arithmetic operator

In the file tests/core/test_metric_result_integration.py:

Line 23:13: E226 missing whitespace around arithmetic operator

In the file tests/deprecated_api/test_remove_1-3.py:

Line 54:17: E226 missing whitespace around arithmetic operator
Line 58:17: E226 missing whitespace around arithmetic operator
Line 62:17: E226 missing whitespace around arithmetic operator
Line 69:17: E226 missing whitespace around arithmetic operator
Line 73:17: E226 missing whitespace around arithmetic operator
Line 85:17: E226 missing whitespace around arithmetic operator
Line 89:17: E226 missing whitespace around arithmetic operator
Line 93:17: E226 missing whitespace around arithmetic operator
Line 97:17: E226 missing whitespace around arithmetic operator
Line 101:17: E226 missing whitespace around arithmetic operator
Line 105:17: E226 missing whitespace around arithmetic operator

In the file tests/deprecated_api/test_remove_1-4.py:

Line 98:17: E226 missing whitespace around arithmetic operator
Line 102:17: E226 missing whitespace around arithmetic operator
Line 106:17: E226 missing whitespace around arithmetic operator
Line 110:17: E226 missing whitespace around arithmetic operator
Line 114:17: E226 missing whitespace around arithmetic operator
Line 119:17: E226 missing whitespace around arithmetic operator
Line 124:17: E226 missing whitespace around arithmetic operator
Line 128:17: E226 missing whitespace around arithmetic operator
Line 132:17: E226 missing whitespace around arithmetic operator
Line 136:17: E226 missing whitespace around arithmetic operator
Line 140:17: E226 missing whitespace around arithmetic operator
Line 144:17: E226 missing whitespace around arithmetic operator

In the file tests/helpers/simple_models.py:

Line 19:13: E226 missing whitespace around arithmetic operator

In the file tests/models/test_horovod.py:

Line 30:13: E226 missing whitespace around arithmetic operator

In the file tests/test_metric_lightning.py:

Line 4:13: E226 missing whitespace around arithmetic operator

In the file tests/trainer/logging_/test_logger_connector.py:

Line 26:13: E226 missing whitespace around arithmetic operator


Update Kubernetes deps to 1.16

OK, this was a bit of a saga. In short: Kubernetes dependency management is broken, subprojects don't talk to each other, nobody versions things the same way, and I'm not sure how this all works.
In short, Kubernetes 1.14 to 1.16 have made a series of breaking changes between code generation and client interfaces. This is all fine, because we can update using Go modules, right?
It's a nice thought, but totally wrong. Because there is no coordinated release strategy for SIG tooling, you cannot depend on SIGs to keep their dependencies up to date with Kubernetes. In this instance, controller-runtime up until recently was pinned to client-go v11. This would be fine, except for a breaking change. Go Modules also uses the property of minimum version selection to solve modules, and KUDO, core Kubernetes projects, and controller-runtime (and another project we'll discuss in a moment!) all had a diamond dependency. In short, as soon as you update client-go, controller-runtime is broken, but as soon as you update controller-runtime, client-go is broken, unless you downgrade everything to Kubernetes 1.14.
Ok, so this is now fixed on master with some review and help. So we go to update to 1.16, and lo and behold, it all looks like it's working - until we go to compile the controller and CLI. Suddenly, client-go is forced back down to 1.14, breaking everything again. Who's the culprit this time? According to go mod graph, it's Kustomize, which despite being officially included in the Kubernetes CLI, is still using client-go v11.
This is so comical this point, I forced client-go to 1.16, which had more breaking changes in the codegen signatures! I re-generated client-gen off of a 1.16 compatible version, and this all builds now and tests fail.
Really, this makes me want to throw out our dependencies and use a discovery based interface. The situation in Kubernetes is so frustrating for external developers that I'm not sure how someone sanely keeps an operator up to date. I guess that's the point of KUDO, but we should set it all on fire and just use Clojure or something. Codegen is an abomination.

Also, so far, it seems like just overriding client-go works fine. It's the lynchpin that causes the cascading nightmare.


Design: filters and search

Design and behaviour of filters and search when expanded. Currently design just shows icon to click to access filters and search.

Behaviours

When a user searches the page reloads to show related results. In the future we would like to make this a live search.
When a user clicks filter, filter options appear
Once a filter is applied filter button changes to clear filters so that live filters can't be hidden and can only be cleared
User should be able to filter search results or search filtered results
Search field retains the input value the user has provided after search is applied
From the main (all) submissions page filtering and search will move users to a single filtered list of submissions

Design

Filter boxes have had their heigh reduced by 8 pixels from the current design


Use Depot for Docker image builds

Exploring the experience here

It looks like there's ~no speed increase. I think we'd need to change our caching somehow?

It looks like there's ~no speed increase. I think we'd need to change our caching somehow?

Yea, try removing the cache-to and cache-from lines.


** do not merge ** TCF/dictionary/2.0 WIP

do not merge just for tracking purposes
Description Of Changes
Write some things here about the changes and any potential caveats
Code Changes

[ ] list your code changes here

Steps to Confirm

[ ] list any manual steps for reviewers to confirm the changes

Pre-Merge Checklist

[ ] All CI Pipelines Succeeded
Documentation:

[ ] documentation complete, PR opened in fidesdocs
[ ] documentation issue created in fidesdocs

[ ] Issue Requirements are Met
[ ] Relevant Follow-Up Issues Created
[ ] Update CHANGELOG.md
[ ] For API changes, the Postman collection has been updated

closing as this was a temporary branch for integration purposes, no longer necessary since all this great work was merged to main in separate PRs!


Relies on compile definitions for testing instead of env vars.

Also touches https://github.com/maliput/maliput_infrastructure/issues/274
Signed-off-by: Franco Cipollone<EMAIL_ADDRESS>

@agalbachicar Same approach as the one carried out for maliput_malidrive here
Therefore, I will proceed to merge this to unblock other PRs.


Introduce services for observability

Impl PR: SpongePowered/Sponge#3296
Some of you may remember the discussions in Discord. I've recently implemented a prometheus metrics exporter as a plugin (actually a CubeEngine module: observe). A few days ago I also added  health checking to the module to get better supervision of the server and allow the orchestrator to automatically restart the container and I'm currently looking at OpenTracing and if/how that might come in handy (considering intrumenting @Faithcaio's terra module).
This PR is a direct copy from the observe code base minus the implementations. All service interfaces accept PluginContainer instances to track plugin ownership and I do support unregistration, not sure if that is something that is necessary/useful.
Health Checks
In observe's implementation, healthchecks are exposed as an HTTP endpoint which will be polled by docker in our case. The API has the concept of a health probe, which is practically a Suppler<HealthState>, so an arbitrary function that, when asked, exposes the current health state of whatever it is probing. The simple probe I implemented simply has a task running on every tick recording the last tick timestamp and depending on how long that last tick was during the probe call, it will either return HEALTHY or BROKEN. The API differentiates between "sync probes" and "async probes", meaning probes that must be run on the server main thread and must provide their state in a synchronous way and probes that may be called from any thread and provide their result in an asynchronous way. The implementation in observe schedules them separately and joins the results.
Metrics
The metrics service is merely a managing layer on top of Prometheus' java libraries. The dependencies that's being pulled and exposed, is the core library that provides the registries, basic collector types (Gauges, Counters, Histograms). On top of that I added a PullGauge helper, that makes it simple to define stateless gauges, that extract their value on-demand (e.g. while being scraped by prometheus) from some target object. I use these to pull information from the Server and ServerWorld's, without requiring me to create a timer (blackbox monitoring basically). The API, similar to the health check service, differentiates between standard Collector instances, that can be scraped from any thread, and SyncCollectors (just a marker), that must be scraped from the server main thread. The implementation in observe schedules them separately and joins the results.
We use these interfaces and the exporter implementation behind it (netty based webserver, scheduling scraping jobs using the sponge schedulers) for weeks now without issues. We measured the overhead of the sync scraping using aikar timings to confirm the overhead is insignificant. The metrics are powering a Grafana dashboard which some of you might have seen.
Tracing
This one is the latest addition, which I assume would be useful to have, but I haven't actually applied this one directly. The service interface simply provides an opentracing Tracer instance, which is backed by whatever opentracing implementation. I chose jaeger in my implementation, because I have experience with that, but I could even make this easily configurable in the plugin. I don't really see much more that needs to be covered by the service interface here. I could however imagine having a set of helpers to ease the instrumentation of code. Since OpenTracing is especially useful for distributed tracing, it might be useful to provide e.g. pre-instrumented web-clients, scheduling interfaces/callback wrapping and so on.

I think I'll drop the TracingService from this PR until I have a clearer idea of what is required for that.

I've been thinking about what @gabizou said in discord about wanting to trace information on a per chunk level. I agree, that the information would definitely be useful, but I don't think prometheus is necessarily the right tool for that job. I've been toying with the idea of generating world to visualized various play high level game aspects, but I guess the same could be done with low-level information.
This makes me reconsider the idea of directly exposing prometheus/openmetrics and instead abstracting over it in order to be more flexible with the provided information.

Just to give an update: I'm working on another design in the observe plugin. I will update this branch once I have something useful

@gabizou @kashike reduced this one to just healthchecks

@gabizou moved the health check stuff over to observer as well. Nothing remains in the PR, so I close it.


State during debugging

When this command is used during a debugging session, are the changes applied immediately or only after the next time a debugging session is started?
Should this command be disabled during a debugging session? I noticed the option under Tools → Options... remains enabled, but there may be usability benefits to disabling the toggle command when it will not be functional.

It's overwhelmingly common for me to need to toggle it either direction during a debug session. That's how the current debug options checkbox works.
I can't imagine a scenario in which I would be happy that it's disabled. If I'm not debugging, I'm pressing a keyboard shortcut and expecting the JMC state to toggle immediately and have an effect on the very next debug session. If I am debugging, I'm pressing a keyboard shortcut and expecting the JMC state to toggle and have an immediate effect like it does in the debug options window. That's about as helpful as it can get IMO.
If I'm using a keyboard shortcut and the item is disabled, I won't know that and it will be irritating when the debug session starts without it. In many cases I'll have to restart the debugging session from the beginning and sometimes that is time consuming.
If I'm using the right click menu and the item is disabled, at least I'll see it and know what to expect, but it'll be nonetheless irritating because I was going to do it my way and you're making me do it in an arbitrary order. Plus in some cases it's nice to have JMC off in the first few milliseconds of the debug session starting- a feat that is hard to reliably achieve even with a keyboard shortcut. So I'll have to press F10, wait for debugging to start, then toggle JMC, then press F5.
tl;dr seems simpler to mimick the existing debug options behavior: take immediate effect, never disable

@jnm2 Thanks. I've never toggled this command myself so my questions were based on not knowing how the existing option behaved if you did toggle it while debugging. Seems easy enough to not ever disable it.


ENYO-1990 Overlay: Text Overlay Offsets to the Right

Closing out - Jira was closed with another fix.


Implement code minification

Mapbox seems to bump the APK size up to 40mb, so there's no more delaying the minification work.

This was merged as e6bdf3c and I haven't seen any crashes come through Sentry about it


Update README: List OpenAI Node.js Library as Dependency

Working on this. Pull request will follow

Thanks for the PR.
What's the idea behind listing this dependency? I mean, we could also list node.js and more obviously the mattermost plugin sdk API and the other utilities we have in package.json.... What's so special about mentioning this method? Those who are interested will be able to read the package.json and find the references in the code. Is this a requirement of the OpenAI API license?

You are right. I just thought it's good practice for beginners to engage in contributing the plugin (like me 😄 ). Fell free to tag this as a wontfix


ap-northeast-3 Osaka region not listed by Session().get_available_regions('ec2')

In [1]: import botocore

In [2]: print botocore.__version__
1.9.23

In [3]: from botocore.session import Session

In [4]: Session().get_available_regions('ec2')
Out[4]:
[u'ap-northeast-1',
 u'ap-northeast-2',
 u'ap-south-1',
 u'ap-southeast-1',
 u'ap-southeast-2',
 u'ca-central-1',
 u'eu-central-1',
 u'eu-west-1',
 u'eu-west-2',
 u'eu-west-3',
 u'sa-east-1',
 u'us-east-1',
 u'us-east-2',
 u'us-west-1',
 u'us-west-2']

We create a list of objects (one for each region) using this call (using boto3 but same underlying call) and the lack of ap-northeast-3 is a  problem.
Once I know that ap-northeast-3 exists I can use it but my module is written to learn about regions from the session not from the ec2 client (because the ec2 client gets it right). Otherwise I could find a region and use the ec2 client to query the regions:

In [18]: ec2 = Session().create_client('ec2', region_name='ap-northeast-2')

In [21]: sorted([ep['RegionName'] for ep in ec2.describe_regions()['Regions']])
Out[21]:
['ap-northeast-1',
 'ap-northeast-2',
 'ap-northeast-3',
 'ap-south-1',
 'ap-southeast-1',
 'ap-southeast-2',
 'ca-central-1',
 'eu-central-1',
 'eu-west-1',
 'eu-west-2',
 'eu-west-3',
 'sa-east-1',
 'us-east-1',
 'us-east-2',
 'us-west-1',
 'us-west-2']

This should be empty:
In [29]: ec2_regions = set([ep['RegionName'] for ep in ec2.describe_regions()['Regions']])

In [30]: session_regions = set(Session().get_available_regions('ec2'))

In [31]: ec2_regions - session_regions
Out[31]: {'ap-northeast-3'}

Since ap-northeast-3 is now GA, can this issue be reopened and resolved?


Audio is longer than original audio when using write_video

🐛 Describe the bug
Hi, I think I found a bug in torchvision's write_video.
When reading a video (with audio) and writing it again without any modifications, the number of audio frames differs by 1024 frames between the original video(/audio) and the newly saved video(/audio).
Using torchaudio's save and load function works fine.
This is my minimal working example:
from torchvision.io import read_video, write_video
import torchaudio

vid, audio, info = read_video("200-4090.mp4", pts_unit="sec")
print("Original video shape:", vid.shape)
print("Original audio shape:", audio.shape)
write_video(
    "tmp.mp4",
    vid,
    30,
    audio_array=audio,
    audio_fps=48000,
    video_codec="libx264",
    audio_codec="aac",
)

vid, audio_vid, _ = read_video("tmp.mp4", pts_unit="sec")
print("saving with torchvision:", vid.shape)
print("saving with torchvision:", audio_vid.shape)

torchaudio.save("tmp.wav", audio, 48000, channels_first=True)
only_audio, t = torchaudio.load("tmp.wav")
print("saving with torchaudio:", only_audio.shape)

I checked the fps and audio_fps numbers. They are correct for my video.
I tested it for different mp4 files with the same results.
In addition, I found out that the written video is always stereo (2 audio channels) even though my original audio is mono (1 audio channel) in my case.
I hope someone can help me with that, Thank you.
Versions
Collecting environment information...
PyTorch version: 2.2.0+cu121
Is debug build: False
CUDA used to build PyTorch: 12.1
ROCM used to build PyTorch: N/A
OS: Ubuntu 20.04.6 LTS (x86_64)
GCC version: (Ubuntu 9.4.0-1ubuntu1~20.04.2) 9.4.0
Clang version: Could not collect
CMake version: version 3.22.4
Libc version: glibc-2.31
Python version: 3.9.18 (main, Sep 11 2023, 13:41:44)  [GCC 11.2.0] (64-bit runtime)
Python platform: Linux-4.18.0-513.5.1.el8_9.x86_64-x86_64-with-glibc2.31
Is CUDA available: True
CUDA runtime version: 11.3.109
CUDA_MODULE_LOADING set to: LAZY
GPU models and configuration:
GPU 0: NVIDIA A100-SXM4-80GB
GPU 1: NVIDIA A100-SXM4-80GB
GPU 2: NVIDIA A100-SXM4-80GB
GPU 3: NVIDIA A100-SXM4-80GB
Nvidia driver version: 555.42.06
cuDNN version: Probably one of the following:
/usr/lib/x86_64-linux-gnu/libcudnn.so.8.2.0
/usr/lib/x86_64-linux-gnu/libcudnn_adv_infer.so.8.2.0
/usr/lib/x86_64-linux-gnu/libcudnn_adv_train.so.8.2.0
/usr/lib/x86_64-linux-gnu/libcudnn_cnn_infer.so.8.2.0
/usr/lib/x86_64-linux-gnu/libcudnn_cnn_train.so.8.2.0
/usr/lib/x86_64-linux-gnu/libcudnn_ops_infer.so.8.2.0
/usr/lib/x86_64-linux-gnu/libcudnn_ops_train.so.8.2.0
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: True
CPU:
Architecture:                       x86_64
CPU op-mode(s):                     32-bit, 64-bit
Byte Order:                         Little Endian
Address sizes:                      48 bits physical, 48 bits virtual
CPU(s):                             32
On-line CPU(s) list:                0-31
Thread(s) per core:                 1
Core(s) per socket:                 16
Socket(s):                          2
NUMA node(s):                       8
Vendor ID:                          AuthenticAMD
CPU family:                         25
Model:                              1
Model name:                         AMD EPYC 7313 16-Core Processor
Stepping:                           1
CPU MHz:                            2994.359
BogoMIPS:                           5988.71
Virtualization:                     AMD-V
L1d cache:                          1 MiB
L1i cache:                          1 MiB
L2 cache:                           16 MiB
L3 cache:                           256 MiB
NUMA node0 CPU(s):                  0-3
NUMA node1 CPU(s):                  4-7
NUMA node2 CPU(s):                  8-11
NUMA node3 CPU(s):                  12-15
NUMA node4 CPU(s):                  16-19
NUMA node5 CPU(s):                  20-23
NUMA node6 CPU(s):                  24-27
NUMA node7 CPU(s):                  28-31
Vulnerability Gather data sampling: Not affected
Vulnerability Itlb multihit:        Not affected
Vulnerability L1tf:                 Not affected
Vulnerability Mds:                  Not affected
Vulnerability Meltdown:             Not affected
Vulnerability Mmio stale data:      Not affected
Vulnerability Retbleed:             Not affected
Vulnerability Spec store bypass:    Mitigation; Speculative Store Bypass disabled via prctl
Vulnerability Spectre v1:           Mitigation; usercopy/swapgs barriers and __user pointer sanitization
Vulnerability Spectre v2:           Mitigation; Retpolines, IBPB conditional, IBRS_FW, STIBP disabled, RSB filling, PBRSB-eIBRS Not affected
Vulnerability Srbds:                Not affected
Vulnerability Tsx async abort:      Not affected
Flags:                              fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid aperfmperf pni pclmulqdq monitor ssse3 fma cx16 pcid sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt tce topoext perfctr_core perfctr_nb bpext perfctr_llc mwaitx cpb cat_l3 cdp_l3 invpcid_single hw_pstate ssbd mba ibrs ibpb stibp vmmcall fsgsbase bmi1 avx2 smep bmi2 erms invpcid cqm rdt_a rdseed adx smap clflushopt clwb sha_ni xsaveopt xsavec xgetbv1 xsaves cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local clzero irperf xsaveerptr wbnoinvd amd_ppin brs arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold v_vmsave_vmload vgif v_spec_ctrl umip pku ospke vaes vpclmulqdq rdpid overflow_recov succor smca fsrm
Versions of relevant libraries:
[pip3] facenet-pytorch==2.6.0
[pip3] numpy==1.26.4
[pip3] pytorch-lightning==1.9.0
[pip3] pytorchvideo==0.1.5
[pip3] torch==2.2.0
[pip3] torch-tb-profiler==0.4.1
[pip3] torchaudio==2.2.0
[pip3] torchinfo==1.8.0
[pip3] torchmetrics==1.4.0.post0
[pip3] torchsummary==1.5.1
[pip3] torchvision==0.17.2
[pip3] triton==2.2.0
[conda] numpy                     1.26.2                   pypi_0    pypi
[conda] torch                     1.12.0+cu113             pypi_0    pypi
[conda] torch-tb-profiler         0.4.1                    pypi_0    pypi
[conda] torchaudio                0.12.0+cu113             pypi_0    pypi
[conda] torchvision               0.13.0+cu113             pypi_0    pypi

Thanks for the report @MKlmt . We'll be consolidating the video decoding/encoding efforts of pytorch within the https://github.com/pytorch/torchcodec/ repo. Torchcodec doesn't support writing videos yet, but that's in scope. That means we won't be updating the video capabilities of torchvision - hopefully you can still use the torchaudio API in the mean time for the correct behavior

Alright. Thank you! Looking forward to Torchcodec video writing function :)


Change "code" command to use lower case "c", due to case sensitivity

Otherwise it'll show the following error when running in Cloud Shell

PS /home/simon> Code $Profile
Code: The term 'Code' is not recognized as a name of a cmdlet, function, script file, or executable program.
Check the spelling of the name, or if a path was included, verify that the path is correct and try again.

@theJasonHelmick
IMPORTANT: When the changes are ready for publication, add a #sign-off comment to signal that the PR is ready for the review team to merge.
#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team

#sign-off

#sign-off


E2E test testing

E2E test testing
Description
Please explain the changes you've made
Issue reference
We strive to have all PR being opened based on an issue, where the problem or feature have been discussed prior to implementation.
Please reference the issue this PR will close: #[issue number]
Checklist
Please make sure you've  completed the relevant tasks for this PR, out of the following list:

[ ] Code compiles correctly
[ ] Created/updated tests
[ ] Unit tests passing
[ ] End-to-end tests passing
[ ] Extended the documentation
[ ] Specification has been updated
[ ] Provided sample for the feature

/ok-to-test

@yaron2 let's see how it works :) I just create pr to validate e2e test in master.

It would actually be better if the failing test was run on this cluster (3) and master was running on (1)

Can close, thanks @dapr-bot


[OP-85] fix negative frequency in gauss_ramsey fit

The build fails with a seemingly unrelated error.
@CumulonimbusCalvus , @peendebak : any idea what this is and how to fix it?
[NbConvertApp] ERROR | Error while converting 'docs/notebooks/analysis/example_charge_sensor.ipynb'
----> 1 h = 1e9scipy.constants.h/(1e-6scipy.constants.elementary_charge)  # Planck's constant in units [ueV/GHz]
  2 kb = scipy.constants.k/(1e-6*scipy.constants.elementary_charge)  # [ueV/K], Boltzmann constant

  3 kT = 10e-3 * kb  # effective electron temperature in ueV

AttributeError: module 'scipy' has no attribute 'constants'

The build fails with a seemingly unrelated error.
@CumulonimbusCalvus , @peendebak : any idea what this is and how to fix it?
[NbConvertApp] ERROR | Error while converting 'docs/notebooks/analysis/example_charge_sensor.ipynb'
----> 1 h = 1e9_scipy.constants.h/(1e-6_scipy.constants.elementary_charge) # Planck's constant in units [ueV/GHz]
  2 kb = scipy.constants.k/(1e-6*scipy.constants.elementary_charge)  # [ueV/K], Boltzmann constant

  3 kT = 10e-3 * kb  # effective electron temperature in ueV

AttributeError: module 'scipy' has no attribute 'constants'

You removed import scipy.constants from one of the files. This triggered an import error in one of the notebooks. I fixed the import in the notebook. @mjwoudstra

Closed. Functionality has been implemented partly elsewhere.


drop umd bundling in favor of iife?

We should consider dropping umd bundling in favor of iife. Few points to note:

umd overlaps a lot with iife.
umd was mainly added for IE11 compat.
klap generates separate module formats for node vs modern browsers, which makes umd little pointless.
iife should help with IE11 compatibility for most cases.

I am unsure if I am missing anything.
This would mean we change compilation strategy from:
pkg.main generates cjs
pkg.module generates es
pkg.browser generates  umd
to
pkg.main generates cjs
pkg.module generates es
pkg.browser generates  iife
This would also mean changing the build target for start command to either es or iife
Let's keep this issue open for user feedback.

it seems there are projects/people who still prefer umd over anything else 😞
closing this for now, but any feedback is welcome.


Mac m1 support

Null-Safe from Felipe and M1 Support

Hi,
I've taken over the mdsflutter admin duties from Tugberk and forked the repo to https://github.com/petri-lipponen-movesense/mdsflutter.
I already published one bug fix, and would like to incorporate the null-safety and M1 supports as well. Could you edit your PR so that it is based on my fork?
Thanks!
Petri L.
Movesense Ltd.

Hi,
I've taken over the mdsflutter admin duties from Tugberk and forked the repo to https://github.com/petri-lipponen-movesense/mdsflutter.
I already published one bug fix, and would like to incorporate the null-safety and M1 supports as well. Could you edit your PR so that it is based on my fork?
Thanks!
Petri L. Movesense Ltd.

Never mind, I managed to do the migration to null safety by myself. However I do not have M1 mac and can't test if the current code (1.1.0-dev.1) supports it or not. Could you try it out?


.net framework 4.7 supports .net standard 1.6

announcement: https://blogs.msdn.microsoft.com/dotnet/2017/05/02/announcing-the-net-framework-4-7-general-availability/

This seems like a small (but important) contribution, so no Contribution License Agreement is required at this point. We will now review your pull request.
Thanks,
.NET Foundation Pull Request Bot

Cross-reference: https://github.com/dotnet/docs/issues/1974

same comment I made for PR #2082

Thanks @hikalkan! Closing this in favor of PR #2245.


Auto arrange upon joining

Would be awesome if there was a checkbox I can click that auto arranges the raid as people join. It would only last during "invite" phase.

@f90 any chance of this being implemented?

Interesting idea, I think that would be a cool feature. It would only be possible to activate that as raid leader so that we prevent the situation where two raid assistants have this feature turned on and constantly try to arrange the raid to different setups, so that they never end up finishing the rearrangement.
I think once I find some more time I will come around to implementing it. Probably a checkbox next to the rearrange button in the group window. Upon clicking it would deactivate the manual arrange button, and it would periodically fire off the rearrangement command (maybe every few seconds), as if you were constantly clicking on the rearrange button yourself.


It does not work for only use Highchart options

It does not work for only use Highchart options, the config.options.series will be override by config.series when watch the 'config.series'.
the following code does not work ,but it will be fine when move the series out of options.
 $scope.pieConfig = {

     options: {
         chart: {
             plotBackgroundColor: null,
             plotBorderWidth: null,
             plotShadow: true,
             width: 200,
             height: 200
         },
         title: {
             text: 20 + '%
Normal Rate',
             //align: 'center',
             verticalAlign: 'middle',
             //useHTML: true,
             y: 0,
             style: {
                 "color": "#333333",
                 "fontSize": "30pt",
                 "fontFamily": "helvetica light,Microsoft YaHei"
             }
         },
         tooltip: {
             pointFormat: '{point.percentage:.1f}%',
             enabled: false
         },
         plotOptions: {
             pie: {
                 allowPointSelect: false,
                 cursor: 'pointer',
                 innerSize: '90%',
                 dataLabels: {
                     enabled: false,
                     color: '#000000',
                     connectorColor: '#000000',
                     format: '{point.percentage:.1f} %'
                 },
                 states: {
                     hover: {
                         enabled: false
                     }
                 }
             }
         },
         colors: [{
             linearGradient: {
                 x1: 0,
                 y1: 1,
                 x2: 0,
                 y2: 0
             },
             stops: [
                 [0, 'rgb(240, 25, 97)'],
                 [1, 'rgb(229, 94, 62)']
             ]
         }, {
             linearGradient: {
                 x1: 0,
                 y1: 0,
                 x2: 0,
                 y2: 1
             },
             stops: [
                 [0, '#EAEAEA'],
                 [1, '#DCDCDC']
             ]
         }],
         series: [{
             type: 'pie',
             data: [
                 ['normal', 20],
                 ['abnormal', 100 - 20]
             ]
         }]
     },
     //The below properties are watched separately for changes.

     // series: [{
     //     type: 'pie',
     //     name: 'Browser share',
     //     data: [
     //          ['normal', 20],
     //         ['abnormal', 100 - 20]
     //     ]
     // }],
 };

This is jsfiddle:
does not work: http://jsfiddle.net/cpsa3/cs5zqL1t/1/
work fine: http://jsfiddle.net/cpsa3/cs5zqL1t/2/

Your second fiddle is the recommended way of using the directive.

Thanks for your reply, but is there any way by only use Highchart native options on this directive?

It may work in some cases but it is not explicitly supported. There is an entry in the FAQ about why.


Error Logging In

Instagram4j instagram = Instagram4j.builder().username("hidden").password("hidden").build();         instagram.setup();         instagram.login();
Throws this error:
Error:(12, 24) java: cannot access org.apache.http.client.ClientProtocolException
class file for org.apache.http.client.ClientProtocolException not found

same problem

Solve the problem, add
<dependencies> <dependency> <groupId>org.brunocvcunha.instagram4j</groupId> <artifactId>instagram4j</artifactId> <version>1.13</version> </dependency> </dependencies>
to pom.xml using Maven.

It did not solve here. Still getting the same error. Any ideas? Thank you.

Addressed in rewrite or no longer relevant.


Slow or no update from spa to HA

I have been using the Gecko integration for two years now and starting up again after winter I'm experiencing the following problem:
Temp changes or turning on/off lights from the spa panel are slow or not registered in home assistant (HA).
Data from HA to the spa is working fine.
I'm controlling garden lights and a heatpump using node-red in HA and this can no longer be done from the spa control panel.
Diagnostics:
Error(s): none
RF signal: 90%
Status: Connected (shows as always connected)
Nothing in the logs.
Hardware:
inYT 413 v3.0
by Gecko Alliance
Firmware: SpaPack:v36.01 Config:61 Log:61
Hardware: EN:88 v15.0 CO:89 v11.0
Any ideas for how to solve this?

I have this same issue. Sometimes temperature changes on the spa get picked up by home assistant immediately and sometimes they never do. Home Assistant will still show that the set point is the previous value, even though it shows the correct information for pump operation history and such.

Hi!
Has something changed? I also have the same problem.

No changes here. I want months without having this issue happen, and then it happened once last week.

Thank You
I found a workaround.
I keep communication awake with an automatism
alias: Jakuzzi ébrentartása
description: ""
trigger:

platform: time_pattern
seconds: /5
condition: []
action:
service: climate.set_temperature
metadata: {}
data:
temperature: "{{ states('input_number.jakuzzi_cel')| float(0) }}"
target:
entity_id: climate.dove_canyon_heater
mode: single

[cid:0a1190ee-243e-445a-8f97-2d66c8083602]
Bari Zoltán
mobil: +36 20 3307033
e-mail:  @.***
Infornax Information Technology Zrt.
Veszprém 8200 József A u. 9.
http://www.infornax.huhttp://www.infornax.hu/

Feladó: BenJewell @.>
Elküldve: 2024. február 26., hétfő 17:45
Címzett: gazoodle/gecko-home-assistant @.>
Másolatot kap: Bari Zoltán @.>; Comment @.>
Tárgy: Re: [gazoodle/gecko-home-assistant] Slow or no update from spa to HA (Issue #82)
No changes here. I want months without having this issue happen, and then it happened once last week.
—
Reply to this email directly, view it on GitHubhttps://github.com/gazoodle/gecko-home-assistant/issues/82#issuecomment-1964620199, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ASVNQTS2KLBTQHNIFJAZA4DYVS3ZFAVCNFSM6AAAAAAVXR4FKGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNRUGYZDAMJZHE.
You are receiving this because you commented.Message ID: @.***>


Add DeprecatedAPIInUse alert

Add an alert that will warn users using deprecated APIs that don't have a precise removal date. This is currently the case for CRDs since there is no way to set a removal time frame in the object.

/remove-lifecycle stale
I need to write a Jira ticket to get the CR deprecation effort prioritized.


Merge new console

What? and Why?

Merge Console 2.0 into master branch

Checklist

[ ] CHANGELOG.md updated? (if required)

All changes have been previously reviewed when merged to the merge-new-console branch. This change replaces sdx-console 1.0


geoda.cars geometry column not automatic

Unclear if you consider this an issue or not, but it would be nice if gpd.read_file(geodatasets.get_path()) always constructed a dataframe with a geometry column. For the geoda.cars dataset, the geometry column is full of None values, but there are lat/lon columns:
gdf = gpd.read_file(geodatasets.get_path("geoda.cars"))

Is the right solution:

Fix this under the hood somehow
Tell the user to construct a geometry column from the lat/lon columns after loading
Inform the user about the underlying CSV structure to pass the right OGR open options

The empty geometry column seems to be issue only for Fiona engine. Reading it with engine="pyogrio" (the new default in the geopandas 1.0), it is not there, but you also get a pandas.DataFrame (that is a bit of inconsistency we need to resolve somehow).
About the solutions, I am not sure what to do.
geodatasets is just giving you an unaltered file and I believe it should stay that way.
The rest is related to a better documentation on a dataset level, which I am not sure how would I do. Maybe via a note in the dataset json?
There is also another option and that is a removal of the dataset if we think that gpd.read_file(geodatasets.get_path("name")) should always result in a GeoDataFrame in an expected form.
Since the goal of geodatasets is to provide mostly educational and illustrational data, having a CSV with point coordinates feels useful but there was never a deep discussion on the scope, so happy to hear your thoughts.


Added support for AROS x86_64

Made some changes to the MUI code to make it work with AROS x86_64 ABIv1. Basically
adding STACKED and changing some ULONGs to IPTR.
The PR require a few fixes to the TheBar mcc as well or else the notifications will not
work, a PR will be created in the AROS repository for those changes.
Also added a simple CMake config file, which also adds support for compiling against
AxRuntime.

Nice!

What does STACKED do btw?

Hi, sorry for the late reply. It makes sure that the items on the stack are correctly sized according to the architecture you are building for.
På 7. august 2020 kl. 20:58:41, Ola Söder<EMAIL_ADDRESS>skrev:
What does STACKED do btw?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.


Character Overlap during Korean IME Composition

Environment
Windows version
Microsoft Windows [Version 10.0.18362.720]

Terminal version
Version: 0.10.761.0

Steps to reproduce

Open "Terminal" app
Type "테스트" (It means test in Korean)
You can probably see the letters overlapping

Expected behavior

Rather than a long explanation, I'd rather attach the behavior of another operating system terminal.

In the case of MacOS, the cursor is positioned under the letter being combined during the Korean language composition process, and there is no collision of letters.

In the Ubuntu 18.04 X Window system environment, if the same operation is performed in the terminal, You can expect that Hangul characters are under the composition process in a cursor shape. And the Hangul characters do not overlap.
Actual behavior

In Version: 0.10.761.0, there is a problem that the Korean characters are overlapped as shown in the picture above.
If this problem is expected to be relatively minor by the core development team, please give a hint to the source code that is expected to be a problem so that I can give you a PR.

A data point: pasting in the same character sequence from the clipboard did not cause such an effect when I tried it, out of curiosity.  I didn't try a Hangeul input method, though.

@jdebp Thanks for the additional comments!  This problem is reproduced in the process of combining IME Hangul characters, so it is difficult to reproduce it by copying the clipboard.

If you test by typing the letters ㅌ, ㅔ, ㅅ, ㅡ, ㅌ, ㅡ in order, you can check the problem.

So at first glance, it seems like the TSFInputControl is getting its set of LayoutRequested events before the Terminal manages to update its cursor, leading to the TextBlock staying in the same place when it should have moved over to where the cursor currently is. If you then type one extra character after the first overlapping keypress, the LayoutRequested will fire again, and will update the TextBlock to the correct position of the cursor.
What's funny is that while debugging this by building it in Visual Studio and running it with the debugger, my breakpoints slow the events down enough that sometimes the Terminal updates its cursor before the LayoutRequested event is received, which makes the text not overlap.
@KennethanCeyer I think the fix might be simple, depending on how difficult it is to figuring out when we should be re-drawing where the TextBlock should be, instead of relying on LayoutRequested to do it. If you're willing to take a stab at it, let me know and I can answer questions if you have any! 😄

@leonMSFT
Thank you for a detailed description. Now it's just a matter of reading the contribution documentation and looking at the code!

Hi @KennethanCeyer, just checking in to see where you're at with this bug, if you haven't had too many chances to make much progress on it, I could pick up from where you left off. Otherwise if you're close to a PR disregard me! 😄 I'm just tracking this bug more closely than others because it's marked as a P1 bug.

@leonMSFT
Yes, I see it on my side, but it takes about 7 days to respond.
Since it's P1, I think I should not hold onto it and become a block
If you can fix it, please proceed immediately. I'm sorry I seemed to be in the way.

Please don’t apologize! You were definitely not a blocker, as I was working on some other bugs in the meantime anyway. I was happy to let you take a look at the bug since you expressed some interest 🙂 I just figured I would check in to see how you were doing and perhaps offer my assistance. Thank you for reporting the bug and looking into it and providing your findings in the meantime though, I really appreciate it! 👍🏻

I see this same problem in version 1.11.2921.0 when Korean typing was made in Cygwin bash.
Both windows 10 and 11 shows same problem.
No issue with cmd and PowerShell.

I also found the bug reproducible in 1.11.2921.0. as mentioned by @sykwon66

Seems fixed in 1.12.10982.0.
However there is actually very short time being overlapped still remained.
Previous: chars overlapped and stayed there.
Now: momentarilly overlapped and splits..
Fixed but annoying to see.


Enhancement / research: Windows containers backend

Expected Behavior
Attempt to port gateway and/or function watchdog over to Windows containers.
Possible Solution
Easiest way to try this may be to start by porting the watchdog component over to Windows containers and then attaching it to the existing Linux API Gateway.
Help wanted: yes!

Watchdog ported successfully to Windows back-end. Next task is to create mixed-swarm and attempt deployment via Swarm constraints.

[ ] Deploy as swarm service on Windows only swarm

Appears to fail with HNS error, even though driver + KB present.

[ ] Deploy in mixed swarm with constraint


Update README with clearer instructions for running the server

Problem
While trying to get the readium-go-toolkit server running locally, I encountered two main pain points:

The publication-path specified in the example config file (./publications) doesn't match the actual location of the test publications in the repo (./test). This caused some confusion and lost time trying to troubleshoot why no publications were being served.

The current README lacks clear information about what endpoints are available and how to interact with them to retrieve publication data. As a new user, I had to dig through the code to understand the API surface.

Solution
This PR updates the README to address these issues and smooth out the onboarding process for new developers:

Adds a note in the "Running the server" section calling out the publication-path discrepancy and providing instructions on how to resolve it
Introduces a new "Accessing a publication" section with step-by-step examples of how to hit the /list.json, /manifest.json, and asset endpoints to retrieve publication data
Includes a comment in the example config file about updating publication-path to ./test when using the provided test publications

Benefits

Reduces confusion and frustration when first trying to run the server locally
Provides a clear "happy path" for getting up and running with the API and exploring the functionality
Improves the overall developer experience and onboarding process for the project

Hi @doomuch , sorry about the delay in response, I was on a trip and was not available here. First of all, thanks very much for interest in helping with the docs, that's not my strong point. However, I was planning to remove the cmd/server program, in favor of the rwp program's serve function, which is effectively replacing it, save for a few things that I don't think should be decided by this implementation (e.g. Sentry as the error reporting service).
I think your documentation could be adapted to the rwp serve command as well. Let me know what you think, I can also try and work on that.


[scss] validate @imports as errors for not existing local files

Hello, when i import a none existing local scss file via @import no error is shown.

But InteliSense works, availble local files are listed.
Version: 1.32.3
Commit: a3db5be9b5c6ba46bb7555ec5d60178ecc2eaae4
Date: 2019-03-14T23:38:49.842Z
Electron: 3.1.6
Chrome: 66.0.3359.181
Node.js: 10.2.0
V8: 6.6.346.32
OS: Linux x64 4.15.0-46-generic

It's very unlikely we will add this feature for two reasons:

Performance: it requires the css/scss language server to observe file changes.
false errors: if we don't fully and correctly re-implement the scss import lookup there will be errors on imports that are actually valid. There are also plugins that allow additional import syntaxes (https://stackoverflow.com/questions/6502313/when-using-sass-how-can-i-import-a-file-from-a-different-directory)

While we provide some linting in the scss language server, we want to stay lightweight. You rather want to run your actual build script in watch mode, e.g. as a task, to get the errors.


Added support for setting cbr hostname in environment variables

This resolves #3 issue,
added the environment settings for url scheme and hostname, leaving cbr.ru as defaults.

Scheme seems to be correct https://tools.ietf.org/html/rfc3986#section-3.1


Not properly aligned

Hey @codervivek5 This section is not properly aligned. Please assign me this issue.  Thank you!

@codervivek5 Please assign me this issue so that I can start working on it.

@codervivek5 Please assign me this issue so that I can start working on it.

@codervivek5 Please assign me this issue so that I can start working on it.


[Feature Request]

Add feedback when connection config is invalid. Currently, it just hangs indefinitely without feedback which makes it hard to debug.
Possibly add a timeout to the connection and fail with an error?

You can do
Redis.on('error', function (error) {

})

Docs for events http://adonisjs.com/docs/3.1/redis#_lifecycle_events

Closing


When the type of css and less in the module is set to css, the css set in the component is invalidate

System Info
System Info:
System:
OS: macOS 13.4.1
CPU: (10) arm64 Apple M1 Pro
Memory: 32.00GB
Shell: 5.9 - /bin/zsh
Binaries:
Node: 14.20.1
pnpm: 7.9.0
Browsers:
Chrome: 114.0.5735.198（正式版本） (arm64)
npmPackages:
@rspack/cli: 0.2.6
Details
Here's a vue project, in which rrspack.config.js is configured as follows:
const { VueLoaderPlugin } = require("vue-loader");
/** @type {import('@rspack/cli').Configuration} */
const config = {
context: __dirname,
entry: {
main: "./src/main.js"
},
builtins: {
html: [
{
template: "./index.html"
}
]
},
devServer: {
historyApiFallback: true
},
devtool: false,
plugins: [new VueLoaderPlugin()],
module: {
rules: [
{
test: /.vue$/,
use: ["vue-loader"]
},
{
test: /.css$/,
use: ["postcss-loader"],
type: "css"
},
{
test: /.less$/,
use: ["less-loader"],
type: "css"
},
{
test: /.svg$/,
type: "asset/resource"
}
]
},
experiments: {
css: false,
},
};
module.exports = config;
Reproduce link
https://gitee.com/tuoy/rspack-vue-demo
Reproduce Steps

install pnpm install
run  pnpm dev
Observe that the text style is not working. We expect the text color to be red. We have set this style in src/app.vue, but it is not working

you mean css in js not working?

This turns out to be a vue2 support issue. Currently, only vue-style-loader and css-loader combination has been supported, which means experiments.css will not be working now.
Pull requests are welcome for supporting this feature. https://github.com/rspack-contrib/rspack-vue-loader

dev环境可以配置 `
{
test: /.less$/,
use: [
'vue-style-loader',
'css-loader',
'postcss-loader',
{
loader: 'less-loader',
options: {
    }
  }
]

}
`
但是production 环境配置肯定不能是'vue-style-loader‘ 的，按照官网配置的如下：
`
{
test: /.less$/,
type: 'css',
use: [
'postcss-loader',
{
loader: 'less-loader',
options: {
    }
  }
]

}
`
虽然提取出一个css文件，但是都不是我想要的css文件，里面都是这些错误的代码
`
export{default }from "-!../../../node_modules/.pnpm/postcss-loader@7.0.2_postcss@8.4.21_webpack@5.76.1/node_modules/postcss-loader/dist/cjs.js!../../../node_modules/.pnpm/less-loader@11.1.0_less@4.1.3_webpack@5.76.1/node_modules/less-loader/dist/cjs.js??clonedRuleSet-5.use[1]!../../../node_modules/.pnpm/vue-loader@17.0.1_vue@3.2.47_webpack@5.76.1/node_modules/vue-loader/dist/index.js??ruleSet[0]!./black-list.vue?vue&type=style&index=0&id=fa7395a6&lang=less&scoped=true"; export * from "-!../../../node_modules/.pnpm/postcss-loader@7.0.2_postcss@8.4.21_webpack@5.76.1/node_modules/postcss-loader/dist/cjs.js!../../../node_modules/.pnpm/less-loader@11.1.0_less@4.1.3_webpack@5.76.1/node_modules/less-loader/dist/cjs.js??clonedRuleSet-5.use[1]!../../../node_modules/.pnpm/vue-loader@17.0.1_vue@3.2.47_webpack@5.76.1/node_modules/vue-loader/dist/index.js??ruleSet[0]!./black-list.vue?vue&type=style&index=0&id=fa7395a6&lang=less&scoped=true"
`

This turns out to be a vue2 support issue. Currently, only vue-style-loader and css-loader combination has been supported, which means experiments.css will not be working now.
Pull requests are welcome for supporting this feature. #3434

Is there any progress in this support?

fixed by #4292


[bug]: Toast not displaying

Describe the bug
The Toaster component is not displaying on the screen when triggered. Despite following the setup instructions and ensuring the component is correctly imported and used, the toast notifications do not appear.
Affected component/components
Toast
How to reproduce
https://github.com/user-attachments/assets/3df8c6e3-c4c8-4e4b-b810-c17344f31eaf
Bug description:
The Toaster component, part of the shadcn/ui library, is not rendering on the page as expected. This issue persists despite using the recommended setup and usage patterns.
Set up a Next.js project and import the Toaster component from shadcn/ui.
Add the Toaster component to a page and trigger it via a user action (e.g., clicking a button).
Observe that no toast notification appears on the screen.

import { Button } from "@/components/ui/button";
import Head from "next/head";
import {toast} from "@/components/hooks/use-toast";
import { ToastAction } from "@/components/ui/toast";

const TestPage = () => {
    return (
    <>

            <title>Test Page</title>
            <meta name="description" content="This is a test page" />

Test Page

            <Button
      variant="outline"
      onClick={() => {
        toast({
          title: "Scheduled: Catch up ",
          description: "Friday, February 10, 2023 at 5:57 PM",
          action: (
            <ToastAction altText="Goto schedule to undo">Undo</ToastAction>
          ),
        })
      }}
    >
      Add to calendar
    </Button>

    </>
    )
    }
export default TestPage;

layout.tsx

import type { Metadata } from "next";
import localFont from "next/font/local";
import "./globals.css";
import { Open_Sans } from 'next/font/google';

import { Toaster } from "@/components/ui/toaster";
interface RootLayoutProps {
	children: React.ReactNode;
}

// export default async function RootLayout({
//   children,
// }: Readonly<{
//   children: React.ReactNode;
// }>) {
export default  function RootLayout({ children }: RootLayoutProps) {
  return (

      <body
        className={`${geistSans.variable} ${geistMono.variable} ${geistOpenSans.variable}  ${geistGilroy.variable} antialiased`}
      >
        {children}
        <Toaster/>

  );
}

Codesandbox/StackBlitz link
No response
Logs
No errors output.

System Info
macOS 15.0.1 (24A348)

React Version 18.3.1
Next.js Version 14.2.14

Before submitting

[X] I've made research efforts and searched the documentation
[X] I've searched for existing issues

have you made TestPage a client component? that's the only issue i can see here @Evsio0n

@Evsio0n What resolutions are you testing it on? If you go below 640px, it might not appear because of the default class names added to Toast's Viewport element. I had to remove 'sm' class before 'right-0' class to show the toast on the mobile phones. Besides that, I don't see anything in your code that could break the toast...


Error on install.sh

When I run sudo ./install.sh on Ubuntu 16.04, I get this error:
Package libusb-1.0 was not found in the pkg-config search path.
Perhaps you should add the directory containing `libusb-1.0.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libusb-1.0' found
k290_fnkeyctl.cpp:6:31: fatal error: libusb-1.0/libusb.h: Aucun fichier ou dossier de ce type
compilation terminated.
Could not build
install: impossible d'évaluer 'k290_fnkeyctl': Aucun fichier ou dossier de ce type

I think this could be fix by rename the k290-fnkeyctl.sh to k290_fnkeyctl or change the path to the good script on install.sh

Thank you for the report! It looks like it cannot find libusb. Is the corresponding -dev package installed? I re-checked and 1.0 still should be the latest version. But I could not find any package for 16.04 in the web package search. Could you check whether libusb-1.0-0-dev is available and installed on your system?

Ok, thanks. libusb-1.0-0-dev package was not installed on my system. After installation of this package, the script works fine.


Use right repository in docker

Use 47deg user in docker

Should it be higherkindness user instead of 47deg?
@juanpedromoreno

@JesusMtnez As it's based on an environment variable, it's something we can tweak easily down the road.


Remove multiple config section

This PR removes docs for a future feature and redirects to #4578 instead. See this discussion for more details :)

The docs for this PR live here. All of your documentation changes will be reflected on that endpoint.


Add an option to disable/remove/hide selected items from the list in a multiple select

It would be great if you could add an option so that when the user selects one of the options that they don't appear in the list anymore, either that or else they appear grayed out and not selectable.
Something like:
$('#select').select2({
    hideSelected: true
});

I've sort of accomplished it here. The <option> is disabled in the original <select> element and then select2 is re-applied. Disabled elements are hidden with CSS. However I feel it's kind of hackish since I re-add the select2 from scratch on every single change.

At the moment, selected items do get a different style applied, and then reselecting them actually removes them from the current selections.  This would be a pretty dramatic departure from the current behavior, but it makes sense to me.

Actually, if you look at #1538, Kevin makes a pretty good case for why you wouldn't want to hide the selected items completely:

Right now the only way to unselect arbitrary (other than the last) options using the keyboard is to type CTRL + SPACE when the result is highlighted. This is to command for toggling a result, so it will select or unselect the highlighted result depending on what state it was previously in. Screen readers should read out the state of the option (whether it is selected or not) as they move through the results list, which is usually important.

Without an alternate way to unselect arbitrary options using the keyboard, the UX problems caused by that far outweigh the UX annoyances that you currently have by showing the selected results.

This seems like a common request, so we should add it to the documentation.

I just realized that this is a duplicate of #4105.


No such module 'Merge'

I get this error since trying to update the Swift Package from revision 89d980c4db9c636bed505a3df9e64f4287881777 to 6ac261ace4a5b20bdbe16deebfdacf9fe274329a.

@rivera-ernesto fixed!


chore(master): release franckdemoute.fr 5.0.8

:robot: I have created a release beep boop
5.0.8 (2024-12-28)
Bug Fixes

Add resume (d2b8545)

This PR was generated with Release Please. See documentation.

:robot: Release is at https://github.com/Zenoo/franckdemoute.fr/releases/tag/franckdemoute.fr-v5.0.8 :sunflower:


dpo_ov7b.sh imports data_processing which is missing

In train_dpo.py line 41, it imports data_processing which is removed in the latest commit.
from data_processing.utils import load_jsonl, load_json
ModuleNotFoundError: No module named 'data_processing'

+1

same issue. Any solution?


Tabular: Bagged blend-stack

Add option for user-enabled bagging during blend-stacking (such as on medium_quality).
This will allow users to have some models be bagged while others be single models (standard), at the same time.
This is useful if some models are far slower than others: These models can be trained in the standard format, while the fast models can be bagged for improved model quality.
By treating all models as bags, a refit-full of this variant will be roughly equivalent to best_quality if refit_full were to instead keep the bags. This is an effective way to control for overfitting, as bagged models in blend-stacks will never get a chance to overfit on the held-out data.
With large enough data, this may be the recommended strategy for best_quality, as held-out data can compose of only 1% or less of the total data.

Have this function released? I definitely need this, because some models in my  ensemble are very time-consuming and could be improved limited by bagging.

@donut1856 The foundations of this logic exist with use_bag_holdout=True in fit call, but we still don't support a mix of bagged and non-bagged models as of v0.5. One reason is that it is incompatible with multi-layer stacking via out-of-fold predictions due to the non-bagged models being unable to generate out-of-fold predictions.
For single-layer stacking this would work because OOF preds are not required, but I would need to add logic forbidding multi-layer stacking when non-bagged models are present. Also, the hyperparameter definition for this case would be fairly complex and not many users would 1. know it exists. 2. know when to use it. 3. know how to use it properly.
The most appealing use-case is actually to automatically switch from bag to non-bag dynamically based on time limit and heuristics for a given model, but this raises its own complications, such as if the user wishes to fit an extra stack layer via a call to fit_extra, it might not work the way they expect.
This is currently on the back-burner, but I may return to it eventually.

Thank you every much for your reply, Nick!


Gamut volumes for all color spaces, not just perceptual ones.

Bitfrost has the potential to make gamut visualization and related experiments more accessible than ever, but currently only for Lab*, Luv*, XYZ, and their subsets intersected with RGB.
Shouldn't it also provide viewable mesh volumes for RGB, HSL, HSV, and CMYK?

This commit added support for gamut volumes on RGB, HSL, HSV, CYM, and CYMK.  The 32bit Discrete RGB spaces also have support, but as of this commit, the 64 bit spaces have bugs.  All of the discrete gamuts look the same as RGB anyway, so future commits may replace them all with references to the gamut volumes of RGB.


Revise “Logging Architecture” topic

Revise Logging Architecture [preview]

Drop mention of Docker
Mention more about log rotation (there's room for even more)

/sig node

This looks good apart from one small editorial change, so I'm approving this PR in order to keep it moving. Other reviewers, feel free to LGTM once feedback is addressed.
/sig instrumentation
@kubernetes/sig-instrumentation-approvers 👋🏻 PTAL
/approve

/lgtm

I want to fix the CRIContainerLogRotation aspect before I mark this as ready for review.

This is once again ready for review.
Relevant changes since last LGTM.

I rebased against main.

/approve

/label refactor
/lgtm