.github/workflows/** always evaluates as true

      - uses: dorny/paths-filter@v2
        id: changes
        with:
          filters: |
            src:
              - 'src/**'
              - '*.json'
              - '*.js'
              - .github/workflows/**

Always evaluates as true log shows that it indicates that every workflow has been modified.

Similar issue here. I didn't include .github/workflows/** in my filter so that any change to those files would be filtered out.
    - name: Check for changes files in Story Editor Frontend repo
      uses: dorny/paths-filter@v3
      id: filter
      with:
        token: ${{ secrets.GITHUBACTIONSTOKEN }}
        filters: |
          both:
            - 'public/**'
            - 'server/**'
            - 'src/**'
            - '!src/**/*.test.ts'
            - '!src/**/*.cy.ts'
            - 'Dockerfile'
            - 'vite.config.ts'
            - 'package.json'
            - 'package-lock.json'
          component:
            - 'src/**/*.test.ts'
            - 'src/**/*.cy.ts'
          e2e:
            - '__testsPlaywright__/**'

Yet, when I ran a pull request, it states that the both filter is flagged true because there's changes in `.github/workflows/**.

Scratch that, issue was because of how picomatch pattern matches files. Specifically this pattern makes it detect any change but to the tests
            - '!src/**/*.test.ts'
            - '!src/**/*.cy.ts'

Had to use predicate-quantifier: 'every' to fix that issue. Note, it does have a linting error.
https://github.com/dorny/paths-filter/pull/226


Bug: NaN result with projection to 1D latent space

Hi,
thanks for publishing and maintaining this cool project! I played around with UMAP a bit and encountered an oddity: I have a small (n=178) distance matrix that I want to project onto a 1D space. If I run UMAP in version 0.3.0 with the default parameters, sometimes the resulting low-dimensional data consists of NaNs exclusively while sometimes the result seems perfectly fine.
I narrowed it down to the random_state  being used, which seems a bit fishy. To reproduce: I call
res = umap.UMAP(
    n_components=1,
    random_state=8,
    metric='precomputed'
).fit_transform(high_dim_data)

print(numpy.count_nonzero(numpy.isnan(res)))

where high_dim_data is as defined in https://gist.github.com/rmitsch/cd99fcacf6a8f3c0d41af6f903735251.
I didn't observe this behaviour with n_components > 1, but haven't checked thoroughly yet. I just tried various values for random_state until I could reproduce the NaN result.
Is this a known problem? I couldn't find any related issues.

It is not a known problem. My best guess is that the spectral
initialization is going badly for your data. As a workaround you can add
init='random' to your UMAP parameters and that may fix the issue for
now. I'll have to try and track down what is actually going wrong here.
Thanks for the data and a random seed -- that will help a great deal with
reproducing the problem and hopefully fixing it!
On Tue, Jul 17, 2018 at 9:16 AM Raphael Mitsch<EMAIL_ADDRESS>wrote:

Hi,
thanks for publishing maintaining this cool project! I played around with
UMAP a bit and encountered an oddity: I have a small (n=178) distance
matrix that I want to project onto a 1D space. If I run UMAP in version 3.0
with the default parameters, sometimes the resulting low-dimensional data
consists of NaNs exclusively while sometimes the result seems perfectly
fine.
I narrowed it down to the random_state being used, which seems a bit
fishy. To reproduce: I call
res = umap.UMAP(
n_components=1,
random_state=8,
metric='precomputed'
).fit_transform(high_dim_data)
print(numpy.count_nonzero(numpy.isnan(res)))
where high_dim_data is as defined in
https://gist.github.com/rmitsch/cd99fcacf6a8f3c0d41af6f903735251.
I didn't observe this behaviour with n_components > 1, but haven't
checked thoroughly yet. I just tried various values for random_state
until I could reproduce the NaN result.
Is this a known problem? I couldn't find any related issues.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/lmcinnes/umap/issues/85, or mute the thread
https://github.com/notifications/unsubscribe-auth/ALaKBZSHieXSJvN53OnWRFuZlDgANuYkks5uHeOggaJpZM4VS04v
.

Thanks for taking a look into it.

I faced the same issue when trying to run UMAP with n_components=1 with precomputed metric.
It works from time to time, but in most of the cases it prodices NaN embeddings.
Dataset size 1000x1000.
Setting init='random didn't help.
UMAP was installed from git commit 91431b29049f74d66b575d1e632576a6642b9213

Thanks for the report -- that sounds like something that is more likely to
be reproducible. I'm on vacation right now but I'll try to look into this
when I get back.
On Thu, Aug 2, 2018 at 10:00 AM Artsiom<EMAIL_ADDRESS>wrote:

I faced the same issue when trying to run UMAP with n_components=1 with
precomputed metric.
It works from time to time, but in most of the cases it prodices NaN
embeddings.
Dataset size 1000x1000.
Setting init='random didn't help.
UMAP was installed from git commit 91431b2
https://github.com/lmcinnes/umap/commit/91431b29049f74d66b575d1e632576a6642b9213
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/lmcinnes/umap/issues/85#issuecomment-409936459, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ALaKBZl8ro-aGVlYcOz_lpImvDA4ViR5ks5uMwYQgaJpZM4VS04v
.

So the bad news is that I grabbed the data from the gist and ran with the supplied parameters but can't reproduce the error locally here. That, unfortunately, makes it hard to track down the actual issue. I'll keep a lookout, but I can't make any promises on getting this fixed too soon as it seems to be intermittent/hard to reproduce.

@lmcinnes have you tried to run several times with different random initializations? It is non-deterministic. Sometimes works, sometimes not.

Fine suggestion. I set a loop running until I got a failure, which is now reproducible with that seed. I'll try to dig into this soon and see what the actual underlying issues is. Thanks!

I faced the same issue when trying to run UMAP with n_components=1 with precomputed metric.
It works from time to time, but in most of the cases it prodices NaN embeddings.
Dataset size 1000x1000.
Setting init='random didn't help.

Faced a similar issue - but then doing something like 300k * 50 => 300k * 2
When doing 300k * 50 => 300k * 10 faced no errors whatsoever

Got it! Well, at lest the one that I could reliably reproduce. If distinct points ended up having perfectly identical coordinates during the embedding optimization that could trigger problems. I believe I now have a catch in place for that. I would be happy if any of the reporters (especially with reproducible issues) could verify that the current master now resolves the problem for them.

Fixes my problem. The version currently available on pip (0.1.1) does not contain the fix though, does it? I just copied the changes in your commit by hand for now.
Thanks!

Fixed the problem for me. Installed from master 16e7ce624dc984cb4a626d7cdfccff4bd8e7ce2c


Regression failure on Ubuntu 22.04

Hi,
I built Kani on Ubuntu 22.04 and I am getting the following output when running the regression.
regression_output.txt
What can it be?

Would you mind doing export RUST_BACKTRACE=1 and re-run those tests? All errors are of the form
thread '<unnamed>' panicked at kani-driver/src/util.rs:64:18:
called `Result::unwrap()` on an `Err` value: Error renaming file /tmp/kani_tmp_2761667929_concrete_playback.tmp

Caused by:
    Invalid cross-device link (os error 18)

but it would be helpful to know where we are invoking rename from.

Attached is the new log.
regression.txt

This could be a bug in Kani. Is your /tmp folder mounted in a different partition as our home folder?
We currently invoke std::fs::rename() to override the new file, but the documentation of this function clearly states that "This will not work if the new name is on a different mount point."

@celinval - yes. The home folder is nfs while tmp is local to the machine.


chore: zrx swapper cleanup

Description

Remove all v1 logic and standardize on v2 with permit 2
Remove feature flag
Consolidate logic between price and quote using same calcs for buyAmountBeforeFeesCryptoBaseUnit and protocolFee

Issue (if applicable)

closes https://github.com/shapeshift/web/issues/8272
Risk

High Risk PRs Require 2 approvals

Low/Med: cleanup and consolidation of logic, but still swapper data so needs to be checked for accuracy

What protocols, transaction types, wallets or contract interactions might be affected by this PR?

Testing

Ensure zrx swaps still work as intended
Validate correct fees and displayed data

Engineering

:point_up:
Operations

[ ] :checkered_flag: My feature is behind a flag and doesn't require operations testing (yet)

:point_up:
Screenshots (if applicable)
https://snowtrace.dev/tx/0xe05a9718266db9f9b962794125baa68b3c6ccda49fbc6ed011238549fdee8cf1?chainid=43114

Confirmed this is the same behavior as on prod right now, but def seems off and I will take a look at it as a follow up. Thanks for the eyes!


Issue-Merge pull request #13 from MicahZoltu/micah
Updates to @ethereumjs/rlp

Automated Review Comments

I got it.


⚠ TorrentLeech has degraded performance

In 4fc9a74, TorrentLeech ($TL) experienced degraded performance:

HTTP code: 200
Response time: 2224 ms

Resolved: TorrentLeech performance has improved in 4c3b364 after 7 minutes.


Pulseaudio module doesn't work

The pulseaudio module doesn't show up and just errors with
[2019-07-04 18:47:43.162] [error] pulseaudio: argument not found
[2019-07-04 18:47:43.162] [error] pulseaudio: argument not found
[2019-07-04 18:47:43.267] [error] pulseaudio: argument not found
[2019-07-04 18:47:43.267] [error] pulseaudio: argument not found

relevant configuration:
	"pulseaudio": {
		"tooltip": false,
		// "scroll-step": 1, // %, can be a float
		"format": "vol{volume}% {icon}",
		"format-bluetooth": "vol{volume}% {icon}\uf0b1",
		"format-muted": "",
		"format-source": "vol{volume}% {icon}",
		"format-source-muted": "\uf75e",
		"format-icons": {
			"headphones": "",
			"handsfree": "",
			"headset": "",
			"phone": "",
			"portable": "",
			"car": "",
			"default": ["", "", ""]
		},
		"on-click": "pavucontrol"
	},

format-source does have the icon argument atm.
I'll look for a proper split of output/input for a proper configuration :)

Er, do you mean doesn't?

Yeah my bad :)


langchain-nvidia-trt installation

I have  setup.py. When I try to install "langchain-nvidia-trt == 0.0.1rc0" through setup.py, I get the below error.
The conflict is caused by:
    tritonclient[all] 2.42.0 depends on cuda-python; extra == "all"
    tritonclient[all] 2.44.0 depends on cuda-python; extra == "all"
    tritonclient[all] 2.43.0 depends on cuda-python; extra == "all"
    tritonclient[all] 2.41.1 depends on cuda-python; extra == "all"
    tritonclient[all] 2.41.0 depends on cuda-python; extra == "all"
    tritonclient[all] 2.40.0 depends on cuda-python; extra == "all"

I am able to run:
pip install --no-deps langchain-nvidia-trt==0.0.1rc0 separately outside setup.py followed by pip install tritonclient[grpc]. And then I can connect to Triton server. But I am not able to do so within setup.py.

