Auto Edge Jump Feature.

Can you please add this? This would be a great feature especially for legit cheating. Thanks! (I tried to but I know nothing about coding so I just stopped doing it when I got a lot of errors) Hope you understand. Thanks!

#938 #859 #773 #456

ghetto af edgejump since there are like 5 issues asking for it:
void Misc::edgeJump(UserCmd* cmd) noexcept { 	if (GetAsyncKeyState('V')) { 		const auto localPlayer = interfaces.entityList->getEntity(interfaces.engine->getLocalPlayer()); 		if (localPlayer->moveType() == MoveType::LADDER) return; 		Vector start, end; 		start = localPlayer->origin(); 		end = start; 		end.z -= 32; 		Trace trace; 		Ray ray(start, end); 		TraceFilter filter(localPlayer); 		interfaces.engineTrace->traceRay(ray, MASK_PLAYERSOLID_BRUSHONLY, filter, trace); 		if (trace.fraction == 1.0f) cmd->buttons |= UserCmd::IN_JUMP; 	} }
note: this is not the proper way to do it. the reason im sharing it is because i don't use it anymore since im doing it properly with engine prediction now.
ready to c+p btw

#938 #859 #773 #456

Auto Edge Jump and Auto Jump-Bug is different... just saying...

Can you please add this? This would be a great feature especially for legit cheating. Thanks! (I tried to but I know nothing about coding so I just stopped doing it when I got a lot of errors) Hope you understand. Thanks!

#956

#938 #859 #773 #456

Auto Edge Jump and Auto Jump-Bug is different... just saying...

i was specifically searching for jump bug, i saw like 3 edge jumps along the way but either way there are too many issues about jump bug and edge jump.


in the readme file, read the docs link id dead

Not sure if there's a plan to have more documentation, but the link to http://sqlalchemy-datatables.readthedocs.org/en/latest/ currently gives "SORRY this page does not exist yet"
Would love to see some use cases there, but I don't have enough experience to contribute.

I prefered having live examples rather than a readthedocs. I fixed the link issue in the v2 branch, not sure that it's the kind of problem where a rtd is helpful. I may be wrong about it :)


Implement scaling standardization for preprocessing

As it stands, when images are loaded in for modeling, they're just re-scaled to an 8-bit range. This has the potential to discard some information, e.g. if the source image is 16-bit but only has values up to ~3000. A better approach will be to set a min and max value for re-scaling during pre-processing, which would protect the bit depth of the input images.

Resolved with #84


Code structure improvements

For the add / subtract / multiply / divide functions, change the location to a file other than main.py and change the structure to import using that file.

I was done.


Add a docs peformance section

📚 Documentation
Have a page where we go through all the tips to improve performance and their caveats.
For example, some are suggested in https://william-falcon.medium.com/pytorch-lightning-vs-deepspeed-vs-fsdp-vs-ffcv-vs-e0d6b2a95719
A speed checklist could be:
Check DataLoader(batch_size)
Check DataLoader(num_workers) (Lightning does not set them for you!)
Check training will happen on device: Trainer(accelerator="gpu")
(If desired) Check script uses the DDP strategy and an apt # of devices
If DDP, use Trainer(strategy="ddp_find_unused_parameters_false")
Set Trainer(benchmark=True)
Disable loggers: Trainer(logger=False)
Disable checkpointing if this is a pure benchmark where we don’t really care about the weights: Trainer(enable_checkpointing=False)
Reduce progress bar printing: Trainer(callbacks=ProgressBar(refresh_rate=N))
During logging, avoid self.log(on_step=True) and self.log(sync_dist=True)
Then for memory:
Beware of overriding training_epoch_end

If you enjoy Lightning, check out our other projects! ⚡

Metrics: Machine learning metrics for distributed, scalable PyTorch applications.

Lite: enables pure PyTorch users to scale their existing code on any kind of device while retaining full control over their own loops and optimization logic.

Flash: The fastest way to get a Lightning baseline! A collection of tasks for fast prototyping, baselining, fine-tuning, and solving problems with deep learning.

Bolts: Pretrained SOTA Deep Learning models, callbacks, and more for research and production with PyTorch Lightning and PyTorch.

Lightning Transformers: Flexible interface for high-performance research using SOTA Transformers leveraging Pytorch Lightning, Transformers, and Hydra.

cc @borda @rohitgr7 @akihironitta

How is this different from https://pytorch-lightning.readthedocs.io/en/latest/guides/speed.html ?

How is this different from https://pytorch-lightning.readthedocs.io/en/latest/guides/speed.html ?

I think the target for the doc is to highlights sections/points that can slow down/affect the performance when using PL for eg in case a user compares PL vs PT. And not just slow downs, but also the memory issues that can come up, for eg in case of overriding training_epoch_end.


Transclusion to only a part of the note aren't supported

Transclusion to part of the note aren't supported and show full note instead, so syntax like:

![[Note#NoteHeading]] will show full Note as transcluded instead of only part of this note concerning NoteHeading
![[Note#^fc5f29]] will show full Note as transcluded instead of only part of this note concerning some paragraph or callout.

Do you think you can support it? I use transclusions a lot and without that feature it's hard for me to share my notes.

I actually wasn't aware that this was possible in Obsidian. Very cool.
I will look into it. If the obsidian APIs make it easy to retrieve sections from a note this should be easy to implement. However if I need to "calculate" sections myself it would be a bit more work. I'll add it to my todo list!

I also encountered this issue. Hope it's not difficult to solve.

PR #78 resolved Heading transclude. Not sure what the second syntax means

+1 since I use anchor links quite frequently, too. Thanks!

Version 2.29.0 has just been released, which adds support for transcluding blocks by anchor tag.
Thanks to @uroybd for implementing this feature.

The original transclude seems to be appearing as regular, unlinked text.
In Obsidian, it appears as linked and superscripted.

The transclusion source number (^123a4b) seems to be appearing as regular, unlinked text.
In Obsidian, it appears as linked and superscripted.

Hi, This is being handled in #141 However, in this case, I'm not superscribing, instead converting it as the id for that block in HTML so it can be linked, just like obsidian.

@jacobmercy , as @uroybd mentioned this has been fixed in the latest version. The ^123abc number will now disappear, but linking to it will still work.

This

Render this way (correctly) in Obsidian 1.3.5

but renders this way in Digital Garden 2.45.2

Is this the defect that was supposed to be solved or a different one?

This
Render this way (correctly) in Obsidian 1.3.5
but renders this way in Digital Garden 2.45.2
Is this the defect that was supposed to be solved or a different one?

It is kind of a defect. Will try to fix it.


Implement token programs

@Jac0xb Should we close this one since it seems that #31 already have these?

@febo I really like ATA-part of that MR, so in case you decide to close it, I would like to open a dedicated MR with ATA-related logic/improvements

@febo I really like ATA-part of that MR, so in case you decide to close it, I would like to open a dedicated MR with ATA-related logic/improvements

Good point! So we could re-purpose this PR to include only the ATA, or close it and create one just for ATA.
cc: @Jac0xb


The approver sees a GBR on the workspace chat but no green button or dot in the reports - just a grey "submit" button

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

Version Number:
Reproducible in staging?: Needs Reproduction
Reproducible in production?: Needs Reproduction
If this was caught on HybridApp, is this reproducible on New Expensify Standalone?:
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
Expensify/Expensify Issue URL:
Issue reported by: @flaviadefaria
Slack conversation (hyperlinked to channel name): #migrate
Action Performed:
Prerequisite: Delay submission enabled for a workspace

As employee submit an expense to the approver
Login as approver and open the report

Expected Result:
No GBR for the approver if the report is in open status
Actual Result:
The approver sees a GBR on the workspace chat but no green button or dot in the reports - just a grey "submit" button
Workaround:
Unknown
Platforms:

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

[ ] Android: Standalone
[ ] Android: HybridApp
[ ] Android: mWeb Chrome
[ ] iOS: Standalone
[ ] iOS: HybridApp
[ ] iOS: mWeb Safari
[x] MacOS: Chrome / Safari
[ ] MacOS: Desktop

Screenshots/Videos

Add any screenshot/video evidence

View all open jobs on GitHub

This has been labelled "Needs Reproduction". Follow the steps here: https://stackoverflowteams.com/c/expensify/questions/16989

These are the steps:
Prerequisite: Delay submission enabled for a workspace
1 - As employee submit an expense to the approver (also an admin)
2- Login as the approver/admin
The expected behavior is to have no GBR and a grey submit button, but what I got was a GBR with the grey submit button.

I just re-tested this and was able to recreate it so update the testing steps I had added above.
This is what the submitter sees (expected):

This is what the admin sees (there shouldn't be a GBR):

Reproduced:

Hi! I'm Bartek from Callstack - expert contributor group. I’d like to work on this issue.

@kadiealexander @mollfpr bump

Also, I wasn't be able to reproduce it:
https://github.com/user-attachments/assets/aa055a08-3a7d-4dce-b1bd-fa821a8ce858
I don't see the GBR, but the submit button is grey both sides - not sure if this is expected behaviour?

I'm testing this again today.

Issue not reproducible during KI retests. (First week)

Issue not reproducible during KI retests. (Second week)

I can't reproduce the issue. @kadiealexander We might be can close the issue.


[2.1] Implement Abort(ConnectionAbortedException) override

This overload was added in ASP.NET Core 2.1 and doesn't invoke existing Abort() overrides.


Refactor feature check (is_feature_enabled)

Moved is_feature_enabled from zcl_abapgit_settings to separate class zcl_abapgit_feature. Makes it much simpler to check from anywhere (using simple if-statement).

looks like this removes the possibility to do dependency injection for the feature checker?

there is the method set_experimental_features, suggest adding that as a comment in the class that it can be used for dependency injectio/testing?

settings are not persisted (unless you use zcl_abapgit_persist_settings~modify) or do you mean something else?


CI tool usage

Objective

Original objective was to add doc build warning check to the ci local execution
I somewhat deviated and changed other things...

Solution
cargo run -p ci can now take more parameters:

format - cargo fmt
clippy - clippy
compile-fail - bevy_ecs_compile_fail_tests tests
test - tests but not doc tests and do not build examples
doc-test - doc tests
doc-check - doc build and warnings
bench-check - check that benches build
example-check - check that examples build
lints - group - run lints and format and clippy
doc - group - run doc-test and doc-check
compile - group - run compile-fail and bench-check and example-check
not providing a parameter will run everything

Ci is using those when possible:

build jobs now don't run doc tests and don't build examples. it makes this job faster, but doc tests and examples are not built for each architecture target
ci job doesn't run the compile-fail part but only format and clippy, taking less time
check-benches becomes check-compiles and runs the compile tasks. It takes longer. I also fixed how it was using cache
check-doc job is now independent and also run the doc tests, so it takes longer. I commented out the deadlinks check as it takes 2.5 minutes (to install) and doesn't work

Mentioning it as possibly topical, given the plethora of crate feature flags in the Bevy family:
https://github.com/taiki-e/cargo-hack
I've found this helpful in my work to make sure that any/all combos of crate features continue to build without warnings or failures. I'm leaning on --each-feature and --feature-powerset
At the scope of something like Bevy it's probably prohibitive to run in CI, though. It's only practical for me by tolerating bloat of /target locally and using cargo-sweep whenever it gets too bad.

https://github.com/taiki-e/cargo-hack

It could be interesting to add a weekly workflow to check feature flag combinations, but that's going to be too much to do on each commit 👍

@mockersf is this ready to go? I remember liking this quite a bit.

bors try

bors r+

bors r-

this one is causing bors timeout

should be fixed now 👍

bors retry

bors r+


[#131890677] Update Rieman to custom release

What
This PR updates Rieman to our custom release build on top of Rieman master branch.  It brings batch processing of events that is fixing Rieman problem with getting stuck after 15-30 mins of forwarding to Datadog. Also, it should improve performance and reduce latency of forwarding.
How to review
Review changes on our fork of Rieman bosh release: https://github.com/xoebus/riemann-boshrelease/compare/master...alphagov:feature/events_batch_processing?expand=1
Rieman jar was created manually according to instructions from docs: http://riemann.io/howto.html#work-with-the-riemann-source
than on paas-cf:
make dev bootstrap

Check if concourse.* metrics are being send from your env. You can wait for half an hour to ensure that Rieman doesn't stop sending them.
Who can review
Not @mtekel or @combor

There was no pull request for the changes to paas-riemann-boshrelease. There should be one.


Implement the automatic offload feature for @jit based on PyDPPL contextmanager

We will use this ticket to track the implementation of automatic offload based on PyDPPL device context (refer Language semantics proposal.

Initial version of this functionality was released as part of oneAPI beta 10.


Error in Generating ARTS Notebook and in Serving the Results in MKdown and Metabase - branch 0.6.1

Hi Matin,
I made a clean re-run on the example dataset with the bgcflow 0.6.1 version, just to make sure that there was no conflict among data. Except for deeptfactor (I posted a comment on the already opened issue), all the rules work.
Anyway, getting to the exploration of the results, I found a few problems: when running "bgcflow run --snakefile workflow/Report", it seems like if it does not find the needed files for generating the arts notebook. Actually the .ipynb file gets built, but the .md does not.
At the end of the whole job I also get the following error "34 of 36 steps (94%) done. Exiting because a job execution failed.". Probably the whole job gets compromised by the arts notebook generation failure? In fact, when I serve with "bgcflow serve --project Lactobacillus_delbrueckii" the webpage does not show any figure for any of the existing jobs.
The visualization with jupyter lab is fine so far.
On Metabase, instead, the sections "Raw Cdss" and "Raw Regions" do not display any data.
I will go on with running bgcflow on my data. Then I will start exploring, let me know when you have fixes.
See below for arts notebook error message and see full attached log for details.
Activating conda environment: .snakemake/conda/03517672abe9c665423eb3b1c199390f_
[Fri Apr 21 15:12:12 2023]
Error in rule mkdocs_py_report:
jobid: 24
input: data/processed/Lactobacillus_delbrueckii/docs/arts.ipynb
output: data/processed/Lactobacillus_delbrueckii/docs/arts.md
log: workflow/report/logs/report/arts-report-Lactobacillus_delbrueckii.log (check log file(s) for error details)
conda-env: /bigdata/home/WIN.DTU.DK/gentile/bgcflow/.snakemake/conda/03517672abe9c665423eb3b1c199390f_
shell:
        jupyter nbconvert --to notebook --execute data/processed/Lactobacillus_delbrueckii/docs/arts.ipynb --output arts.ipynb 2>> workflow/report/logs/report/arts-report-Lactobacillus_delbrueckii.log
        jupyter nbconvert --to markdown data/processed/Lactobacillus_delbrueckii/docs/arts.ipynb --no-input --output arts.md 2>> workflow/report/logs/report/arts-report-Lactobacillus_delbrueckii.log

    (one of the commands exited with non-zero exit code; note that snakemake uses bash strict mode!)

arts-report-Lactobacillus_delbrueckii.log

Thanks to last Matin implementations the error in "rule copy_readme" has been solved, but the error in "rule mkdocs_py_report" still remains and the prokka.md does not get generated.
Moreover, while visualizing the results through MkDocs report, the reports for bigslice, query-bigslice, eggnog, cblaster-genome and cblaster-bgc do not show any results. The roary report, instead, is not displayed at all, and the following error arises while serving the project:
INFO     -  [macros] - ERROR # Macro Rendering Error
        **UndefinedError**: 'dict object' has no attribute 'roary'

        ```
        Traceback (most recent call last):
          File "/bigdata/home/WIN.DTU.DK/gentile/mambaforge/envs/bgcflow/lib/python3.11/site-packages/mkdocs_macros/plugin.py", line 480, in render
            return md_template.render(**page_variables)
                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
          File "/bigdata/home/WIN.DTU.DK/gentile/mambaforge/envs/bgcflow/lib/python3.11/site-packages/jinja2/environment.py", line 1301, in render
            self.environment.handle_exception()
          File "/bigdata/home/WIN.DTU.DK/gentile/mambaforge/envs/bgcflow/lib/python3.11/site-packages/jinja2/environment.py", line 936, in
        handle_exception
            raise rewrite_traceback_stack(source=source)
          File "<template>", line 195, in top-level template code
          File "/bigdata/home/WIN.DTU.DK/gentile/mambaforge/envs/bgcflow/lib/python3.11/site-packages/jinja2/environment.py", line 466, in getitem
            return obj[argument]
                   ~~~^^^^^^^^^^
        jinja2.exceptions.UndefinedError: 'dict object' has no attribute 'roary'

I confirm that the error in "rule mkdocs_py_report" has been solved and prokka.md gets generated. Also the roary report now gets generated (the problem was due to the project_metadata.json not being updated).
These problems remain:

As regarding Metabase, if you close the connection with ctrl-c and then open it again, it will ask you the set-up the account and the databases all over again.

While visualizing BGCflow results through MkDocs report, the reports for bigslice, query-bigslice, eggnog, cblaster-genome and cblaster-bgc do not show any results.


Added: lean body mass calculator

Title :  lean body mass calculator
Issue : #95

@ritika728 , I fix the background & resolved all conflicts....


Fix coding style in NBitcoin - Part 1

This PR fixes the coding style in the following files:

BlockStore.cs
Coins.cs
CoinsView.cs
PaymentACK.cs
RawFormatter.cs
RestClient.cs

Thank you @fassadlr. I've made most of the changes that you have suggested.


🐛Error on update to latest version

When I tried to embed flutterfire into my project, it shows up error as follow:
is it because Apple M1 or do I miss any step?
pod install
Analyzing dependencies
firebase_analytics: Using Firebase SDK version '8.14.0' defined in 'firebase_core'
firebase_auth: Using Firebase SDK version '8.14.0' defined in 'firebase_core'
firebase_core: Using Firebase SDK version '8.14.0' defined in 'firebase_core'
firebase_messaging: Using Firebase SDK version '8.14.0' defined in 'firebase_core'
/Users/wilson/.gem/ruby/2.6.0/gems/ethon-0.15.0/lib/ethon/curls/classes.rb:36: [BUG] Illegal instruction at 0x0000000104bf0000
ruby 2.6.8p205 (2021-07-07 revision 67951) [universal.arm64e-darwin21]
[pubspec.yaml]
firebase_core: ^1.14.0
firebase_auth: ^3.3.12
firebase_messaging: ^11.2.12
flutter_local_notifications: ^9.4.0
[flutter doctor -v]
[✓] Flutter (Channel stable, 2.10.4, on macOS 12.0.1 21A559 darwin-arm, locale en-HK)
• Flutter version 2.10.4 at /users/wilson/Development/flutter
• Upstream repository https://github.com/flutter/flutter.git
• Framework revision c860cba910 (9 days ago), 2022-03-25 00:23:12 -0500
• Engine revision 57d3bac3dd
• Dart version 2.16.2
• DevTools version 2.9.2
[✓] Android toolchain - develop for Android devices (Android SDK version 32.0.0)
• Android SDK at /Users/wilson/Library/Android/sdk
• Platform android-32, build-tools 32.0.0
• Java binary at: /Applications/Android Studio.app/Contents/jre/Contents/Home/bin/java
• Java version OpenJDK Runtime Environment (build 11.0.10+0-b96-7249189)
• All Android licenses accepted.
[✓] Xcode - develop for iOS and macOS (Xcode 13.3)
• Xcode at /Applications/Xcode.app/Contents/Developer
• CocoaPods version 1.11.3
[✓] Chrome - develop for the web
• Chrome at /Applications/Google Chrome.app/Contents/MacOS/Google Chrome
[✓] Android Studio (version 2020.3)
• Android Studio at /Applications/Android Studio.app/Contents
• Flutter plugin can be installed from:
🔨 https://plugins.jetbrains.com/plugin/9212-flutter
• Dart plugin can be installed from:
🔨 https://plugins.jetbrains.com/plugin/6351-dart
• Java version OpenJDK Runtime Environment (build 11.0.10+0-b96-7249189)
[✓] VS Code (version 1.65.2)
• VS Code at /Users/wilson/Downloads/Visual Studio Code.app/Contents
• Flutter extension can be installed from:
🔨 https://marketplace.visualstudio.com/items?itemName=Dart-Code.flutter
[✓] Connected device (2 available)
• iPhone 13 Pro Max (mobile) • F822E737-B8C2-4F0B-ACC5-6F6AEF9D3774 • ios            • com.apple.CoreSimulator.SimRuntime.iOS-15-4 (simulator)
• Chrome (web)               • chrome                               • web-javascript • Google Chrome 100.0.4896.60
[✓] HTTP Host Availability
• All required HTTP hosts are available
• No issues found!
Bug report
Describe the bug
A clear and concise description of what the bug is.
Steps to reproduce
Steps to reproduce the behavior:

Go to '...'
'...'
See error or incorrect behavior

Expected behavior
A clear and concise description of what you expected to happen.
Sample project
Providing a minimal example project which demonstrates the bug in isolation from your main App greatly enhances the chance of a timely fix.
Please link to the public repository URL.

Additional context
Add any other context about the problem here.

Flutter doctor
Run flutter doctor and paste the output below:
Click To Expand
PASTE OUTPUT INSIDE HERE

Flutter dependencies
Run flutter pub deps -- --style=compact and paste the output below:
Click To Expand
PASTE OUTPUT INSIDE HERE

/Users/wilson/.gem/ruby/2.6.0/gems/ethon-0.15.0/lib/ethon/curls/classes.rb:36: [BUG] Illegal instruction at 0x0000000104bf0000

This does not seem to be due to updating to latest version, but looks like an issue with cocoapods. See this similar link : https://developer.apple.com/forums/thread/652822
I suggest you to open the issue in cocoapods repo. Closing from here.


Adding cgroups path to the Spec.

Related to #114
This change should be useful for exec'ing new processes in an existing container.

This might be worth floating on the list first 1 ;).  Reviewing
different proposals (e.g. your path in be6ec5ff vs. my array of
objects in 2) is probably too much to wedge into GitHub's inline
comments :p.

@wking: Apologies for not being updated on the new contribution workflows.
@mrunalp: Any thoughts on systemd compatibility?

@vishh I think that this should work with systemd as well. The only difference is the terminology AFAICS.
For e.g.
10:blkio:/system.slice/sshd.service
9:hugetlb:/
8:perf_event:/
7:devices:/system.slice/sshd.service
6:freezer:/
5:memory:/system.slice/sshd.service
4:net_cls,net_prio:/
3:cpuset:/
2:cpu,cpuacct:/system.slice/sshd.service
1:name=systemd:/system.slice/sshd.service

# mount
...
cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd)
...

nit: reformat to one sentence per line please

Needs rebase as well.

@mrunalp @crosbymichael: WDYT of making cgroups path required? Without that, the options are cgroups can created under under root /, or under a user specified hierarchy (which requires configuration).

@vishh I think we could default to  / if cgroups path is not specified and a user specified path otherwise.

What will be the identifier we use for the cgroups? Will it be the base
name of the bundle?
On Wed, Sep 9, 2015 at 4:49 PM, Mrunal Patel<EMAIL_ADDRESS>wrote:

@vishh https://github.com/vishh I think we could default to / if
cgroups path is not specified and a user specified path otherwise.
—
Reply to this email directly or view it on GitHub
https://github.com/opencontainers/specs/pull/137#issuecomment-139075073.

That is a common thought.
On Sep 9, 2015 19:55, "Vish Kannan"<EMAIL_ADDRESS>wrote:

What will be the identifier we use for the cgroups? Will it be the base
name of the bundle?
On Wed, Sep 9, 2015 at 4:49 PM, Mrunal Patel<EMAIL_ADDRESS>wrote:

@vishh https://github.com/vishh I think we could default to / if
cgroups path is not specified and a user specified path otherwise.
—
Reply to this email directly or view it on GitHub
<https://github.com/opencontainers/specs/pull/137#issuecomment-139075073
.

—
Reply to this email directly or view it on GitHub
https://github.com/opencontainers/specs/pull/137#issuecomment-139075796.

@vishh runc uses the --id or the base name if not specified.

On Wed, Sep 09, 2015 at 04:55:45PM -0700, Vish Kannan wrote:

What will be the identifier we use for the cgroups? Will it be the
base name of the bundle?

Does this need to be spec'ed out?  There's not currently much language
around container IDs.  We just list them in state.json, and I've
pointed out that I'm not clear on why 1.  It makes sense that we'd
want some sort of handle for tracking “the same container” across a
checkpoint/restore migration (which is likely to change the PID), but
I don't see a need to bind the container ID in more tightly than that.
I think we should leave the cgroup/namespace name generation to the
runtime, and have consumers query (via the PID) to figure out the
cgroup/namespace name if they need it for something.
 Message-ID<EMAIL_ADDRESS>

@wking: My understanding is that it is recommended for runtimes to manage cgroups. But for a good dev experience, we can default to creating cgroups under / with an easy to use identifier (base name of the bundle).

@mrunalp @vbatts @dqminh Updated docs based on comments and rebased. PTAL.

Though base of the bundle would not be unique enough for more than 1
container runtime. Let's leave this id for the runtime. Won't the paths be
referencable through the /run/opencontainers/ path anyways.
On Sep 9, 2015 20:13, "Vish Kannan"<EMAIL_ADDRESS>wrote:

@wking https://github.com/wking: My understanding is that it is
recommended for runtimes to manage cgroups. But for a good dev experience,
we can default to creating cgroups under / with an easy to use identifier
(base name of the bundle).
—
Reply to this email directly or view it on GitHub
https://github.com/opencontainers/specs/pull/137#issuecomment-139077877.

Yeah. The cgroup paths can be retrieved from the state.

On Wed, Sep 09, 2015 at 05:13:32PM -0700, Vish Kannan wrote:

My understanding is that it is recommended for runtimes to manage
cgroups. But for a good dev experience, we can default to creating
cgroups under / with an easy to use identifier (base name of the
bundle).

If folks can spawn new containers without setting ‘cgroupsPath’, then
folks using a runtime shouldn't be guessing “/{container.id}” (or
whatever) as a cgroup path, they'll have to look it up for each
container (which I think is a good thing).
So since users will have to lookup a process's cgroups path anyway,
why should we bother specifying a rule to auto-generate paths?  If
different runtimes pick different rules for the default cgroup path,
what use-cases will suffer?
Wed, Sep 09, 2015 at 06:43:27PM -0700, Vish Kannan:

Yeah. The cgroup paths can be retrieved from the state.

Not directly.  Folks need to use the PID to get them (and that seems
fine to me), at least with the spec that landed via #87, see 1.

LGTM

LGTM

LGTM


After building a Word Addin and using angular6 probably occurs trying to debug application.

After building a Word Addin and using angular6 probably occurs trying to debug application.
No symbols are loaded. even after starting and then setting breakpoints, the debugger doesn't sync up with the map files to allow a debug session to happen.   I was looking for a github sample project with angular, but wasn't able to fine one. I will see about building and showing.  Stay tuned.

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

ID: dc5ae4ef-9ead-887d-9e15-fd94d224bf68
Version Independent ID: 5fcb4dc0-275a-a365-b0ac-3f97f2cd40cb
Content: Develop Office Add-ins with Angular
Content Source: docs/develop/add-ins-with-angular2.md
Product: office 365
GitHub Login: @o365devx
Microsoft Alias: o365devx

Hi @foxjazz,
Can you tell us more about how you're debugging your add-in (what platform, etc.)? We have some guidance around this subject in the Test and debug Office Add-ins article. If the information you're looking for isn't there, please let us know.
Thanks!

@foxjazz even i am facing the same issue with VS2019, can you share how to resolve this issue?


⚠ Fortnite has degraded performance

In 71c547c, Fortnite (https://fortnite.com) experienced degraded performance:

HTTP code: 200
Response time: 1560 ms

Resolved: Fortnite performance has improved in c2023bf.


After upgrading VS Code to 1.93  in SFC breaks code coloring in subsequent sections

Vue - Official extension or vue-tsc version
Vue - Official v2.1.6
VSCode version
1.93
Vue version
3.4.38
TypeScript version
not applicable
System Info
OS: Windows Server 2016 10.0.14393
    CPU: (8) x64 Intel(R) Xeon(R) CPU E5-1620 v4 @ 3.50GHz
    Memory: 12.28 GB / 63.88 GB
  Binaries:
    Node: 18.20.1 - C:\Program Files\nodejs\node.EXE
    Yarn: 1.22.19 - ~\AppData\Roaming\npm\yarn.CMD
    npm: 9.5.1 - C:\Program Files\nodejs\npm.CMD
  Browsers:
    Chrome: 128.0.6613.120
    Internet Explorer: 11.0.14393.2007

package.json dependencies
No response
Steps to reproduce
Install VS code 1.92.1 or earlier.
create SFC with  section like in docs: https://vue-i18n.intlify.dev/guide/advanced/sfc.html (minimal is something like that:
<template>
  <div>{{ greeting }}</div>
</template>

<i18n lang="yaml">
  en:
    test: test
</i18n>

<script setup>
import { ref } from 'vue'
const greeting = ref('Hello world!')
</script>

)
everything is fine
Upgrade VS code to 1.93
code coloring broken
What is expected?
Correct code coloring, like in VS Code 1.92.1 and earlier
What is actually happening?
all code coloring after i18 section is broken

move i18n section at the end:

Link to minimal reproduction
No response
Any additional comments?
No response

This is related to YAML code section detection:

and I haven't any YAML related extensions.

With VS code 19.3.1 & extentsion version 2.1.6 all is OK

Version: 1.94.1 re-happended...

dup https://github.com/vuejs/language-tools/issues/4654


Change instanceof Array to Array.isArray

Hello,
I faced with the issue during search requests. I've got Joi validation error:
jsonApi:validation:error>>> "value" must be an object

And I figure out, that this issue was related to this method: _enforceSchemaOnArray.
This code is wrapping array with results into a new array:
if (!(items instanceof Array)) {
   items = [ items ]
 }

Here is an example:
responseHelper._enforceSchemaOnArray = (items, schema, callback) => {
  console.log(items);
  console.log(items instanceof Array);
  console.log(Array.isArray(items));
  console.log(Object.prototype.toString.call(items) === '[object Array]');
  if (!(items instanceof Array)) {
    items = [ items ]
  }
  async.map(items, (item, done) => responseHelper._enforceSchemaOnObject(item, schema, done), (err, results) => {
    if (err) return callback(err)

    results = results.filter(result => !!result)
    return callback(null, results)
  })
}

Console Output:
  console.log node_modules/jsonapi-server/lib/responseHelper.js:21
    [ { addressType: 'mailing',
        nameOfAddressee: '',
        addressLine1: '123 Seasame Str',
        addressLine2: 'APT 1',
        city: 'NY',
        state: 'NY',
        country: 'US',
        zipCode: '10000',
        zipCodePlus4: '',
        id: '00000000-0000-0000-C000-000000000046',
        type: 'addresses',
        account: { type: 'accounts', id: '00000000-0000-0000-C000-000000000046' } } ]

  console.log node_modules/jsonapi-server/lib/responseHelper.js:22
    false

  console.log node_modules/jsonapi-server/lib/responseHelper.js:23
    true

  console.log node_modules/jsonapi-server/lib/responseHelper.js:24
    true

So, I decided that this small change could possibly fix all related issues.

Hi @alunyov. Thank you very much for your contribution. I concur that Array.isArray is more robust. I'll look into merging this soon.

@paparomeo any updates on this?

Apologies @andrew-makarenko, life has interrupted and handling this issue has side-tracked. I'll merge it today.


NavBrand: insufficient color contrast

per our audit - related to the NavBrand component

The "Skills" button has an insufficient color contrast of 1.4:1 in hover state (foreground color: #292F34, background color: #0D0F12). Expected color ratio is 3:1.
Please follow next link to find the correct colors for hover state to reach the expected ratio:
https://contrast-finder.org/

@danethurber
From: https://www.w3.org/WAI/WCAG21/Understanding/non-text-contrast.html

Boundaries
This success criteria does not require that controls have a visual boundary indicating the hit area, but if the visual indicator of the control is the only way to identify the control, then that indicator must have sufficient contrast. If text (or an icon) within a button or placeholder text inside a text input is visible and there is no visual indication of the hit area then the Success Criterion is passed.

If I am understanding this correctly, the hover state background of the NavBrand item does not need to meet 3:1 contrast ratio because the image inside NavBrand does meet contrast guidelines. This would also apply to Secondary & Flat buttons.


Yearly inflation is not 1% as described in whitepaper

As briefly discussed on the bitcointalk forum, the POS block reward of 1.5 BLK is not dynamic and yearly inflation will continue to decrease from the 1% per year as the coin continues to age.
https://bitcointalk.org/index.php?topic=469640.msg12860963#msg12860963

I find this current protocol an unacceptable deviation from the original source code.

I assume that by original source code you mean the earlier protocol that have dynamic reward. However, the v1 and v2 protocol actually does not gives 1% inflation as well. It will give 1% when no coinage is lost, which is only possible in theory. In reality, people make transactions and destroys coinage, therefore the 1% will not be achieved. Also, please bear in mind that there are coins that are lost due to missing privkeys, and those coins will never stake again, and thus making the inflation even less.
In protocol v3, it only distribute the reward to the people who stake, which provide a smooth inflation as opposed in earlier version, and it is a close estimate to 1%
If you look at this chart:

source
You can see that the inflation is smooth and annualized at slightly less 1% after the v3 switch. On the other hand, the earlier protocol remain at 0.2% to 0.4% annualized most of the time with occasional spikes to 5-11%

Since the blocks already have a target of 64 seconds per block, the diffcultly readjusts according; therefore, the dynamic reward could possibly be calculated from the total number of coins.

This could be a good idea though

Will be 1% in Blacknet


3.0.0-alpha.2 - attempting to fetch sampling rules crashes application when agent is not running

We've just upgraded our application from alpha.1 to alpha.2 for testing and immediately noticed that the application exited in cases where the xRay agent was not running on the configured url:port.
This was not the behaviour in alpha.1
The application is an express server, and we are using the express_mw module, and using AWSXRay.captureHTTPsGlobal.
I did some digging and found the difference appears to be somewhere in the hierarchy that starts with mwUtils.resolveSampling(amznTraceHeader, segment, res);
https://github.com/aws/aws-xray-sdk-node/blob/aws-xray-sdk%403.0.0-alpha.2/packages/express/lib/express_mw.js#L40
and proceeds down to service_connector.js:fetchSamplingRules
https://github.com/aws/aws-xray-sdk-node/blob/aws-xray-sdk%403.0.0-alpha.2/packages/core/lib/middleware/sampling/service_connector.js#L23
Here there appears to be some custom http request handling, that, when there is no agent running, or it's running on a different port,  throws an ECONNREFUSED error like
   trace: [     {       column: 16,       file: 'net.js',       function: 'TCPConnectWrap.afterConnect [as oncomplete]',       line: 1134,       method: 'afterConnect [as oncomplete]',       native: false     }   ],   stack: [     'Error: connect ECONNREFUSED <IP_ADDRESS>:2000',     '    at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1134:16)'   ]
This does not get caught anywhere in the stack, and results in a runtime uncaughtException that terminates the application. It seems to sidestep any express error capturing logic I put in.
In alpha.1 it appears that fetchSamplingRules was implemented using a completely different http client (the AWS-SDK request library?), and for some reason that seems to have swallowed and hidden any ECONNREFUSED errors.
https://github.com/aws/aws-xray-sdk-node/blob/aws-xray-sdk%403.0.0-alpha.1/packages/core/lib/middleware/sampling/service_connector.js#L22
An ideal fix (for us) would be to capture and log any errors connecting (or using) the agent to the logger and not crash the application. Or possibly make the error behaviour configurable? Note that we are already using the  AWSXRay.setContextMissingStrategy to avoid the RUNTIME_ERROR cases for missing context.

Hi @pdhodgkinson ,
Thank you very much for raising this issue. Did you configure the different address of the daemon via the AWS_XRAY_DAEMON_ADDRESS environment variable? I'll try to reproduce this error on my end and resolve it (since it shouldn't be happening in the first place). Generally though you are correct that X-Ray, as a tool purely for observability, should not be causing runtime errors in your main application. I'll improve the error capturing as well.
For some context, we changed the way the sampling APIs were called from using the AWS SDK to the native HTTP client to eliminate our dependency on the AWS SDK package.

We are using the setDaemonAddress function, but not the ENVIRONMENT variable
Our boilerplate looks something like:
  const AWSXRay = require('aws-xray-sdk');     const address =${host}:${port};     AWSXRay.setDaemonAddress(address);   AWSXRay.config([AWSXRay.plugins.ECSPlugin]);  AWSXRay.captureHTTPsGlobal(require('https'), true);     AWSXRay.captureHTTPsGlobal(require('http'), true); AWSXRay.setContextMissingStrategy((...args) => {        ...     }); AWSXRay.captureAWS(require('aws-sdk'));

Yep, that setup looks correct. I've reproduced the error and caught it so it shouldn't disrupt your application anymore, and verified that it works with a non-default address. I'll get the PR for that out later today.
Do you think the reason it wasn't initially connecting was just some delayed start in the daemon?

It's mostly when our developers are running the application locally during development. They don't typically run the agent so there's nothing running on that port. Have not had this issue in a production environment

^ PR is out, we'll try to release it next week!

Thanks! The PR looks to have fixed the issue for us. 🍻

Fix released in 3.0.0 :)


How to deal with casks that require special system version?

nvidia-web-driver's version is related with Kernel build string.
$ sw_vers
ProductName:	Mac OS X
ProductVersion:	10.13.3
BuildVersion:	17D102

$ system_profiler SPSoftwareDataType | grep Version
      System Version: macOS 10.13.3 (17D102)
      Kernel Version: Darwin 17.4.0

if Kernel Build Version and Nvidia web driver version mismatch installation will fail.
https://gfe.nvidia.com/mac-update has all definition. Here are some of the relations

Kernel Build Version
Required Nvidia Web Driver version

17D2102
3<IP_ADDRESS>.25.159

17D102
3<IP_ADDRESS>.25.158

17D2047
3<IP_ADDRESS>.25.157

17D47
3<IP_ADDRESS>.25.156

We don't have method to check anything except a major release.
i.e. depends_on macos: '>= :high_sierra'
https://github.com/caskroom/homebrew-cask/blob/master/doc/cask_language_reference/stanzas/depends_on.md#depends_on-macos


Risc v to x86

@alexkollert Let me also recreate the dev branch here to be up-to-date with master. Please pull those changes in before working on my feedback. Thanks!


Change the ScaleLine according to resolution

I would like to change the ScaleLine unit according to the resolution. In my case, show distance in nautical unit when distance is more than one and meter when it is less.
To do this, I would like to add the FunctionUnits type in ScaleLine module and when units parameter is a FunctionUnits, executes it.
The FunctionUnits will be a function(nominalCount: number, pointResolution: number)::{
suffix: string
pointResolution: number
}
I can make changes if you are agree.

i think ,you can create a custom ScaleLine module to do this.

What about listening to the resolution change events and set the units accordingly?
Something like:
map.getView().on("change:resolution", function(event) {
  var resolution = event.target.getResolution();
  if (resolution > 500) {
    scaleLine.setUnits("metric");
  } else {
    scaleLine.setUnits("degrees");
  }
});

Hello @fredj
You probably right... It more simple...
Thank you !
I'll close this issue. If I can help to contribute tell me. I would like to help.


Content tree: Keyboard navigation to move items

Description

Added Keyboard navigation to move items from one position to another

References
Fixes #1597
Type of change

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] Documentation update

How Has This Been Tested?

Checklist

[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my own code
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[x] My changes generate no new warnings
[x] I have added tests that prove my fix is effective or that my feature works
[ ] New and existing unit tests pass locally with my changes
[ ] Any dependent changes have been merged and published in downstream modules
[x] I have checked my code and corrected any misspellings

@ElishaSamPeterPrabhu 2 things:
When i pick an item and press down once, it does not move to where i expect it to go, it essentially is putting the line where the item already is, requiring that i press down twice.  Can we have it so the down arrow is aware enough to put it where we expect?
Can we handle escape key to cancel as well?

@ElishaSamPeterPrabhu 2 things: When i pick an item and press down once, it does not move to where i expect it to go, it essentially is putting the line where the item already is, requiring that i press down twice. Can we have it so the down arrow is aware enough to put it where we expect?
Can we handle escape key to cancel as well?

Updated the up and down behavior as expected and added escape to cancel draggable state


[FE] Add variant threads_per_warp number supporting for Intel GPU.

To support the user can use different threads_per_warp number to generate the Triton kernel on Intel GPU.
This is required by the task #145

@etiotto @pengtu ,
I will roll back the changes in the parse_options.
We need to discuss about the target tuple interface for the Intel GPU.

I add a new function getModuleWarpSize to get the warp size value from the number of the threads_per_warp in the module attribute.
The function triton::gpu::getWarpSize is implemented based on the method getThreadsPerWarp of the layout. But the semantic of this method is that get the shape of the warp dimension in the hierarchized multiple threads. It is mostly used for mapping the value of each thread back to the coordinate of its original tensor. e.g: SliceLayout only supports 2D layout for now and returns the shape with the sliced shape.

2024-02-01T06:36:34.9848665Z FAILED operators/test_matmul.py::test_op[128-128-32-1-4-2-107-233-128-False-False-bfloat16-bfloat16-True-True-None-None] - AssertionError: Tensor-likes are not close!
2024-02-01T06:36:34.9848676Z
2024-02-01T06:36:34.9848806Z Mismatched elements: 1625 / 24931 (6.5%)
2024-02-01T06:36:34.9849134Z Greatest absolute difference: 1.6015625 at index (56, 75) (up to 1e-05 allowed)
2024-02-01T06:36:34.9849390Z Greatest relative difference: 1.8203125 at index (8, 87) (up to 0.016 allowed)
2024-02-01T06:36:34.9850208Z FAILED operators/test_matmul.py::test_op[128-128-32-1-4-2-107-233-83-False-False-bfloat16-bfloat16-True-True-None-None] - AssertionError: Tensor-likes are not close!
2024-02-01T06:36:34.9850215Z
2024-02-01T06:36:34.9850338Z Mismatched elements: 1645 / 24931 (6.6%)
2024-02-01T06:36:34.9850646Z Greatest absolute difference: 1.5 at index (16, 122) (up to 1e-05 allowed)
2024-02-01T06:36:34.9850894Z Greatest relative difference: 2.46875 at index (24, 84) (up to 0.016 allowed)
2024-02-01T06:36:34.9851673Z FAILED operators/test_matmul.py::test_op[128-128-32-1-4-2-107-233-128-False-True-float16-float16-True-True-None-None] - AssertionError: Tensor-likes are not close!
2024-02-01T06:36:34.9851687Z
2024-02-01T06:36:34.9851804Z Mismatched elements: 1669 / 24931 (6.7%)
2024-02-01T06:36:34.9852125Z Greatest absolute difference: 1.6015625 at index (56, 75) (up to 1e-05 allowed)
2024-02-01T06:36:34.9852389Z Greatest relative difference: 1.8095703125 at index (8, 87) (up to 0.001 allowed)
2024-02-01T06:36:34.9853225Z FAILED operators/test_matmul.py::test_op[128-128-32-1-4-2-107-233-128-False-False-float16-float16-True-True-None-None] - AssertionError: Tensor-likes are not close!
2024-02-01T06:36:34.9853232Z
2024-02-01T06:36:34.9853351Z Mismatched elements: 1908 / 24931 (7.7%)
2024-02-01T06:36:34.9853672Z Greatest absolute difference: 1.6015625 at index (56, 75) (up to 1e-05 allowed)
2024-02-01T06:36:34.9853931Z Greatest relative difference: 1.8095703125 at index (8, 87) (up to 0.001 allowed)
2024-02-01T06:36:34.9854703Z FAILED operators/test_matmul.py::test_op[128-128-32-1-4-2-107-233-83-False-True-float16-float16-True-True-None-None] - AssertionError: Tensor-likes are not close!
2024-02-01T06:36:34.9854710Z
2024-02-01T06:36:34.9854821Z Mismatched elements: 1779 / 24931 (7.1%)
2024-02-01T06:36:34.9855140Z Greatest absolute difference: 1.4921875 at index (16, 122) (up to 1e-05 allowed)
2024-02-01T06:36:34.9855414Z Greatest relative difference: 2.46484375 at index (24, 84) (up to 0.001 allowed)
2024-02-01T06:36:34.9856254Z FAILED operators/test_matmul.py::test_op[128-128-32-1-4-2-107-233-83-False-True-bfloat16-bfloat16-True-True-None-None] - AssertionError: Tensor-likes are not close!
2024-02-01T06:36:34.9856261Z
2024-02-01T06:36:34.9856382Z Mismatched elements: 1568 / 24931 (6.3%)
2024-02-01T06:36:34.9856682Z Greatest absolute difference: 1.5 at index (16, 122) (up to 1e-05 allowed)
2024-02-01T06:36:34.9856927Z Greatest relative difference: 2.46875 at index (24, 84) (up to 0.016 allowed)
2024-02-01T06:36:34.9857737Z FAILED operators/test_matmul.py::test_op[128-256-32-1-8-2-None-None-None-False-False-float16-int8-True-True-None-None] - AssertionError: Tensor-likes are not close!
2024-02-01T06:36:34.9857743Z
2024-02-01T06:36:34.9857867Z Mismatched elements: 32767 / 32768 (100.0%)
2024-02-01T06:36:34.9858301Z Greatest absolute difference: 365.25 at index (52, 85) (up to 1e-05 allowed)
2024-02-01T06:36:34.9858550Z Greatest relative difference: inf at index (0, 4) (up to 0.001 allowed)
2024-02-01T06:36:34.9859378Z FAILED operators/test_matmul.py::test_op[128-256-32-1-8-2-None-None-None-False-True-float16-int8-True-False-None-None] - AssertionError: Tensor-likes are not close!
2024-02-01T06:36:34.9859384Z
2024-02-01T06:36:34.9859515Z Mismatched elements: 32768 / 32768 (100.0%)
2024-02-01T06:36:34.9859820Z Greatest absolute difference: 371.5 at index (52, 85) (up to 1e-05 allowed)
2024-02-01T06:36:34.9860044Z Greatest relative difference: inf at index (0, 4) (up to 0.001 allowed)
2024-02-01T06:36:34.9860863Z FAILED operators/test_matmul.py::test_op[128-256-32-1-8-2-None-None-None-False-False-float16-int8-True-False-None-None] - AssertionError: Tensor-likes are not close!
2024-02-01T06:36:34.9860870Z
2024-02-01T06:36:34.9860991Z Mismatched elements: 32767 / 32768 (100.0%)
2024-02-01T06:36:34.9861306Z Greatest absolute difference: 365.25 at index (52, 85) (up to 1e-05 allowed)
2024-02-01T06:36:34.9861529Z Greatest relative difference: inf at index (0, 4) (up to 0.001 allowed)
2024-02-01T06:36:34.9862321Z FAILED operators/test_matmul.py::test_op[128-256-32-1-8-2-None-None-None-False-True-float16-int8-True-True-None-None] - AssertionError: Tensor-likes are not close!
2024-02-01T06:36:34.9862327Z
2024-02-01T06:36:34.9862453Z Mismatched elements: 32768 / 32768 (100.0%)
2024-02-01T06:36:34.9862754Z Greatest absolute difference: 371.5 at index (52, 85) (up to 1e-05 allowed)
2024-02-01T06:36:34.9862980Z Greatest relative difference: inf at index (0, 4) (up to 0.001 allowed)

10 matmul cases failed because the LLVM O3 optimization on Triton side. Need to further debug.

matmul-performance:
      M     N     K  TRANS_A  TRANS_B      cuBLAS      Triton
0  2048   512   512    False     True   21.862134    8.248351
1  2048  1024  1024    False    False   72.932787   31.827559
2  2048  2048  2048     True    False  101.632714   85.073901
3  2048  4096  4096     True     True   89.152606  358.050157
Traceback (most recent call last):
  File "/runner/_work/intel-xpu-backend-for-triton/intel-xpu-backend-for-triton/python/tutorials/10-experimental-tma-store-matrix-multiplication.py", line 119, in <module>
    assert_close(c, golden, rtol=1e-2, atol=1e-3, check_dtype=False)
  File "/opt/hostedtoolcache/Python/3.10.13/x64/lib/python3.10/site-packages/torch/testing/_comparison.py", line 1520, in assert_close
    raise error_metas[0].to_error(msg)
AssertionError: Tensor-likes are not close!

Mismatched elements: 257384 / 262144 (98.2%)
Greatest absolute difference: 0.7141353487968445 at index (192, 259) (up to 0.001 allowed)
Greatest relative difference: 3702.51318359375 at index ([440](https://github.com/intel/intel-xpu-backend-for-triton/actions/runs/7737679640/job/21097071205?pr=414#step:17:441), 131) (up to 0.01 allowed)

An correctness issue of the tutorial example 10 when the threads_per_warp=16.

I add a new function getModuleWarpSize to get the warp size value from the number of the threads_per_warp in the module attribute. The function triton::gpu::getWarpSize is implemented based on the method getThreadsPerWarp of the layout. But the semantic of this method of some layout is not aligned to our requirements. It is mostly used for mapping the value of each thread back to the coordinate of its original tensor. e.g: SliceLayout only returns the threads per warp of sliced shape (One dim is removed).

@chengjunlu: This is not needed. The getWarpSize function multiplies the 2 dimensions of the getThreadsPer from the layout, as can be seen here: https://github.com/intel/intel-xpu-backend-for-triton/blob/llvm-target/lib/Dialect/TritonGPU/IR/Dialect.cpp#L85

Yes.
But some layout doesn't return the full shape of the threadsPerWarp.
The SliceLayout only returns partial of the sliced shape of the threadsPerWarp of the parent layout.
So the API triton::gpu::getWarpSize returns unexpected value for this use case.

I will roll back some workaround changes and revert the default threads_per_warp to 32 for this PR.
And I will file new issues to track the correctness issues find here. Those correctness issue only happens in the case matmul on FMA.

@etiotto @pengtu , I will roll back the changes in the parse_options.
We need to discuss about the target tuple interface for the Intel GPU.
The Triton JIT feature is highly dependent on the Torch. The Torch limits the forked processes to re-initialize the CUDA context. In order to compile the Triton kernel parallelly. the Torch caches the device's capability returned by torch.cuda.get_device_capability in main process and pass it to the sub-processes for triton.compile directly.
To support that, we need to parse the options based on the capability returned by the torch.xpu.get_device_capability. The implementation need to align with IPEX on the capability it passed.

@chengjunlu:  I discussed with @LiyangLingIntel about this.  I think that IPEX can set the capacity to a HEX number using the following scheme:  0x80860001 for ATSM, 0x80860002 for PVC, so XPU backend can check the upper 16 bits to make sure it is coming from Intel IPEX and use the lower 16 bit to match the DPAS version numbers as in your DPAS PR.  Will this work?

I add a new function getModuleWarpSize to get the warp size value from the number of the threads_per_warp in the module attribute. The function triton::gpu::getWarpSize is implemented based on the method getThreadsPerWarp of the layout. But the semantic of this method of some layout is not aligned to our requirements. It is mostly used for mapping the value of each thread back to the coordinate of its original tensor. e.g: SliceLayout only returns the threads per warp of sliced shape (One dim is removed).

@chengjunlu: This is not needed. The getWarpSize function multiplies the 2 dimensions of the getThreadsPer from the layout, as can be seen here: https://github.com/intel/intel-xpu-backend-for-triton/blob/llvm-target/lib/Dialect/TritonGPU/IR/Dialect.cpp#L85

Yes. But some layout doesn't return the full shape of the threadsPerWarp. The SliceLayout only returns partial of the sliced shape of the threadsPerWarp of the parent layout.
So the API triton::gpu::getWarpSize returns unexpected value for this use case.

I didn't know that.  Good to go then.  Thanks!

cussed

@etiotto @pengtu , I will roll back the changes in the parse_options.
We need to discuss about the target tuple interface for the Intel GPU.
The Triton JIT feature is highly dependent on the Torch. The Torch limits the forked processes to re-initialize the CUDA context. In order to compile the Triton kernel parallelly. the Torch caches the device's capability returned by torch.cuda.get_device_capability in main process and pass it to the sub-processes for triton.compile directly.
To support that, we need to parse the options based on the capability returned by the torch.xpu.get_device_capability. The implementation need to align with IPEX on the capability it passed.

@chengjunlu: I discussed with @LiyangLingIntel about this. I think that IPEX can set the capacity to a HEX number using the following scheme: 0x80860001 for ATSM, 0x80860002 for PVC, so XPU backend can check the upper 16 bits to make sure it is coming from Intel IPEX and use the lower 16 bit to match the DPAS version numbers as in your DPAS PR. Will this work?

I think it could work for now.
A dilemma situation is that when in the sub-processes, the triton is not allowed to call torch runtime API to get the SYCL device handler and query the device capability from the L0 API or SYCL API.
But there is some critical information we need to compile the kernel for high performance. Like the: max_group_size to decide the proper num_warps for Intel GPU if the user doesn't specify a number.
If the Interface only accept an value to identify the device arch, we have to keep a Intel GPU device arch information data internally in Triton XPU.


#7688: update device command to reduce amount of copying

Running ./build/test/tt_metal/perf_microbenchmark/3_pcie_transfer/test_rw_buffer on WH BM:
fd-2/main:
                  Metal | INFO     | AI CLK for device 0 is:   1000 MHz
                  Verif | INFO     | Created a random vector of size 134217728
                   Test | INFO     | Measuring host-to-device and device-to-host bandwidth for buffer_type=DRAM, transfer_size=536870912bytes
                   Test | INFO     | Num tests 10
                   Test | INFO     | EnqueueWriteBuffer to DRAM (H2D): 129.032ms, 3.875GB/s
                   Test | INFO     | EnqueueReadBuffer from DRAM (D2H): 442.650ms, 1.130GB/s
                   Test | INFO     | EnqueueWriteBuffer to DRAM (H2D): 128.735ms, 3.884GB/s
                   Test | INFO     | EnqueueReadBuffer from DRAM (D2H): 357.763ms, 1.398GB/s
                   Test | INFO     | EnqueueWriteBuffer to DRAM (H2D): 131.572ms, 3.800GB/s
                   Test | INFO     | EnqueueReadBuffer from DRAM (D2H): 257.252ms, 1.944GB/s
                   Test | INFO     | EnqueueWriteBuffer to DRAM (H2D): 128.695ms, 3.885GB/s
                   Test | INFO     | EnqueueReadBuffer from DRAM (D2H): 264.794ms, 1.888GB/s
                   Test | INFO     | EnqueueWriteBuffer to DRAM (H2D): 128.524ms, 3.890GB/s
                   Test | INFO     | EnqueueReadBuffer from DRAM (D2H): 238.321ms, 2.098GB/s
                   Test | INFO     | EnqueueWriteBuffer to DRAM (H2D): 128.711ms, 3.885GB/s
                   Test | INFO     | EnqueueReadBuffer from DRAM (D2H): 199.632ms, 2.505GB/s
                   Test | INFO     | EnqueueWriteBuffer to DRAM (H2D): 129.872ms, 3.850GB/s
                   Test | INFO     | EnqueueReadBuffer from DRAM (D2H): 207.881ms, 2.405GB/s
                   Test | INFO     | EnqueueWriteBuffer to DRAM (H2D): 128.498ms, 3.891GB/s
                   Test | INFO     | EnqueueReadBuffer from DRAM (D2H): 313.964ms, 1.593GB/s
                   Test | INFO     | EnqueueWriteBuffer to DRAM (H2D): 128.372ms, 3.895GB/s
                   Test | INFO     | EnqueueReadBuffer from DRAM (D2H): 318.628ms, 1.569GB/s
                   Test | INFO     | EnqueueWriteBuffer to DRAM (H2D): 128.515ms, 3.891GB/s
                   Test | INFO     | EnqueueReadBuffer from DRAM (D2H): 318.840ms, 1.568GB/s
                  Metal | INFO     | Closing device 0
                   Test | ERROR    | The host-to-device bandwidth does not meet the criteria. Current: 3.875GB/s, goal: 11.200GB/s
                 Always | INFO     | CSV_MICROBENCHMARK:title:test_rw_buffer
                 Always | INFO     | CSV_INPUT:buffer-type:DRAM:transfer-size:536870912
                 Always | INFO     | CSV_OUTPUT:H2D_Bandwidth(GB/s):3.875:D2H_Bandwidth(GB/s):1.885
                 Always | INFO     | CSV_RESULT:pass:false
                   Test | ERROR    | Test Failed
                 Device | INFO     | Closing user mode device drivers

abhullar/device-cmd
                  Metal | INFO     | AI CLK for device 0 is:   1000 MHz
                  Verif | INFO     | Created a random vector of size 134217728
                   Test | INFO     | Measuring host-to-device and device-to-host bandwidth for buffer_type=DRAM, transfer_size=536870912bytes
                   Test | INFO     | Num tests 10
                   Test | INFO     | EnqueueWriteBuffer to DRAM (H2D): 96.129ms, 5.201GB/s
                   Test | INFO     | EnqueueReadBuffer from DRAM (D2H): 548.164ms, 0.912GB/s
                   Test | INFO     | EnqueueWriteBuffer to DRAM (H2D): 95.329ms, 5.245GB/s
                   Test | INFO     | EnqueueReadBuffer from DRAM (D2H): 115.788ms, 4.318GB/s
                   Test | INFO     | EnqueueWriteBuffer to DRAM (H2D): 95.113ms, 5.257GB/s
                   Test | INFO     | EnqueueReadBuffer from DRAM (D2H): 142.929ms, 3.498GB/s
                   Test | INFO     | EnqueueWriteBuffer to DRAM (H2D): 95.132ms, 5.256GB/s
                   Test | INFO     | EnqueueReadBuffer from DRAM (D2H): 192.830ms, 2.593GB/s
                   Test | INFO     | EnqueueWriteBuffer to DRAM (H2D): 95.070ms, 5.259GB/s
                   Test | INFO     | EnqueueReadBuffer from DRAM (D2H): 318.122ms, 1.572GB/s
                   Test | INFO     | EnqueueWriteBuffer to DRAM (H2D): 95.687ms, 5.225GB/s
                   Test | INFO     | EnqueueReadBuffer from DRAM (D2H): 204.580ms, 2.444GB/s
                   Test | INFO     | EnqueueWriteBuffer to DRAM (H2D): 95.218ms, 5.251GB/s
                   Test | INFO     | EnqueueReadBuffer from DRAM (D2H): 307.991ms, 1.623GB/s
                   Test | INFO     | EnqueueWriteBuffer to DRAM (H2D): 95.441ms, 5.239GB/s
                   Test | INFO     | EnqueueReadBuffer from DRAM (D2H): 130.433ms, 3.833GB/s
                   Test | INFO     | EnqueueWriteBuffer to DRAM (H2D): 95.026ms, 5.262GB/s
                   Test | INFO     | EnqueueReadBuffer from DRAM (D2H): 219.099ms, 2.282GB/s
                   Test | INFO     | EnqueueWriteBuffer to DRAM (H2D): 95.098ms, 5.258GB/s
                   Test | INFO     | EnqueueReadBuffer from DRAM (D2H): 289.830ms, 1.725GB/s
                  Metal | INFO     | Closing device 0
                   Test | ERROR    | The host-to-device bandwidth does not meet the criteria. Current: 5.250GB/s, goal: 11.200GB/s
                 Always | INFO     | CSV_MICROBENCHMARK:title:test_rw_buffer
                 Always | INFO     | CSV_INPUT:buffer-type:DRAM:transfer-size:536870912
                 Always | INFO     | CSV_OUTPUT:H2D_Bandwidth(GB/s):5.250:D2H_Bandwidth(GB/s):2.654
                 Always | INFO     | CSV_RESULT:pass:false
                   Test | ERROR    | Test Failed

host-to-device BW: 3.875GB/s --> 5.250GB/s,


GeekBench5 automation is broken for latest version (5.4.6)

GeekBench5 has been updated in the Play on Dec 2nd from version 5.4.4 to 5.4.6 cause WA to fail launching GB5. The screen flickers briefly and returns to the home screen. The app is subsequently broken and cannot be launched again. The icon changes and the app must be reinstalled to work again. 5.4.6 works fine if launched manually.
This is tested on a Pixel 6, running Android 12, and custom kernel.

Hi, Thanks for raising this.
To launch an Android app WA relies on the generic Android mechanism, therefore to try and debug this would you be able to run the launch command manually on the device to see if you get the same behaviour?
am start -W -n com.primatelabs.geekbench5/com.primatelabs.geekbench.HomeActivity
I have also tried using the same version with my Nexus5 and do not encounter this problem, do you have another device available to verify whether this is an issue specific to the Pixel 6?


[B] Countdown doesnt make sense, as soon as there is connection it connects

Im wondering why that countdown is shown, it says it will check after X number of seconds. But in fact it is doing that non-stop. Perhaps this is bug in the reconnect option.  But i tried it without that and the basic setup also shows that its non-stop checking connection.
Is this running all the time in the background then?

Also what is the offline.js for and the other 2?
I also find something in your readme.md you state compressed 3kb? the offline.min.js is already 10kb and then it also need all the other files. So what file is 3kb?


Feature request: There's no default formatting for CSS files when pressing shift+alt+f

VSCode Version: 1.16.0
OS Version: Windows 10 Pro

Steps to Reproduce:
Just press the default formatting shortcut shift+alt+f in a CSS file. You'll notice that the shortcut won't work for it.

Reproduces without extensions: Yes
Though we can get formatting by using beautify extension but I think every code editor must have CSS formatting in-built. It was quite disappointing. I hope it'll be resolved in coming updates.

Duplicate of #19166


NetworkConnection manages messages handlers

Now you register handles with NetworkConnection instead of NetworkClient/NetworkServer
This resolves the broken abstraction at NetworkConnection level.  Now NetworkConnection deals with sending and receiving messages,  it knows how to encode and decode them with no help from the caller.

 Here is an overview of what got changed by this pull request:

Issues
======
+ Solved 3
- Added 3

Clones removed
==============
+ Assets/Mirror/Runtime/NetworkServer.cs  -1
+ Assets/Mirror/Runtime/NetworkClient.cs  -1
+ Assets/Mirror/Tests/Play/NetworkServerTest.cs  -41

See the complete overview on Codacy

 Here is an overview of what got changed by this pull request:

Issues
======
+ Solved 3
- Added 4

Complexity decreasing per file
==============================
+ Assets/Mirror/Runtime/MessagePacker.cs  -2

Clones removed
==============
+ Assets/Mirror/Runtime/NetworkServer.cs  -1
+ Assets/Mirror/Tests/Play/NetworkServerTest.cs  -41
+ Assets/Mirror/Runtime/NetworkClient.cs  -1

See the complete overview on Codacy

 Here is an overview of what got changed by this pull request:

Issues
======
+ Solved 3
- Added 4

Complexity decreasing per file
==============================
+ Assets/Mirror/Runtime/MessagePacker.cs  -2

Clones removed
==============
+ Assets/Mirror/Tests/Play/NetworkServerTest.cs  -41
+ Assets/Mirror/Runtime/NetworkServer.cs  -1
+ Assets/Mirror/Runtime/NetworkClient.cs  -1

See the complete overview on Codacy

 Here is an overview of what got changed by this pull request:

Issues
======
+ Solved 4
- Added 4

Clones removed
==============
+ Assets/Mirror/Runtime/NetworkClient.cs  -1
+ Assets/Mirror/Tests/Play/NetworkServerTest.cs  -41
+ Assets/Mirror/Runtime/NetworkServer.cs  -1

See the complete overview on Codacy

 Here is an overview of what got changed by this pull request:

Issues
======
+ Solved 4
- Added 5

Clones removed
==============
+ Assets/Mirror/Runtime/NetworkServer.cs  -1
+ Assets/Mirror/Runtime/NetworkClient.cs  -1
+ Assets/Mirror/Tests/Play/NetworkServerTest.cs  -41

See the complete overview on Codacy

 Here is an overview of what got changed by this pull request:

Issues
======
+ Solved 4
- Added 5

Clones removed
==============
+ Assets/Mirror/Runtime/NetworkClient.cs  -1
+ Assets/Mirror/Tests/Play/NetworkServerTest.cs  -34
+ Assets/Mirror/Runtime/NetworkServer.cs  -1

See the complete overview on Codacy

Nice work, this logic is way better!


Refactor FinnGen study table generation

Ticket created after discussion with @DSuveges 2022-10-26. The goal is to migrate FinnGen and UKBB study table generation to the new monorepository.
Old approach
The two scripts, make_FINNGEN_study_table.py and make_UKB_study_table.py, in this directory: https://github.com/opentargets/genetics-v2d-data/tree/master/scripts
New approach
There is a new repository https://github.com/opentargets/genetics_etl_python. It has strict rules, such as:

Enforcing code style
Docstrings must be present for each function (used for generating the documentation + pytest picks up examples for testing)
Poetry for managing the environments
Flexible configuration using Hydra
Pre-commit hooks

The steps are currently implemented as Makefile, but this is a temporary solution. make build can be used to make a wheel which is deployable to Dataproc.

I would start with creating a new step eg. ingest_FINNGEN.py. At first it would only create the study table, we can later sort out how to do the summary stats ingestion.
Steps around this effort:

[ ] Adding required configuration to the config files.
[ ] Adding preparation and run steps to the makefile.
[ ] Main script in the /etl/ directory.
[ ] Supporting scripts in the /etl/ingest_FINNGEN/ directory if needed. There might be some sharable components.
[ ] Before saving data, schema is checked.
[ ] All functions need to have attached docstrings.
[ ] I think there's a requirement that the code coverage cannot go down.
[ ] The format of the docstrings also checked.
[ ] Type checks for all functions are required.

If you have any problem setting up the environment, let us know. There's a tool in vscode that generates docstrings automatically, using the typesettings of the function.

Summary of some past discussions and decisions (so that this is stored somewhere)...
Repository architecture

In docs/modules/variants.md, why are variants lifted over from 38 to 37? → This is just used as an annotation, all actual processing is still done in 38.
Why is some configuration repeated in Makefile, such as project ID,region, and parameters for cluster creation? → Makefile is used only for prototyping. It will eventually evolve into a Dataflow pipeline.
With the existing approach, it looks like we're pinning everything to Dataproc. → The running infrastructure is indeed tied to Dataproc, but the code itself is not. The stages will integrate with other stages in Dataproc. The code itself is going to be agnostic of the execution architecture.
When pytest picks up docstring examples, is this a feature of pytest, or Poetry? → pytest.

Studies schema

General comment: hard to work without explanation (compare: opentargets.json) → Look into populating the metadata field.
initialSampleSize, initialSampleCount, and initialSampleCountEuropean? →  It was in the old GWAS ingest pipeline. These values were calculated to determine the proportion of Europeans, and if it was above a certain proportion, the files were ingested into the finemapping pipeline.
Do we need discoverySamples and replicationSamples? → Used by the GWAS catalogue for additional verification, probably not applicable to FinnGen.

FinnGen specific

Where is FinnGen's old study table output stored? → Doesn't matter, just format the new output to src/etl/json/schemas/studies.json.
What is gc_lambda in FinnGen API output? → Generally, these are genomic control values to account for population stratification. The meaning of the thresholds is uncertain. Don't use it for now, but it can be useful for quality control later.
studyAccessions → This is an identifier of a study in GWAS catalogue, separate for each study.
study → Presumably name of the study, should also look in GWAS catalogue.
ancestry → Assume the complete sample size is Finnish.
diseaseTrait = original disease name? → Yes, for FinnGen that would be a phenostring.
efos = mapped disease name identifiers? — Yes.
Are backgroundEfos applicable to FinnGen? → Eventually yes, because there are some examples of traits “Disease X in disease Y”. But adding support for this is not a priority.
Is it always true that nSamples = nControls + nCases? — True for case-control studies; but not for the continuous trait studies. However, when we see nControls and nCases, we can indeed always calculate nSamples as their sum.

Everything's done and ready for review in https://github.com/opentargets/genetics_etl_python/pull/59


PInvoke/WinSCard SCardListReaders returns no readers

The SCardListReaders overload that takes an out string[] parameter does not return the actual reader names when there are connected readers.
SCardEstablishContext(SCARD_SCOPE.SCARD_SCOPE_USER, phContext: out var ctx);
SCardListReaders(ctx, null, out var readers);

The problem is that this overload makes an underlying call to SCardListReaders like so:
IntPtr ptr = default;
uint cch = SCARD_AUTOALLOCATE;
var ret = SCardListReaders(hContext, mszGroups, ptr, ref cch);

According to the documentation, in this case the native code converts ptr to a pointer to a byte pointer, so ptr is always IntPtr.Zero and the out array is always empty.
I tried to fix the issue myself but came across many loose ends so I thought it would be better to report the bug and start the discussion.
The native SCardListReaders method has 3 different semantics (sticking just to the happy paths) depending on the value pointed to by pcchReaders:

If it's 0, pcchReaders is set to the required number of bytes and mszReaders is unchanged
If it's SCARD_AUTOALLOCATE, pcchReaders is set to the required number of bytes, mszReaders is allocated and filled and the ownership is passed to the caller
Otherwise pcchReaders is set to the required number of bytes and mszReaders is filled

The current PInvoke.WinSCard.SCardListReaders implementation contains 2 overloads but both overloads will fail when using SCARD_AUTOALLOCATE semantics.
We should either remove the overload with the out parameter and leave the allocation of the IntPtr to the user or make both overloads aware of the SCARD_AUTOALLOCATE semantics and behave accordingly.

Thanks for finding this. It exposes a logic error in all the SCard overloads. I'm correcting them now and will release once tested.

I have posted a fix, but cannot test on my system as it has no smart cards. In a few minutes, you should be able to pull an updated NuGet package from AppVeyor (see home page for details). Please test and confirm the overloaded method is now working.

Looks good to me, ran the WinScard unit tests and can confirmed that all List* overloads are now correctly returning the respective arrays.
Before:
Standard Output:
Registerd Readers(s)
======================

Registerd Card(s)
======================

Registerd Group(s)
======================

After:
  Standard Output:
Registerd Readers(s)
======================
OMNIKEY CardMan 5x25 0
OMNIKEY CardMan 5x25-CL 0
Registerd Card(s)
======================
Identity Device (Microsoft Generic Profile)
Identity Device (NIST SP 800-73 [PIV])
Registerd Group(s)
======================
SCard$DefaultReaders
Registerd Interface(s) for Identity Device (Microsoft Generic Profile)
======================
None

Thank you. This will go out in the next release.


fix: prevent double base in assets on dev mode when assets plugin is applied before html transformation

Description
On dev mode, for absolute asset URLs in monorepos, the assets plugin resolves the asset including the base and origin from the vite config when calling fileToDevUrl, then when transformIndexHtml is applied, the indexHtml plugin appends base again when resolving the asset path in processNodeUrl the base is appended again.
Fixes https://github.com/vitejs/vite/issues/15214
Before

After

Additional context
Setup
vite config
{
  base: '/my-path/'
}

directory structure
/
  /lib
  /app

example snippet
library-file.tsx
 import myicon from './myicon.svg'

 export const LibComponent = () =>  <img src={myicon} />;

app-file.tsx
import { LibComponent } '@namespace/lib';

export const appComponent = () => <LibComponent/>;

The resolved asset URL in dev mode results as<EMAIL_ADDRESS>
What is the purpose of this pull request?

[X] Bug fix
[ ] New Feature
[ ] Documentation update
[ ] Other

Before submitting the PR, please make sure you do the following

[X] Read the Contributing Guidelines, especially the Pull Request Guidelines.
[X] Check that there isn't already a PR that solves the problem the same way to avoid creating a duplicate.
[X] Provide a description in this PR that addresses what the PR is solving, or reference the issue that it solves (e.g. fixes #123).
[X] Update the corresponding documentation if needed.
[ ] Ideally, include relevant tests that fail without this PR but pass with it.

Checking the reproduction, transformIndexHtml shouldn't be called on the result of render as documented in https://vitejs.dev/guide/ssr.html#setting-up-the-dev-server. It is intended to be called for the index.html template.

Checking the reproduction, transformIndexHtml shouldn't be called on the result of render as documented in https://vitejs.dev/guide/ssr.html#setting-up-the-dev-server. It is intended to be called for the index.html template.

@patak-dev In the reproduction, the intent is to demonstrate rendering content without having an actual index html so I can do a direct render pass and use the result to call transformIndexHtml, mainly what I'm trying to solve is a different result by doing apply plugins -> transform index vs transform index -> apply plugins.
While I could do my own custom transformIndexHtml to solve the issue for me, I'd prefer contribute with a solution for the ecosystem, other suggestions are welcome.
Thanks for everything y'all do in vite, really love using it so far. Happy new year!

Let's close this PR. We can keep https://github.com/vitejs/vite/issues/15214 open to discuss. In case it is helpful, there are efforts to integrate RSC and Vite that don't seem to be running into that issue. Maybe a good idea to check them out https://github.com/facebook/react/pull/26926


Issues Using on Windows

Hello! I have been trying to get FastNoise2 to work on Windows but am new to the C++ build process - I have been able to get it to successfully work on MacOS. Please let me know if my question is better asked on Discord or elsewhere. Currently I have been trying to use VSCode's build tools with FastNoise's precompiled binaries for Clang. The build tools as I have them setup generate this command that runs to build the executable:
g++ -std=c++17 -fdiagnostics-color=always -g -IC:\Users\hilfu\Desktop\Code\minecraft-opengl/dependencies/include -LC:\Users\hilfu\Desktop\Code\minecraft-opengl/dependencies/library_windows C:\Users\hilfu\Desktop\Code\minecraft-opengl/dependencies/library_windows/FastNoise.lib C:\Users\hilfu\Desktop\Code\minecraft-opengl/*.cpp C:\Users\hilfu\Desktop\Code\minecraft-opengl/glad.c -lglfw3dll -lFastNoise -lFastNoiseD -o C:\Users\hilfu\Desktop\Code\minecraft-opengl/app
However, this fails with many undefined reference errors, making me think the dlls or .lib files are not linking correctly:
C:/Users/hilfu/Desktop/Code/minecraft-opengl/dependencies/include/FastNoise/FastNoise.h:34: undefined reference to FastNoise::Add* FastSIMD::New<FastNoise::Add>(FastSIMD::eLevel, void* (*)(unsigned long long, unsigned long long))'
For reference, attached below is an image of my current file structure. I have also tried using the clang++ compiler instead of g++, but got different errors (which if needed I can try to reproduce again and attach here). If there is any additional information needed to help resolve this, or if there is anything obvious I missed in my inexperience, please let me know. I am hoping I won't have to use FastNoiseLite just for windows!

You should use either -lFastNoise or -lFastNoiseD (debug) not both. Your library link folder also looks wrong it should be -LC:\Users\hilfu\Desktop\Code\minecraft-opengl\dependencies\library_windows

Thank-you for the input! I have gotten rid of the debug file and fixed the link library folder so it only uses backslashes now, however I seem to still be getting the same undefined reference errors. I also tried forward slashes with no luck. Here is how the command looks now:
g++ -std=c++17 -fdiagnostics-color=always -g -IC:\Users\hilfu\Desktop\Code\minecraft-opengl\dependencies\include -LC:\Users\hilfu\Desktop\Code\minecraft-opengl\dependencies\library_windows C:\Users\hilfu\Desktop\Code\minecraft-opengl\dependencies\library_windows\FastNoise.lib C:\Users\hilfu\Desktop\Code\minecraft-opengl\*.cpp C:\Users\hilfu\Desktop\Code\minecraft-opengl\glad.c -lglfw3dll -lFastNoise -o C:\Users\hilfu\Desktop\Code\minecraft-opengl\app
In case it may help I've also dropped here the full error stack as a txt file when running the command. Thank-you for your help.
full_undefined_error.txt

I assume you are using minGW? I don't think MSVC binaries are compatible with MinGW

It looks like g++ is mingw, I see that would not work then. I was mostly hoping it would because g++ worked with the MacOS clang binaries. If I switch my project to use ClangCL (with the clang++ command) that should work with the binaries highlighted below then, right? If not I was thinking maybe I should try to port my code over to visual studio since the wiki example uses that and MSVC is used by Visual Studio from what I can tell

That should work, you will have to use Clang++ outside of MinGW in order to be ABI compatible with the FastNoise2 libs. Alternatively you could compile FastNoise2 libs yourself for Clang on MinGW if you do want to go that route.
GCC MinGW is not supported: https://github.com/Auburn/FastNoise2/issues/69

Thanks for the suggestion to compile on MinGW! It looks like it worked, I have some other errors in my code but I don't seem to be getting any undefined reference errors anymore, once I get my program fully working shortly and fix these seemingly unrelated errors I'll confirm it definitely worked.
I actually tried to compile the source before using the wiki, but I only noticed now by default it was compiling for Visual Studio (and thus likely for MSVC)! I used this command so it uses the GCC and G++ compilers/MinGW, and was able to get it to work for the project setup portion:
cmake -G "MinGW Makefiles" -S . -B build -D FASTNOISE2_NOISETOOL=OFF -D FASTNOISE2_TESTS=OFF -D BUILD_SHARED_LIBS=ON -D CMAKE_CXX_COMPILER="C:/Users/hilfu/Documents/mingw64/bin/g++.exe" -D CMAKE_C_COMPILER="C:/Users/hilfu/Documents/mingw64/bin/gcc.exe"

It may be useful to add a note to this wiki page (linked here) that you'll need to add -G "MinGW MakeFiles and the extra options for the CMAKE_CXX_COMPILER and CMAKE_C_COMPILER to compile it for mingw.
Thanks for your help again!

Ah, unfortunately I misread and you are right - I got no linker errors compiling with g++ but the program crashes when ran with any FastNoise2 command that actually generates noise.
I have since tried using clang++ instead, and get no linker errors, but for some reason instead get this error when running program:

However, when compiling with clang using the command below I don't even get a libFastNoise.dll so not sure where that is coming from.
clang++ -std=c++17 -fdiagnostics-color=always -g -IC:\Users\hilfu\Desktop\Code\minecraft-opengl\dependencies\include -LC:\Users\hilfu\Desktop\Code\minecraft-opengl\dependencies\library_windows C:\Users\hilfu\Desktop\Code\minecraft-opengl\dependencies\library_windows\glfw3dll.lib C:\Users\hilfu\Desktop\Code\minecraft-opengl\dependencies\library_windows\FastNoiseD.lib C:\Users\hilfu\Desktop\Code\minecraft-opengl\*.cpp C:\Users\hilfu\Desktop\Code\minecraft-opengl\glad.c -lglfw3dll -lFastNoiseD -o C:\Users\hilfu\Desktop\Code\minecraft-opengl\app

On another note, for some reason when I compile the FastNoise2 source with clang I cannot get the release version only the debug version but I don't think that should matter. I might need to mess around with this a bit more to see if I can get this to work.

Aaahhhh! There we go! For some reason the terrain is see-through (will have to figure that one out lol some other weird windows bug Im sure) but it does look to be generating now with the FastNoise2 noise on windows hah. Thanks so much for all the help Auburn!

Just for reference, I was able to build FastNoise fully like you suggested in the release mode with this command:
cmake -G "Ninja" -S . -B build -D FASTNOISE2_NOISETOOL=OFF -D FASTNOISE2_TESTS=OFF -D BUILD_SHARED_LIBS=ON -D CMAKE_CXX_COMPILER="C:/Program Files/LLVM/bin/clang++.exe" -D CMAKE_C_COMPILER="C:/Program Files/LLVM/bin/clang.exe" -D CMAKE_BUILD_TYPE=Release
I realized that libFastNoise.dll error was because I was building my project with -o app which built an app.exe with g++, but which only build an app file with clang++. After fixing that and rebuilding with the new DLLs it looks like it is working!
If you would like I can see at making a pull request with this information on how to build for clang in the wiki - let me know. Thanks for all the help again!


Node type gen improvements

This patchset will change the generation of our JSON node type definitions (src/modules/flow/.json, src/lib/flow/builtins.json) so they are generated from generator specifications (src/modules/flow//*.json) in Python, so it's platform independent and we can get these even for other OS.
Even the src/lib/flow/builtins.json is generated in Python using a script that loads all the definitions and merging into a single file with the module name being "builtin".

rebased and merged.


Adds Dj-Models

I've created Dj-Models - a tool that allows developers to use the Django ORM and models in any Python webframework (e.g Flask + Django in the same app).

Hi @iMerica this looks quite interesting. Seems it hasn't quite picked up in adoption yet and since I don't have personal experience with it, I'm going to hold off adding to the 3rd party list for now since I don't want it to bloat out and just become Django Packages step by step.


Strider “npm start” generating errors

I am trying to install a Strider instance on an AWS EC2 instance. I have installed all the perquisites as described in this document but have run across a problem running Strider using npm start.
I have confirmed that MongoDB is running correctly.
I will eventually run it as a service, but I'd like to check it's running first. I receive pages of errors along the lines of:

<EMAIL_ADDRESS>start /home/ubuntu/strider
bin/strider

7577 forked
module.js:341
    throw err;
    ^

Error: Cannot find module '../../../models'
    at Function.Module._resolveFilename (module.js:339:15)
    at Function.Module._load (module.js:290:25)
    at Module.require (module.js:367:17)
    at require (internal/module.js:16:19)
    at Object.<anonymous> (/home/ubuntu/strider/lib/routes/collaborators/api.js:3:14)
    at Module._compile (module.js:413:34)
    at Object.Module._extensions..js (module.js:422:10)
    at Module.load (module.js:357:32)
    at Function.Module._load (module.js:314:12)
    at Module.require (module.js:367:17)
    at require (internal/module.js:16:19)
    at Object.<anonymous> (/home/ubuntu/strider/lib/routes/collaborators/index.js:9:11)
    at Module._compile (module.js:413:34)
    at Object.Module._extensions..js (module.js:422:10)
    at Module.load (module.js:357:32)
    at Function.Module._load (module.js:314:12)
    at Module.require (module.js:367:17)
    at require (internal/module.js:16:19)
    at Object.<anonymous> (/home/ubuntu/strider/lib/app.js:44:27)
    at Module._compile (module.js:413:34)
    at Object.Module._extensions..js (module.js:422:10)
    at Module.load (module.js:357:32)
    at Function.Module._load (module.js:314:12)
    at Module.require (module.js:367:17)
    at require (internal/module.js:16:19)
    at Object.<anonymous> (/home/ubuntu/strider/main.js:9:11)
    at Module._compile (module.js:413:34)
    at Object.Module._extensions..js (module.js:422:10)
7577 died 1 null

I have looked at this overflow but it doesn't solve my problem unfortunately. I do not appear to have a server.js anywhere.
Do I need one of these? Am I configuring it correctly? Incidentally, my Strider instance is located in
/home/ubuntu but not really being a Unix bunny, I'm not sure if this is really where it ought to go.
Any help greatly appreciated.

You must have pull down master, try installing the stable version via npm install -g strider or checkout the v1.8.0 tag if you clone it yourself. If you still want to do canary, then just pull down the latest code, it should be fixed.


Assess libraries.io trending projects feed, consider replacing ours

The Libraries.io list of trending PyPI projects is very different from the one on the http://pypi.org/ front page. Our list just computes a zscore of downloads. We should check their data & methods, and if their results are more interesting or better than ours, we should hit their API and use their list instead of ours on our front page.
From IRC today.

I've looked under the hood at the libraries.io source code, to try to understand how their trending list was computed. However, I'm not so familiar with Ruby or Rails, so let's see what I can find... I've started by searching for "trending", which trimmed down the results.
At first glance, there is a query from the repository model which name looked promising. But the other search results from Github seem to reference the hacker_news query instead of the trending one. I'm not clear which query is used, but it seems it relies on Github stars?
Now, looking at their API documentation, I'm not sure there is an endpoint available to expose this trending data. The project search seems interesting but seems to require a search term.
Is that answering the research questions?

I appreciate you looking into this, @browniebroke!
@andrew is a maintainer of Libraries.io and could probably help answer our question about the endpoint availability and how we'd access trending data.
@browniebroke could you try comparing the list of trending projects on the pypi.org front page with the list at https://libraries.io/trending?platforms=PyPI , and briefly assess how widely used or trending some of those projects seem to be (when you look for mentions of them on social media, on GitHub, in StackOverflow, and in new release announcements)? That might help us figure out how different the results are.


I can't send alerts to Slack due to unknown record type (?)

I managed to have this running but I can't send alerts to Slack.
I am able to read the unified2 file using u2spewfoo but I can't find the Buffer type inside the code, this is an example:
Buffer
        sensor_id: 0    event_id: 447   event_second:<PHONE_NUMBER>
        packet_second:<PHONE_NUMBER>       packet_microsecond: 132363
        packet_length: 111
[    0] 16 03 03 00 6A 02 00 00 66 03 03 27 7C 68 F6 D4  ....j...f..'|h..
[   16] 0C E2 1B 09 88 ED 82 92 8E 24 16 D5 E3 4D 17 66  .........$...M.f
[   32] 82 FD EA 6B F0 23 96 80 00 13 D2 20 58 04 84 FE  ...k.#..... X...
[   48] CC 70 A4 C8 05 E6 73 6D 74 A3 B6 66 50 CA C0 BB  .p....smt..fP...
[   64] 8A 73 2A DA 1B BE 54 B5 CE 31 76 97 C0 2F 00 00  .s*...T..1v../..
[   80] 1E 00 00 00 00 00 0B 00 02 01 00 FF 01 00 01 00  ................
[   96] 00 10 00 0B 00 09 08 68 74 74 70 2F 31 2E 31     .......http/1.1

I mentioned this because I also tried with others libraries and they do not support that record type.
Thanks.

For the unified file reader itself please head over to go-unified.
Keep in mind that the slack and pushover plugin only forward messages where either the source or target ip is not in the private ip range.
func (p *Plugin) do(v interface{}) error {

	switch data := v.(type) {

	case *ids.Record:

		if !data.IsValid() || data.Drop {
			return nil
		}

		// ignore internal packet

		if data.IsLocal() {
			return nil
		}

		if len(data.SIDMap.Msg) == 0 {
			return nil
		}

		select {
		case p.data <- data:
		case <-time.After(250 * time.Millisecond):
			log.Errorf("%T data channel full, drop message", p)
		}

	}

	return nil
}

Thank you so much for the answer; porkpie seems to be the simplest way to send alerts, most solutions requires many other tools.


Revert "Use class names instead of strings"

Reverts vespa-engine/vespa#30357
Broke ~at least~ 1 system test, need to look into it

👍


Updating ARN.py to look for StringEqualsIgnoreCase in policy condition blocks

Example statement:
{
      "Resource": "arn:aws:sqs:<region>:<account_number>:<queue_name>",
      "Effect": "Allow",
      "Sid": "1",
      "Action": "sqs:SendMessage",
      "Condition": {
        "StringEqualsIgnoreCase": {
          "aws:SourceArn": "<some_arn>"
        }
      },
      "Principal": "*"
    }

Coverage remained the same at 51.375% when pulling f7f1b2560358a4dec0b86c6d9db97d1ed94dff29 on update_ARN_condition_extraction_stringequalsignorecase into 3d0e1d5ce8c77cb5e7e6eaad12b0cd7983c5e9f8 on develop.


Fix mismatch vid range of synthetic population specs.

This change is

The global range did not match the last subrange.


Update id in config.xml

Hi Olivier,
I discovered this project when looking for the issue you reported in OpenBoard. I'm not part of the OpenBoard project, but probably currently the main contributor, especially for the upcoming 1.7 release, which is expected somewhere next year. Here we replace the QWebKit based browser engine with QWebEngine, which in turn is based on Chrome. This will also affect the widgets.
For this issue I want to point you to a small improvement: Please choose a unique id for your widget. So it is better to use id="http://obooklage.free.fr/TeX2Book", as this will uniquely identify your widget.
This very much helps the automatic upgrade of widgets when moving from 1.6.x to 1.7.x. Here OpenBoard has to know which widgets are in a document. The id is more or less the only way to find this out.
For the future widget API, please also have a look at https://github.com/letsfindaway/OpenBoard/wiki/Widget-API. The main difference is that functions returning a value will be asynchronous. A prominent example is window.sankore.preference. See https://github.com/letsfindaway/OpenBoard/wiki/Widget-API#functions on examples how this works with the asynchronous API.
In OpenBoard 1.7 you will have the option to "Fix" a widget. This takes a snapshot of the current state and shows this instead of the actual web page. Using this function also allows to export this snapshot to PDF. See also some thoughts on related things here: https://github.com/letsfindaway/OpenBoard/issues/98.
Martin

Hi Olivier,
I discovered this project when looking for the issue you reported in OpenBoard. I'm not part of the OpenBoard project, but probably currently the main contributor, especially for the upcoming 1.7 release, which is expected somewhere next year. Here we replace the QWebKit based browser engine with QWebEngine, which in turn is based on Chrome. This will also affect the widgets.
For this issue I want to point you to a small improvement: Please choose a unique id for your widget. So it is better to use id="http://obooklage.free.fr/TeX2Book", as this will uniquely identify your widget.
This very much helps the automatic upgrade of widgets when moving from 1.6.x to 1.7.x. Here OpenBoard has to know which widgets are in a document. The id is more or less the only way to find this out.
For the future widget API, please also have a look at https://github.com/letsfindaway/OpenBoard/wiki/Widget-API. The main difference is that functions returning a value will be asynchronous. A prominent example is window.sankore.preference. See https://github.com/letsfindaway/OpenBoard/wiki/Widget-API#functions on examples how this works with the asynchronous API.
In OpenBoard 1.7 you will have the option to "Fix" a widget. This takes a snapshot of the current state and shows this instead of the actual web page. Using this function also allows to export this snapshot to PDF. See also some thoughts on related things here: letsfindaway/OpenBoard#98.
Martin

Hello Martin.
Is done today, this widget is now compatible with OpenBoard >= 1.7.0
Regards,
Olivier.