[BUG] Restoring status from backup never changes to running

Describe the bug

When you restore a vm from backup it goes to restoring status, but never back to running
To Reproduce
Steps to reproduce the behavior:

Create new VM
Take backup
restore from backup
Expected behavior

After restore is done the status should go back to running
Support bundle

supportbundle_754ee1c7-96c6-45f2-98a9-705f42b7a2f6_2021-12-09T01-38-27Z.zip
Environment:

Harvester ISO version: master-655c251a-head
Underlying Infrastructure (e.g. Baremetal with Dell PowerEdge R630): 3 node vagrant ipxe setup

Additional context
Add any other context about the problem here.
If you refresh the page it will update with running, but it requires a manual page load
Developer update @FrankYang0529
Test plan
Take Backup without error.

Create a VM.
Setup Backup Target.
Take a VMBackup for the VM.
Before VMBackup is ready, there should not have any error message in VMBackup.status.

sounds like the websocket problem. can you check if there are error messages in the developer's console? Reenable the warning should solve it.

I tried it again and checked the web console and the network traffic via developer tools and didn't see anything. I also did all of this after resetting the enable warning setting on the SSL cert. A refresh still fixed the issue.

When you create a backup the label updates after creation with an error. I tested this on an NFS server that was created on the embedded Rancher, but it should do it on any one.
Validation steps

Set a valid NFS target in settings
Create a new VM
Log into VM and create a file and put some text in it
run sync to write out memory to the disk
run a NFS backup
immediately check backups page in Harvester UI

@guangbochen  This may be a backend issue.

It shows the error then it continues to create the backup. the issue is that it shouldn't be showing the error.

It shows the error then it continues to create the backup. the issue is that it shouldn't be showing the error.

This is related LH issue https://github.com/longhorn/longhorn/issues/3392. We parse status in VolumnSnapshot. If there is an error message in VolumnSnapshot, we also set it in VMBackup. However, this error message is temporary, so we will clear the error status and get a healthy VMBackup after VolumnSnapshot is done.

PR has been created https://github.com/longhorn/longhorn-manager/pull/1233. Longhorn will backport it to 1.2.4. Moving this issue out of the icebox.

Moving this back to icebox until Longhorn RC

Longhorn v.1.2.4 RC1 is available. Moving this issue out of the icebox and into implement. https://github.com/longhorn/longhorn/releases/tag/v1.2.4-rc1

Verified this issue has been fixed.

Test Information

Environment: qemu/KVM 3 nodes
Harvester Version: master-fd872c99-head
ui-source Option: Auto

Verify Steps:

Follow the steps in https://github.com/harvester/harvester/issues/1650#issuecomment-1024612633


feat: setup app for telegraf

Overview
Ref: #179

Checklist

[x] New and updated code has appropriate documentation
[x] New and updated code has new and/or updated testing
[x] Required CI checks are passing
[x] Visual proof for any user facing features like CLI or documentation updates
[x] Linked issues closed with keywords

I'll create a ticket for this and we can keep it in the backlog for when we'll have sometime


Add page links

Closes #82

@uriyyo Could you please explain somewhere in the docs how to use the enhancements you added and the way to use it?
from fastapi_pagination.links import Page
Sorry not to be very close to python but the time I spent to enable the links drived me crazy :)


Refactor receipt-required-enum to merge inton expense-type-enum so expense values in single location

https://github.com/ministryofjustice/apvs-external-web/blob/57738f0889338d1e4061b4983ff5b08ebc0ba070/app/constants/receipt-required-enum.js

Might be worth holding off on this one, this functionality is going to be moved to the database level in user story 825


Add new LSP extension for workspace symbol lookup

As well as all symbol types (functions, modules).
Remove outdated documentation regarding symbol lookup filtering.
Closes #4881

The current PR makes the UX of using RA with VSCode a bit nicer (IMHO), but I realize it removes the filtering functionality from other editors.
If that's unacceptable, perhaps we could expose these filtering knobs as settings to be controlled in VSCode? Or detect VSCode as the LSP client and set them accordingly?

Yeah, it's sad that this got broken in vs code. That being said, I think searching in the current workspace by default works better, and I definitely think that we should keep the heuristic of "search for types by default, if there are no results, search for all symbols instead".
Let's make this user configurable. In config.rs, I think we should add:
search.dependencies: bool = false,
search.allSymbols: bool = false,

Let's make this user configurable. In config.rs, I think we should add:
search.dependencies: bool = false,
search.allSymbols: bool = false,

Would it be possible to override these settings on per-request basis? i.e. starting ra with default to not search dependencies, but changing it for 1 request, when you might want to see them.
I think this is the perfect usecase for an elisp function that takes an optional prefix argument similar to this function in lsp-clangd. That way, we can call M-x lsp-find-workspace-symbol or C-u M-x lsp-find-workspace-symbol to include dependencies in the results.

@petr-tik emacs can directly add * and # to the query string, this PR is specifically for VS Code.
That being said, given that #* workaround is broken in vscode, it make sense to design a proper LSP extension here. See the how-to for how this should be done: https://github.com/rust-analyzer/rust-analyzer/tree/master/docs/dev#how-to-
basically, we need to add two fields to lsp request params: search_scope and search_kinds

Pushed code to implement a new LSP extension extending the usual workspace symbol lookup request.
Aside from bikeshedding names (suggestions welcomes), I'd like some feedback for a few open points:

I added the additional search_scope and search_kind params to both the global server config, as well as to the request. Is that desirable?
I assume we want a search_kind enum instead of an OR'ed flag-like search_kinds to keep it simple?
Currently the logic still checks for the * and # markers because there might be existing LSP clients using that. Do we want it? Current precedence logic is markers -> request params -> global config
config.rs currently transforms WorskpaceSymbolSearchScopeDef into lsp_ext::WorkspaceSymbolSearchScope. I'm not sure we want an additional enum / struct indirection in between those.
I haven't actually tested the per-request params case, only the VSCode setting -> rust-analyzer global config path. Is there an easy way to check the per-request case?

Since the markers work fine in Emacs, I would vote for keeping them.

Should we file an issue or proposal on https://github.com/microsoft/language-server-protocol?

Should I add some caveat / note to https://rust-analyzer.github.io/manual.html#workspace-symbol that that the # and '*' markers don't work with VSCode?

Updating manual would be helpful, yeah (it’s in this repo)
On Tuesday, 18 May 2021, alcroito @.***> wrote:

Updated PR.
Should I add some caveat / note to https://rust-analyzer.github.
io/manual.html#workspace-symbol that that the # and '*' markers don't
work with VSCode?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/rust-analyzer/rust-analyzer/pull/7698#issuecomment-842671411,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AANB3M3YL3X2YXYHWBL3HVLTOGG67ANCNFSM4XW5SNKQ
.

Updated manual to mention VSCode users shouldn't use the filtering symbols, but should rely on the config settings instead.

bors r+
Thanks!

bors retry

bors retry


:fire: mongo: removes index option SetBackground due to being deprecated as of Mongo 4.2.

Fixes #47.
Note:

To be merged @ Mongo 4.0 EOL April 2022.

Pull Request Test Coverage Report for Build 327

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-0.2%) to 28.114%

Totals

Change from base Build 324:
-0.2%

Covered Lines:
808

Relevant Lines:
2874

💛  - Coveralls

Closed in favour of #61.


[Bug] when persistent_workers=False, map of yolox-s decreases by 2 + points

Prerequisite

[X] I have searched Issues and Discussions but cannot get the expected help.
[X] I have read the FAQ documentation but cannot get the expected help.
[X] The bug has not been fixed in the latest version (master) or latest version (3.x).

Task
I'm using the official example scripts/configs for the officially supported tasks/models/datasets.
Branch
master branch https://github.com/open-mmlab/mmdetection
Environment
sys.platform: linux
Python: 3.7.5 (default, Oct 25 2019, 15:51:11) [GCC 7.3.0]
CUDA available: True
GPU 0,1,2,3,4,5,6,7: NVIDIA A100-SXM4-80GB
CUDA_HOME: /usr/local/cuda-11.6
NVCC: Cuda compilation tools, release 11.6, V11.6.55
GCC: gcc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0
PyTorch: 1.12.1+cu116
PyTorch compiling details: PyTorch built with:

GCC 9.3
C++ Version: 201402
Intel(R) Math Kernel Library Version 2020.0.0 Product Build 20191122 for Intel(R) 64 architecture applications
Intel(R) MKL-DNN v2.6.0 (Git Hash 52b5f107dd9cf10910aaa19cb47f3abf9b349815)
OpenMP 201511 (a.k.a. OpenMP 4.5)
LAPACK is enabled (usually provided by MKL)
NNPACK is enabled
CPU capability usage: AVX2
CUDA Runtime 11.6
NVCC architecture flags: -gencode;arch=compute_37,code=sm_37;-gencode;arch=compute_50,code=sm_50;-gencode;arch=compute_60,code=sm_60;-gencode;arch=compute_70,code=sm_70;-gencode;arch=compute_75,code=sm_75;-gencode;arch=compute_80,code=sm_80;-gencode;arch=compute_86,code=sm_86
CuDNN 8.3.2  (built against CUDA 11.5)
Magma 2.6.1
Build settings: BLAS_INFO=mkl, BUILD_TYPE=Release, CUDA_VERSION=11.6, CUDNN_VERSION=8.3.2, CXX_COMPILER=/opt/rh/devtoolset-9/root/usr/bin/c++, CXX_FLAGS= -fabi-version=11 -Wno-deprecated -fvisibility-inlines-hidden -DUSE_PTHREADPOOL -fopenmp -DNDEBUG -DUSE_KINETO -DUSE_FBGEMM -DUSE_QNNPACK -DUSE_PYTORCH_QNNPACK -DUSE_XNNPACK -DSYMBOLICATE_MOBILE_DEBUG_HANDLE -DEDGE_PROFILER_USE_KINETO -O2 -fPIC -Wno-narrowing -Wall -Wextra -Werror=return-type -Wno-missing-field-initializers -Wno-type-limits -Wno-array-bounds -Wno-unknown-pragmas -Wno-unused-parameter -Wno-unused-function -Wno-unused-result -Wno-unused-local-typedefs -Wno-strict-overflow -Wno-strict-aliasing -Wno-error=deprecated-declarations -Wno-stringop-overflow -Wno-psabi -Wno-error=pedantic -Wno-error=redundant-decls -Wno-error=old-style-cast -fdiagnostics-color=always -faligned-new -Wno-unused-but-set-variable -Wno-maybe-uninitialized -fno-math-errno -fno-trapping-math -Werror=format -Werror=cast-function-type -Wno-stringop-overflow, LAPACK_INFO=mkl, PERF_WITH_AVX=1, PERF_WITH_AVX2=1, PERF_WITH_AVX512=1, TORCH_VERSION=1.12.1, USE_CUDA=ON, USE_CUDNN=ON, USE_EXCEPTION_PTR=1, USE_GFLAGS=OFF, USE_GLOG=OFF, USE_MKL=ON, USE_MKLDNN=OFF, USE_MPI=OFF, USE_NCCL=ON, USE_NNPACK=ON, USE_OPENMP=ON, USE_ROCM=OFF,