@tapansstardog will you share your setup.py or a minimal reproducer?
➜ python --version
Python 3.12.2

➜ pip install langchain-nvidia-trt==0.0.1rc0
Collecting langchain-nvidia-trt==0.0.1rc0
...

➜ pip freeze | grep -e triton -e cuda -e langchain
cuda-python==12.4.0
langchain-core==0.1.35
langchain-nvidia-trt==0.0.1rc0
tritonclient==2.44.0

@mattf Here is the code:
from setuptools import find_packages, setup

setup(
    name="core",
    version="1.0.2",
    description="desc",
    author="author",
    url="https://github.com/",
    package_dir={"": "src"},
    packages=find_packages(where="src"),
    install_requires=[
        "langchain-nvidia-trt == 0.0.1rc0",
        "tritonclient[grpc] == 2.42.0",
    ],
    python_requires=">=3.10",
)

@tapansstardog i'm not able to reproduce, even when i specify 2.42.0 for tritonclient. it could be there's something else in your environment that is conflicting. is your environment fresh before you run the command? what is the command & full output where you have this error?

Thanks, let me look into the environment.
Just wanted to confirm. Did you install it using setup.py and pip install . command?

yes but with a fresh environment.
➜ tree
.
├── setup.py
└── src

2 directories, 1 file

➜ cat setup.py
from setuptools import find_packages, setup

setup(
    name="core",
    version="1.0.2",
    description="desc",
    author="author",
    url="https://github.com/",
    package_dir={"": "src"},
    packages=find_packages(where="src"),
    install_requires=[
        "langchain-nvidia-trt == 0.0.1rc0",
        "tritonclient[grpc] == 2.42.0",
    ],
    python_requires=">=3.10",
)

➜ virtualenv -p 3.10 .venv
created virtual environment CPython3.10.13.final.0-64 in 115ms
  creator CPython3Posix(dest=/tmp/issue-11/.venv, clear=False, no_vcs_ignore=False, global=False)
  seeder FromAppData(download=False, pip=bundle, setuptools=bundle, wheel=bundle, via=copy, app_data_dir=/home/matt/.local/share/virtualenv)
    added seed packages: pip==24.0, setuptools==69.1.1, wheel==0.42.0
  activators BashActivator,CShellActivator,FishActivator,NushellActivator,PowerShellActivator,PythonActivator

➜ pip install .
Processing /tmp/issue-11
  Preparing metadata (setup.py) ... done
...
Successfully built core
Installing collected packages: cuda-python, brotli, zope.interface, zope.event, urllib3, typing-extensions, types-protobuf, tomlkit, tomli, tenacity, smmap, six, PyYAML, python-rapidjson, protobuf, platformdirs, packaging, orjson, numpy, multidict, mccabe, jsonpointer, isort, idna, grpcio, greenlet, frozenlist, dill, charset-normalizer, certifi, attrs, async-timeout, annotated-types, yarl, tritonclient, requests, pydantic-core, jsonpatch, gitdb, gevent, astroid, aiosignal, pylint, pydantic, gitpython, geventhttpclient, aiohttp, lint, langsmith, langchain-core, langchain-nvidia-trt, core
Successfully installed PyYAML-6.0.1 aiohttp-3.9.3 aiosignal-1.3.1 annotated-types-0.6.0 astroid-3.1.0 async-timeout-4.0.3 attrs-23.2.0 brotli-1.1.0 certifi-2024.2.2 charset-normalizer-3.3.2 core-1.0.2 cuda-python-12.4.0 dill-0.3.8 frozenlist-1.4.1 gevent-24.2.1 geventhttpclient-2.0.2 gitdb-4.0.11 gitpython-3.1.42 greenlet-3.0.3 grpcio-1.62.1 idna-3.6 isort-5.13.2 jsonpatch-1.33 jsonpointer-2.4 langchain-core-0.1.35 langchain-nvidia-trt-0.0.1rc0 langsmith-0.1.36 lint-1.2.1 mccabe-0.7.0 multidict-6.0.5 numpy-1.26.4 orjson-3.10.0 packaging-23.2 platformdirs-4.2.0 protobuf-3.20.3 pydantic-2.6.4 pydantic-core-2.16.3 pylint-3.1.0 python-rapidjson-1.16 requests-2.31.0 six-1.16.0 smmap-5.0.1 tenacity-8.2.3 tomli-2.0.1 tomlkit-0.12.4 tritonclient-2.42.0 types-protobuf-<IP_ADDRESS>40311 typing-extensions-4.10.0 urllib3-2.2.1 yarl-1.9.4 zope.event-5.0 zope.interface-6.2

➜ tree
.
├── build
│   └── bdist.linux-x86_64
├── setup.py
└── src
    └── core.egg-info
        ├── dependency_links.txt
        ├── PKG-INFO
        ├── requires.txt
        ├── SOURCES.txt
        └── top_level.txt

5 directories, 6 files

➜ pip freeze | grep -e triton -e cuda -e langchain
cuda-python==12.4.0
langchain-core==0.1.35
langchain-nvidia-trt==0.0.1rc0
tritonclient==2.42.0

Thanks @mattf . Something is not right on my environment. I tried the same on other machine and didn't see any issue. Need to look into it. I am closing the ticket. Thanks.

Hey @mattf . An update from my end.
I was able to run setup.py on ubuntu 22.04 boxes but facing the concerned issue on MacOS. Wanted to check with you the OS that you used to reproduce the issue. If not MacOS, can you reproduce on that?

@tapansstardog i used Fedora 39. i don't have a MacOS system available to me.


test: Remove usec test for pwm_api

As the pwm interface only takes nanosecond for parameter,
the original test case for mircosecond is not needed.
Check github issue 44887 for more info.
Signed-off-by: Hu Zhenyu<EMAIL_ADDRESS>

This pull request is for issue it8xxx2_evb: tests/drivers/pwm/pwm_api assertion fail #45458
The pwm interface is changed to "always use nanoseconds for set" by commit ae91933c4add21552985dd9af50e49cad80da326
But the test case is not changed correspondingly (delete the usec tests). So the test case will fail on it8xxx2_evb board.


Add tool for managing projects

Initial concept: tool should support package API that can be used by both a CLI and Cloud Code for enhancing developer experience working with Functions Framework for Dart projects, making it easy to create, deploy, and monitor function apps.