TorchVision: 0.13.1+cu116
OpenCV: 4.6.0
MMCV: 1.7.0
MMCV Compiler: GCC 9.3
MMCV CUDA Compiler: 11.6
MMDetection: 2.26.0+31c8495
Reproduces the problem - code sample
None
Reproduces the problem - command or script
bash tools/dist_train.sh configs/yolox/yolox_s_8x8_300e_coco.py 8 --cfg-options data.persistent_workers=False fp16.loss_scale=dynamic

Reproduces the problem - error message
The running accuracy is 40.1 according to the default configuration, and the running accuracy is 37.8 when set to False by data.persistent_workers.
Additional information
No response

It would be really appreciated if you could upload your training log to help us find the reason. We will try to fix it as soon as possible.

mmdet_yolox_s_map_bug_report.zip

It would be really appreciated if you could upload your training log to help us find the reason. We will try to fix it as soon as possible.

This problem may cause by the randomness of numpy.
Try to modify the worker_init_fn like this PR   https://github.com/open-mmlab/mmdetection/pull/8142 to see whether it can solve the problem.
Due to the resource limitation, we currently have no GPU to verify it in these days. We will report the result a few days later.


Fix update memory bug

Description
Fixing bug when using the m.update() method.
Fixes #1917
Type of change
Please delete options that are not relevant.

[x] Bug fix (non-breaking change which fixes an issue)
[x] Refactor (does not change functionality, e.g. code style improvements, linting)
[x] Documentation update

How Has This Been Tested?
Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration
Please delete options that are not relevant.

[x] Unit Test
[x] Test Script

Checklist:

[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my own code
[x] I have commented my code, particularly in hard-to-understand areas
[x] 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
[x] New and existing unit tests pass locally with my changes
[x] Any dependent changes have been merged and published in downstream modules
[x] I have checked my code and corrected any misspellings

Maintainer Checklist

[x] closes #1917
[x] Made sure Checks passed

Hello. I would like to ask when this bug will be fixed.

@yann0917 You can check out the latest commit of the mem0. The issue is solved in that commit.

Clossing the PR as it's already been solved with the PR #1939


Tooltip is cut off by the modal when too large

Migrated from GitLab: https://gitlab.com/meltano/meltano/-/issues/1443
Originally created by @oleary on 2019-12-12 21:15:45

What is the current bug behavior?
If the tooltip is too large, it is cut off by the modal.
What is the expected correct behavior?
Being able to read the entire tooltip
Steps to reproduce

Add Google Analytics tap
Hover over View ID
Observe tooltip issue

Relevant logs and/or screenshots

Possible fixes
If you can, link to the line of code that might be responsible for the problem or suggest a fix
Further regression test
Ensure we automatically catch similar issues in the future

[ ] Write additional adequate test cases and submit test results
[ ] Test results should be reviewed by a person from the team

View 3 previous comments from the original issue on GitLab


DeadlockWatchdogExitOnTimeout and DeadlockWatchdogInterval Options not found

From checking the logs I see these two options are added in the command line but don't seem to be recognized on any versions of Graalvm/Native Compile available with Java 11 compatibility. Any insight will be helpful.
[Wed May 06 15:25:41 PDT 2020][INFO] ==================== COMPILE TASK ====================
[Wed May 06 15:25:41 PDT 2020][INFO] We will now compile your code for x86_64-linux-linux. This may take some time.
[Wed May 06 15:25:52 PDT 2020][INFO] [SUB] Error: Could not find option 'DeadlockWatchdogExitOnTimeout'. Use -H:PrintFlags= to list all available options.
[Wed May 06 15:25:52 PDT 2020][INFO] [SUB] Error: Could not find option 'DeadlockWatchdogInterval'. Use -H:PrintFlags= to list all available options.
[Wed May 06 15:25:52 PDT 2020][INFO] [SUB] Error: Use -H:+ReportExceptionStackTraces to print stacktrace of underlying exception
[Wed May 06 15:25:52 PDT 2020][INFO] [SUB] Error: Image build request failed with exit status 1

Task :nativeCompile
[Wed May 06 15:25:52 PDT 2020][SEVERE] Process compile failed with result: 1
Check the log files under /home/giovanniem/NetBeansProjects/GraalVMTest/build/client/x86_64-linux/gvm/log
And please check https://docs.gluonhq.com/client/ for more information.
[Wed May 06 15:25:52 PDT 2020][INFO] Logging process [compile] to file: /home/giovanniem/NetBeansProjects/GraalVMTest/target/client/log/process-compile-1588803952473.log
[Wed May 06 15:25:52 PDT 2020][SEVERE] Compiling failed.
Check the log files under /home/giovanniem/NetBeansProjects/GraalVMTest/build/client/x86_64-linux/gvm/log
And please check https://docs.gluonhq.com/client/ for more information.

Fixed using graalvm version found in https://docs.gluonhq.com/client/


Clean up/refactor GraphNode and make it more flexible

Split from #67152. Depends on #79308.
This PR contains the rework of GraphNode.
Detailed changes:

Split GraphNode into GraphElement and GraphNode
Renamed set/get_connection_input/output_x methods to set/get_port_input/output_x
Remove get_port_input/output_height as it was not necessary (basically returned the height of the slot of the given port which is the height of the child in that slot)
GraphNode: get_port_input/output_position returns no longer the position premultiplied with the scale
Revised custom port drawing (now achievable via overriding a function)
Flexibility improvements to GraphNode's titlebar

It now consists of a HBoxContainer with a Label (accessible via `get_titlebar_hbox
StyleBox for body (slot area) and title bar (both with selected variants)
Use "GraphNodeTitleLabel" theme variation for title labels, remove the title offset theme constants

Respective adjustments to the editor theme and default project theme
Rename lots of variables to be more descriptive (e.g. icofs -> icon_offset, c -> child)
Restructure the header and source files to follow a consistent scheme (i. a. order of member variable and method declarations, which were sometimes mixed)
Fix custom port icon not being centered when it's bigger than the default icon
Fix and improve documentation with regard to port/connection/slot terminology
Fix comment style in various places
[can be extracted if desired] VisualShader: Fix error label increasing the minimum size in an ugly way since it autowrap isn't enabled

Rebased.

You need to handle the compatibility breakages

I'll review it this week, but for now I wanted to mention that grid toggle icons shouldn't be a part of this. They were added (though originally missing) in https://github.com/godotengine/godot/pull/79308.

I fixed the icons and added some missing renames. I noticed some existing inconsistencies with closing/deleting, and unified them using the term closing, closable as it makes the most sense from the perspective of the graph itself. We can discuss this, but at least it's all consistent now and doesn't use both terms interchangeably.
From a quick look at visual shaders everything works fine. So I'll continue with my review.
PS. I think the names that we've picked for updated classes are good, but we can ask for more opinions.

I haven't checked the code too closely, but it seems mostly fine outside of outlined problems. This is to say that once those are addressed, I think we can go ahead with this, and use public testing to help us identify if there remain any typos or calculation mistakes.
What remains to test is using GraphEdit in a project, customizing it, extending elements and configuring the titlebar. I will do this tomorrow.

We should also remove the configuration warning with this PR:

Tested functionality. The improvements are very nice! I am a bit concerned that it's impossible to make something closable without writing code that adds buttons, but I guess you are free to define your own subclass of GraphNode that does that. We can also see if there is any negative feedback to this change.
There are a couple of sizing issues.

One I've noticed during the code review already, where child's height was added during the minimum size calculation. This leads to GraphElements growing in height the more children they have.

For the first frame GraphNode's titlebar has incorrect dimensions. It basically fits only the label itself and doesn't account for stylebox margins or other children. It fixes itself if you click on it.

Resizable GraphNodes can't shrink under certain conditions. If you resize it and let go, then resize it again, it all works fine. However, if you click anywhere (on the node itself, on the title, on the empty space) and then try to resize again, the current size is going to stay fixed.

https://github.com/godotengine/godot/assets/11782833/98d83753-4c44-4b12-bab9-274e18b2aa8f

Committed the fixes/changes, should address all review comments.
I would remove the configuration warning in a few weeks after making sure that everything works fine and we haven't overlooked any major design flaw.
The highlights for the menu buttons in the default theme aren't introduced with this or recent PRs (already present in 4.0.4), so I would rather not include it in this one, but in a follow-up.

More generally, I also have lots of requests about UI interactions with connections (being able to insert a node into a connection, select a connection to remove it etc.), mainly inspired by Blender. Not sure which ones actually require changes in Godot, though.

I think GraphEdit would need to provide a utility method/signal to detect clicks on the connection line. And the rest can be done on the application side.

Looks like visual shader nodes now misses the delete button - does it intended?

@RodZill4

I'd really like the "new comment node" to be able to contain any Control (something like a Window pinned to the graph canvas). Would be much more flexible and not limited to comments.

This will definitely be the case. You can probably implement a basic comment node right now (without fancy sorting or automatic resizing) using the new base class GraphElement.

More generally, I also have lots of requests about UI interactions with connections (being able to insert a node into a connection, select a connection to remove it etc.), mainly inspired by Blender. Not sure which ones actually require changes in Godot, though.

I have plans to construct an API around connections, but this has to wait for 4.3+.

This is a bit more verbose, but doing input checks in graph_element_resized feels not right, so I went with this approach.

I think singleton exists for this specific purpose, so you can check the state of the input at any point. So I don't have a problem with just copying the logic from GraphEdit::gui_input. But I'm not against setting a flag either. Just as long as we don't end up with many of them, making it's harder to understand the current state of the node (because many flags mean many permutations of them).

No worries! Next time try out the "Add suggestion to batch" option to do all in one commit

Thanks!

@YuriSizov The snapping was already fixed (when resizing).

I don't see any relevant changes and you haven't pushed anything before I asked the last time 👀

@Geometror Just to re-confirm, because I've just tested it on master, but there is no snapping when resizing. I think you haven't pushed the fixed that you've described before.

We should also remove the configuration warning with this PR:

@YuriSizov btw that never happened, might be worth doing before the upcoming release?

GraphEdit is still experimental so I'd keep it until that changes

Leaving it as experimental gives us room to tweak and fix, my suggestion is to leave it until 4.2.1 at the earliest to get some more field testing of it done

We should also remove the configuration warning with this PR:

@YuriSizov btw that never happened, might be worth doing before the upcoming release?

We decided to keep it marked as experimental until 4.3, but there shouldn't be major breaking changes. It's just to account for possible feedback from GraphEdit users, who aren't many.

@YuriSizov ah yeah that kinda makes sense, the main issue i see with it is just that currently the most common feedback is "i'm scared to become a GraphEdit user, because it literally tells me to wait for an undetermined amount of time before i do so, when will the rework finally happen so i can start using it?"

Updating Material Maker for Godot 4.2 has been pretty smooth on the GraphEdit/GraphNode side. Didn't notice any problem (and graph nodes are used A LOT). The only aspect I didn't dig into yet is converting comment nodes into GraphElements.

@RodZill4 Comment nodes are likely going to be difficult to implement just with GraphElement (at least how they used to work) due to the removal of dedicated logic in GraphEdit. Comment nodes were removed because the implementation was problematic and I couldn't come up with a better approach in time. I had a few prototypes which did almost work (but failed in certain cases). This has a high priority for me, but time is a scarce commodity and I'd like to merge the other GraphEdit related PRs first, since they might alter the implementation of GraphFrame (the dedicated comment node class).

@Geometror can you please take a look at this issue which was probably introduced due to this pull? I'm not familiar with the codebase, so I could do with some help understanding the GraphNode::_resort function.


Blog post about moving rattler to the conda organization

Initial blog post, still in review.

Thanks @beeankha 🙏 !


yogananda.org not bypassing

Domain
https://yogananda.org/
Link
https://yogananda.org/
Version
0.0.0
What browsers are you seeing the problem on?
Firefox, Chrome, Microsoft Edge
What OS are you seeing the problem on?
Windows
Anything else?
every page I want to open starts with : https://r20.rs6.net/

We do not currently bypass yogananda.org based on this list, please read https://github.com/FastForwardTeam/FastForward/issues/656 for more details.
Once we have finished with the project, you are free to reopen the issue.


Move WatchMode to org.gradle.internal.watch.registry

The registry should not depend on the virtual file system,
and leaving WatchMode in vfs causes a cyclic dependency
when doing the continuous build changes.

@bot-gradle test and merge

OK, I've already triggered a build for you.

Pre-tested commit build failed.

@bot-gradle test and merge

OK, I've already triggered a build for you.


Collect requirements for new flow runner

In order to develop a flow runner that can be used by Intel, we must collect a list of settings (Image tag, resource requests) and a basic understanding of how submission will take place (HTTP request, Python client, etc.).

User story and design work available at https://www.notion.so/Flow-runtime-specification-8ad6173c425449af857d4761d896ed16

Design document available at https://www.notion.so/Intel-flow-runner-4219055ad3d1433d8a170ed4ae0c4cef


Change usage of "view" to "reshape" in resnet to enable running with mkldnn

Recently we have added Mkldnn tensor in PyTorch, which can be used to gain big perf gain when doing resnet style models inference.
However, in PyTorch currently Mkldnn tensor couldn't support the storage sharing semantics in view, so instead we support reshape. https://github.com/pytorch/pytorch/pull/19209

Codecov Report

Merging #890 into master will decrease coverage by 0.08%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master     #890      +/-   ##
==========================================
- Coverage    56.7%   56.61%   -0.09%
==========================================
  Files          38       38
  Lines        3432     3432
  Branches      540      540
==========================================
- Hits         1946     1943       -3
- Misses       1370     1372       +2
- Partials      116      117       +1

Impacted Files
Coverage Δ

torchvision/models/resnet.py
87.17% <100%> (ø)
:arrow_up:

torchvision/transforms/transforms.py
81.89% <0%> (-0.65%)
:arrow_down:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update dc7db17...1473e10. Read the comment docs.


Contact email address no longer working

The contact info says
Jordan Zimmerman<EMAIL_ADDRESS>I sent email to there and got a bounce:
The following message to<EMAIL_ADDRESS>was undeliverable.
The reason for the problem:
5.1.0 - Unknown address error 550-'5.2.1 The email account that you tried to reach is disabled. fe2si2350133pab.161 - gsmtp'

This was in the main README:
https://github.com/Netflix/exhibitor

fixed


Improved watchman autoreloader to pass on SocketTimeouts.

These are expected with the non-blocking loop.
Only with other errors, e.g. WatchmanError('empty watchman response')
after killing watchman need to check the server status.

@orf  Can you take a look?

I’m confused @blueyed, can you elaborate some more on why this is needed? I’m really not sure about skipping socket timeouts here, surely they are indicative of an issue?

It is not needed (i.e. does not fix a bug), but just avoids the version request every 5 seconds.
For reference: https://github.com/facebook/watchman/blob/0513bb4dc6719b49d1ee6455ac538457bc64491c/python/pywatchman/init.py#L271-L278
I'd even argue that we should not have a timeout here in the first place, i.e. just let it block there until there is either a response or the socket gets closed (e.g. when watchman gets killed), but thought to rather play it safe.

With this it is also (easier) possible to add debug logging here for unexpected things: https://github.com/django/django/pull/11305.

It requires pywatchman v3.8.0 (https://github.com/facebook/watchman/commit/1e9d5cb949700100e39614f9253e133f9092b136), 4 years old.

Looks good to me, thanks for the explanation 👍

I checked and SocketTimeout had appeared in pywatchman 1.2.0. Can you add a note to the ref/django-admin.txt about minimum supported version of pywatchman? Thanks.

I rebased from master and added a note about bumping supported pywatchman version to 1.2.0.

Thanks, what about https://github.com/django/django/pull/11305 then?


[google_maps_flutter] Polygon and Circles stroke width different between iOS and Android

When creating a polygon with stroke of 10 on Android the actual number of pixels is 10 while on iOS is multiplied by the screen density making it much thicker on iOS than Android.
Looks like this problem has already been fixed for polylines in the PolylineController but hasn't been done for circles or polygons.
https://github.com/iskakaushik/plugins/commit/5be4feca4983532ed5a1b85baf05b8fa088546d3#diff-1c7f83c2ba58345880fe8a6abd5bdaf4
The SDK docs for each platform describe strokeWidth as:
Android: Line segment width in screen pixels.
https://developers.google.com/android/reference/com/google/android/gms/maps/model/Polygon
iOS: The width of the polygon outline in screen points.
https://developers.google.com/maps/documentation/ios-sdk/reference/interface_g_m_s_polygon.html
Screen points are the same as idea as density pixels.
https://developer.apple.com/library/archive/documentation/DeviceInformation/Reference/iOSDeviceCompatibility/Displays/Displays.html
My temporary workaround is to do the multiplication myself
void toStrokeWidth(int width) {
  if (Platform.isAndroid) {
    return width * WidgetsBinding.instance.window.devicePixelRatio.ceil();
  }

  return width;
}

I'm not sure if this has any flow on effects if the value is changed in regards to serializing / deserializing as I haven't looked to see if the API returns objects from native back to flutter which contain the stroke width.

Hi @JamesMcIntosh
Is this issue still valid?
Thank you

@TahaTesser  The fix we merged on Feb 11 2020


Mark a document as "done" with no annotations

Feature description
In the context of sequence labeling projects, some documents may contain no interesting sequences. We'd like to be able to mark these as "done" to distinguish between documents  that have been reviewed and contain no spans vs. documents in need of review.

It is discussed at #280 (annotation status).


All download links closed and "Under Construction"

When will there be a way to download ModEngine 2 again?

https://github.com/soulsmods/ModEngine2/releases


MinAPI filter sample update

Fixes https://github.com/dotnet/AspNetCore.Docs/issues/26699
@Rick-Anderson

Moved commit to #26715


Parent Document Retriever feature.

Expected Behavior
Lanchain's Parent Document Retriever feature is expected in Spring AI
Current Behavior
Files are chunked and cretead embeddings for them. We would like to have child chunks for parent chunks of the document.

https://python.langchain.com/docs/modules/data_connection/retrievers/parent_document_retriever as a reference.
I'd like to have some RAG evaluation setup in place to better understand how things improve or not based on these types of algorithms.  Putting in the backlog for now.
Contributions are welcome.


Fixed the way we get the Twig template source

This reverts the temporary #356 solution thanks to this fix made by Twig 1.25.0 version: https://github.com/twigphp/Twig/issues/2011

:+1:


remove repeating section of date/time in the merged output

Summary
For readability, I would like the option to pass a flag that would filter the repeating part of date stamp out.
I've doctored up a messages file I've merged from 3 sosreports against a test cluster I have in my lab.
$ s4 -c never sosreport-rhel88-ibmcs53-node01-2023-10-25-vxfdxbb/var/log/messages sosreport-rhel88-ibmcs53-node02-2023-10-25-tyeyxof/var/log/messages sosreport-rhel88-ibmcs53-node03-2023-10-25-cfvpfeb/var/log/messages > merge
Current behavior
Currently every full timestamp is included in the resulting file - e.g. in the raw file that I produced the example below from, the first several lines all start with 'Oct  6 11:44:00'
Suggested behavior
I would like to remove that part of the timestamp that repeats from the previous line.
So if there are 6 lines, each with the timestamp repeating twice :
Oct  6 11:44:00 XXXXXXXXXXXXXXXXXX XXXXX XXX XXXX XXXX
Oct  6 11:44:00 XXXXXXXXXXXXXXXXXX XXXXX XXX XXXX XXXX
Oct  6 11:44:01 XXXXXXXXXXXXXXXXXX XXXXX XXX XXXX XXXX
Oct  6 11:44:01 XXXXXXXXXXXXXXXXXX XXXXX XXX XXXX XXXX
Oct  6 11:44:02 XXXXXXXXXXXXXXXXXX XXXXX XXX XXXX XXXX
Oct  6 11:44:02 XXXXXXXXXXXXXXXXXX XXXXX XXX XXXX XXXX

The resulting output would be something like this :
Oct  6 11:44:00 XXXXXXXXXXXXXXXXXX XXXXX XXX XXXX XXXX
                          XXXXXXXXXXXXXXXXXX XXXXX XXX XXXX XXXX
                    :01 XXXXXXXXXXXXXXXXXX XXXXX XXX XXXX XXXX
                         XXXXXXXXXXXXXXXXXX XXXXX XXX XXXX XXXX
                   :02 XXXXXXXXXXXXXXXXXX XXXXX XXX XXXX XXXX
                         XXXXXXXXXXXXXXXXXX XXXXX XXX XXXX XXXX

Then when the hour/day changes, it will show that
e.g. same day, different hour, all that gets removed is 'Oct 6'
RAW:
Oct  6 12:00:00 XXXXXXXXXXXXXXXXXX XXXXX XXX XXXX XXXX
Merged:
           12:00:00 XXXXXXXXXXXXXXXXXX XXXXX XXX XXXX XXXX

e.g. day changes to 'Oct 7' so the first line gives the full date/time
RAW:
Oct  7 00:00:00 XXXXXXXXXXXXXXXXXX XXXXX XXX XXXX XXXX
Merged:
Oct 7 00:00:00 XXXXXXXXXXXXXXXXXX XXXXX XXX XXXX XXXX

Describe the feature change.
Oct  6 11:44:00 rhel88-ibmcs53-node01 ceph-e2c93d10-2faa-11ee-8d7c-5254008008b9-mon-rhel88-ibmcs53-node01[1997]: debug 2023-10-06T15:44:00.027+0000 7fc18a883700  1 mon.rhel88-ibmcs53-node01@0(leader).osd e212 _set_new_cache_sizes cache_size:1020054731 inc_alloc: 310378496 full_alloc: 310378496 kv_alloc: 394264576
                rhel88-ibmcs53-node01 ceph-e2c93d10-2faa-11ee-8d7c-5254008008b9-mon-rhel88-ibmcs53-node01[1997]: cluster 2023-10-06T15:43:59.014747+0000 mgr.rhel88-ibmcs53-node02.zegnka (mgr.104101) 1693 : cluster [DBG] pgmap v1697: 1 pgs: 1 active+clean; 0 B data, 73 MiB used, 90 GiB / 90 GiB avail
                rhel88-ibmcs53-node03 ceph-e2c93d10-2faa-11ee-8d7c-5254008008b9-mon-rhel88-ibmcs53-node03[1918]: cluster 2023-10-06T15:43:59.014747+0000 mgr.rhel88-ibmcs53-node02.zegnka (mgr.104101) 1693 : cluster [DBG] pgmap v1697: 1 pgs: 1 active+clean; 0 B data, 73 MiB used, 90 GiB / 90 GiB avail
                rhel88-ibmcs53-node03 ceph-e2c93d10-2faa-11ee-8d7c-5254008008b9-mon-rhel88-ibmcs53-node03[1918]: debug 2023-10-06T15:44:00.909+0000 7f04f5c2a700  1 mon.rhel88-ibmcs53-node03@2(peon).osd e212 _set_new_cache_sizes cache_size:1020054731 inc_alloc: 335544320 full_alloc: 335544320 kv_alloc: 339738624
       11:44:02 rhel88-ibmcs53-node01 ceph-e2c93d10-2faa-11ee-8d7c-5254008008b9-mon-rhel88-ibmcs53-node01[1997]: cluster 2023-10-06T15:44:01.015512+0000 mgr.rhel88-ibmcs53-node02.zegnka (mgr.104101) 1694 : cluster [DBG] pgmap v1698: 1 pgs: 1 active+clean; 0 B data, 73 MiB used, 90 GiB / 90 GiB avail
                rhel88-ibmcs53-node02 ceph-e2c93d10-2faa-11ee-8d7c-5254008008b9-mgr-rhel88-ibmcs53-node02-zegnka[1869]: debug 2023-10-06T15:44:02.588+0000 7f938999e700 -1 received  signal: Hangup from Kernel ( Could be generated by pthread_kill(), raise(), abort(), alarm() ) UID: 0
                rhel88-ibmcs53-node02 ceph-e2c93d10-2faa-11ee-8d7c-5254008008b9-osd-3[2712]: debug 2023-10-06T15:44:02.588+0000 7efe4f4c0700 -1 received  signal: Hangup from Kernel ( Could be generated by pthread_kill(), raise(), abort(), alarm() ) UID: 0
                rhel88-ibmcs53-node02 ceph-e2c93d10-2faa-11ee-8d7c-5254008008b9-osd-2[2729]: debug 2023-10-06T15:44:02.589+0000 7f80336f5700 -1 received  signal: Hangup from Kernel ( Could be generated by pthread_kill(), raise(), abort(), alarm() ) UID: 0
                rhel88-ibmcs53-node02 ceph-e2c93d10-2faa-11ee-8d7c-5254008008b9-osd-1[2775]: debug 2023-10-06T15:44:02.589+0000 7f8732cf8700 -1 received  signal: Hangup from Kernel ( Could be generated by pthread_kill(), raise(), abort(), alarm() ) UID: 0
                rhel88-ibmcs53-node02 ceph-e2c93d10-2faa-11ee-8d7c-5254008008b9-mon-rhel88-ibmcs53-node02[1962]: debug 2023-10-06T15:44:02.589+0000 7f0869cbe700 -1 received  signal: Hangup from Kernel ( Could be generated by pthread_kill(), raise(), abort(), alarm() ) UID: 0
                rhel88-ibmcs53-node02 logrotate[10562]: ALERT exited abnormally with [1]
                rhel88-ibmcs53-node02 ceph-e2c93d10-2faa-11ee-8d7c-5254008008b9-mgr-rhel88-ibmcs53-node02-zegnka[1869]: ::ffff:<IP_ADDRESS> - - [06/Oct/2023:15:44:02] "GET /metrics HTTP/1.1" 200 163986 "" "Prometheus/2.32.1"
                rhel88-ibmcs53-node02 ceph-e2c93d10-2faa-11ee-8d7c-5254008008b9-mgr-rhel88-ibmcs53-node02-zegnka[1869]: debug 2023-10-06T15:44:02.879+0000 7f9347706700  0 [prometheus INFO cherrypy.access.140270770949816] ::ffff:<IP_ADDRESS> - - [06/Oct/2023:15:44:02] "GET /metrics HTTP/1.1" 200 163986 "" "Prometheus/2.32.1"
                rhel88-ibmcs53-node03 ceph-e2c93d10-2faa-11ee-8d7c-5254008008b9-mon-rhel88-ibmcs53-node03[1918]: cluster 2023-10-06T15:44:01.015512+0000 mgr.rhel88-ibmcs53-node02.zegnka (mgr.104101) 1694 : cluster [DBG] pgmap v1698: 1 pgs: 1 active+clean; 0 B data, 73 MiB used, 90 GiB / 90 GiB avail
       11:44:03 rhel88-ibmcs53-node01 ceph-e2c93d10-2faa-11ee-8d7c-5254008008b9-mon-rhel88-ibmcs53-node01[1997]: cluster 2023-10-06T15:44:03.016301+0000 mgr.rhel88-ibmcs53-node02.zegnka (mgr.104101) 1695 : cluster [DBG] pgmap v1699: 1 pgs: 1 active+clean; 0 B data, 73 MiB used, 90 GiB / 90 GiB avail
       11:44:03 rhel88-ibmcs53-node02 ceph-e2c93d10-2faa-11ee-8d7c-5254008008b9-mgr-rhel88-ibmcs53-node02-zegnka[1869]: debug 2023-10-06T15:44:03.015+0000 7f93631bd700  0 log_channel(cluster) log [DBG] : pgmap v1699: 1 pgs: 1 active+clean; 0 B data, 73 MiB used, 90 GiB / 90 GiB avail
...
Oct  7 00:00:00 rhel88-ibmcs53-node01 ceph-e2c93d10-2faa-11ee-8d7c-5254008008b9-mon-rhel88-ibmcs53-node01[1997]: debug 2023-10-06T15:44:00.027+0000 7fc18a883700  1 mon.rhel88-ibmcs53-node01@0(leader).osd e212 _set_new_cache_sizes cache_size:1020054731 inc_alloc: 310378496 full_alloc: 310378496 kv_alloc: 394264576

If applicable, describe other considerations that you decided are not worthwhile.
Other
Any other suggestions or thoughts on accomplishing the desired behavior? Or anything else.

I can pastebin the example files if it helps any, i see the formatting above is thrown off

Thanks for writing the issue clearly.
Thinking about this, I'm not inclined to add this feature as there's a lot of strange situation that would occur.
Consider this, a log file log1 with lines like
2000-01-01T00:00:00 DEBUG hello

merged with log file log2 with lines like
DEBUG [Jan 1 2000 00:00:00] hello

Merged together and applying the behavior proposed the results looks like
2000-01-01T00:00:00 DEBUG hello
DEBUG [                   ] hello

It's a very strange result.
There are many differing datetimestamp formats where this would result in very strange behavior.

Something you could try, use the --prepend-local option (or --prepend-utc) and then use GNU program awk to only print changes. This bash script worked for me:
#!/usr/bin/env bash

set -eu
s4 --color=never --prepend-separator '|' --prepend-local "${@}" 2>/dev/null \
    | awk \
'
BEGIN { FS = "|" }
{
    prev0 = curr0
    prev1 = curr1
    # field 0 - prepended local datetimestamp
    curr0 = $1
    # field 1 - log message
    curr1 = $2
}
NR == 1 {
    print curr0 "|" curr1
}
NR > 1 {
    if ( curr0 != prev0 ) {
        print curr0 "|" curr1
    } else {
        # print a blank field
        for (i = 0; i < length(curr0); i++)
            printf " "
        # print the remainer of the log message
        print "|" curr1
    }
}
'

Put it into a file, chmod +x, then pass the paths to the log files.


Introduce distributed cache

Something like a redis cache, or whatever else azure can provide for free

Would require table to be added to cosmosdb - redis-cache doesn't have a free tier

Pros / Benefits

quicker data retrieval times after app wake-up/deployment
cache can be viewed/managed more effectively
more typical solution for data cache

Cons / Costs

cache could need to be invalidated after each deployment (depends on scope of release)
would need different cache table per environment (already accommodated for)
more complexity to solution
solution isn't prohibitively slow at start up currently

Decision:

wait for the benefits to outweigh the costs
wait for an issue that a distributed cache would solve


Fix Modify the default value of async_task_consumer_thread_num

Proposed changes
Issue Number: close #xxx

Further comments
If this is a relatively large or complex change, kick off the discussion at<EMAIL_ADDRESS>by explaining why you chose the solution you did and what alternatives you considered, etc...

run buildall


Add build container make target

Adds two new make targets:

build-container uses golang:latest to install protoc-gen-go and bufbuild/buf container to create a new image that can be used to buf generate
buf-generate-container uses the previously built image to buf generate and then copy the resulting generated code to the host.

This should make it easier to regenerate based on .proto definitions, without having to worry about differing versions of the buf cli tool or protoc-gen-go.

Some makefiles (like alloy) have an env var to build in container, rather than a separate target. I don't have a strong opinion, but want to make sure we look at it for consistency.


Error with npm on ubuntu: executable file not found in $PATH

Hi! Having this issue on aspire with npm app.
fail: Aspire.Hosting.Dcp.dcpctrl.ExecutableReconciler[0]
      failed to start a process {"Executable": {"name":"frontend-mrxuuacr"}, "Reconciliation": 8, "error": "exec: \"npm\": executable file not found in $PATH"}
fail: Aspire.Hosting.Dcp.dcpctrl.ExecutableReconciler[0]
      failed to start Executable        {"Executable": {"name":"frontend-mrxuuacr"}, "Reconciliation": 8, "error": "exec: \"npm\": executable file not found in $PATH"}

this is my config:
builder.AddNpmApp("frontend", "./../../dm-studio-frontend", "dev")
    .WithHttpEndpoint(port: 3000, env: "PORT")
    .WithReference(backend)
    .PublishAsDockerFile();

I also tried to create a starter app, creating a new react app and adding a similar config as above:
var builder = DistributedApplication.CreateBuilder(args);

var apiService = builder.AddProject<Projects.testing_ApiService>("apiservice");

builder.AddProject<Projects.testing_Web>("webfrontend")
    .WithExternalHttpEndpoints()
    .WithReference(apiService);

builder.AddNpmApp("fr", "../my-app", "dev");

builder.Build().Run();

Screenshot of the dashboard:

I also tried to configure the app via executable and got the same error:
builder.AddExecutable("frontend", "npm run dev", "../../dm-studio-frontend")
    .WithHttpEndpoint(port: 30010, env: "PORT")
    .WithReference(backend)
    .PublishAsDockerFile();

I am not sure if this is a runtime/aspire issue but if I just run the app from the terminal, it works. It only gives this error while running via aspire.
Some extra info:
IDE: Rider
dotnet version:
8.0.401
aspire workload version:
aspire                     8.2.0/8.0.100         SDK 8.0.400
ubuntu:
24.04.1 LTS (Noble Numbat)
Thanks in advance!

yes, the react app, in standalone, works just fine

Did you install nodejs/npm via nvm? If you did then nvm does not add node/npm to the path but instead works by using a script in the bashrc to add the installation to the path on starting your terminal.
If this is what is happening to you, you would need to add the binaries to your system path (I believe in ~/.profile) then it should work. Other option would be to start Rider from a terminal terminal and then it will inherit the PATH from that terminal.

@jack775544 as a matter of fact, I actually used fnm (alternative to nvm). is this a situation exclusive to linux? I usually use nvm on windows and never had this particular issue

I've never used fnm before but a quick skim of the readme makes me feel like it would have the same issue.
NVM for Windows actually works a bit different to the Macos/Linux version. It creates a symlink in a folder (normally C:\Program Files\nodejs) and adds that folder to the system PATH. When you change versions of node, it will adjust the location that the symlink points to. This means that it doesn't rely on any shell script magic to add node to the path and causes everything to work normally.

Appears this is a machine configuration issue, converting to discussion


why online seving slower than offline serving??

offline serving

online serving(fastapi)

log: INFO 12-11 21:50:36 llm_engine.py:649] Avg prompt throughput: 0.0 tokens/s, Avg generation throughput: 0.0 tokens/s, Running: 1 reqs, Swapped: 0 reqs, Pending: 0 reqs, GPU KV cache usage: 0.4%, CPU KV cache usage: 0.0%
INFO 12-11 21:50:41 async_llm_engine.py:111] Finished request 261ddff3312f44cd8ee1c52a6acd10e6.

Why is the speed 2 seconds slower when displayed as fastapi??
parameters is same, prompt is same
"Open-Orca/Mistral-7B-OpenOrca" this model same issue
and any llama2 model same issue
python : 3.10.12
my library list.txt
cuda_version : 12.0
gpu: a100 40g
my library list attached

@irasin   Hello,  About  https://github.com/vllm-project/vllm/issues/2257#issuecomment-1869400614, Through my testing, I've noticed that when using AsyncLLMEngine compared to LLMEngine with a batch size of 1 (bs=1), the throughput remains almost unchanged. Could you explain why this is the case? Have you conducted any related tests to see how much faster an async online service might be?
I am running llama 70b on 8*A800 80G, and in both scenarios, the GPU utilization is consistently around 80%-90%, with Memory Usage approximately at 74.72GB (gpu_memory_utilization=90%). I'm also curious to know why there is such high memory consumption.

Same issue here, online inference is almost half as fast as offline inference.

Hello @irasin, is there some new thoughts on this issue? I encounter the same thing, the speed is ~0.49 of the offline batch in tps. Much appreciated for any suggestions!

Hello @irasin, is there some new thoughts on this issue? I encounter the same thing, the speed is ~0.49 of the offline batch in tps. Much appreciated for any suggestions!

I have observed the same issue

+1 have observed this also, currently just living with it.

I think it's slower due to internet latency.
On Mon, 15 Apr 2024, 15:48 Sam Comber, @.***> wrote:

+1 have observed this also, currently just living with it.
—
Reply to this email directly, view it on GitHub
https://github.com/vllm-project/vllm/issues/2019#issuecomment-2056529923,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ATYE26B7Q2J3HOMDG6AQZNTY5OV57AVCNFSM6AAAAABAPWXDNWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANJWGUZDSOJSGM
.
You are receiving this because you commented.Message ID:
@.***>

I think it's slower due to internet latency.
…
On Mon, 15 Apr 2024, 15:48 Sam Comber, @.> wrote: +1 have observed this also, currently just living with it. — Reply to this email directly, view it on GitHub <#2019 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/ATYE26B7Q2J3HOMDG6AQZNTY5OV57AVCNFSM6AAAAABAPWXDNWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANJWGUZDSOJSGM .

Confused +1

Confused +1

2~3 times slower with local serving
about 30~40 tokens/s with 8 H100s when serving Llama 3.1 70B

2~3 times slower with local serving
about 30~40 tokens/s with 8 H100s when serving Llama 3.1 70B

2~3 times slower using online serving.
When using llama3.1 70B with 8 H100s, tokens per second about 30~40

Confused +1

The performance should be fine, now that the server is run in a separate process.

Meet the same issue. Any solutions?

Meet the same issue. Any solutions?

Can you open a fresh issue with more information?


Use of atomics

In several places atomics are incremented with code like this:
finishedPixels.store(finishedPixels.load() + 1);

This is not atomic, it's three separate statements (read, modify, write). Consider what happens if you have two threads modifying the same variable:

Thread 1 calls finishedPixels.load() and reads (for example) the value 2
Thread 2 also calls finishedPixels.load() and also reads 2
Thread 1 increments the value to 3 and calls finishedPixels.store(3)
Thread 2 increments the value to 3 and also calls finishedPixels.store(3).

The value is now 3 instead of the expected 4, just as if you had used a plain non-atomic variable - this is what atomic operations exist to avoid.
std::atomic overloads the ++ and -- operators, so you can increment/decrement your values as one unsplittable (-> atomic) operation.

Fixed it, thanks!


repeated / recurring job - feature request

Hi,
Any plans on adding a repeated job feature with a cronjob like setup? It could, at least for me, take the need to use something like breejs away, in some cases at least.

Not for the time being, I'd prefer to keep this library focused solely on task queueing. Having said that, you can already implement primitive repeated job behaviour by enqueuing a job in a worker with a delay https://github.com/conveyor-mq/conveyor-mq#scheduled-tasks


Added attributes for selecting best prices for continuous electricity…

… usage
If electricity usage assumes that some device should be fed with electricity for a certain time, then it makes sense to find best possible time window where prices sum would be optimal.
For example this can be applicable to dishwashers, water heaters, car charging stations.

Would it be possible for someone to test this change locally? Also wonder how useful this seems?

The automation in the examples folder requires some testing. I'll keep pull request in draft state because of that.

I have an alternative approach using pyscript, i have a service defined like this:
from dateutil.parser import parse
from datetime import timedelta
from datetime import datetime, timezone

@service
def calculate_required_state(number_of_hours=None, on=None, off=None):
    """Calculate required state state based on time"""
    log.info(f"Calculating state for {number_of_hours} setting to {on} or {off}")

    hours = sensor.average_electricity_price_today.prices_today
    hours.sort(key=lambda item: item.get("price"))
    on_hours = [parse(h.get("time")) for h in hours[:int(number_of_hours)] ]
    # Check if current time is in that time
    now = datetime.now(timezone.utc)
    time_delta = timedelta(hours=1)

    for hour in on_hours:
        next_hour = hour + time_delta
        if hour <= now <= next_hour:
            print(f"{now} is between {hour} and {next_hour}")
            domain, name = on["service_name"].split(".")
            service.call(domain, name, **on["service_data"])
            return

    # else turn off
    domain, name = off["service_name"].split(".")
    service.call(domain, name, **off["service_data"])

With and automation that has this as an action:
service: pyscript.calculate_required_state
data:
  number_of_hours: "{{ states.input_number.warmtepomp_minimaal_uuren.state }}"
  "on":
    service_name: climate.set_temperature
    service_data:
      temperature: 20.5
      entity_id: climate.bdr_thermostat
  "off":
    service_name: climate.set_temperature
    service_data:
      temperature: 18
      entity_id: climate.bdr_thermostat

That makes it possible to easily set the thermostat to high based on the number of hours it should be on on a day.
the only disadvantage is that you need the pyscript plugin for this.

This makes sense. I did not hear about pyscript for HA before :)
I will investigate this option and may be revoke my PR later as not needed.

There's also integration nordpoo_diff which can be used to create a custom filter for your specific use case. It supports this integration.


Fix CC referral ID on GCR tutorials

The include used in step 1.1 expects a page-level variable for the referral ID. This variable was missing.

This change is


Test Dir Cannot Link to Alsa Effects Dir

In the 'test' directory of audio_driver_dev, the test.cpp file cannot find the libraries being linked in the 'AlsaEffects' dir.

Could attempt to remove 'include' directory and observe if that helps to link

Done and merged.


SWARM-1808 override properties with system env

Make it possible to override values in projects-*yml with environment variables.
Its need if running in docker container and you need to push variabels from exempel ansible

[x] Have you followed the guidelines in our Contributing document?
[x] Have you created a JIRA and used it in the commit message?
[x] Have you checked to ensure there aren't other open Pull Requests for the same issue?
[x] Have you built the project locally prior to submission with mvn clean install?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

ok to test

@bobmcwhirter, could you take a look at this as to me it seems fine, but you've dealt with the yaml stuff a lot more than me!

looks good to me


Request Queue graceful shutdown

shutdown the request queue first and then shutdown the asio io service.

I can look at this.

#9 PR


api: support custom dev-url for atlasschema

LGTM, but I think we need to support custom docker image too. Because the devdb need to recycle after each run, and it can be a pan if the user doing it by themself. Atlas currently doesnt known how to handle others resource that it doesnt support. Like PG extenstion

The solution here is a bit more involved since the image isn't enough, you may need to define env vars, volumes etc.


Storage test

Issue
Issue number - #131
PR type
Test case for storage

Pull Request Test Coverage Report for Build 535

0 of 0   changed or added relevant lines in 0 files are covered.
3 unchanged lines in 2 files lost coverage.
Overall coverage increased (+4.06%) to 64.958%

Files with Coverage Reduction
New Missed Lines
%

file:/home/travis/build/AY1920S1-CS2103T-T10-4/main/src/main/java/seedu/address/model/person/Person.java
1
98.98%

file:/home/travis/build/AY1920S1-CS2103T-T10-4/main/src/main/java/seedu/address/storage/JsonSerializableTimeBook.java
2
94.87%

Totals

Change from base Build 525:
4.06%

Covered Lines:
4599

Relevant Lines:
7080

💛  - Coveralls


use TabletWriter::Thread to load/unload/split TabletIO

Now we use thread_pool to load/unload/split. Because of the limit of thread number, we have to control the concurrency. So when a ts restart, the load process is very slow.
Every TabletIO has a TabletWriter, every TabletWriter has a thread. We could use that thread to do these work.

we always need a concurrency control?

Yes.  But the thread number will not be out limitation any more. The concurrency could be very large, e.g. 100.

why not TabletWriter shared in thread pool?


add 'Issue Template' and 'Pull request template' in awesome-electron-alternatives

Hey y'all!
What an incredible project!
@sudhakar3697 - added 'Issue Template' and 'Pull request template' in awesome-electron-alternatives. Please see this: [1]: 'Issue templates' and 'Pull request template' in awesome-electron-alternatives?, [2]: About issue and pull request templates,[3]:🔣 A collection of GitHub issue and pull request templates, [4]: Creating a pull request template for your repository
and here:

img-before
img-after

and here too:

img-before
img-after

Have you all ever thought about adding the Issue templates' and 'Pull request Templates' feature here to automate the process of opening and closing issues, pull-requests?

Hi @nichdemos,
Thanks for the effort, but this repo is just an informative repo. I do not think these templates would make sense for this repo containing just a markdown file.
Thank you.

Hi @sudhakar3697, thanks for comment.


Vulnerability report payment E/E #258839

@tienifr payment for vulnerability report  https://github.com/Expensify/Expensify/issues/258839
$1000

@tienifr can you please accept the job and reply here once you have?
https://www.upwork.com/jobs/~0196e3b653ac11cc5d

@tienifr paid, closing


Language does not change! LuckPerms

I copy the file "lang.yml" and put mods> luckperms and reboot the server, but it does not replace the pl language!

I have the same problem. Version 4.4.26 for Sponge

Are there any errors in the console on startup?

There are no errors in the console. I put the translation in the / luckperms folders and in the config / luckperms and the translation as a whole began to work as seen in the screenshot, but the translation of the message about insufficient rights to the command does not work.

That message isn't being sent by LuckPerms, so isn't affected by LP's locale file.


Validating Indian mobile number with ISO Code: US(countryCode: 1) and return true

PhoneNumber number = PhoneNumber.parse(phone,callerCountry: IsoCode.fromJson(isoCode));
print("Phone is ${phone} ISO is ${isoCode} caller country ${IsoCode.fromJson(isoCode)} destination country ${IsoCode.fromJson(isoCode)}, formatted number with caller country ${PhoneNumber.parse(phone,destinationCountry: IsoCode.fromJson(isoCode))} isvalid ${number.isValid(type: PhoneNumberType.mobile)}");
if(number.isValid(type: PhoneNumberType.mobile)){
  return true;
}

Result
Phone is<PHONE_NUMBER> ISO is US caller country IsoCode.US destination country IsoCode.US, formatted number with caller country PhoneNumber(isoCode: IsoCode.US, countryCode: 1, nsn:<PHONE_NUMBER>) isvalid true
Actually when i try for validated some indian mobile number then above code giving valid number with ISO code US and country code 1 but if we use indian number with +1 country code then it should return false

The number which we giving start with the country code as per US 838 you mentioned above Eastern Upstate New York so the number will get accepted .Am stuck with the same issue that the Indian number given is returning true for country US.

You did not provide a reproducible example.

I'm closing this as innactionable. Please open a proper issue.

if you select the country code US and number from india the OTP
getting send there is no validation there
On Wed, May 29, 2024 at 9:49 PM cedvdb @.***> wrote:

I'm closing this as innactionable. Please open a proper issue.
—
Reply to this email directly, view it on GitHub
https://github.com/cedvdb/phone_numbers_parser/issues/63#issuecomment-2137802188,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/BIRRXRECAHDDRRRX4CNOELLZEX5ZNAVCNFSM6AAAAABHMLTSQKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMZXHAYDEMJYHA
.
You are receiving this because you commented.Message ID:
@.***>


Mass reformatting attempt to try and get rocFFT to pass the formattin…

Summary of proposed changes:

Massive reformatting  of all .h, .hpp, .cpp, and .py files
Want to run Jenkins tests (yet to be done) with format_check set to true
Please don't merge anything for now

Leave this open for now. It was ran as a test. Will show this to @saadrahim and @feizheng10 tomorrow, and will close it soon after.


Cts backport

Backport of recent CTS fixes by @cmgrote @grahamwallis
Commits:
546eb9d
19544e2
ab5f6f8
a4ac408
8446f6f
f200e16
2118133
b18ff2f
8248f6d
afb65f6
a228b38
2118133
(the last one was already merged in)
Please review

Awaiting a further change from @grahamwallis

Hi Chris - it looks like Mandy wanted the super class to delegate to the actual method (i.e save rather than delete) which if implemented will save to the repository and if not implemented will report unsupportedOptionalFunction. Maybe this is to ensure that the base class provides the switch (from delete to save).

Ok, interesting (and a bit confusing without documentation in the class explaining why it's different)...  In any case, I've just kicked off a local run with this entire PR built as-is to do a final check that everything still operates as expected.

Added
f4fb9503456fa1197af6ba09ad1b77c0e509b19e
620a173edda7970ec2b9e10460cf557eddf7e626
e13be8018694a97bf9822c2448b8e1e363390902
This covers a reporting issue, and the notebook (as it makes it easier to test)

Leaving as draft - will be interesting to hear of your results @cmgrote. If good will look at merging - and I'll also rerun the cts against inmem/graph with the 1.2 branch

Still looks fine from my perspective after testing overnight.


Many messages about "Project level command overrides"

Describe the Problem
No troubles with DDEV, diagnostics run fine: https://gist.github.com/bserem/7ec29e276487a27ad723507834cae057
After working on #3518 where I had to run a second copy of ddev (custom compile) I get these messages when I am running the original version (1.18.2):
Project-level command 'mysql' is overriding the global 'mysql' command
Project-level command 'launch' is overriding the global 'launch' command
Project-level command 'xdebug' is overriding the global 'xdebug' command

Everything works fine, but my terminal just got crowded.
To Reproduce
Can't say much, I just executed the second version
Screenshots

Version and configuration information (please complete the following information):

Host computer OS and Version: Linux Debian Testing
ddev version information: 1.18.2
config.yaml contents for the misbehaving project: affects all projects
Do you have any custom configuration (nginx, php, mysql) in the .ddev folder? No

This is a result of you using an old version of ddev after using the current HEAD. The current HEAD doesn't complain... and your old v1.18.2 recreates the in-project shell commands (and does complain).

Ok, so only way to fix it is to wait for the next version and update?
Thanks

All you have to do is remove those items from ~/.ddev/commands


How can I send a NonConfirmable message?

I saw at the code, and find out that the udp part of clientConn.Do and clientConn.WriteMessage eventually does this: req.SetType(udpMessage.Confirmable).
What is the reason of doing this? And how can I send a NonConfirmable message, which isn't manipulated by the sender?

Yes this is not supported for now. For blockwise transfer we always send confirmable message via WriteMessage.
To fix issue:

we can always create confirmable message and via settype you can change it.
create WriteRawMessage where user is responsible for all sets.

@jkralik Thanks for your response.


[BUG] I'm not able to create a 7 child, if I add more than 6 #, the 7th one is not detected

[x] I have searched for existing issues that already reported this problem and found none
[x] The bug is present in REPL

Describe the bug

To Reproduce

Expected behavior

Actual behavior

Environment:

OS: [e.g. macOS]
Browser: [e.g. chrome, safari]
Browser Version: [e.g. 22]

Additional context

https://markmap.js.org/docs/faq#why-cant-i-have-more-than-6-levels-of-


Use NEON instructions on aarch64.

The code is a direct translation of the sse3 code for x86, and provides
approximately a 0.67x decrease of image decoding time on a Samsung A51.
Fixes #202, or at least improves the situation.
decode a 2268x1512 JPEG time:   [83.619 ms 85.692 ms 87.848 ms]

decode a 2268x1512 JPEG time:   [56.209 ms 57.019 ms 57.876 ms]
                        change: [-35.318% -33.460% -31.535%] (p = 0.00 < 0.05)

Should we add a CI run on a emulated aarch64? If so, in this PR or in another?

If we can, that'd be perfect. It can be another PR though I'd prefer adding it before this one then.

Done and new feature added to the CI.


typo: Double word "that"

@nschonni : Thanks for your contribution! The author(s) have been notified to review your proposed change.

Verified typo fix, OK to merge.


[RulePad] RulePad fails when the top element is not class.

For mined rules for class field ADTId in ADTCommand:
function with ( visibility "public" and specifier "static" and type "void" and name "writeADT||ADT||write" and parameter with type "String||ADTInFirebase||long||int" and parameter with name "projectId||dto||ADTId||version" ) of class must have expression statement with ( "Calling a Function With Argument: ADTId||json||projectId||PUT" and "Calling Function: enqueueWrite" )
error: error: not connected in graphicalEditor.js

Fixed the issue by considering the lowest common ancestor, which was used before for starred elements.
commit: e41a43f


Can't navigate/move to date

Bug: If the user changes the prop selectedDate after the initial render, the component does not move to the new date selected.
Expected behavior: the component should move to the selected date as indicated by the selectedDate prop.
Where in the code:
After this commit the user can't change the selectedDate prop after the initial render (i.e. if the prop changes, the state.currentMoment does not get changed).
Possible solutions:

Provide a method goToDate() (or other name), accessible by creating a ref to the WeekView component. The users would have to connect the ref and use the method, instead of changing the selectedDate prop. For example:

import WeekView from 'react-native-week-view';

class MyComponent extends React {
  someMethod = () => {
    const someDate = new Date() // some date...
    this.weekViewRef.goToDate(someDate);
  };

  render() {
    return (
      <WeekView
        ref={(ref) => { this.weekViewRef = ref; }}
        // ...otherProps
      />
    );
  }
}

This is similar to the behavior with the ScrollView, which provides scrollTo() methods.

Make WeekView a fully controlled component, by removing the state.currentMoment and only using the prop selectedDate internally. This would mean that the user would necessarily have to connect the onSwipePrev and onSwipeNext methods, to update the prop:

  changeDate = (date) => {
    this.setState({ date });
  };

  render() {
    return (
      <WeekView
        selectedDate={this.state.date}
        onSwipePrev={(date) => this.changeDate(date)}
        onSwipeNext={(date) => this.changeDate(date)}
        // ...otherProps
      />
    );
  }

I think the first option is better. I could submit a PR if you agree @hoangnm.
Both are breaking changes.

Hey @pdpino , many thanks for the suggestions! I removed that code because I thought we rarely need to update the selectedDate, but it seems that sometimes we still need it. I agree with you that the first option is better in this case. It's truly awesome if you can raise the PR 🙏 .

Sure!  Thanks!

Hi @hoangnm, I am also feeling the same. In the last version I am using the selected date and change my app ruction based on it now I am not able to do that. Can you please add the option.

PR #56 added the goToDate(date, animated = true) method, i.e. changing the selectedDate prop won't have any effect, but using goToDate() should change the date
A note about performance:

If the user navigates to a date that has already been rendered (i.e. is already contained in the state.initialDates), the movement should go very smooth
If the user navigates to a date that has not been rendered, the animation may seem slow, as new pages have to be added to state.initialDates, and then the component moves to the new date.

Thanks @pdpino


GOSW17-Create an event table in database

Storing the data from event registration form in the database.

could you please elaborate it more specifically

We will provide credentials to the database. You need to push the data collected from registration form to the database.

Which database will be used in this project mongo or sql ??

@sachinsom93  Firestore is used as the database.

Can I work on this @nanda-mik ?

We will provide credentials to the database. You need to push the data collected from registration form to the database
Kindly provide the credentials of database @geekyaditya100 .


Bump dbt version to 1.2.0

Is this ready to be merged? We would like to use v1.2 in our Github actions :)

Thank you @Aylr for the PR and to @NicWagenaar for the nudge. I somehow overlooked the original PR. In the meantime, the latest version is 1.2.1 so I created a new PR #38 based on yours.

Thanks @mwhitaker!


how to use userheader in the untyped request/response

If i have a common IPC send function as following code, parameter msgPayload is untyped, it may changed according some other conditions, and paramter cnt is the number of msgPayload, so the total size i want to send is header + sizeof(msgPayload) * count
bool sendBroadcast(
    const msgHeader& header,
    const msgPayload* payload,
    const uint32_t& cnt)

it is very easy to wrap by using iox untyped_publisher funtions, since loan functions of untyped_publisher has "head" paramter.
loan(const uint32_t userPayloadSize,
         const uint32_t userPayloadAlignment = iox::CHUNK_DEFAULT_USER_PAYLOAD_ALIGNMENT,
         const uint32_t userHeaderSize = iox::CHUNK_NO_USER_HEADER_SIZE,
         const uint32_t userHeaderAlignment = iox::CHUNK_NO_USER_HEADER_ALIGNMENT)

and i can easily wrap like this,
loan(sizeof(msgPayload) * cnt, alignof(msgPayload), sizeof(msgHeader), alignof(msgHeader));

but how do i use customer header and untyped payload in request/response, it looks like request/response header size is fixed
cxx::expected<void*, AllocationError> UntypedClientImpl<BaseClientT>::loan(const uint32_t payloadSize,
                                                                           const uint32_t payloadAlignment) noexcept

cxx::expected<void*, AllocationError> UntypedServerImpl<BaseServerT>::loan(const RequestHeader* const requestHeader,
                                                                           const uint32_t payloadSize,
                                                                           const uint32_t payloadAlignment) noexcept

@qclzdh request-response does not support a user-header since it already uses that portion of the chunk for it's own header. This means the segmentation must be done by the user on the user-payload portion of the chunk

@elBoberido Thanks, if there is no smart way, i will pack them together. It looks a little ugly, but should work well.

@elBoberido  is there any limitation about payloadAlignment, for example payloadSize % payloadAlignment must equal to 0 ?

@qclzdh it's not the most convenient solution but should work. If there is a big demand for a user-header with request-response we can think of extending the API but it might become quite complex on the user side

@elBoberido is there any limitation about payloadAlignment, for example payloadSize % payloadAlignment must equal to 0 ?

@qclzdh yes, the assumption was that the payload will contain a struct and therefore the same restrictions apply

@qclzdh it's not the most convenient solution but should work. If there is a big demand for a user-header with request-response we can think of extending the API but it might become quite complex on the implementation side

Yes, userHeader is mandatory, please consider to extend the API.

@qclzdh @elBoberido I've not come to a final conclusion, but my feeling is the custom user header could also be helpful for rmw_iceoryx, see here: https://github.com/ros2/rmw_iceoryx/pull/84

From a user point view, a custom user header would be much more helpful, it's better to support this kind of feature.


Auto attachThreadToJVM

Why do I have to call attachThreadToJVM explicitly? Would it make sense to delegate this to jpype doing it automatically? Or are there any cases where I don't want to attach a thread?
Or is it a performance issue to always attach the thread? Maybe there's a lightweight way to check that could be used by jpype to make the decision?

This seems to be necessary, or at least it's one way to stop NULL pointer deref crashing... See #217

Actually one has to take care to detach the currently attached thread, otherwise one will cause memory leaks https://stackoverflow.com/questions/26534304/android-jni-call-attachcurrentthread-without-detachcurrentthread#26534926

This is currently implemented in master.


LambdaType should be renamed ArrowType

LambdaType is used to type all "arrow-like" objects in the language, not only lambdas. The only exception are method bundles, but those already have a dedicated MethodType.

What are some other arrow-like objects?

type A {
  init() {}
  fun ham() -> Int { 2 }
}

public fun main() {
  fun foo() -> Int { 0 }
  let bar = fun() -> Int { 1 }
  let a = A()
  ...
}

foo, bar, A.init, A.ham, and a.ham are arrow-like objects, but they're not all the exact same kind of arrows. That has subtle consequences on the semantics.
Note that only bar is a lambda.

Is there any role for the word “callable” in addressing this issue?

Could be CallableType instead of ArrowType. The latter is shorter and very a quite common name in type theory though.

Not just Callable?

I'd like to keep the suffix, at least for now. I still think it's helping distinguishing between important kinds, as we have entities like TraitType and TraitDecl.
Given the way we tend to name stuff in Swift, I would also reserve Callable for a protocol describing a family of arrow types, should we have one.

I could give this rename a shot if it's helpful. Just want to check this issue is still relevant.

I think it is.
Note that now we have CallableType which is implemented by the arrow types and SubscriptType, filling the role of the trait I hypothesized we'd need:

I would also reserve Callable for a protocol describing a family of arrow types, should we have one.

So you'll have to rename that one too.

Just to clarify, what would you like to rename CallableType to?
LambdaType -> ArrowType
CallableType -> ?

Actually if we rename LambdaType to ArrowType then there's nothing to change for CallableType. I'd accept that change.
@dabrahams had expressed reluctance because (IIUC) "arrow" isn't as established as "callable". But I think this ship has sailed because the distinction is already significant in the compiler in other places:
https://github.com/hylo-lang/hylo/blob/9ade3acff6c34f8041c8e6306105a0797cf2814a/Sources/Core/Types/CallableType.swift#L10-L11
https://github.com/hylo-lang/hylo/blob/9ade3acff6c34f8041c8e6306105a0797cf2814a/Sources/FrontEnd/TypeChecking/Constraints/CallConstraint.swift#L35-L36
So to be clear, I'm suggesting that you only rename LambdaType to ArrowType.

"Arrow" remains very esoteric and if another term like “lambda” could work, I'd prefer it.  Just looking around for definitions of arrow in this domain it's very hard to find references that don't lead to something like this.  Just trying to refresh my memory about what an Arrow is I am still not quite sure.  One definition says it's a "structure preserving" map which makes me think in general functions don't fit the category since they can be many-to-one, and that's confusing.  Maybe I'm too old to use the google but I'm still looking for a simple definition that I can stand on.
If this is the only correct term, of course, so be it.  But at a minimum docs for names that include the term should contain links to a comprehensible definition.

I can understand this, but only because I understand Haskell notation… and what the "number of axioms" they mention are is still a mystery.  IIUC I would sum the arrow idea up as "functions within a domain," where the domain (best word I can think of) is not the idea related to codomain but is the type class a itself.  I don't know what the multiple domains might be in practice but regardless don't we have just one of those, and isn't the domain (a) the thing that is the arrow, as opposed to particular instances of a?

I understand the confusion and sympathize with it. Naming is hard and I'm not particularly good at it.
We do have a constellation of concepts that needs different names, though:

Things that are callable, which include subscript bundles, subscripts, method bundles, functions, initializers, and lambdas
Things that create projections, which include subscript bundles and subscripts
Things that return values, which include functions, initializers, and lambdas

Callable was a strong candidate for (2) but:

entities in (3) are also "called", so ultimately I don't think it's right to reserve the term for (2)
we'd still need a term for (1)

Application could be a candidate for (1), being very well established in lambda calculus, but I think the term is too overloaded in the context of a compiler implementation. I also think the term is much closer to lambdas than it is to subscripts, so I don't think it's the right fit.
I like "arrow" because it's tied to the way to express these type terms. An arrow is just a callable that is declared ... with an arrow. It's also short and concise; if someType.isArrow { ... } makes a lot of sense to me.
Note that whatever we choose, these terms are very internal to Hylo's frontend and only significant to the few souls courageous enough to venture in the type checker's implementation. So to some degree I think it's fine to just come up with our own vocabulary if there isn't strong precedent to guide us. We still have to write a lexicon, and these terms would be part of it.

I like "arrow" because it's tied to the way to express the types in (2). An arrow is just a callable that is declared ... with an arrow.

Oh, you mean syntactically.  Sure, but it isn't just that syntactic arrow that is only part of its declaration, and I'm still very unclear on all the points about how (or even whether) the category-theoretic idea maps on to this thing.

if someType.isArrow { ... } makes a lot of sense to me.

Well sure, but the problem I'm trying to grapple with is whether it's going to make sense to anyone else.  What's wrong with if someType.returnsAValue { ... } which is literally how you described this category in plain English?  If you really insist on something that's both short and concise (😉) I offer someType.returns { ... } but personally I don't think the concision is worth the loss of straightforward comprehensibility.
And if you need a noun… from my point of view, “functions, initializers, and lambdas” (don't forget methods) are all just functions with various declaration syntaxes, and “function” would make a much better term for these things.  IIRC Swift named even top-level functions "methods"—since they could easily be viewed “static methods of the module”—and doing that would definitively free up the term “function” in the compiler.

Note that whatever we choose, these terms are very internal to Hylo's frontend and only significant to the few souls courageous enough to venture in the type checker's implementation

Really?  It seems to me we want to use the same terms in our specification and instructional materials that we use in the compiler implementation to classify the language's major entities.

Just some observations as a novice looking at this codebase. If I'm muddying the conversation feel free to ignore. 😄

"Arrow" remains very esoteric and if another term like “lambda” could work, I'd prefer it.

It's clear to me that it would be best to change the name from "lambda" to something, because it's been difficult in some cases to figure out if the code is referring to arrow-like expressions, or to actual lambda expressions.

Sure, but it isn't just that syntactic arrow that is only part of its declaration

I see this point. If I was looking at codebase for the first time it might not be clear that "arrow" doesn't just refer to -> but encompasses the whole declaration of the arrow-like expression. Perhaps ArrowlikeType and isArrowlike() would be preferable to just ArrowType.

Things that are callable, which include subscript bundles, subscripts, method bundles, functions, initializers, and lambdas
Things that return values, which include functions, initializers, and lambdas
Things that create projections, which include subscript bundles and subscripts

Here's my very naive suggestion that would be clear what each type does:

Callable
CallableWithReturn
CallableWithProjection

It's my bad having described (2) and (3) that way, but we can't use returns, returnsAValue, or callableWithReturn to identify arrow types. sink-subscripts return a value and they are not arrow-like. Yet they must satisfy the same predicate as let-subscripts.

IIRC Swift named even top-level functions "methods"

I didn't forget methods. In fact I made the same simplification as the Swift crowd, except that I decided to refer to methods as functions, since they are just functions with an environment.
I once considered using isFunction and isSubscript but the distinction between (2) and (3) is still significant in the IR, where all subscripts have been lowered as functions!

You keep calling them arrow types as though that's what they are.  If they really are that, you should be able to clear up all my questions about the category-theoretic mapping.  But you haven't done that, so I feel both like there's a fâit accompli here, and like I'm not being heard.

I didn't forget methods. In fact I made the same simplification as the Swift crowd, except that I decided to refer to methods as simply functions, since they are just functions with an environment.

Everything has an environment.  It just might be void.

sink-subscripts return a value and they are not arrow-like.

I'm increasingly frustrated with the way the word “arrow” is being used here without explanation or clarification, when I've made it quite apparent that its meaning in this context is unclear.  In what way are sink subscripts less “arrow-like” than a function taking a sink parameter?

So AFAIC, a method is just another name for a "non-static member function". Method bundles are a different concept, though. I once considered using isFunction and isSubscript but the distinction between (2) and (3) is still significant in the IR, where all subscripts have been lowered as functions!

You're missing my point.  There's a way to shuffle the names around so that "Function" becomes the name of category (2) and you still have subscripts (or projections).  You just have to be willing to view the things you're currently thinking of as "plain functions" as static methods of the module.  IMO that would be preferable to using a term that you haven't even been able to help me understand, to say nothing of the rest of the world.

The frustration is shared. The name has nothing to do with category theory. I explained where it comes from. The type term has an arrow, that's it. I don't know how to explain that better.
The fact that a tiny fraction of Haskell enthusiast use "arrow type" to express monad-like abstractions is coincidental but name clashes do happen.

Everything has an environment. It just might be void.

Of course I know that everything has an environment. It should be equally obvious that a lambda with an "empty" environment is equivalent to a lambda with a "void" environment, which is an empty type.

In what way are sink subscripts less “arrow-like” than a function taking a sink parameter?

Subscripts are not written with an arrow in their type. The compiler cares about that because it must generate different code for a sink-subscript than it does for a function.

You just have to be willing to view the things you're currently thinking of as "plain functions" as static methods of the module. IMO that would be preferable to using a term that you haven't even been able to help me understand, to say nothing of the rest of the world.

It is frustrating to have to change my vocabulary and way of thinking about entities, which are used consistently in the many lines of the implementation that I mostly wrote and maintain, because other people prefer other terms. The faits accomplis come from the fact that I keep having to make choices for representing pretty much everything in the compiler, and I can't pause every time to setup a vote.
I'm happy to explain every possible gory detail of the compiler to anyone who'd like me to, really. But I find it frustrating to be pressed for justifying why something has been written the way out of the blue.

The name has nothing to do with category theory

I can't understand why you didn't ever say that earlier.  I kept going down that path and you never stopped me… 😢

I explained where it comes from. The type term has an arrow, that's it. I don't know how to explain that better.

You didn't say it had to do with type terms; you said the arrow referred to what the entity was “declared with,” and allowed me to assert that it was about declaration syntax without correcting me.  I see now that in fact you're not saying it has anything to do with the declaration syntax of the entity; it's about the syntax one would use to express the type (which is never declared, because it's not nominal).  I realize you dropped the hint "it's tied to the way to express the types" but that's pretty vague and the correct interpretation of that reference is ruled out by what you said about declaration immediately following that.

The fact that a tiny fraction of Haskell enthusiast use "arrow type" to express monad-like abstractions is coincidental but name clashes do happen.

This potential confusion is very easily solved.  Just stop calling these things arrows and say that they're types that have arrows.  If you really must.

Subscripts are not written with an arrow in their type.

Subscripts don't have a type as far as I know.  At least I've never seen a subscript type in any example we've discussed.  I think you're talking about declaration syntax again.  But then intializers don't have an arrow in their declaration syntax either.

It is frustrating to have to change my vocabulary and way of thinking about entities, which are used consistently in the many lines of the implementation that I mostly wrote and maintain, because other people prefer other terms.

It's not about my preference; it's about understanding.  If I can't understand the term and it leads me to look for connections that aren't even supposed to be there, the project is harder than necessary for others to use, participate in, and contribute to.  I assert again that we will want to use the same terms in our specification and instructional materials that we use in the compiler implementation to classify the language's major entities.

We do have a constellation of concepts that needs different names, though:

Things that are callable, which include subscript bundles, subscripts, method bundles, functions, initializers, and lambdas
Things that return values, which include functions, initializers, and lambdas
Things that create projections, which include subscript bundles and subscripts

Questions:
What are the current names of these concepts, and which one is being considered to be remapped to "arrow"?
For the items that are callable and don't create a projection or return a value, what do they result in?

What are the current names of these concepts, and which one is being considered to be remapped to "arrow"?

Functions are declared by FunctionDecl (see here); that includes the declarations of anonymous functions underlying lambdas;
Initializers are declared by InitializerDecl  (see here);
Method bundles and method variants (i.e., the individual implementations of a bundle) are declared by MethodDecl  (see here) and MethodImpl  (see here), respectively;
Subscript bundles and subscript variants are declared by SubscriptDecl (see here) and SubscriptImpl  (see here), respectively.
All of these declarations introduce a callable entity (see here).
Functions, initializers, and method variants are given a LambdaType (see here).
Method bundles are given a MethodType (see here).
Subscript bundles are given a SubscriptType (see here).
Subscript variants are given a SubscriptImplType (see here).
All of these types are CallableTypes (see here).
A callable type is considered an arrow if it's the type of a function, initializer, or method variant (see here). Types for which this property holds are LambdaType and MethodType.
The change proposed by the issue is to rename LambdaType to ArrowType.

For the items that are callable and don't create a projection or return a value, what do they result in?

There are no such items. Functions, initializers, and methods always return a value as far as the type system is concerned. That value may be an instance of Void or Never. Subscripts project a value along with a capability. That capability may be sink, making the projection notionally equivalent to a returned value.
While one may think of a sink subscript as being equivalent to a function, the type checker reasons differently because it has to consider the effect on the arguments of the subscript. I'm happy to get into more details but I hope it would create distractions at this point.


Bundle CurseForge-referenced files that are not in standard folders

It would be nice if certain files in the resulting CurseForge modpack could be marked to be downloaded rather than being added to the manifest.
I don't know if it's an uncommon use case, but I'm trying to have packwiz manage every file from CurseForge, but I run into the issue where the CurseForge format seems to really be able to handle files in the mods and resourcepacks folders.
See https://github.com/falxie/construct to see what I'm talking about

A rough workaround I have for this right now is to use packwiz-installer to download the files, copy them to a GDLauncher instance, wait for GDLauncher to synchronize, and then export the GDLauncher instance.

I don't know why I didn't think to do it before, but I can just use packwiz curseforge detect on the result of packwiz-installer for the result that I want. GDLauncher's detection is excruciatingly slow

Ah, it looks like the app just lumps datapacks in with resource packs (and the actual location they should go in isn't recorded anyway). I should be able to make pack exporting directly bundle files that are not in the correct folders (i.e. mods, resourcepacks, saves) so this will be automatically handled, unless CF rejects datapacks hosted on CF that are bundled in the modpack.

So I'm not sure if this actually makes sense anymore.
I'll be honest, I finally got my first pack approved by CurseForge and the reason I needed this feature was for the global_packs folder to be created properly since their modpack format only supports downloading their files to resourcepacks and mods. But CurseForge doesn't allow for their files to be in modpacks.

CurseForge rejection

The status of the file Construct-1.0.1-1.zip (Construct) has been changed to Rejected
Notes:
The following files belong to CurseForge-hosted projects, and should therefore not be added directly to zip files:
overrides/global_packs/required_data/Repurposed_Structures-Better_Dungeons_v2.zip
overrides/global_packs/required_data/Repurposed_Structures-Better_Strongholds_v3.zip
overrides/global_packs/required_data/Repurposed_Structures-Better_Witch_Huts_v1.zip
overrides/global_packs/required_data/Repurposed_Structures-Etched_v2.zip
overrides/global_packs/required_data/Repurposed_Structures-Farmers_Delight_v3.zip
overrides/global_packs/required_resources/Xaero's Minimap - Mod Icons.zip
overrides/resourcepacks/Stay True Compats v3 [1.18].zip
overrides/resourcepacks/Stay_True_1.18.zip

These files should, instead, be referenced in the manifest.json file generated by the Twitch Desktop App during a profile export.
If you have any questions please contact our support team https://support.curseforge.com/.

If you know of a case where this wouldn't be the case this could be valid I think it could be worth keeping open but otherwise I'd be ok with closing this.

Oh well, I'll change this issue to just warning when such files are encountered, as there appears to be no way to properly include such files in a CurseForge pack.


Redirect to the docs site from https://pr.omethe.us

https://stackoverflow.com/questions/9082499/custom-domain-for-github-project-pages/9123911#9123911

Also https://help.github.com/articles/using-a-custom-domain-with-github-pages/

Also, just noticed, Issue #100! Woo!

Or maybe just add a link to the homepage?

I could pretty easily redirect something like https://pyked.pr.ometheus.com, I think; the host allows me to create subdomains, and those are easy to redirect.

Nvm, that was actually pretty easy... try https://pr.omethe.us/pyked now!

I did this via a "meta refresh": <meta http-equiv="refresh" content="0; url=https://pr-omethe-us.github.io/PyKED/">

Nice! Any idea whether the meta-refresh is preferred over setting the domain parameters? I barely understand any of this so I have no idea

So, if you make the change at the domain level (i.e., with the website host), I think a redirect would happen before the browser even sees the HTML of the page (which is where the meta-refresh happens).
But I think I can only do a domain-level redirect for a subdomain.

Ah, now I remember what I was thinking here. In this answer: https://stackoverflow.com/a/22374542/2449192 it is possible to redirect and respect the paths, so https://pr.oemthe.us would redirect to https://pr-oemethe-us.github.io and https://pr.oemthe.us/PyKED would redirect to https://pr-oemethe-us.github.io/PyKED and so forth. But obviously, that's not necessary and this solution seems perfect! Now we just need some content for the homepage 😄


add license to TOML and fix the author list according to PEP 621

@rabrie
I fixed the author list in the TOML file according to PEP 621.
This resolves a TOMLDecodeError when installing the package with pip.
Also the license was missing in the TOML.

I noticed that you have already fixed that issue.
But you could still add the license to the TOML


docs: Small errors in docs

Hi,
Thank you all so much for all your hard work on this project. I recently used this for a demonstration and was amazed by its power an elegance, and would like to give back however I can.
I encountered two small issues in the docs which that I would like to address. I will gladly issue a pull request for the bugs and changes mentioned in this issue. I felt it was courtesy to raise this issue first before issuing the pull request to ensure it would be acknowledged and accepted.
Describe the bug
https://docs.locust.io/en/stable/extending-locust.html#run-a-background-greenlet
There are two python errors in the code provided on this page, which is generated by https://github.com/locustio/locust/blob/master/docs/extending-locust.rst:
Bug 1
The first example is as follows:
from locust import events

@events.request.add_listener
def my_request_handler(request_type, name, response_time, response_length, response,
                       context, exception, start_time, url, **kwargs):
    if exception:
        print(f"Request to {name} failed with exception {exception}")
    else:
        print(f"Successfully made a request to: {name})
        print(f"The response was {response.text}")

The  "Successfully made a request to" f-string is invalid. Running this sample code will raise an error at runtime.
Bug 2
In Running a background greenlet in
from locust import events
from locust.runners import STATE_STOPPING, STATE_STOPPED, STATE_CLEANUP, MasterRunner, LocalRunner

def checker(environment):
    while not environment.runner.state in [STATE_STOPPING, STATE_STOPPED, STATE_CLEANUP]:
        time.sleep(1)
        if environment.runner.stats.total.fail_ratio > 0.2:
            print(f"fail ratio was {environment.runner.stats.total.fail_ratio}, quitting")
            environment.runner.quit()
            return

@events.init.add_listener
def on_locust_init(environment, **_kwargs):
    # dont run this on workers, we only care about the aggregated numbers
    if isinstance(environment.runner, MasterRunner) or isinstance(environment.runner, LocalRunner):
        gevent.spawn(checker, environment)

This sample code will fail in on_locust_init as it does not import gevent before using it. Running this code will raise an error at runtime.
Expected behavior
The code should be  copy-and-pasteable from the docs without much modification to work. In both instances these are whole self-contained tasks and not classes.
Actual behavior
The code fails when copy-pasting into a new locust task file.
Steps to reproduce

After installing locust, copy and paste the code into a locustfile.py and run locust.

Suggested Fixes
Bug 1
Change invalid f-string to:
print(f"Successfully made a request to: {name}")

Bug 2
Import gevent, which gets installed as a dependency of locust.
import gevent
from locust import events
from locust.runners import STATE_STOPPING, STATE_STOPPED, STATE_CLEANUP, MasterRunner, LocalRunner

I again will gladly volunteer to make this change and issue a pull request.
Environment

OS: Mac OS Big Sur 11.6.8
Python version: 3.10.8
Locust version: 2.13.0
Locust command line that you ran: locust
Locust file contents (anonymized if necessary):

Looking forward to the PR! Thanks!

PR: https://github.com/locustio/locust/pull/2254

Hi,
Closing out this issue. Thanks for taking my contribution.


Can't get Info for Failed Processor Task in the UI

In the UI, s a processor task has a failed status, then clicking the blue I has no effect.

not an issue, task was deleted


IE8 does not set type as a prop

IE8 throws an exception when changing type, at least in some cases (like changing the value from "reset" to "submit").
In the normalize function, we should attempt forcing type to be set with setAttribute, and see if that satisfies IE8 (along with modern browsers).

Even if we change it to use setAttribute, IE8 still reports "This command is not supported". It seems it's not possible to change the type attribute once it has been set.

@ebryn trololo, you were correct about type as far as IE8 is concerned :-)
Thanks @benmoss

No IE8 support is what I'm reading here, sort of.