[ ] Including project scaffolding support; generate example and starter projects (relates to #19 - one or more starter project templates can also be exposed through stagehand)
[ ] Minimize need for installing other tools (gcloud, stagehand, etc) to work with cloud projects
[ ] Associate current project with a Google Cloud project, deploy, get URL, open logs/traces directly
[ ] Potentially be able to add new handlers (and tests) for different HTTP methods and Cloud Event types to an existing project.

Rationale for project support:
Currently, we require that you install and configure gcloud (see the repo docs). We can make this step easier for users who aren't familiar with the Google Cloud SDK, while still respecting the gcloud configuration, if there is one.
For example, a deploy command might accepts a --project ID argument, but if not supplied, also checks the active gcloud configuration and possibly a project-local configuration, for example:
.function.yaml
project: demo-project
region: us-central1
runtime: cloudrun  # or gcf


Thread-safety

Because plugin developers aren't smart enough to take care of this

A lot of progress has been made on this in 4c2588a4d8b4c0f21ffce574eee8f4077414abcd

Yeah, probably gonna have to write my own thread-safe List implementation to support the necessary operations. ain't memory overhead great!

ok lists are locked down, this should be good.


Tons of Qt warnings when Rviz runs

In the kinetic packaged binaries (perhaps also in the current kinetic HEAD), a warning is printed out a lot whenever Rviz starts.  The number of times this warning prints seems to be a function of what is loaded in the .rviz file.  The default (empty) rviz configuration only spews 4 lines, but other spew hundreds. The lines are all the same “Attempt to set a screen on a child window” warning message.
[ INFO] [1481909923.838898198]: rviz version 1.12.4
[ INFO] [1481909923.838931162]: compiled against Qt version 5.5.1
[ INFO] [1481909923.838939431]: compiled against OGRE version 1.9.0 (Ghadamon)
[ INFO] [1481909925.009882314]: Stereo is NOT SUPPORTED
[ INFO] [1481909925.009967339]: OpenGl version: 4.5 (GLSL 4.5).
0x1bd7c10 void QWindowPrivate::setTopLevelScreen(QScreen*, bool) ( QScreen(0x10f7710) ): Attempt to set a screen on a child window.
0x1be10c0 void QWindowPrivate::setTopLevelScreen(QScreen*, bool) ( QScreen(0x10f7710) ): Attempt to set a screen on a child window.
0x1bdea90 void QWindowPrivate::setTopLevelScreen(QScreen*, bool) ( QScreen(0x10f7710) ): Attempt to set a screen on a child window.
0x1be59a0 void QWindowPrivate::setTopLevelScreen(QScreen*, bool) ( QScreen(0x10f7710) ): Attempt to set a screen on a child window.

Apparently, this is due to using a deprecated widget on multi-monitor systems.
http://stackoverflow.com/questions/33545006/qt5-attempt-to-set-a-screen-on-a-child-window-many-runtime-warning-messages

Thanks for the report. I don't have time to look into it at the moment, but I'll get to it eventually. If anyone has time to make pr to fix this it would go faster.

+1. Run rviz on Kinect version, PX2.
same error occurs. and the rviz will exit and cannot use totally.

this is urgent request...

I don't have time to look into this right now, but perhaps someone else does (maybe even yourself)?

this is urgent request...

See http://wiki.ros.org/Support#Etiquette:

It's considered bad form to list your personal deadlines; Community members answering questions also have them.
Do not beg for help. If there is someone willing and able to help with your problem, you usually get a response. Asking for faster answers will mostly have a negative effect.

+1, seeing the same issue with ROS Kinetic/16.04 on multi-monitor setup

the rosdep view is empty: call 'sudo rosdep init' and 'rosdep update'

Did you try that?

As mentioned here:
this warning messages occur whenever setMinimumWidth()  setMinimumHeight() are called on a QGLWidget under Linux with a dual screen display.
So I searched in the rviz repo, and find here called the setMinimumWidth()  function.
So a fix for this is as the first link suggested:

This is probably a bug in Qt. It will probably be not fixed since it is recommended in the documentation to use the new QOpenGLWidget instead, that appeared in Qt 5.4 (note: "OpenGL" instead of "GL"), which I did and the warning messages disappeared.

So "simply" replace QGLWidget with QOpenGLWidget should work.

I can't reproduce the warning messages in Melodic. In which version / distro do you see them?

Oh, you're right, Melodic version don't have this warning now. Kinectic version, the warning still exists.

We will not fix this issue in Kinetic anymore. Hence, I'm closing this issue.
Thanks for confirming the fix in Melodic.


add-adfsrelyingpartytrust required parameters aren't consistent

In the example, the -identifier parameter is not used. It's also not listed in 2 of the 3 syntax blocks. Seems this parameter is only required when -MetadataUrl or -MetadataFile are not used.
Still it is listed as a required parameter, which the other two parameters are not.
In the second and third syntax block, only -Name is set as required, but the command doesn't run when just Name is defined.

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

ID: 7d3854ea-a248-2b59-197f-0edd6fc9800a
Version Independent ID: 123cee00-5841-0abc-d76b-00f002969f37
Content: Add-AdfsRelyingPartyTrust (adfs)
Content Source: docset/windows/adfs/add-adfsrelyingpartytrust.md
Product: w10
Technology: powershell-windows
GitHub Login: @coreyp-at-msft
Microsoft Alias: coreyp

@officedocsbot assign @e0i

Hello, @Ba4bes
The content is being reviewed in the light of your feedback and we'll keep you posted on updates.
Thank you for providing feedback.


Performing database migrations

Worth looking at:

alembic https://pypi.org/project/alembic/
flyway https://flywaydb.org/

duplicate #168 - we chose alembic because it's part of SQLAlchemy


Font not inherited in theme type variation

Godot version
4.1.1.stable
System information
Ubuntu Linux 22.04, Nvidia
Issue description
Creating a new theme type variation that inherits from a Base Type of Button does not inherit the font of the Button. Instead, it inherits from the Default Font for the theme and ignores the Base Type font. However, the inherited button does correctly inherit other properties like Styleboxes.
I expected the new button to inherit all of the properties of the base type including the font.
Steps to reproduce

Create a new theme
Set a default font for the theme
Create a theme item for Button
Add a different custom font for the Button
Create a theme item called Button2
Set the Base Type for Button2 to Button
Add a Button to a scene
Set the Type Variation to Button2

Minimal reproduction project
ThemeTypeFontBug.zip

This also applies to font size.


Call back with remaining count

The PR adds a 3rd argument for the callback function so that we know the remaining count. This information is important to generate X-RateLimit-Remaining header.
Ideally, we should callback with an object such as {remaining: 100, reset: timeLeft} but that will be a breaking change. Let me know if you prefer to do so.

Looks good to me!  I'll stick with the 3-argument version, to avoid breaking changes as you mentioned and to keep the convenience of being able to treat the second argument as a boolean for whether you were rate-limited or not.
I'll merge, update the readme, and publish

@peterkhayes Thank you for the quick response. I look forward to a new version in npm.

It should be published - let me know if there are issues!


New Org: Methuselah Foundation

https://www.mfoundation.org/who-we-are#our-team

Ready for review


svg element returns to it's original position after window resize/scroll

if transition css property is set to draggable element, the element will move back to it's original position as if the new position values have been removed.
https://jsfiddle.net/u60dpnhv/
steps to replicate:

move the rect element anywhere inside svg
resize window

Hi @girtskokars, thank you for the comment.
Sorry, do you mean that you want to use something (CSS property) with a transition effect?
If so, you can specify the CSS property that you want via transition-property property.
For example, you want to use color property with transition effect:
transition-property: color;

See document: https://developer.mozilla.org/en-US/docs/Web/CSS/transition-property

not exactly, i've set the transition property so the element would animate (transition) to new position when i programmatically set it's new coordinates, but it's not the issue i'm describing - the issue is that the element moves (sets/removes coordinates) when it shouldn't.
if there is no transition property set to the draggable element, it doesn't change it's position after window resizes (correct):

but if i set the transition property and resize the window - svg element moves to it's original position:

you can see and reproduce the problem in the following jsfiddle - https://jsfiddle.net/u60dpnhv/
note that this issue is only with svg elements, other HTML elements (ex, div's) seem to be working correctly

Hmm... Sorry, I couldn't understand that.
What is problem? That is, since you specified the transition, it is a matter of course. Then, the CSS behavior is correct.
Also, you can avoid using the translate for HTML element.
https://anseki.github.io/plain-draggable/#lefttop-option

i'm sorry, i don't think i can make it any clearer
for now i'll just use div elements, as they work without any issues, but if i have the time i'll look into the source code and try to debug the issue

Sorry, I don't know what you want to do, but if you want to do something by using the translate, I think that the PlainDraggable is not suited to your app because it uses the translate to move an element.

No reply came, then this abandoned issue is closed.


Release 1.1.7

Main changes
Fixed bugs:

Push deactivate/activate sequence results in stopped notifications #863

Merged pull requests:

Fix Push Activation State Machine: WaitingForRegistrationUpdate bad state #864 (ricardopereira)

Thanks @paddybyers. I noticed it was outdated so I updated it.


Enhance UI for sample codes

For the sample codes in flutter.io, I'd like to suggest adding a unique UI:

On hover, highlight a block of code, starting from the line under a mouse pointer to the end of the widget, variable, or child (closing bracket, end of line, etc.)
When highlighted, show a copy button on the corner of the highlighted block so that the user can copy the whole block without worrying about finding a matching closing bracket
Highlight goes away on click so that the user can copy custom parts of the sample

It can be particularly useful for users going through the tutorials such as:
https://flutter.io/tutorials/layout/

Issue moved to flutter/website #1968 via ZenHub


vscode not re-reading files from disk even after closing unedited file buffers

VSCode Version: Version 1.17.2 (1.17.2)
OS Version: MacOS 10.12.6 (16G29)

Steps to Reproduce:

Open file in project (don't edit it)
Change file outside of vscode
File change not reflected in vscode
Close file in vscode
Re-Open File in vscode
File change still not reflected in vscode

Reproduces without extensions: Yes

@breathe is that reproducible? it should at least show the content after reopening

Sorry — the issue went away on its own several releases ago — apologies for going silent here.


Fix group names in inventory to remove warning + some linting

Group names must be valid variable names, see
https://docs.ansible.com/ansible/latest/user_guide/playbooks_variables.html#creating-valid-variable-names

fantastic! thanks for the contribution

i think change to the default behavior for when no target_hosts is specified need to be reverted

done


ListSkillsets must take a select parameter in search documents

In search-documents, the ListSkillSets operation must take a select parameter. Please fix the code.

Code merged. Closing the issue


Bad keys in Terraform plugin for Softlayer provider

I setup a simple Terraform instance test for Softlayer based off of the AWS-Two-Tier example.  When I ran the Provision I could see the 'instance-x.tf.json' file and the instance-terraform plugin was running 'terraform apply' regularly as expected.  However, when I checked SoftLayer, nothing appeared.
I then stopped the plugin and ran terraform apply manually and got the following error messages:

4 error(s) occurred:

softlayer_virtual_guest.instance-1493408012: "name": required field is not set
softlayer_virtual_guest.instance-1493408012: : invalid or unknown key: hostname
softlayer_virtual_guest.instance-1493408012: : invalid or unknown key: tags
softlayer_virtual_guest.instance-1493408012: : invalid or unknown key: user_metadata

I did some manual playing around with the tf.json file and got it working with the manual terraform apply by:

renaming the "hostname" key to "name"
renaming the "user_metadata" key to "user_data"
removing the "tags" entry altogether (couldn't figure out a way to get that to work).

I got those updated names from the Argument Reference for the SL Terraform Provider.
Looking through the issues I saw several people that were having issues that seemed to indicate that they had gotten past this point, however, I couldn't find any documentation showing me how they had done so.  So, it's possible that I've missed something, but, from what I can tell, it appears that the key names in the JSON are incorrect.

Finally got back to this one and I think I found my issue.  Looks like my Provider hasn't been updated in a while and the SoftLayer Provider plugin has had a lot of updates.


Fault-tolerant checklist

🚀 Fault-tolerant training progress tracker
Fault-tolerant training in PL can be activated by setting the environment variable.
PL_FAULT_TOLERANT_TRAINING=1

Tracker for work in progress. The list is incomplete and will be updated.

[x] progress tracking in loops

[x] progress restart of loops

[ ] capturing state of iterable datasets

[x] non-random state, multiple workers
[ ] random state
[x] sampler inside of iterable dataset
[ ] batch sampler
[ ] testing of items above

[ ] capturing state of map-style dataset

[x] single worker global random state (#8950)
[x] multiple workers global random state (#8950)
[ ] local generators
[ ] random sampler state, after updates in pytorch 1.10
[ ] testing of items above (partially done in #8950)

[ ] reloading multiple train dataloaders with individual random states (see #8950 for todos in added tests)

[ ] parametrize the important tests in test_auto_restart.py with num_workers > 0 and run as part of slow tests #9086

[ ] end-user guide - how to use and description of limitations

[ ] benchmark iteration/s for small and large models with fault-tolerant enabled vs. not enabled

[ ] add test case for different batch structures (dict, list, etc.)

Open questions:

Do we need to capture torch.cuda.get_rng_state too?

Supplementary documents:
State of fault-tolerant training in PyTorch Lightning

Do we have a design document for the proposed work?
Fault tolerance is very easy to get wrong. We have spent a lot of time at Facebook ensuring fault tolerance in our internal toolkit so we have some idea of multiple things that could go wrong.
It would be great if we went through a careful design review for this one.

@awaelchli @tchaton  - I don't think metrics is properly covered here. One gap today is around the assumptions o saving the metric states only on rank 0. https://github.com/PyTorchLightning/pytorch-lightning/blob/35876bb75f27eb8f44220afd4bfa757a0432d233/pytorch_lightning/trainer/connectors/checkpoint_connector.py#L137-L141
Doesn't this not hold for deepspeed, or any case where we save a part of the lightning module state dict across ranks?

Do we have a design document for the proposed work?
Fault tolerance is very easy to get wrong. We have spent a lot of time at Facebook ensuring fault tolerance in our internal toolkit so we have some idea of multiple things that could go wrong.
It would be great if we went through a careful design review for this one.

Hey @aazzolini,
I entirely agree, this is definitely very error prone ! We are working on this with @awaelchli and we will share it with you asap.
We would be happy to have recorded meeting to present the code too for ease onboarding.
We will really appreciate if Facebook could participate on this feature support, as I believe PyTorch needs improvement to make this process simpler.
Hey @ananthsub,
We didn't investigate the impact of sharding on TorchMetrics yet and added fault tolerant for non-sharded model for our fault tolerant V0.
IMO, we should have a mechanism to prevent sharding by default for Metric as each rank is accumulating their own state.
My intuition is that this assumption should still hold. Before saving, we accumulate the states on all ranks. So each ranks will contain the accumulated states. On reload, we just reset the metric on non-rank 0.
But it might become more intricate if metrics states get sharded, which might results in state collisions.
Best,
T.C


torchaudio.transforms.SpectralCentroid supports only real valued input

🐛 Describe the bug
The SpectralCentroid transform supports only real valued inputs. If complex values are provided, it yields an error : RuntimeError: Cannot have onesided output if window or input is complex. I've tracked down the error and it is caused by the fact that there is no possibility to pass a "onesided" parameter to all the layers so the call to the spectrogram method takes the default parameter value, which is True, thus generating the error.
I think it could be easily fixed and I can create a PR for that.
Some code to reproduce the issue :
import torch
from torchaudio.transforms import SpectralCentroid
start = 0
end = 300 * 3.14
n_points = 8000
theta = torch.linspace(start, end, n_points)
waveform = torch.sin(theta) + 1j * torch.sin(theta)
waveform = waveform.unsqueeze(0)
n_fft = 400
sample_rate = (end - start) / n_points
spec = SpectralCentroid(sample_rate = sample_rate, n_fft=n_fft)(waveform)

Versions
PyTorch version: 1.13.1+cu117
Is debug build: False
CUDA used to build PyTorch: 11.7
ROCM used to build PyTorch: N/A
OS: Ubuntu 20.04.4 LTS (x86_64)
GCC version: (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0
Clang version: Could not collect
CMake version: version 3.16.3
Libc version: glibc-2.31
Python version: 3.8.10 | packaged by conda-forge | (default, May 11 2021, 07:01:05)  [GCC 9.3.0] (64-bit runtime)
Python platform: Linux-4.14.294-220.533.amzn2.x86_64-x86_64-with-glibc2.10
Is CUDA available: False
CUDA runtime version: No CUDA
CUDA_MODULE_LOADING set to: N/A
GPU models and configuration: No CUDA
Nvidia driver version: No CUDA
cuDNN version: No CUDA
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:                   46 bits physical, 48 bits virtual
CPU(s):                          8
On-line CPU(s) list:             0-7
Thread(s) per core:              2
Core(s) per socket:              4
Socket(s):                       1
NUMA node(s):                    1
Vendor ID:                       GenuineIntel
CPU family:                      6
Model:                           85
Model name:                      Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz
Stepping:                        7
CPU MHz:                         3103.732
BogoMIPS:                        4999.98
Hypervisor vendor:               KVM
Virtualization type:             full
L1d cache:                       128 KiB
L1i cache:                       128 KiB
L2 cache:                        4 MiB
L3 cache:                        35.8 MiB
NUMA node0 CPU(s):               0-7
Vulnerability Itlb multihit:     KVM: Vulnerable
Vulnerability L1tf:              Mitigation; PTE Inversion
Vulnerability Mds:               Vulnerable: Clear CPU buffers attempted, no microcode; SMT Host state unknown
Vulnerability Meltdown:          Mitigation; PTI
Vulnerability Mmio stale data:   Vulnerable: Clear CPU buffers attempted, no microcode; SMT Host state unknown
Vulnerability Retbleed:          Vulnerable
Vulnerability Spec store bypass: Vulnerable
Vulnerability Spectre v1:        Mitigation; usercopy/swapgs barriers and __user pointer sanitization
Vulnerability Spectre v2:        Mitigation; Retpolines, STIBP disabled, RSB filling
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 ss ht syscall nx pdpe1gb rdtscp lm constant_tsc rep_good nopl xtopology nonstop_tsc cpuid aperfmperf tsc_known_freq pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch invpcid_single pti fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid mpx avx512f avx512dq rdseed adx smap clflushopt clwb avx512cd avx512bw avx512vl xsaveopt xsavec xgetbv1 xsaves ida arat pku ospke
Versions of relevant libraries:
[pip3] mypy-extensions==0.4.3
[pip3] numpy==1.22.2
[pip3] sagemaker-pytorch-training==2.4.0
[pip3] torch==1.13.1
[pip3] torchaudio==0.13.1
[pip3] torchvision==0.11.3+cpu
[conda] mkl                       2020.2                      256    anaconda
[conda] mkl-include               2020.2                      256    anaconda
[conda] numpy                     1.22.2                   pypi_0    pypi
[conda] sagemaker-pytorch-training 2.4.0                    pypi_0    pypi
[conda] torch                     1.13.1                   pypi_0    pypi
[conda] torchaudio                0.13.1                   pypi_0    pypi
[conda] torchvision               0.11.3+cpu               pypi_0    pypi

thanks @rgt-yncrea . We wonder whether does it make sense to pass waveform composed of complex values to the spectrum centroid function? What's the use case?  Thanks!

The usecase is the processing of a RF radar signal. In my case, the Spectrogram gives information about a speed that could either be positive or negative, corresponding respectively to positive/negative frequency in the spectrum. Thus the need to have a two-sided FFT

thanks @rgt-yncrea . We discussed among our team and thought it makes sense. Can you go ahead making an PR? Thanks!

@xiaohui-zhang , I'm working on it. I'm struggling with the local build of torchaudio (related to this issue). Once I manage to build it, I'll open the PR


j'ai fais toutes les mises a jours mais cette erreur persiste meme quand je change de version

Resolving dependencies...
The current Dart SDK version is 3.3.1.
Because biodiv requires SDK version >=3.21.0 <4.0.0, version solving failed.
Process finished with exit code 1

Hi @93cory,
When opening an issue, please try to provide all information indicated in the template so that we can address the issue properly (See bug issue template here)
More specifically:

Please provide the output of flutter doctor -v
Could you share your pubspec.yaml file content?


ReasonML -> ReScript

Closes #731
The *.bs.js files don't really need to be managed by the version control system, so they are removed at the same time.

Hi @smorimoto & thanks for helping. But like I explained this morning in #731 with my last comment, I would like to wait for 0.64 to be published (anytime soon as RN 0.64 is RC4) to publish a last version in ReasonML & then handle the conversion.
Also, .bs.js files are to visualise the generated js code. One goal of this bindings are to ensure zero cost, and visualising generated code help to ensure that we don't produce unwanted & unecessary javascript indirection.
Removing them would make us forget about that goal. Also we cannot just ship this in this package without any minimal checks and the generated JS is a (tiny) part of this.
Last part, keeping ReScript formatting in the git hook is essential to ensure a correctly formatted codebase. So we will have to revisit this PR after changes for 0.64.
We can't just push this as a breaking change just like that. We will do that with a proper transition when we handle the change of name for the package.
For big changes like this, please next time you want to help ask us in issue before handling that. I hope it didn't take you too much time, but I guess thanks to the command I added to rescript doc it was fast to do.
Closing this for now. I hope you understand.

Do you intend to make them available on GitHub? If not, we have no reason to track them.
We are keeping them on GitHub to visualise during PR the generated JS code involved, to ensure there is 0 cost. FYI, previous bindings of this lib where "not zero cost at all" (eg: https://github.com/reasonml-community/bs-react-native/blob/master/bs-react-native/src/style.bs.js). Keeping the generated JS is for us a way to be aware of the code that we are going to add to the end user. For most bindings it doesn't make sense indeed, but since rrn is pretty large, I think it's still better to keep them.

They are not published in npm module

which will only cause problems in the future.

What kind of problems?

If you commit unnecessary files and make git objects grow unnecessarily, the clones will generally be very slow. That's why I don't commit any files that are not needed.

Well, I needed a formatting stuff pretty urgently, so I wrote terrible scripts. Feel free to use it if anyone needs them.
Makefile:
SRCFILES = $(shell git ls-files "*.res" "*.resi")

fmt:
	$(foreach fname,$(SRCFILES),sh scripts/fmt.sh $(fname);)
.PHONY: fmt

fmt-check:
	$(foreach fname,$(SRCFILES),sh scripts/fmt-check.sh $(fname);)
.PHONY: fmt-check

scripts/fmt.sh:
#!/bin/sh

fmt() {
  src="$1"
  backup="${src}.bak"

  node_modules/.bin/bsc -format "$src" >"$backup" && mv "$backup" "$src"
}

fmt "$1"

scripts/fmt-check.sh:
#!/bin/sh

fmt_check() {
  src="$1"
  expected="${src}.expected"

  node_modules/.bin/bsc -format "$src" >"$expected"

  diff=$(diff "$src" "$expected")

  rm "$expected"

  if [ "$diff" != "" ]; then
    echo "Error: $src"
  fi
}

fmt_check "$1"


can't hear people

Hello i did everthing correct but i can't hear people ingame, and my radio doens't show up with the keybinds or /radio

https://github.com/FrazzIe/rp-radio#note

yea did it but i can't still hear nobody? can you join my discord for checking ? or like fast support i tried some many things
https://invite.gg/crimeliferp


feature: how to ask a question about a particular document?

Is there any way to ask a question about a particular document?
I do understand that RAG architecture has not been designed to ask a question about a particular document but wondering is it possible to hack the "retrieval" part by providing a filename?
I can ask a query like "summarize abc.pdf" and sometimes it works, sometimes not! but looking for a more reliable solution.

Check https://github.com/Azure-Samples/azure-search-openai-demo/issues/493#issuecomment-1662814997. I wish I could show available files in the search index when a trigger like @ is used in the UI's question input, similar to how Copilot for MS does.

@bnodir it would be amazing feature!


Updating Spark version from 3.0 to 3.1.1

Spark will hit GA for Kubernetes scheduler in 3.1.1
Ref: https://issues.apache.org/jira/browse/SPARK-33005
Note: The Kubernetes scheduler is currently [in 3.0] experimental. In future versions, there may be behavioral changes around configuration, container images and entry points.

Is this still WIP?

It's ready, just that Spark is yet to release 3.1.1. Right now it's in rc3
stage.
On Fri, 26 Feb, 2021, 10:55 pm Yinan Li<EMAIL_ADDRESS>wrote:

Is this still WIP?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/GoogleCloudPlatform/spark-on-k8s-operator/pull/1153#issuecomment-786783614,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AD35JA4KCJJIXAQMDBCZR2LTA7KRBANCNFSM4XBKELSQ
.

3.1.1 doc is also getting ready: https://github.com/apache/spark-website/pull/319

Is this ready for review?

Is this ready for review?

@liyinan926 Yes, and can you send the current bash script which is creating the following docker images:

gcr.io/spark/spark
gcr.io/spark-operator/spark
gcr.io/spark-operator/spark-py

It will be helpful for those who want to use it to generate the custom spark images or in CI pipelines, Thank You

Is this ready for review?

@liyinan926 Yes, and can you send the current bash script which is creating the following docker images:

gcr.io/spark/spark
gcr.io/spark-operator/spark
gcr.io/spark-operator/spark-py

It will be helpful for those who want to use it to generate the custom spark images or in CI pipelines, Thank You

I followed the instruction here http://spark.apache.org/docs/latest/running-on-kubernetes.html#docker-images.

I have built and pushed the following images:
gcr.io/spark-operator/spark:v3.1.1-hadoop3
gcr.io/spark-operator/spark-py:v3.1.1-hadoop3

Hey @liyinan926 Would it be possible for you to push the base spark 3.1.1 image too?
gcr.io/spark-operator/spark:v3.1.1

Hey @liyinan926
i tried new gcr.io/spark-operator/spark-py:v3.1.1-hadoop3 image with latest spark-operator.
And with 3.1.1 spark i am getting these kind of errors, see gist link.
https://gist.github.com/matus123/723d15f8dd9b29069a8ffa4162534118
i guess, that you need to update helm chart, so it will create serviceAccount with all required permissions ?
PS: i installed helm chart with these commands
- helm repo add spark-operator https://googlecloudplatform.github.io/spark-on-k8s-operator
- helm install my-release spark-operator/spark-operator --namespace spark-operator --create-namespace --set sparkJobNamespace=spark-apps

Hey @liyinan926 Would it be possible for you to push the base spark 3.1.1 image too?
gcr.io/spark-operator/spark:v3.1.1

Done.

Hey @liyinan926
i tried new gcr.io/spark-operator/spark-py:v3.1.1-hadoop3 image with latest spark-operator.
And with 3.1.1 spark i am getting these kind of errors, see gist link.
https://gist.github.com/matus123/723d15f8dd9b29069a8ffa4162534118
i guess, that you need to update helm chart, so it will create serviceAccount with all required permissions ?
PS: i installed helm chart with these commands
- helm repo add spark-operator https://googlecloudplatform.github.io/spark-on-k8s-operator
- helm install my-release spark-operator/spark-operator --namespace spark-operator --create-namespace --set sparkJobNamespace=spark-apps

I also encountered the same error using spark_streaming v3.1.1 inside v3.1.1-hadoop3 image.
However using spark_streaming v3.0.0 provided in v3.0.0 image does not show the error when using JavaStreamingContext.
Is there any reason/changes from v3.0.0 to v3.1.1 that requires "spark" serviceAccount to have the permission to create configmaps?

Hey @liyinan926
i tried new gcr.io/spark-operator/spark-py:v3.1.1-hadoop3 image with latest spark-operator.
And with 3.1.1 spark i am getting these kind of errors, see gist link.
https://gist.github.com/matus123/723d15f8dd9b29069a8ffa4162534118
i guess, that you need to update helm chart, so it will create serviceAccount with all required permissions ?
PS: i installed helm chart with these commands
- helm repo add spark-operator https://googlecloudplatform.github.io/spark-on-k8s-operator
- helm install my-release spark-operator/spark-operator --namespace spark-operator --create-namespace --set sparkJobNamespace=spark-apps

Hi @liyinan926
I also encountered the same error using spark_streaming v3.1.1 inside v3.1.1-hadoop3 image.
However using spark_streaming v3.0.0 provided in v3.0.0 image does not show the error when using JavaStreamingContext.
Is there any reason/changes from v3.0.0 to v3.1.1 that requires "spark" serviceAccount to have the permission to create configmaps?

Looks like the RBAC config in https://github.com/GoogleCloudPlatform/spark-on-k8s-operator/blob/master/charts/spark-operator-chart/templates/spark-rbac.yaml needs to be updated. I'm not sure if Spark 3.1.x introduced some changes in the Kubernetes backend that require the permission to create ConfigMaps.

Hey @liyinan926 Would it be possible for you to push the base spark 3.1.1 image too?
gcr.io/spark-operator/spark:v3.1.1

Done.

Hey @liyinan926
i tried new gcr.io/spark-operator/spark-py:v3.1.1-hadoop3 image with latest spark-operator.
And with 3.1.1 spark i am getting these kind of errors, see gist link.
https://gist.github.com/matus123/723d15f8dd9b29069a8ffa4162534118
i guess, that you need to update helm chart, so it will create serviceAccount with all required permissions ?
PS: i installed helm chart with these commands
- helm repo add spark-operator https://googlecloudplatform.github.io/spark-on-k8s-operator
- helm install my-release spark-operator/spark-operator --namespace spark-operator --create-namespace --set sparkJobNamespace=spark-apps

Hi @liyinan926
I also encountered the same error using spark_streaming v3.1.1 inside v3.1.1-hadoop3 image.
However using spark_streaming v3.0.0 provided in v3.0.0 image does not show the error when using JavaStreamingContext.
Is there any reason/changes from v3.0.0 to v3.1.1 that requires "spark" serviceAccount to have the permission to create configmaps?

Looks like the RBAC config in https://github.com/GoogleCloudPlatform/spark-on-k8s-operator/blob/master/charts/spark-operator-chart/templates/spark-rbac.yaml needs to be updated. I'm not sure if Spark 3.1.x introduced some changes in the Kubernetes backend that require the permission to create ConfigMaps.

Hi @liyinan926 , thank you for the reply.
I think so. Tested using the sparkv3.1.1-hadoop3 image, with or without packing the spark_streaming 3.1.1 into the uber jar, will still throw the error.
May you help review the issue and release a new version of chart for the issue?

Spark 3.1 needs permission to create ConfigMaps, Pods and services
Change the Line 13 to following:
["pods", "configmaps", "services"]

and restrict to the namespace. Try the above, it should work

Spark 3.1 needs permission to create ConfigMaps, Pods and services
Change the Line 13 to include "configmaps" or just add another block.
rules:
- apiGroups: [""]
  resources: ["pods", "configmaps", "services"]

and restrict to the namespace. Try the above, it should work

@ChethanUK could you please include the change in this PR? Thanks.

@ChethanUK could you please include the change in this PR? Thanks.

I think, This should work

@ChethanUK @liyinan926 will this be part of the next release? if it is, when is the next release?

Hi there! Do we have any news on this one?

@ChethanUK can you rebase this PR and resolve the conflict?

@ChethanUK can you rebase this PR and resolve the conflict?

Done, Rebased with master and resolved conflicts

@ChethanUK looks like one of the pre-submit checks failed, can you take a look?

@ChethanUK looks like one of the pre-submit checks failed

Done, Fixed it


feat: dtoss-3350 infrastructure cd pipeline for Azure DevOps

New Azure DevOps CD pipeline.

A code for the CD pipeline for deploying infrastructure from Azure DevOps + few changes in the Terraform code to deploy new version of the Cohort Manager resources (new names, linux-based function apps, etc).
As usual, adding Dan as a reviewer for visibility.

Type of changes

[ ] Refactoring (non-breaking change)
[X] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would change existing functionality)
[ ] Bug fix (non-breaking change which fixes an issue)

Checklist

[X] I am familiar with the contributing guidelines
[X] I have followed the code style of the project
[ ] I have added tests to cover my changes
[ ] I have updated the documentation accordingly
[ ] This PR is a result of pair or mob programming

Sensitive Information Declaration
To ensure the utmost confidentiality and protect your and others privacy, we kindly ask you to NOT including PII (Personal Identifiable Information) / PID (Personal Identifiable Data) or any other sensitive data in this PR (Pull Request) and the codebase changes. We will remove any PR that do contain any sensitive information. We really appreciate your cooperation in this matter.

[X] I confirm that neither PII/PID nor sensitive data are included in this PR and the codebase changes.

As usual, adding @stefaniuk as a reviewer for visibility.


Preliminary support for new task metadata

Checklist before merging

[ ] I added an appropriate entry to CHANGELOG.md

@tcompa I added some tags & some more categories + set the authors. With this, this is good to merge from my side and we can make it the 1.3.3 release that we use to test how we build those interfaces


Global Prometheus metrics for server meta data

Besides user-specific metrics like total hours, etc., I'd like to have another endpoint to expose global meta data about the whole server. Such might include:

Total hours
Number of users
Number of active user (e.g. last 7 days)
Number of tracked heartbeats
Number of aliases (per entity type)
...

What else could be interesting to track over time?

Currently, we rely on wakatime_exporter and don't implement an own /metrics endpoint. However, for this feature, we would have to. Question is, shall that endpoint also expose the user-specific metrics then, or shall we stick with the external tool. The former would be more user-friendly and we would need to pull in Prometheus dependencies anyway. However, latter would be easier to implement.

Added with #126


write swagger content and CLI args to API template, remove all other …

…logic

        YamlMappingNode mapping = (YamlMappingNode)yaml.Documents[0].RootNode;

Can you add the sample YAML document you are parsing here?

Refers to: src/APIM_ARMTemplate/apimtemplate/FileHandlers/YAMLReader.cs:81 in 11f35a3. [](commit_id = 11f35a3fa1b3cf5b67b3694eb8a9a1ea06b05059, deletion_comment = False)

        YamlMappingNode mapping = (YamlMappingNode)yaml.Documents[0].RootNode;

Rather than parsing through the structure of YAML ourselves,
should we leverage some nugets.. which are MIT Licensed like
https://github.com/aaubry/YamlDotNet

Refers to: src/APIM_ARMTemplate/apimtemplate/FileHandlers/YAMLReader.cs:27 in 11f35a3. [](commit_id = 11f35a3fa1b3cf5b67b3694eb8a9a1ea06b05059, deletion_comment = False)


Be more intelligent about deciding whether to use an online checkpoint

It would be nice to know in advance whether an appropriate instance of neo-express is running, and do an online checkpoint if it is and offline otherwise.
We could either:

have the dev-tracker keep track of which instances are running
Or:
make a change in neo-express so the neo-express checkpoint command knows which instances of neo-express are running

The second option requires work in neo-express but has the advantage that the UI will always do the right thing even when neo-express is not run from within the dev-tracker.

See https://github.com/neo-project/neo-express/pull/53


[Feature]: Widget table trigger the enter key when searching

Is there an existing issue for this?

[X] I have searched the existing issues

Summary
Need a trigger when the user press the enter key on the search input of the widget table

Why should this be worked on?
For exemple when searching and press enter, we could run backside event

@rblachon you can use the onSearchTextChange event to do this

@Nikhil-Nandagopal Thanks for your answer.
The problem is onSearchTextChange is triggered every time a charater is entered.
We need to trigger the Enter key that is not triggered by onSearchTextChange.

@Nikhil-Nandagopal Thanks for your answer.
The problem is onSearchTextChange is triggered every time a charater is entered.
We need to trigger the Enter key that is not triggered by onSearchTextChange.


Environment variable for limiting the number of JOBS [Again]

Is it possible to finally add the support for an environment variable that would limit the maximum number of jobs ninja can spawn?
I would suggest having an optional environment variable NINJA_NUM_JOBS, which would be used as an initial value when provided. This variable will be parsed before command line arguments that could of course override it.
I'm not asking for "additional flags" support [https://github.com/ninja-build/ninja/pull/1399], just a way to override the initial guess of the number of jobs as I understand the concerns behind NINJA_FLAGS and I understand that it might never get accepted.
I'm proposing a small change like this:
int GuessParallelism() {
  int n = GetProcessorCount();
  switch (n) {
    case 0:
    case 1: n = 2; break;
    case 2: n = 3; break;
    default: n += 2; break;
  }

  const char* s = getenv("NINJA_NUM_JOBS"); // or any better name.
  if (!s)
    return n;

  char* end;
  long nUserDefined = strtol(s, &end, 10);

  // If the environment value is invalid or is greater than our initial guess, drop it.
  if (*end != 0 || nUserDefined <= 0 || nUserDefined > n)
    return n;

  // Otherwise use the sane value provided by the user.
  return int(nUserDefined);
}

Have you thought about writing a wrapper script which you put on your PATH named ninja which calls the real ninja with the amount of jobs you want?

"Anyone can make the simple complicated."
BTW all of these were already discussed in other issues [I read them]. I really don't understand why there is such refusal regarding this feature as it's just a useful one. Can I workaround it? Yeah, but is it a solution? No.

Yeah, but is it a solution? No.

Why not?

You cannot see a difference between having a possibility to override a default value and between passing a default value to every invocation of ninja?

You cannot see a difference between having a possibility to override a default value and between passing a default value to every invocation of ninja?

I can see the difference.

I'm wondering why such refusal and whether it has some reason.

The reason for me would be that this can already solved by creating a wrapper script, so there's no need to implement this in Ninja itself.

And this is what I'm trying to point out - wrapper script is not the same as environment variable and it's definitely not a solution. With your reasoning I would propose to remove support for NINJA_STATUS environment variable, because you can create a wrapper script, thus there is no point of having that in Ninja itself.

Please see these:

https://github.com/ninja-build/ninja/issues/922
https://github.com/ninja-build/ninja/pull/1363
https://github.com/ninja-build/ninja/pull/1399

Possible workarounds were already discussed with possible answers as well.

A script would always override that value

No, you can adjust the script so that it doesn't always overwrite the value.

make sure that "each" process that executes ninja executes that script instead (not even sure this would be possible on Windows).

Yes, this is possible on Windows. The PATH works nearly identical there, so you just have to put your script in a directory that comes before the real ninja executable (or just remove the real ninja executable from the PATH).

What I mean, we can discuss workarounds to no end, but it would not solve the real problem which is controlling the number of jobs through an environment variable.

But it would, as you can read in the environment variable in your script.

And considering this is not a drastic change I don't see a reason "why not".

nico explained some of the "why not" arguments in #1399.

It was explained why not NINJA_FLAGS, which is a more general and would basically be another "arguments" to the process, but nobody really explained why not a single environment variable to override the initial guess.

Okay, giving up.

I have provided an initial code that can be used to implement this issue. I tried to make a code that is as least invasive as possible. It only parses one more environment variable (if present) and checks whether the input value is OK.

A wrapper script can not replace all of the functionality that NINJA_STATUS provides, so there's a point of having it in Ninja itself.

Prove it.
Seems to me like it's exactly the same concept.
Wrapper script reads NINJA_STATUS from the environment variable, and transforms it into a commandline argument that ninja accept.
If there's something about this method of providing the NINJA_STATUS feature that can't be done via commandline, please explain the problem.

Hello! I've been following the discussion. I support the proposal as I often find myself in the same situation. A wrapper script is a bad workaround in this situation IMO, we are only in need of a very simple way to configure (or override) the guessing logic.
I don't see how an optional, adequately named environment variable controlling a guess could hurt ninja, and many people seem to be asking for something like that.
I would even remove the nUserDefined > n check, if the env var is present it just replaces the guess. This looks sane and useful to me.
Of course I'm just stating an opinion, but I'd like to hear explanations for why not and how would it hurt ninja, not just you can do it another way. Thanks!

Please @jhasse would you be that kind to review the code and write your thoughts?

As the discussion has got a little bit heated, I think it would be better if someone else would review it and decide on this.
The code looks good, I like the name of the variable and would also drop nUserDefined > n. Also you might think of some way to accept 0 as a valid value (not sure if there's a way with strtol), as there's a PR which adds support for that meaning infinity.

@jhasse I initially thought that it would not be safe to pass for example 1000, so I wrote it in a way that you can influence the guess from NINJA_NUM_JOBS variable, but you cannot harm ninja itself by assigning it to some ridiculously high value. It's questionable why not, of course, but I just thought to be safe here and to not introduce anything that would require fixing later.
BTW the discussion got heated, that's true, but I don't see any other maintainer here, so I guess we would have to just figure out ourselves and I personally don't care about wording if we can achieve something here.

I'm here to voice support as well. Omitting this feature on principle seems a bit like navel gazing to me.

This flag is mandatory for me too. Due to AUR and other "automated" build processes when I don't have control of the ninja command line… Or PATH variable.

Bump. Ran into a need for this again. A wrapper script will not work in this use case for the reasons @Salamandar pointed out. Lacking this is a serious sore point with ninja, and the response from the maintainers is really disappointing. I'm going to start advocating that Linux distros drop ninja outright in favor of samurai, which does offer a feature like this.
Paging maintainers who have commented on this before: @jhasse, @ncio
The feature does not contradict any of ninja's stated goals and provides a critical feature which is sorely missed, as evidenced by persistent discussion on the subject for 5 years. The feature is simple to add and easy to maintain and already has patches prepared for it. As far as I can tell, you're just proud to have the phrase "Ninja supports one environment variable to control its behavior" in its docs out of a bizzare distaste for environment variables which has taken hold of a certain misled segment of the unix development community, even for an environment variable whose value proposition is significantly stronger than the only other use of getenv in the codebase.
Even as a particularly opinionated maintainer myself, I think you're betraying your responsibility as one by continuing to fix your eyes affirmedly upon your navels in this respect. Please reconsider.

I think you meant to mention @nico , instead of @ncio

Thanks @jonesmz, I did.

As the discussion has got a little bit heated, I think it would be better if someone else would review it and decide on this.

Who though? You're the only maintainer who's had any substantial activity for months.

@jhasse please nominate another maintainer to field this issue.

You've already paged nico.

nico hasn't touched this repo at all in almost a year. Putting it on nico is effectively the same as sending it to /dev/null.

@ddevault Which maintainer would you rather like to see me nominate then?

Any active maintainer? If that list is just "you" long, then tough luck?

You were the one who said "please nominate another maintainer to field this issue.". If your request is instead "please nominate another maintainer which has committed something in the last months to field this issue.", then that's impossible, yes.

Let me rephrase, then: if you refuse to address this issue, please nominate a maintainer who will [which must presumably be an active one]. If there is no such maintainer, address it yourself. Doing neither of these things is a breakdown in the project's maintainership as a whole.

You already knew that there's no such maintainer as jonesmz said that before your comment. So you're basically saying: "Address this!" and that's not the way I want to be talked to. https://github.com/ninja-build/ninja/issues/1482#issuecomment-516624886 was a bit rude, too, IMHO and it reinforces my desire not to be part of this discussion. If I have to discuss every issue in order to be a maintainer, then I'm not a maintainer.

I'm not saying you must address this, but that if you don't and no one else can, then ninja's maintainership has failed. When simple patches exist for a highly demanded and well justified feature, and they aren't being merged, then the project's maintainership has failed. This just reinforces my opinion that ninja should be dropped in favor of samurai. I'm not telling you this out of a desire to create hostility but rather clearly laying out the facts and their consequences.

Let's be rational here, the ratio benefit / risk is high, probably higher than other features that get merged. The only reason this doesn't get in Ninja is that the maintainers personally don't like it. If I may put @ddevault a different way: in a healthy project, at some point, the project maintainers have to listen to the users voice, and put their personal opinion aside. That's even more true for Ninja, of which most users are developers.

I personally understand reasoning against NINJA_FLAGS, but I have never understood objections against NINJA_NUM_JOBS. It's a safe addition a lot of people would benefit from and I personally see no downsides except one person not liking it.
Maybe community should finally fork this project and create something like ninja-ng, I would use it.

@kobalicek pull requests welcome : https://github.com/splinter-build/splinter

Kitware also has a fork btw: https://github.com/Kitware/ninja
And as ddevault mentioned samurai is ninja-compatible reimplementation in C which supports a SAMUFLAG environment variable, see https://github.com/michaelforney/samurai/issues/15.

I have not read the entire discussion, but would simply put up a question to those who think a wrapper script is going to solve every and all issues:
How do you inject it into the QtWebengine build process, for instance? Are you really suggesting we replace the system ninja command with a wrapper that does the trick, including processing the actual arguments to see if they too contain a -j or -l setting?
An env. variable is simple: use it to change the hardcoded default for -j, before processing $argv.

You don't need to replace the system command (i.e. /usr/bin/ninja), because /usr/local/bin usually has a higher priority in the PATH.

@RJVB this discussion is long since become irrational, you're wasting your time. The ninja maintainers have already had their stance on this issue wholely debunked and would rather save face and defend their egos by rejecting reason on the matter.

I guess we'll just have to stop using Ninja and use Samurai : https://github.com/michaelforney/samurai.

I've started the discussion about replacing Ninja with Samurai for Alpine Linux, with a symlink for compatibility.

Using C99 for this kind of application sounds like an atrocious idea...

lol, there's absolutely nothing wrong with C99.  Using C99+POSIX as the lowest common demoninator for a build system makes a lot of sense as it makes it unlikely that the build system will be the bottleneck in portability for any downstream software.

lol, there's absolutely nothing wrong with C99.  Using C99+POSIX as the lowest common demoninator for a build system makes a lot of sense as it makes it unlikely that the build system will be the bottleneck in portability for any downstream software.

Well Ninja files often are generated by high-level softwares written in Python, so… ;)

C99 is 20 years old, and has significant, and subtle, security problems that many / most programmers do not pay attention to.
At the very minimum, C11 should be used.
But I shouldn't have shoved my foot in my mouth by starting a language supremacy discussion, so this'll be my last comment on the subject in this thread.

C99 is 20 years old, and has significant, and subtle, security problems that many / most programmers do not pay attention to.

OK, I did not know about those issues.

Don't get suckered in by that guy. There's nothing wrong with C99.

@ddevault Don't insult me by saying i'm trying to "sucker" someone.
This comment is intended to be purely informative, and I'm not trying to continue a language war. I'm simply trying to provide information to someone who apparently doesn't know some details about the subject matter.
@Salamandar, hopefully this gives you the full view of the situation.
The security issues from C99 are widely and frequently discussed. They aren't problems with the language directly, they are problems with the language being difficult to use in a fully secure and safe manner. Programmers aren't omniscient. They make mistakes like anyone else. C99 is a very very sharp tool.  C11 is strictly more powerful than C99, which is strictly more powerful than C89. However, none of them are "safe" automatically. They all require the programmer to actually use the newly added language / standard library features, but the new features typically make it easier and safer to do something that people were already doing anyway.
C++ suffers from many of the same security problems as any version of the C language (In no small part because many / most C language programs can also be compiled directly as C++ programs with no, or minuscule, modifications.), and you can see many many C-isms even in the Ninja codebase that exhibit these exact issues. So don't think that I'm saying that C++ is magically less problematic than C is. Just like C89 / C99 / C11, the languages are only safer if you take advantage of the functionality that make them easier / safer to use. If you just write C89-style code in C11, then it's the same result. Just like if you compiled your C99 program in C++03. Just because the compiler is treating it as C++ doesn't mean you aren't still using unsafe code. It's just that C++03 has language / library features that C99 doesn't have, which can drastically simplify your program.
Some examples of where C acts as a very sharp tool via which you may shoot your own foot

The use of va_lists, really at all. Stack overflow is trivially easy to cause if you don't know what you're doing.
The printf family of functions, and the way you must carefully construct the format string, or risk buffer overflow. Some compilers provide limited compile-time analysis of these, but 1) It hardly ever works right, because programmers use it wrong. 2) Programmers ignore the warnings even when the analysis feature is configured correctly. Every job I've ever had has had examples of both points 1, and 2. Further, Ninja has some of these warnings as well...
The extremely common practice of type-casting a pointer-to-void (void*) into some other type (e.g. "generic" programming, C-style). Very easy to screw this up...
The lack of any kind of polymorphic function calling, which means if you need multiple functions to do the same operation, but on different inputs, you end up needing to copy-paste your function, and tweak it. Leaving plenty of room for forgetting to update one of the various instances of this function as your codebase evolves.
Good luck finding a C library that doesn't have either 1) a third party linked list library, 2) a linked list library implemented with (mostly) macros, or 3) a linked list library that doesn't toe the line of undefined behavior by typecasting everything everywhere.

And the list trails on ad infinitum...
The key difference is that while C is "simpler" it requires overwhelmingly more programmer attention, and more lines of code, to accomplish the same outcome. C++ has a large number of features that have well defined mechanics for having the compiler generate code that "does the right thing" using less verbose syntax / verbiage. By providing these mechanisms, if you use them, you get the same outcomes (e.g. the same assembly code) but with much much less C++ code than the equivalent C program. However, in some situations, C++'s increased "expressiveness" allows C++ programs to have less assembly generated for the same outcome. E.g. things like virtual function devirtualization, for example.
For the items that I point out above, C++ offers these equivalents.

Va_lists are completely, and utterly, replaced by C++11 variadic templates.
In C++ in general, printf is replaced by the iostreams library, which is quite a bit "safer" than printf, but does have a heavy speed penalty. In C++20 (or C++17, with a third party library) there's the {fmt} library which is quite a bit faster while still offering complete type safety.
For the use of void*, the concepts of C++ templates in general do the job. But on top of that, C++ also offers a replacement for C-style casts that provide excellent compiler diagnostics if you screw something up.
C++ has a variety of polymorphic functionality, both in terms of object hierarchy, and in terms of function calls. C++ does this at the compiler level, and generates code that's as optimal as possible, so that you can get elegant object hierarchies or appropriate function calls based on object type, without having to do a hell of a lot of work yourself, and probably screw it up somewhere.

So the point here is that C++ can be more secure than C, for the equivalent amount of code, because it's possible to leverage the compiler to do a lot of the things that you'd normally (In a C program) need to implement by hand, and the compiler is going to do it better than you can anyway.
But to address my original point, using C99 twenty years later is just simply idiotic. While I'm aware that there are some specialty embedded systems that have strong vender lock-in on compiler toolchains and have never upgraded anything, the overwhelming majority of platforms that someone could possibly target outside of very very specialized environments all support C11, and if they don't, I have no problem stating that I question their decision making to use that platform unless there's some large external requirement.
Starting a new project in C99 is simply a mistake, and I don't feel at all like that's a controversial statement.
Starting a new project in C-lang in general is a mistake, though quite a few people will disagree with me.
Further, C11 has several important code-safety features. https://en.wikipedia.org/wiki/C11_(C_standard_revision)

_Alignas -- No longer requires using compiler specific extensions and other hacks (I've seem some pretty gnarly code from K&R C / C89 involving manually constructing structs in memory using type casts that were really questionable, even then).
_Noreturn -- Provides more compiler-nagging about invalidly discarding without using the return values of functions. Sadly though, there are so many projects out there with hundreds of warnings per .c file (Ninja itself has a very large number, for what it's worth) that you still need a competent programmer to use this effectively.
_Thread_local -- Prevents the need for setting up storage on a per thread basis yourself. But not particularly relevant to single threaded programs like Ninja / Samuari.
 I did it at an old job that didn't have access to these from the standard lib, ughhh so many bugs. Even found a 20 year old bug in some atomic code one of my co-workers wrote. No one ever noticed it, but it was pretty trivial to reproduce if you knew what to do.
Removal of the gets function -- It's widely publicized that there is no actual safe way to use this function, too many corner cases.
Including type generic macros -- A very small nod towards polymorphism. Helps on code-duplication.
Bounds checking versions of functions (Annex K). -- Buffer overflow prevention for a variety of very tricky to use functions. If for no other reason, this is the reason why projects should use C11, unless they use none of the functions in question whatsoever. Amusingly, several prominent C-language people criticize Annex K because... it's too difficult for C programmer to use correctly. They do moronic things like... ignore the return value (of type errno_t), or provide the arguments to the function in the wrong order. Which C happily allows in many cases, because it's type-system is very lax. This is simply more evidence that the C language is a very sharp tool.

For what it's worth, this is the same set of arguments that I continually make with regards to Ninja switching from C++03 to C++11, but shrug. It is what it is.
@Salamandar hopefully that helps you out.

spoiler alert: humans are a huge security risk. Should they be banned from computers?
Translation: exactly what in the above breakdown carries any real danger in the intended use of a build tool?
(As it is, ninja is already a good tool to provoke a local DOS situation.)
About samurai: has anyone tried to build QtWebEngine (or anything else that contains an embedded Chromium payload)?
Re: /usr/bin vs. /usr/local/bin : the latter is typically part of the system too nowadays, and even if it is usually earlier in the $PATH than the former that doesn't mean complex build systems will respect that. Remember, we're talking about the kind of system where you don't have control over how ninja is invoked.
Wasn't ninja more or less developed for or by Chrome devs? If so it's kind of ironic that the ninja devs are apparently dead-set against allowing some kind of external/toplevel control over certain options. If I understand correctly the way ninja manages (scales) build jobs it should be tailored to bring any system to similar extent to its knees with big jobs like building Chrome.

I thought you didn't want to start a language flamewar, then you wrote a 1,300 word triaste on the language. Haters gonna hate? Every language has problems, but you can definitely write C99 with care, avoiding common problems and building a robost codebase nevertheless. It's a valid choice, and is not obsolete.

@jonesmz OK, I see. I knew about some of those issue, but did not consider them as "security" flaws.
@ddevault That's not starting a language flamewar to give information about the issues of a language. I personally hate C since i started C++, mostly because of the inexistance of destructors (the rest is mostly making dev's life easier). Read the git source code, it's full of goto/label… But C++ also has its issues. One uses the language they like.

Read the git source code, it's full of goto/label…

There's nothing wrong with goto/labels, it's quite effective for error handling in C. You're just cargo culting bad advice without understanding what it meant. Do you really think that git, one of the most successful software projects ever, doesn't know better than some blog post you read that one time?

That applies to a lot of language flaming against C in general: cargo culting bad advice written by and read by people who don't grok C.

[...] and even if it is usually earlier in the $PATH than the former that doesn't mean complex build systems will respect that.

Why not? Have you actually tried it with QtWebEngine?

There's nothing wrong with goto/labels, it's quite effective for error handling in C.

Probably, but that's still a fragile design. I don't make any judgements on git. A good software design does not mean a good code (and vice-versa).

It is not a fragile design. It's best goddamn practices.

Why not? Have you actually tried it with QtWebEngine?

I admit I haven't.

It is not a fragile design. It's best goddamn practices.

Exactly, what would be fragile about it? I haven't looked at git's code, but I've seen a lot of Apple code that takes the form
err = DoSomething();
if (err != noErr) {
goto bail;
}
If you have to lots of DoSomething steps to get something done that amounts to avoiding a whole bunch of nested ifs. In C++ you might more easily end up doing early returns but there are people who don't like those either (1 exit point per function if possible) ... and there's a good chance that the optimiser will create a similar goto structure for you just to have a single exit point.
The whole point with C has always been that it's close to the hardware and that it thus allows you to take matters into your own hand. Higher level languages like C++ allow to delegate more and more chores to the compiler and/or runtime. Both have their advantages, disadvantages and applications.
A former supervisor of mine hated anything C-related (esp. C++), swearing only by Modula-2. Though he did like the ideas behind ObjC IIRC, and had wet dreams about VHDL :)

Arrived here because I googled how to set the number of CPU on ninja. I have to say this conversation is unreal...
My use-case: When compiling on my laptop I sometimes want to limit the number of cores used, otherwise the system becomes too slow to keep working. But I'm doing this only when I'm starting a long background compilation. With make I can do this with export MAKEFLAGS='-j7' (on 8 threads CPU). Since ninja is hidden behind build scripts, I would have add/delete a ninja wrapper in ~/.local/bin, this is clearly not convenient.
I've read most of the conversation, and I'm yet to see an argument against NINJA_NUM_JOBS, can we please focus on that instead of speaking on totally irrelevant language wars?

The discussion about environment variables took place over a year ago on multiple different issues. Including this one.
The maintainers of the ninja project don't want this feature.

And so we just end up using samurai which has other advantages too (and I don't mean being more noble ;) )

@RJVB  samurai's documentation is pretty thin, or I didn't find the proper one, can you tell us how to specify the maximum number of jobs?

It's a drop-in replacement which only lacks ninja's feature to couple the number of jobs to system load. So the number of jobs is specified by -j on the commandline, or by SAMUFLAGS=-jN in the environment (you can also set -v via that variable).

Just make an alias ninja=samu, and you won't event feel the difference.

I just created the AUR package ninja-samurai that installs Samu instead of Ninja and adds a symlink as a system-wide alias.

@Salamandar Thank you! I'm beginning to promote ninja-samurai to resolve the haunting resource-exhaustion issue on our build machine and I hope it works well.
For people who wonder, it's simpler to install another package than change a already-installed package by post-install hacks or use a modified package.

samurai is a re implementation. Why hasn't someone made a fork? The fork can wrap around the main() function and parse environment variables as needed.

There are multiple forks of Ninja, in various levels of separation from the Ninja codebase.
Ultimately it's about the network effect of contributors focusing on one codebase vs. another.
Everyone targets their patches at this version of Ninja, and others get ignored. People who would be interested in making a fork know that this is the case, so they either make a soft-fork and try to keep their changes in sync with the main repository, or they only have a fork for purposes on making contributions back to the main repo.

I really don't understand why it's such a big deal to accept such feature. A small change that would help many and harm none, and yet ninja maintainers spent more time arguing instead of simply reviewing the code and proposing improvements. This project is lost.

Why not? Have you actually tried it with QtWebEngine?
I admit I haven't.

See https://github.com/qt/qtwebengine/commit/3e9cf092689dcd85bf5a5709eab6cbd2785b42b8 for how this was worked around in the build system and https://codereview.qt-project.org/c/qt/qtwebengine/+/251319 for how a further update would have passed the incoming total from Make. I needed those changes so I could build QtWebEngine in a 100+ node cluster instead of letting ninja run with an equivalent of -j28 because that's all it could see of my system.
Admittedly, nesting one build tool inside another is never a good idea and there will be rough edges.
Anyway, as the recommended solution is to use a script, can we have this script inside the Ninja repository itself, so it gets installed for most people who need it?

FWIW, I've been using Samu since about the time of the post Thiago just quoted, and haven't looked back. It's a drop-in replacement and at least at the time it made true the promises ninja itself no longer could.

Likewise. Ninja is essentially deprecated in favor of Samurai as far as I'm concerned.

autoconf/make has stood the test of time.  It has many environment variables available to control its behavior. "Write a wrapper script" is an approach I'd probably write one of my guys up for in most situations.

Adding another case to support adding this feature:
Currently, it is not possible to specify the number of JOBS when building ninja itself using the officially provided configure.py.
See https://github.com/ninja-build/ninja/blob/53346f18fd4c90fa6f07a2b40e5c788ffe46e738/configure.py#L202
It is very common that the end user does not directly control the options passed to ninja. And the default value for NUM_JOBS does not work for some modern machines with too many cores but not that much memory.

At the end of the day, people have spent 8+ years offering cases to support this feature and the Ninja developers don't want to add it. I'm not sure how adding more cases helps persuade them, in practice.
As far as practical solutions that work today go...
The independent Ninja build language reimplementation https://github.com/michaelforney/samurai supports this via the environment variable SAMUFLAGS. Simply use samu anywhere you'd otherwise use ninja, or install samu as your system /usr/bin/ninja (some linux distros have options to install this competing implementation as the default, or only, ninja).

Fittingly, the samurai were always the more noble ones ^^


Tinkerbell basic validation for datacenterconfig

Issue #, if available:
Description of changes:
Added basic validation for the tinkerbell datacenter config.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

/lgtm


[$1000] Chat is inserting empty lines when pasting a large text copied from any website that generates big text

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Action Performed:
1- Copy a bug text from https://www.fancytextpro.com/BigTextGenerator
2- paste the text in the chat and hit enter
3- empty lines are added to the text
Expected Result:
the pasted text should remain in the same format
Actual Result:
empty lines are added to the text
Workaround:
Can the user still use Expensify without this being fixed? Have you informed them of the workaround?
Platforms:

Which of our officially supported platforms is this issue occurring on?

[ ] Android / native
[ ] Android / Chrome
[ ] iOS / native
[ ] iOS / Safari
[x] MacOS / Chrome / Safari
[ ] MacOS / Desktop

Version Number: 1.3.46-0
Reproducible in staging?: y
Reproducible in production?: y
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos: Any additional supporting documentation
bigtext.webm
https://github.com/Expensify/App/assets/43996225/4bdd183b-7d2c-4666-a9a3-bc0bafb55162
Expensify/Expensify Issue URL:
Issue reported by: @hichamcc
Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1690294867467309
View all open jobs on GitHub
Upwork Automation - Do Not Edit

Upwork Job URL: https://www.upwork.com/jobs/~01896a724274d065f2
Upwork Job ID:<PHONE_NUMBER>103550976
Last Price Increase: 2023-07-30

Is the issue already fixed?

Contributor details
Your Expensify account email<EMAIL_ADDRESS>Upwork Profile Link: https://www.upwork.com/freelancers/~012cc10ba78b95dab6

Contributor details
Your Expensify account email<EMAIL_ADDRESS>Upwork Profile Link: https://www.upwork.com/freelancers/~012cc10ba78b95dab6

@kavimuru Hey, I am unable to reproduce it on staging

Contributor details
Your Expensify account email<EMAIL_ADDRESS>Upwork Profile Link: https://www.upwork.com/freelancers/hichamg9

Contributor details
Your Expensify account email<EMAIL_ADDRESS>Upwork Profile Link: https://www.upwork.com/freelancers/~0155c699362e3388b9

@MayankVir Did you try with the text used in the bug report?

Yes @kavimuru  tried with same. Here is the screen recording for staging.
https://github.com/Expensify/App/assets/41983025/3dd2e670-4dda-4156-83e4-d6ccd7665f2c

I also couldn't reproduce it in staging.

But the screen recording is of the staging environment only.

Contributor details
Your Expensify account email<EMAIL_ADDRESS>Upwork Profile Link: https://www.upwork.com/freelancers/~01c8c523f07ca9b1da

@sakluger continues to experience this.

Can't reproduce it on staging v1.3.50-2.
https://github.com/Expensify/App/assets/25520267/4977ee35-e756-4c15-b8e8-6f2f6379f281

I've asked @hichamcc to re-test the behavior to see if they can reproduce it.

Ok, I checked with Sasha as well, and it sounds like this behavior has been fixed. Closing!


heading--null  class applied when display not set

Describe the bug
When the display attribute is not defined, the header element is given a class of heading--null, rather than a default value.
To Reproduce
Steps to reproduce the behavior:

Create  component and set the level to any value
The H1..6 element will have a class on it called heading-null

Expected behavior
null should not be apart of the class name, or a default should be set.
Screenshots

What is the HTML that created this output? A default is set. See attached screenshot. Unable to repro.

I could put a catch in there that if display="" then I can force the default back in. But I am not sure that this is the problem.

In reviewing this further, the issue seems to be a use case where the display prop is removed from the DOM. The WC is not re-rendering on this update and then updates the prop value with null.

:tada: This issue has been resolved in version 1.2.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Key like 3D button

Is your feature request related to a problem? Please describe.
Describe the solution you'd like
Additional notes

Hi @Charu271 please add more description to the issue next time!
If you would like to contribute with this idea, please add it to the button ideas file in the correct category with a clear description of what you mean.

Okay


Nickel: Annotations

This PR introduces:

[x] Formatting rules for annotated symbol definitions
[x] Formatting rules for nested annotations
[x] Updated Nickel integration tests
[x] Exposed Nickel as a supported language in the CLI

This will flow |-annotations on to new lines, when the annotations as a whole cover multiple lines. It will not reflow type annotations, because they can be nested and this causes idempotency issues (there doesn't appear to be a way of establishing the depth of the nesting from the grammar alone). For example:
{
  single-line : type | annot | annot = whatever,

  multi-line : type
    | annot
    | annot
    = whatever
}

For let bindings, the RHS will appear indented, on a new line, if it covers multiple lines:
let single-line = fun x => x

let multi-line =
  fun x => x

Likewise for function definitions:
let multi-line-function =
  fun x =>
    x

Miscellaneous stuff:

Allow blank lines between record fields.
Designate builtins as leaves so their surrounding % characters don't get parsed as mod operators.
Began to tidy up the query file, with comments and explanations of formatting choices.

(Ignore the CI for now...)

There's a double indent somewhere and there's an idempotency problem on, e.g.:
{
  foo
    : forall a. Array { field : String, value : a } -> a
    | doc "foo"
    = 1
}

I think this PR is at high risk of turning into a bit of a rabbit hole. I suggest you split it in smaller PRs each making progress. Everytime you have an improvement, you can merge it. If anything, you'll feel better that way.

I think this PR is at high risk of turning into a bit of a rabbit hole. I suggest you split it in smaller PRs each making progress. Everytime you have an improvement, you can merge it. If anything, you'll feel better that way.

This PR can't (or, at least, "probably shouldn't") be merged until the upstream changes are stabilised. That said, I can still set this branch as a base and merge smaller PRs into it :+1:

@yannham What is the status of the unstable branch of the tree-sitter  grammar? (in particular: why does it exist?)

This PR can't (or, at least, "probably shouldn't") be merged until the upstream changes are stabilised. That said, I can still set this branch as a base and merge smaller PRs into it 👍

I don't think depending on a particular commit of the Nickel grammar should be keeping us from merging this. That is simply the best version of the grammar that we have. We can always come back and update our dependency later.

I agree with @torhovland: There's no harm in pinning a dependency to a commit, regardless of which branch it happens to be on... I'll split this PR up :slightly_smiling_face:

@aspiwack the rationale is that the master branch of tree-sitter, of nickel-lang.org (including the documentation), etc. all points to the current stable version of Nickel (e.g. if you use nvim-tree-sitter then it automatically picks the version from the master branch, and current stable and current master are quite deeply incompatible). Be we all use the latest version, so we put the up-to-date grammar on the unstable branch for now.

This will flow |-annotations on to new lines, when the annotations as a whole cover multiple lines. It will not reflow type annotations, because they can be nested and this causes idempotency issues (there doesn't appear to be a way of establishing the depth of the nesting from the grammar alone).

Out of curiosity, what's special about type annotations? Is that you encountered concreted cases with nesting? Because, on paper, contract annotations and type annotations accept exactly the same syntax on the right of the separator |/:, which is mostly an arbitrary nickel expression (almost, if you put other type/contract annotations, you might have to add parentheses). I would expect them to have the same characteristics, and thus the same issues.

Out of curiosity, what's special about type annotations? Is that you encountered concreted cases with nesting? Because, on paper, contract annotations and type annotations accept exactly the same syntax on the right of the separator |/:, which is mostly an arbitrary nickel expression (almost, if you put other type/contract annotations, you might have to add parentheses). I would expect them to have the same characteristics, and thus the same issues.

It's a good question that, I'm afraid, I don't have a satisfactory answer for :sweat_smile: I was getting idempotency errors when trying to format this from the stdlib:
let partition : forall a. (a -> Bool) -> Array a -> { right : Array a, wrong : Array a }

It has a multi-line context, because of the | doc, so in the first parse it turns into:
let partition
  : forall a. (a -> Bool) -> Array a -> { right
      : Array a, wrong
      : Array a }

Besides the double indent, this makes sense; even though it looks horrible. However, some other rule is then turning it into:
let partition
  : forall a. (a -> Bool) -> Array a -> {
      right
      : Array a,
      wrong
      : Array a }

This is being caused by some other rule that I've yet to "internalise". Once I find it -- and tweak it -- I can possibly relax the condition on type annotations...

the rationale is that the master branch of nickel-tree-sitter, of nickel-lang.org (including the documentation), etc. all point to the current stable version of Nickel (e.g. if you use nvim-tree-sitter then it automatically picks the version from the master branch, and current stable and current master are quite deeply incompatible). Be we all use the latest version, so we put the up-to-date grammar on the unstable branch for now.

Thanks. So most definitely no obstacle on depending on the unstable branch in Topiary.


Added ARVR_Helpers script.

This is a preliminary script related to issue #70 to help locate ARVR nodes.
I ended up not adding a function to look for the PlayerBody in here because it leads to circular dependencies. Instead my demo project adds the routine to the PlayerBody script:
    # Find the player body from our own node somewhere under the player
    var body := PlayerBody.get_player_body(self)

Looks good, just need to find a nice way to make sure this is accessible. It should really be auto loaded, I wish there was a way to automate this.

Ok, I never knew this. It used to be so that you had to autoload scripts to use them, but the combo of using class_name with static func will automatically load the script if you call the static function from anywhere else in the code. :)


use scipy constants rather than magic numbers

Pull Request Test Coverage Report for Build 311

2 of 2 (100.0%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.01%) to 70.55%

Totals

Change from base Build 284:
0.01%

Covered Lines:
2180

Relevant Lines:
3090

💛  - Coveralls