chore(main): release 2.1.0

:robot: I have created a release beep boop
2.1.0 (2024-12-20)
Features

actions: add Kotlin language support (8ff42b0)
actions: allow custom placeholders (#17) (9e86494)
bash: add Bash language support (83335a0)
buffers: add option to sort log entries in float window (#19) (699ee87)
buffers: make float window at least as wide as title (b8dbf22)
buffers: make separator lines in floating win virtual text (134e821)
lua: support variables in return statement (cb2b22d)
odin: add Odin language support (#13) (862c5f9)
odin: change default template to printfln instead of printf (#13) (b516f54)
summary: add summary window (c58691e)
summary: apply source buffer options if summary window has only single source (83d3f92)
summary: summary window customization (988dbd0)
summary: use sequence id as tie-breaker for timestamp sort (9b44d22)
swift: add Swift language support (#18) (a47f09b)
template: add %filename placeholder (#16) (f274dc4)
watcher: remove | in the %watcher_marker (d25e1a8)

Bug Fixes

buffers: make the log snippet always follows log marker line (451b826)
failling CI (8b855f4)
summary: make show help order consistent (e95cce8)
test conflicts in parallel (05d5e2b)
watcher: allow capture log in the middle of the line (7cb8f07)

This PR was generated with Release Please. See documentation.

:robot: Created releases:

v2.1.0
:sunflower:


spsolve: separate logic for choosing method and method itself

This is a clean up of the solver logic in spsolve. It basically separates the choice of which solver to use from the actual solver logic. Along the way, this allows the right-hand side b to have any shape as long as A.shape[1] == b.shape[0]. The shape of the solution x is guaranteed to have the same shape as b. Fixes #8772.
These changes trivially enable other improvements which can be added in a second PR:

Give the user more control of what solver is used. Right now, spsolve decides on its own with a hint from use_umfpack. It's not possible, for example, to use umfpack twice for input right-hand sides of shape (n, 2) right now. I envision replacing use_umfpack by method=None, where spsolve choses itself if method==None (default), and otherwise uses what it specified.

Is #8722 relevant?

@homocomputeris #8722 is a little bit similar to #8772 in that a rhs of shape (n, 1) results in a result of shape (n,). Probably worth fixing too. It's different from the direct solver context though in that bicg only accepts "vector" input whereas spsolve can have any number of columns.

+1 on the idea of cleaning this up; the current setup is confusing (use of global useUmfpack and a very similarly named parameter use_umfpack and misleading.
For instance, if I remember (and am reading the code correctly):
If the scikit is not installed then the the global useUmfpack is set False by default according to Line 19.
If the right hand side is not a sparse matrix, then b_is_sparse is False on Line 134.
So currently, if the user provides a (dense) array for b and specifies use_umfpack=True but doesn't have the scikit (so useUmfpack is False), then line 164:
if b_is_vector and use_umfpack and useUmfpack
skips to the else clause on Line 175, and on the next line 176:
if b_is_sparse:
skips to the else on 179:
method = 'superlu'
Then the problem is solved with superlu, but the user gets no indication that their choice is not being respected. (That RuntimeError is only if they set the default useUmfpack = True despite not having the scikit, in which case they'll end up at Line 166 or Line 428.)

While you're in there (possibly in a second PR, as you say), would you also consider changing the name of the variable useUmfpack to indicate that it is setting whether to use UMFPACK by default, and/or add comments / documentation to this effect. I understand that this global and the use_solver function are useful for setting which underlying solver will be used by higher level routines like linprog, but I don't use globals frequently so this was quite confusing initially.

Also, it looks like if the method is factorized the use_umfpack option is not respected; only the global useUmfpack is considered. Sorry if this is beyond the intended scope, but while I'm reading your code I need to note it.

Overall I think this is an improvement. Right now, I don't have any line by line suggestions, just the comments above, which I recognize might be beyond the intended scope.
However, I think you need to add some unit tests so that we can confirm that these changes effect the desired behavior.

This is a backward compatibility break, and needs assesment of the impact.

This PR has been inactive for almost 7 months & there are concerns about a backward-compatibility break that haven't been fully considered / discussed.
I'm tempted to bump the milestone to 1.3.0 if there are no objections by Nov. 6th (tomorrow).

Ok, no objections / activity to move this forward -- milestone bumped accordingly

This PR remains stagnant as per my notes above prior to previous release -- bumping the milestone

@pv @mdhaber This PR is still stagnant with a "needs decision" label, although there is some broadly positive feedback above. Unless things pick up here soon, I'll likely have to bump the milestone.

Too bad this never got through.

@tylerjereddy @pv indicated that there was a backwards compatibility break. I'm not sure what it was and I can't look into it before the release. @nschloe do you know how this might break backwards compatibility? If so, addressing it could help push this through.

@mdhaber It changes the shape of the output in certain cases; see https://github.com/scipy/scipy/issues/8772.

@pv is that the backwards compatibility break you were referring to? What would you want to see in terms of impact assessment? (e.g. search GitHub, reason about cost vs benefit, discuss on mailing list?)

Yes. A bit similar bug is in the iterative solvers: https://github.com/scipy/scipy/pull/8723

My comment about backward compatibility is just because potential breakage was not discussed at all. If we decide this is a bugfix and the behavior change is OK, it probably still would need to be mentioned e.g. in the release notes.

is it clearly a bug (probably yes)

Yes, the documentation says that spsolve returns x:

the solution of the sparse linear equation. If b is a vector, then x is a vector of size A.shape[1] If b is a matrix, then x is a matrix of size (A.shape[1], b.shape[1])

But that is not currently true:
import numpy
import scipy.sparse.linalg

A = scipy.sparse.random(5, 5, density=1.0).tocsr()
b = numpy.random.rand(5, 1)
print(scipy.sparse.linalg.spsolve(A, b).shape)  # NOT okay: (5,)

This PR is supposed to fix this defect.

has this behavior been around "always" (in this case, since 0.11.0)

I checked 0.11.0 and 1.0.0; the behavior in those versions is the same current master.

how likely is it that the affected case is hit in code and people are relying on this (I'd guess more people use 1-dim vectors than column vectors, and are not affected), what's the fallout (shape difference often means exception or obviously wrong behavior later on, so probably not so bad to deal with)

I agree with your assessment of these points @pv. @perimosocordiae could you weigh in?

It's not clear to me that the backwards incompatibe change is essential to the cleanup in this PR. Would it be possible to preserve the existing behavior while retaining the bulk of the improvements?

Make a separate PR with the backward incompatible change (since it should be fixed)? Makes sense. What do you think @nschloe ?

It's not clear to me that the backwards incompatible change is essential to the cleanup in this PR.

The purpose of this PR is to fix the inconsistency in #8772. The clean-up is sort of a by-product of looking at the file for the first time in 100 years. :smiley: I'm not sure how easy it would be to clean up and still keep the inconsistency, but yeah, feel free to make another PR of course.

I'll bump the milestone, sounds like this might get split into two PRs?

Ah, I now see that I missed the larger context when looking through the changes.
I'm leaning toward this being a documentation fix rather than a behavior change, for the reason that changing the shape of a returned value can often result in silent errors in downstream code.
Consider this case:
A = scipy.sparse.random(5, 5, density=1.0, format='csr')
b = np.random.rand(5, 1)
x = scipy.sparse.linalg.spsolve(A, b)

y = x * np.random.rand(1, 5)

Currently, the last line would be an elementwise multiply and y would be a row vector. With the proposed change, it silently turns into an outer product and y.shape == (5, 5).
It's possibly a contrived example, but I'd rather we avoid even the potential for this sort of bug if the alternative is updating a docstring to reflect the current behavior.
With all of that said:

I think there are good, worthwhile cleanups in this PR that don't have compatibility concerns, and we should merge those in any case.
If I'm being overly conservative and the consensus from other scipy folks is to make the change, I won't push back further.

Six months without activity in this PR; reviews seem positive, but in danger of getting bumped on the milestone if activity does not pick up soon.

bumping milestone

I don't think there's a final decision here so I'll bump the milestone again. Feel free to ping me if activity picks up again in the next few weeks.

I'm going to bump the milestone again--more than a year without any activity and there is still a "needs-decision" label here


[Bugfix] Fix vLLM UsageInfo and logprobs None AssertionError with empty token_ids

When there is no new tokens generated, Sequence.get_output_token_ids_to_return should return empty list.
FILL IN THE PR DESCRIPTION HERE
FIX #8988  (link existing issues this PR will resolve)
BEFORE SUBMITTING, PLEASE READ THE CHECKLIST BELOW AND FILL IN THE DESCRIPTION ABOVE

 PR Checklist (Click to Expand)
Thank you for your contribution to vLLM! Before submitting the pull request, please ensure the PR meets the following criteria. This helps vLLM maintain the code quality and improve the efficiency of the review process.
PR Title and Classification
Only specific types of PRs will be reviewed. The PR title is prefixed appropriately to indicate the type of change. Please use one of the following:

[Bugfix] for bug fixes.
[CI/Build] for build or continuous integration improvements.
[Doc] for documentation fixes and improvements.
[Model] for adding a new model or improving an existing model. Model name should appear in the title.
[Frontend] For changes on the vLLM frontend (e.g., OpenAI API server, LLM class, etc.)
[Kernel] for changes affecting CUDA kernels or other compute kernels.
[Core] for changes in the core vLLM logic (e.g., LLMEngine, AsyncLLMEngine, Scheduler, etc.)
[Hardware][Vendor] for hardware-specific changes. Vendor name should appear in the prefix (e.g., [Hardware][AMD]).
[Misc] for PRs that do not fit the above categories. Please use this sparingly.

Note: If the PR spans more than one category, please include all relevant prefixes.
Code Quality
The PR need to meet the following code quality standards:

We adhere to Google Python style guide and Google C++ style guide.
Pass all linter checks. Please use format.sh to format your code.
The code need to be well-documented to ensure future contributors can easily understand the code.
Include sufficient tests to ensure the project to stay correct and robust. This includes both unit tests and integration tests.
Please add documentation to docs/source/ if the PR modifies the user-facing behaviors of vLLM. It helps vLLM user understand and utilize the new features or changes.

Adding or changing kernels
Each custom kernel needs a schema and one or more implementations to be registered with PyTorch.

Make sure custom ops are registered following PyTorch guidelines: Custom C++ and CUDA Operators and The Custom Operators Manual
Custom operations that return Tensors require meta-functions. Meta-functions should be implemented and registered in python so that dynamic dims can be handled automatically. See above documents for a description of meta-functions.
Use torch.libary.opcheck() to test the function registration and meta-function for any registered ops.  See tests/kernels for examples.
When changing the C++ signature of an existing op, the schema must be updated to reflect the changes.
If a new custom type is needed, see the following document: Custom Class Support in PT2.

Notes for Large Changes
Please keep the changes as concise as possible. For major architectural changes (>500 LOC excluding kernel/data/config/test), we would expect a GitHub issue (RFC) discussing the technical design and justification. Otherwise, we will tag it with rfc-required and might not go through the PR.
What to Expect for the Reviews
The goal of the vLLM team is to be a transparent reviewing machine. We would like to make the review process transparent and efficient and make sure no contributor feel confused or frustrated. However, the vLLM team is small, so we need to prioritize some PRs over others. Here is what you can expect from the review process:

 After the PR is submitted, the PR will be assigned to a reviewer. Every reviewer will pick up the PRs based on their expertise and availability.
 After the PR is assigned, the reviewer will provide status update every 2-3 days. If the PR is not reviewed within 7 days, please feel free to ping the reviewer or the vLLM team.
 After the review, the reviewer will put an  action-required label on the PR if there are changes required. The contributor should address the comments and ping the reviewer to re-review the PR.
 Please respond to all comments within a reasonable time frame. If a comment isn't clear or you disagree with a suggestion, feel free to ask for clarification or discuss the suggestion.

Thank You
 Finally, thank you for taking the time to read these guidelines and for your interest in contributing to vLLM. Your contributions make vLLM a great tool for everyone!

@CatherineSue looks like the test is failing, the max context for the model used is 8k token, would that be sufficient to expose the issue?

Oh I saw in the server fixture in test_chat.py we set --max-model-len to 8192.
I tested it locally, --max-model-len to 8192 and zephry model is not gonna trigger the issue.
In our test, we used llama3.2-1b-instruct and llama3.2-3b-instruct, with --max-model-len=131072, and a prompt with 2000 tokens can expose it. Can we use llama3.2 model in CI?

@njhill sorry for the late updates. I was sick for the past two weeks and didn't get time to fix the ut.
I tried to use llama3.2-1b-instruct, but the CI raises:
FAILED entrypoints/openai/test_chat.py::test_chat_completion_stream_options_and_logprobs_with_long_prompts[meta-llama/Llama-3.2-1B-Instruct] - openai.NotFoundError: Error code: 404 - {'object': 'error', 'message': 'The model `meta-llama/Llama-3.2-1B-Instruct` does not exist.', 'type': 'NotFoundError', 'param': None, 'code': 404}

Emm do we need to pass specific HF_TOKEN for the CI?

@CatherineSue no problem, sorry to hear that and I hope you're feeling better. Actually I had just started to look at this myself, and have written a separate test that uses a smaller max_num_batched_tokens to force prompt chunking without needing a very long context. This also reproduces the issue.
In the process of doing that I also found some related bugs. In any case I'm happy to push those updates to your branch so feel free to leave this and I'll do it soon (hopefully tonight).

OK @CatherineSue I have pushed the additional test, as well as changes to omit redundant empty chunks being returned to the user in this case. Hopefully this is good to go now!


Add custom sphinx translator dynamically with a mixin

Originally posted by @humitos in https://github.com/pandas-dev/pydata-sphinx-theme/pull/95#issuecomment-609067871
FYI, I changed the way that we are handling this in sphinx-hoverxref for a more permissive way. Instead of overriding the translator completely, I'm just adding the behavior that I need by creating a new class dynamically and inheriting from the translator define by the user (or extension) plus my mixin class with the behavior I need.
This allowed me to make my extension compatible with your theme. I just tested this theme with my extension and they both work nicely together!
So, if you think that you can be compatible with other HTML5Translator that the user could define, you may want to follow a similar pattern to avoid the same problem that I had with your theme.
See the PR at https://github.com/readthedocs/sphinx-hoverxref/pull/42

Good question. Eventually I'd say so, though if this one is really easy to implement it might reduce the problem enough that the other one isn't that necessary anymore.


gitignore 1

Yes it does exist when running gulp serve (development environment), and it doesn't show up on git because it is in that .gitignore.


Default confirmation

Add confirmation setting in settings screen, add statuses for transactions (sending 1/10, receiving 1/10, etc...)

New details:

confirmations should be shown only for regular txs
if the user changes the number of confirmations in settings - it applies only for future txs, not for the current ones

Waiting for answers for the next questions from @sasha-abramovich

how should tx details look like if the user sets 0 confirmations in settings? should we show 0/0 or remove this info at all?
what should be the max number of confirmations that a user can set?

how should tx details look like if the user sets 0 confirmations in settings? the confirmations' line should not be displayed
what should be the max number of confirmations that a user can set? let's set it to 10 now, if users will complain we can always increase it later.

checked


Mark partially visible when center is visible

This change marks an element as partially visible when just the center is visible, in addition to one of the sides being visible.
I've also added comments to make the code a bit easier to understand.
Right now, these two scenarios are marked as partially visible:

And when this PR is merged, this will be marked as visible too:

Note: the logic to determine whether an element is vertically partially visible already works this way.

👍

Nice, thanks @bramschulting


Module not loading

Hello,
i have created a module, enabled it, put a dd('Test') in the ServiceProvider and did a dump-autoload.
However, it does not seem to load the module. Also the routes are not accessible, so it is surely not loading the module.What am I doing wrong?
Thanks

Sounds like you need to register the packages service provider and facade classes in your app config file.

Oh, i thought the package does that automatically. Is there a way to automate that? I was using L4 before and everything was automated there (with the module package). I want to develop some modules for end users and it would be not that nice if they need to manually dig around in the code.
Thanks

Just saw that it tries to automatically register the service-provider for the specified slug. It would still be much more flexible if you could make it so that it uses the json file to get the service.providers which it should register. You could make it so that, when you create a module (with the artisan command) it automatically adds the default service provider to the JSON file.

I'm a little confused by what you mean. You would register any additional service providers you may have for your module through the modules service provider.
e.g., say you have a Users module - you would have a UsersServiceProvider.php service provider generated and autoloaded for you. You could then register additional service providers within the register method, like so:
/**
 * Register the Users module service provider.
 *
 * @return void
 */
public function register()
{
	// This service provider is a convenient place to register your modules
	// services in the IoC container. If you wish, you may make additional
	// methods or service providers to keep the code more focused and granular.
	App::register('App\Modules\Users\Providers\RouteServiceProvider');
	App::register('App\Modules\Users\Providers\RepositoryServiceProvider');

	$this->registerNamespaces();
}

Also, I want to clarify that you should not be adding your modules service providers to your app config file. You only need to add the Caffeinated Modules package service provider - it will handle auto-loading any modules you have for you.


mpd: fix build on darwin

Motivation for this change
Fixes https://github.com/NixOS/nixpkgs/issues/117061
cc: @smancill
Things done

[ ] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[x] NixOS
[x] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

Thanks, that was fast.
It builds on my mac now.


Performance Metrics Results

Hello Michael,
Could you please help me for the following questions?
1- Where can I find the result of performance measures such as sensitivity, fp, fn, .... ?
2- After running the model for the detection task of ADAM dataset, the results_boxes.json is created in val_resutls.
a) So, is this file the result of test data?
b) this file consists of some texts. For example: "FROC _Score_IoU_0.10: 0.75". Could you pls let me know what does it mean?
Thank you very much!
Maysam

Dear @orouskhani,
since nnDetection is not geared towards a specific medical problem (with a single working point -> "so not a single probability threshold") it does not provide cutoff metrics (so metrics which are only computed at a single threshold) in its current form.
All of the scalar metrics are written inside the results_boxes.json file and comprise of the AP and FROC metric. More information about detection metrics, pitfalls and literature resources can be found here: https://arxiv.org/abs/2206.01653
The IoU part of the metric name refers to the IoU threshold used to compute the metric.
Results from the "curve" (i.e. non scalar) metrics can be found in the results_boxes.pkl and the boxes subdirectory. If you are interested in Sens and FP, the FROC curve should be helpful.
The val_results folder contains the results from the validation set while test_results would contain results from the test set.
Best,
Michael

Dear @mibaumgartner
Thank you very much for the information provided.
It seems that the content of results_boxes.json is similar to results_boxes.pkl. Isn't it?
Best,
Maysam

The json file only contains the scalar metrics, the pkl file contains the scalar and the curve metrics (e.g. it contains the entire FROC curve and not just the FROC score).

Thanks for tour reply.
I have some simple questions too. Just to double check with you. Thx
1- nnDetection uses Retina Unet?
2- What's the loss function?
3- I run nnDetection for ADAM dataset. The output folder, val_predictions_nii, has some json file for each case. For example, for case 27, the json file contains as follows. There are three numbers, 1-3. What does it mean? Is it the number of aneurysms? Also what is score?
{
"1": {
"score": 0.5380976796150208,
"label": 0,
"box": [
34,
231,
40,
240,
247,
257
]
},
"2": {
"score": 0.6861448884010315,
"label": 0,
"box": [
58,
265,
64,
279,
279,
292
]
},
"3": {
"score": 0.8369495868682861,
"label": 0,
"box": [
50,
232,
57,
238,
376,
384
]
},
Regards,
Maysam

Dear @orouskhani,

yes nnDetection uses Retina U-Net
Bos classification: BCE, Box Regression: GIoU, Segmentation: CE+Soft Dice

Please refer to our paper for more details about the training and architecture.

each prediction is associated with a corresponding probability score. The json file are generated to add information to the nifty files, the first integer number refers to the index in the nifty file.

It really helped me. Thx for your response.
However, in Json file, the box is: "box": [
50,
232,
57,
238,
376,
384
]
},
It indicates the 3d location of two aneurysms? first one is [50, 232,57,] and second is [238, 376, 384]. Is it true?
Regards,
Maysam

Logging is performed via MLFlow (please refer to their documentation for more info).
No, the coordinates are bounding boxes, one box is defined by two points. The format is x1, y1, x2, y2, z1, z2 => the box points would be [50, 232, 376] and [57, 238, 384].

Thank you very much for your support. Really appreciate your kind help.
Just as the last question:

in results_boxes.json: "FROC_score_IoU_0.10": "0.75". Could you please what is the meaning of " FROC score"?
I see the FROC curve is presented by different IoU. Why we need to calculate FROC in different IoU?

Regards,
Maysam

Hi Michael,
I hope you are doing well.
I see the project's output for ADAM dataset as a text file including the center of coordination.
Is there any result for the diameter of predicted aneurysm?
Best regards,
Maysam

The challenge only expected the center coordinate, so the provided script only computes the center. It should be straight forward to extend the script to return the approximated diameter as well though. Since the prediction is a box and not an ellipse it won't be perfect though and it can only be roughly estimated.

Logging is performed via MLFlow (please refer to their documentation for more info).

Hello, the logging metrics for which train or val is not specified correspond to which subset please? Training or validation subset? Eg, FROC_score_IoU_0.10.
Thank you.

The metrics are computed across the validation set -> BUT: during training we only sample patches from the validation, NOT the entire image is predicted since that would take too much time thus the final result in the json file at the end of the training (entire images were predicted for these) are different from the logging results during training

Thank you !


BUG: drawing spheres behind the camera

When objects are placed behind the camera, they "inverse" themselves instead of disappearing
Ball at z:10, camera at z:0 looking at positive axis:

Ball at z:10, camera at z:0 looking at negative axis (backwards):

Fixed in 164a426


No longer getting MAC address on iOS 11

Using iOS 11.0 beta 1, the current code returns a spoofed mac address. 02:00:00:00:00:00

MAC Address of your device or every other device? eg. When you scan the network you can see other devices MAC Addresses but not yours?

All devices show spoofed MAC's. Some devices still show hostname but, not all. Running same code in 10.3 shows all the appropriate info.

Just googled it looks enhanced the security on iOS 11: Check this link

Not work on iOS 11.0 beta. All returns 02:00. And Find does NOT work neither.

and the countdown to a hackish solution begins once more... :/

I've reached out to two developers for network utility apps. Both have contacted Apple and have seemed to have made no progress convincing them to at least allow a permission for this. I think this is going to break most network apps when it drops.

Any sign of any workaround for this issue yet? I noticed with IOS11 GM that all the Network scanning apps like Fing do not work anymore. But would be interested if news of any developer workarounds are being looked at?

I am closing this issue since there is no workaround for iOS 11. If you find anything please post it here and reopen the issue.

Hello.
Looks like Fing app creators discovered some workarounds for this issue.

tested Fing and work normally, but this is not

did anyone get a workaround for this issue


feat: add evm tests

add vmtest of ethereum tests

What this PR does / why we need it:
Which issue(s) this PR fixes:

Fixes #
Which docs this PR relation:
Ref #
Which toolchain this PR adaption:
No Breaking Change
Special notes for your reviewer:
CI Switch
ci-runs-only: [Chaos CI, Cargo Clippy, Coverage Test, E2E Tests, Code Format, Unit Tests]

Codecov Report

Merging #542 (9ffa8a6) into main (c829b16) will increase coverage by 0.80%.
The diff coverage is 85.91%.

@@            Coverage Diff             @@
##             main     #542      +/-   ##
==========================================
+ Coverage   16.97%   17.77%   +0.80%
==========================================
  Files         137      139       +2
  Lines       18823    19036     +213
==========================================
+ Hits         3195     3384     +189
- Misses      15628    15652      +24

Impacted Files
Coverage Δ

core/executor/src/tests/mod.rs
100.00% <ø> (ø)

core/executor/src/tests/vm_state.rs
75.00% <75.00%> (ø)

core/executor/src/lib.rs
88.88% <94.73%> (+5.71%)
:arrow_up:

core/executor/src/tests/vm_test_suite.rs
97.82% <97.82%> (ø)

core/executor/src/debugger/mod.rs
86.53% <100.00%> (+7.12%)
:arrow_up:

core/mempool/src/pool.rs
87.86% <0.00%> (-0.58%)
:arrow_down:

core/executor/src/adapter/mod.rs
64.93% <0.00%> (+1.29%)
:arrow_up:


Possible SQL Injection not detected by the RegEx

This seems to pass the filtering:
http://localhost/admin/symptoms/(select id from users where id = 34)
while this doesn't:
http://localhost/admin/symptoms/(select id from users where id = 34;)
Our JS function looks like this:
   dao.getSymptoms = function(patientId){

        return dao.executeQuery('SELECT id,uid,date FROM questionnaires where uid = ' + patientId);
    };

I was able to expose all our database table with this method. Is there a fix?
Thanks

@Danielmr123 , which database are you using?
If you are using MySQL, express "mysql" library/package has a built-in function to avoid SQL Injection, i.e. mysql.escape(), pool.escape(), connection.escape(), etc
Hope it helps.


No paging and scrolling option available

Not able to scroll on large data rows.

Sure @usmanC9.
Thanks for reporting this. Original design is not to have scroll bar. I
used to adjust panel height instead. But I would like to fix in next
version.
On Tue, 10 Apr 2018, 1:10 pm usmanC9<EMAIL_ADDRESS>wrote:

Not able to scroll on large data rows.
[image: image]
https://user-images.githubusercontent.com/17683147/38556107-f4660772-3ce1-11e8-8166-80c02e7e0c29.png
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/yesoreyeram/yesoreyeram-boomtable-panel/issues/19,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAJY88SxYD2aC1Qz9A2qn0jfUCn97OStks5tnKEegaJpZM4TOIh3
.


ignore case when checking elb protocol

We currently get a slightly obscure error when using lower case to specify ELB protocol.

An error occurred (ValidationError) when calling the CreateLoadBalancer operation: Secure Listeners need to specify a SSLCertificateId

So save future developer debug time and do a case insensitive check.

👍  with version bump.

Discussed the change with @pchand-amplify as well so merging.


test: add placeholder of several test case for baiji developer

Signed-off-by: zhuangqh<EMAIL_ADDRESS>
Ⅰ. Describe what this PR did
Add placeholder of several test case for "Bainian technology" developer.
Ⅱ. Does this pull request fix one issue?

Ⅲ. Describe how you did it
Ⅳ. Describe how to verify it
Ⅴ. Special notes for reviews

Codecov Report

Merging #1628 into master will decrease coverage by 3.39%.
The diff coverage is n/a.

@@            Coverage Diff            @@
##           master    #1628     +/-   ##
=========================================
- Coverage   41.86%   38.46%   -3.4%
=========================================
  Files         270      270
  Lines       17685    19241   +1556
=========================================
- Hits         7404     7402      -2
- Misses       9369    10927   +1558
  Partials      912      912

Impacted Files
Coverage Δ

apis/server/exec_bridge.go
46.15% <0%> (-22.03%)
:arrow_down:

daemon/mgr/container.go
34.38% <0%> (-15.97%)
:arrow_down:

daemon/mgr/image.go
54.09% <0%> (-14.38%)
:arrow_down:

daemon/mgr/container_exec.go
53.84% <0%> (-13.9%)
:arrow_down:

apis/server/server.go
35.39% <0%> (-12.8%)
:arrow_down:

daemon/logger/syslog/validate.go
40.7% <0%> (-11.93%)
:arrow_down:

cri/v1alpha1/cri_utils.go
20.5% <0%> (-8.23%)
:arrow_down:

cri/v1alpha2/cri_utils.go
19.81% <0%> (-8.05%)
:arrow_down:

apis/server/router.go
86.98% <0%> (-4.39%)
:arrow_down:

cri/v1alpha1/cri.go
0% <0%> (ø)
:arrow_up:

... and 7 more

Is this ready for merging? I think this just add some framework or example in test. And this will not affect the code base?
If you confirm OK to merge, we could merge this. @zhuangqh

yep. Please merge. @allencloud


Use of Object and Function discouraged?

I have a question about the docs, which discourage the use of Object and Function types.
Should they really be discouraged at all? Because I'd say in most cases, it's not practical to specify the full type of an object or function. For instance, if I use a third party library that returns an object that has 200 properties attached to it, and I want to pass that into my own function which is annotated with Flow. It's not practical at all for me to create a new type and specify those 200 props. I'd just use Object.
Am I approaching this wrong? Bear with me as I literally just started using Flow a few days ago!
Thanks.

You can use them, as well as any, but then flow will be unable to type-check some parts of your code.

I want to pass that into my own function which is annotated with Flow. It's not practical at all for me to create a new type and specify those 200 props

You can just specify the props you are going to use in your function

Ah ok, so you can do selective annotation for objects. Great! Thanks for the info :)


Upgrade UI dependencies

I'm not entirely sure if these upgrades are needed for the release.
I have tested it locally, and it builds. I also did a spot check on the local UI. But I don't know how to ensure everything works as expected.
Please let me know :)
Signed-off-by: Kemal Akkoyun<EMAIL_ADDRESS>

Conflicting files :(

Conflicting files :(

Rebased 👍

Thanks!


fix(library): update parser to handle september issue of mwb 2024

:tada: This PR is included in version 3.16.1 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Auto debug signals from list

As a part of debuging #260 I have found that auto_debug_signals have problems when methods are in list. Here is extension which add support for this case.

I have rewritten this function so that calling auto_debug_signals on element with debug_signal will correctly call debug_signal method. This also break reference cycle, because we don't traverse owner in instances of TransactionBase

I have found another reference cycle. This time in Amaranth, which use MustUse class which point on it self to check if Elaboratables are used. So I introduced following changes:

added support for Mapping
added visited set to break dependecy cycles
added ignoring of private fields to get pretty print (to don't print _MustUse_context)

I acknowledge that last point can be controversial, so I am ready to remove it


WIP: split big epochs files when saving

I still have to modify the read function and clean up + add tests

@Eric89GXL for the sake of simplicity and after some discussion with @agramfort , I haven't modified the saving function to save epoch-wise -- as of now.

I don't think it's much simpler, we lose out on some benefits, and we're breaking compatibility with other readers with this change anyway. So I don't really see why this is the best option...?

we don't break backward compat. Old code will basically not read automatically all the parts.
to me it's much simpler.
@mainakjas travis is not happy and we need tests.

So you're splitting the events definition and data into separate blocks,
too? You must do this, otherwise it won't work (reading in the first chunk
of data with full events list won't function properly). This seems a bit
clunky but workable, I guess. And I suppose it might be possible to add
incremental read write with the large array, too.
But I am curious what is complex about my solution? Having two read/write
paths and having to update fieldtrip?

i kinda liked the way @Eric89GXL outlined the split epochs. also his method would make it easier for the reading from disk functions he proposed, which is really desired.

ping @Eric89GXL time to review ;-)

Other than my minor comments LGTM, other than my general grumpiness about the choice of solution :)

will we be able to access the epochs from disk with preload=False? or will it still be feasible with the split epochs?

will we be able to access the epochs from disk with preload=False?

no. It's not supported.

besides LGTM

great, I'm done addressing eric's comments. Travis is doing it's job ...

travis made my day :)

+1 for merge when travis is happy

Thanks @mainakjas


Improve performance of v2 arg handling

@searlmc1 this is missing a change: on https://github.com/ROCm-Developer-Tools/HIP/blob/41b29c699fa65a53abba01d0cd151b6b0cfa46b0/src/program_state.inl#L152 the vector holds std::string, not std::vector<char>. This is why the CI fails. Otherwise LGTM.


cpu_instr 8: mismatched instruction from blargg test on line 208109

I downloaded the .gb file from https://github.com/retrio/gb-test-roms/blob/master/cpu_instrs/individual/08-misc instrs.gb and on line 208109 it says there is a POP AF instruction but I'm seeing that there is instead a NOP at that position instead.
Is the test file for blargg cpu_instr 8 out of date?

Hey @ysawyers , it's definitely possible that the gameboy-doctor logs are wrong. Did you find out anything that caused you to close this issue?

Hey @ysawyers , it's definitely possible that the gameboy-doctor logs are wrong. Did you find out anything that caused you to close this issue?

Yeah, saw it was just a bug on my end. Great tool by the way!


Uncaught Exception: ENOENT: no such file or directory, open '/home/davor/GPMDP_STORE/.settings.json'

This happened after I resized the window.
An uncaught exception was reported.
Info:
OS: linux
Arch: x64
GPMDP Version: 3.0.0
Time: Tue Mar 08 2016 17:33:55 GMT 0100 (CET)
Error:
ENOENT: no such file or directory, open '/home/davor/GPMDP_STORE/.settings.json'
Error: ENOENT: no such file or directory, open '/home/davor/GPMDP_STORE/.settings.json'
    at Error (native)
    at Object.fs.openSync (fs.js:584:18)
    at Object.module.(anonymous function) [as openSync] (ATOM_SHELL_ASAR.js:159:20)
    at Object.fs.writeFileSync (fs.js:1234:33)
    at Settings._save (/usr/share/google-play-music-desktop-player/resources/app/build/main/utils/Settings.js:82:22)
    at Settings.set (/usr/share/google-play-music-desktop-player/resources/app/build/main/utils/Settings.js:67:14)
    at BrowserWindow._save (/usr/share/google-play-music-desktop-player/resources/app/build/main/features/core/persistAppState.js:17:14)
    at emitOne (events.js:77:13)
    at BrowserWindow.emit (events.js:169:7)

This issue was created automatically inside the uncaughtException handler

Closed?  Your mistake or what?

Yes, this happened because I saw a folder called GPMDP_STORE in my home folder. I didn't realize what it was, so I removed it. Following that, I got that error after I resized the window.
I opened up #380 instead.

Ah, the old "delete the unknown folder and watch the world burn" ploy. :+1:
I do that all the time aswell, we should have a PR merged soon to move the linux config


Editorial request: Apps paywall - add "Already a subscriber? Sign in"

On this sign-in page for apps, when I click the "Already a subscriber? Sign in" option it brings me back to the homepage. Are we sure the apps paywall is working properly? Could be a dev thing.

I think you may be hitting a 404ed homepage because it redirects to what will be the live link http://www.bostonglobe.com/elections/2016/. But we'll recheck on pre-prod.

Duplicate of https://github.com/BostonGlobe/elections-2016/issues/375


Feature/hw10 investigate mixins

Created object, function and widget mixins and showed result on contact page.

@Ehnvik send only the code, that's related to the current HW, please. I see 34 changed files


Only 'get_include' method visible on import

Issue: Sorry if this is a bit of a basic question, but when I import the cairo module I only see the get_include method, not anything else like ImageSurface, etc. What am I doing wrong?

In [9]: dir(cairo)
Out[9]:
['__builtins__',
 '__cached__',
 '__doc__',
 '__file__',
 '__loader__',
 '__name__',
 '__package__',
 '__path__',
 '__spec__',
 'get_include']

Environment (conda list):

$ conda list

Name                    Version                   Build  Channel
ca-certificates           2018.03.07                    0
cairo                     1.14.12              hc4e6be7_4
certifi                   2018.10.15               py37_0
fontconfig                2.13.0               h5d5b041_1
freetype                  2.9.1                hb4e5f40_0
gettext                   <IP_ADDRESS>             h15daf44_3
glib                      2.56.2               hd9629dc_0
icu                       58.2                 h4b95b61_1
libcxx                    4.0.1                hcfea43d_1
libcxxabi                 4.0.1                hcfea43d_1
libedit                   3.1.20170329         hb402a30_2
libffi                    3.2.1                h475c297_4
libiconv                  1.15                 hdd342a3_7
libpng                    1.6.35               ha441bb4_0
libxml2                   2.9.8                hab757c2_1
ncurses                   6.1                  h0a44026_0
openssl                   1.1.1a               h1de35cc_0
pcre                      8.42                 h378b8a2_0
pip                       18.1                     py37_0
pixman                    0.34.0               hca0a616_3
pycairo                   1.18.0           py37ha54c0a8_0
python                    3.7.1                haf84260_3
readline                  7.0                  h1de35cc_5
setuptools                40.6.2                   py37_0
sqlite                    3.25.3               ha441bb4_0
tk                        8.6.8                ha441bb4_0
wheel                     0.32.3                   py37_0
xz                        5.2.4                h1de35cc_4
zlib                      1.2.11               h1de35cc_3

Details about  conda and system ( conda info ):

$ conda info
          conda version : 4.5.11
    conda-build version : 3.0.27
         python version : 3.6.3.final.0

Good question! It looks like something is wrong on your system. What operating system, OS version, CPU type, etc, are you using?

This makes me think that maybe this is specific to your installation. Perhaps try removing and reinstalling the pycairo package? Try a conda update --all? In both cases, exercise some caution if the installation plan seems to involve a large number of downgrades or package removals — sometimes Conda installations can get into positions where running upgrades can break the overall installation.

Thanks for the suggestion. I tried updating conda and reinstalling pycairo. It all went smoothly, but I still have the same problem. I'm going to try setting up an docker container and installing within that. I'm using a conda env right now, and that evidently isn't providing enough insulation ... Thanks!

@H-Sha Are you still affected by this bug? If so, perhaps we can come up with a way to pursue it. If not, I might close it just to tidy things up.

@pkgw, thanks for following up. I wasn’t able to resolve but had some other issues with the machine and wiped it.
Haven’t tried since. Let’s go ahead and close. Thanks again.


 Have you reviewed your app's hosting compute logs? The logs are delivered to CloudWatch under the log group /aws/amplify/{app-id}. These logs should indicate errors that may have occurred in the compute runtime and will be a good starting point to debug such issues.
Docs: https://docs.aws.amazon.com/amplify/latest/userguide/monitoring-with-cloudwatch.html#ssr-logs.

Closing this thread as we shared the best practice on debugging compute runtime errors.


Class (instead of file) based script assignment in editor

Following some discussion with Karroffel and getting neikeq's GodotSharp module functional, I had an idea to make script/class organization easier, by having Godot automatically parse the project files for all classes/scripts and having a popup that lists them (with search bar and filters) to select a class rather than pointing a given node to a file directly. For example, on a Node2D selecting a subclass would make this window appear:

For GDScript/VisualScript, the class path could either be the file path in dot notation, or to further reduce the dependency on the file system's organization, GD/VS could have namespaces added or simply always appear top-level with no namespaces.
XCode operates similarly where the selection menu for a custom subclass on a view/component will list all of the classes in the project that inherit from the required type.

I partly agree -- especially for C#/DLScript where the classes are known beforehand, it would be nifty to have this; but for languages as GDScript and VScript where every file is a class, and there is no global "polling" of all files, it makes no sense at all (even less with the scenes idea, maybe you wanted to have just a "dotified" path there?)

Scenes.MainScene doesn't refer to the main scene in the project. It would be equivalent to a folder structure set as res://Scenes/MainScene/TestScript.gd

Two possible issues:

While this makes sense for languages like C# where there is totally no file/class relation, it would affect usability for GDScript (and other possible similar languages. Java for example has a file/public class relation). I want to select GDScript scripts with a file dialog not by searching a qualified name. And since we don't know the script type the user will choose in advance, we cannot display different loading forms.
How are you going to open the script in the editor? A Godot script MUST be a file (not a qualified name), that's how the API works and I don't think it's worth changing it. This one doesn't apply if you only intend to use the qualified time at load time and instantly get the actual file with a new virtual method in the ScriptLanguage API.

This is one of the solutions I had in mind for solving the namespace detection issue with C#: neikeq/GodotSharp#9, but I soon discarded the idea for the reasons above (we are just going to use a simple parser to find the namespace).

@neikeq if you're using a parser to find the namespace, does it mean F# can't be used anymore? I liked that the code just had to live in the assembly and be CLI compliant, with this you kick out all the CLI compliant languages that run on Mono, don't you?

@neikeq if you're using a parser to find the namespace, does it mean F# can't be used anymore? I liked that the code just had to live in the assembly and be CLI compliant, with this you kick out all the CLI compliant languages that run on Mono, don't you?

@karroffel The current behaviour is that it iterates through the typedef table until it finds a class that derives from GodotEngine.Object and matches the name of the script file. The problem with this is that you can't have NamespaceOne.Player and NamespaceTwo.Player, making namespaces pointless. This will be the default behaviour for any language that has no parser, including F# (in other words, it will be the same as now). Alternatively you can write a parser for it (see 4613cb7).

@karroffel The current behaviour is that it iterates through the typedef table until it finds a class that derives from GodotEngine.Object and matches the name of the script file. The problem with this is that you can't have NamespaceOne.Player and NamespaceTwo.Player, making namespaces pointless. This will be the default behaviour for any language that has no parser, including F# (in other words, it will be the same as now). Alternatively you can write a parser for it (see 4613cb7).

On my godot python binding, I've deal with this problem following the zen of python: "Explicit is better than implicit"
So to be available from Godot, a Python class should have been explicitly decorated as exposed. Obviously only one exposed class is allowed per file so it feels just like GDScript.
from godot import exposed

@exposed
class Player(Node):
    def _ready(self):
        pass

While it works great with dynamic language where a lot can be done at load time, I'm not sure such a thing could be achieved on C#...
@neikeq I don't know much about C#, is there a __file__ attribute (like the C one which the preprocessor replaces by the file path at compile time) ?
If so you could implement this in the decorator to end up with some classes flagged as exportable and with there associate file path. From there it would be trivial to run your scan between the compiled class and the source file.

@touilleMan I tried that already. I was close to achieving this by using the CallerFilePath attribute. This was an attempt: https://gist.github.com/neikeq/db685eda63e558d207abf12dececa51b
The problem was that the path provided by CallerFilePath is absolute, and considering it's at compile time... I thought about saving the path to the project somewhere and then using it to fix the script paths when running the game, but I don't think anyone would like the idea of exporting their dev directory path with the game.

@neikeq at least you made me puke my tea with your commit message 😆
I guess the simplest way that remains is to force user too keep namespace and file path the same for the exposed classes. Potentially providing a configuration field the user could overwrite to specify by hand a custom path for the class.

I would still very much like a system like this.
It would be important to not break old code, so what about a system like this?

Registry
A script registry would scan the project for all detected script files and queries the appropriate ScriptingLanguage for any "exported" classes. An "exported" class would be identifyable by name.
There could be a "low level" API for querying and even procedurally inserting exposed classes.
By accessing the ScriptRegistry singleton it would be possible to get Scripts by name for example.
Namespaces
Since "exported" classes would need to have a unique name namespaces might be optionally needed, using a default "empty" namespace would work too.
GDScript integration
With this design it wouldn't be required to be limited by the file-based architecture that's currently implemented in Godot.
To not break old code, the ScriptRegistry integration should be optional and old code would still behave like it does.
What could be done with this registry in place, is that multiple classes (or in the case of GDScript - inner classes) could be put into one file.
example of usage
fruits.gd

# no "extends" here, will default to Reference then

export class Fruit:
    var name
    func _init():
        name = "some fruit, has not been given a name yet"

export class Apple extends Fruit:
    func _init():
        name = "Apple"

export class Pear extends Fruit:
    func _init():
        name = "Pear"

export class FruitBox:
    var fruit

    func set_obj(f):
        fruit = f

    func get_obj():
        return fruit

# for namespaces this could be used
#
# export("fruits") class ...
# or this for nested namespaces maybe?
# export("fruits", "tasty")

some_other_file.gd
extends KinematicBody2D # maybe a Player controller?

func on_hit_by_object(obj):
    if not obj.is_in_group("has_fruit_attachement"):
        return

    if obj.get_fruit() is Pear: # inheritance check via name instead of preload()
        show_dialog_bubble("Why are you throwing pears? Their shape doesn't even hurt me on impact")
    else:
        show_dialog_bubble("Ohhh you hit me with a ", obj.get_fruit().name)

func on_fire_button_pressed():
    var fruit_box = FruitBox.new() # creates class by name, not preload()
    fruit_box.set_obj(Apple.new())
    shoot_box(fruit_box)

GDScript would check if an identifier exists in the registry, like this ScriptRegistry.get_class("SomeClass", ["fruits", "tasty"]) and if it exists it can be used. This is similar to how GDScriptNativeClass works, it checks if an identifier names a class known by ClassDB, Autoloads work the same way.

TL;DR:

add a ScriptRegistry singleton that scans for exported classes
No big changes needed for this to work
existing code will still function
purely optional
namespaces to allow duplicated names of classes
referring to a class would look like accessing a Godot internal class

WDYT?

@karroffel That would be much more convenient, especially if it works with autocompletion. Static variables would be a nice inclusion too.

Just discovered that I've been working on a similar project. Hopefully somebody else hasn't already been working on this too. XD Gotta figure out how we're gonna coordinate on this mess, cause I'm trying to create one branch that handles this Issue and another.

I think gdscript needs no changes for this. Entire system does not need go
become more complex for differences with other systems, or an apparent ease
of use that is not.
On Mar 9, 2018 19:35, "Will Nations"<EMAIL_ADDRESS>wrote:

Just discovered that I've been working on a similar project. Hopefully
somebody else hasn't already been working on this too. XD Gotta figure out
how we're gonna coordinate on this mess, cause I'm trying to create one
branch that handles this Issue and another
https://github.com/godotengine/godot/issues/6067.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/7402#issuecomment-371964960,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AF-Z20W_kL-5IcDwgujmNV3BuESUIPn9ks5tcwOzgaJpZM4LYlq8
.

@reduz So then, if we wanted a feature of this sort, it would have to be a feature that is exclusive to and part of the /modules/gdscript/ module? Or you just don't want GDScript to support this at all because of the added complexity?

Also selecting class from a global list is imho a terrible idea.
For C#, I still think the best that can be done is marking the main class in the file with some tag, I fail to see why doing this is not possible.

@willnationsdev I see this pointless in GDScript too. I don't think it's needed.

In other words, going from script oriented to class oriented is a definitive no from me.

@reduz

Also selecting class from a global list is imho a terrible idea. You still know better where your file is than where your class is on a large project.
...
In other words, going from script oriented to class oriented is a definitive no from me.
I beg to differ on this one, at least when it involves C# support.

I can understand how GDScript might not need any such changes, as it is a special purpose language which means anything written in that language would presuppose Godot specific workflow.
But we can't assume the same with C#, or potentially other similar general purpose languages. Such a language like C# is never meant to be used by distributing and referencing by in its source format.
It was simply an unfortunate side effect of introducing the C# binding after GDScript - which is more suitable for such a script oriented approach - rather than being a conspicuous choice that would provide an optimal workflow for C# as well.
C# already has a well established convention and mechanism to resolve and manage dependencies which is all assembly/class based rather than script based, and it's the way what most of its tools and libraries presupposes and what the developers are accustomed to.
And unlike GDScript, there exist a vast amount of third party libraries that can be referenced from a C# project in their binary format. Godot currently supports referencing those dlls from the main *.csproj file, but when it comes to addons we still need to find a way to make it possible for a C# project to reference C# addons with its own binary dependencies both within Godot and external IDEs.
If we are to adhere to a workflow that is alien to a typical C# development process, it would make the development set up more difficult and such things like building your addon from a popular IDE and distributing it as a NuGet package would only provided limited usage, because any classes contained in such an assembly cannot be referecend by Godot.
And I disagree that providing a global class list to be a terrible idea. It's the way most of the IDEs supports a similar functionality (i.e. selecting a target class for a unit test), and with auto completion or namespace support, it's pretty easy to find a wanted class.
Actually, in most cases, it's much easier than referencing them by their source locations. Developing a C# project can involve dealing with multiple libraries and classes can be located in a deep namespace hierarchy. So, doing a quick search by their names is often much more convenient than having to navigate between different file system locations.
And it's also how Unity supports its C# binding as well, so I think it'd be better if we also support such a workflow that is more common to typical C# development projects including that involving Unity, rather than shoehorning a binary based language into a scripted one.

With optional typing, something like syntatic sugar but for classes can be useful to make better code.
Writing
func a_function(load("res://some_directory/sub_directory/character_weapon.gd"): weapon)
  var load("res://some_directory/sub_directory/character.gd"):character = load("res://some_directory/sub_directory/character.gd").new()
...

may look ugly, probably :thinking:

Idk if the static typing was meant to I clude scripted types (not privy to any of that debate). I'm guessing that in that case we'd have to use something without identifiers of any kind, like...
const MyType = preload("res://dir/dir/another_dir/MyType.gd")

func my_func(p_obj: MyType):
    # do something with p_obj where (p_obj is MyType) == true

@willnationsdev I know, also the whole thing an be made by a plugin that registers every new GD file in a singleton (writing consts in the script) for global access, but something integrated may be better.

@eon-s I thought of that too. It's basically a hack, but it'd be MUCH better than nothing. I already set it up so that EditorPlugins can add/remove singletons

@reduz I agree that my original idea at the top of this thread is mostly pointless, and only a convenience feature to avoid clicking through folders. However, with the suggestion from @karroffel, the discussion shifted to file-versus-class as the basis for GDScript. Since his recommendation was an entirely optional feature, a 'definitive no' is slightly heavy-handed. One of the main issues I've had with GDScript is the way scripts are handled as loaded files, and thus require explicit load statements at the top of other scripts for all use cases. Changing the location of a script file means changing all the scripts that reference its path. While that is a similar issue as with import statements in Java, most Java IDEs offer a refactor tool that automatically updates such references, and an auto-import tool that removes the need to remember class locations. As far as I know, Godot's file-mover does not modify paths written in scripts, and while autocomplete does provide script paths, the suggestions aren't filtered down to a specific class name. Loading and storing countless different scripts to do instance-of checks or instantiation is far less elegant than an '''import namespace.*''' statement. GDScript is already quick and easy to learn, and an optional feature that resembles other popular languages would assist those coming from a Java/C# background.

First, It's not heavy handed, this is about making a game engine, so the priority is that it's simple and performant.
Second, the use case is rare at most. It's only for assigning scripts to nodes. I'v worked on pretty large projects and only did this once.. twice maybe? 99% of the time you create new scripts, rarely assign them.
So, bloat for something rarely used is difficult to justify for me.

Sorry, did not mean to close.

If we are going to separate the 'file vs class' aspect from this issue and treat it purely as a usability problem for GDScript, maybe we should reopen #15661 and continue the discussion there?
While I might agree that it could be less of a problem for GDScript, I believe it's not simply a matter of convenience for C# projects though.

I don't really see it as a problem for C# either, the rationale is the same.

99% of the time you create scripts, not assign them.
Class based makes 1) more complex

I just don't see any justification for the use case.

@reduz I don't believe that @karroffel's idea would sabotage simplicity or performance. Godot now has four scripting languages, and a binding API for almost any other language. Contrast that with Unity's choice to drop support for anything but C#. Giving users options may increase the length of a drop-down menu, but allowing users to stick with what they already know makes everything else simpler.
However, unofficial languages will never be as convenient or well-suited to Godot as GDScript. Even the well-implemented C#/Mono binding has additional implementation and compilation challenges. Providing more ways to use GDScript, instead of bailing to another language, would simplify the user experience.
The issue is no longer just about assigning scripts from paths versus from qualified names. It's about writing scripts too. With my background in Java, const Class = preload("res://script.gd") is annoying, especially if I need to load multiple scripts:
const enemy_types_path = "res://scripts/enemies"
const enemy_type_names = ["tank", "soldier", "aircraft"]
var enemy_types = load_enemy_types()

func load_enemy_types():
    var types = []
    for name in enemy_type_names:
        types.append(load(enemy_types_path + name))
    return types

Versus:
import enemies.*

@reduz Let me elaborate then. Let's assume I have MyProject which references 3rdPartyAddon both of which are C# projects.
In a typical C# development, all I need to do is add the reference of 3rdPartyAddon to MyProject within an IDE, preferrably by using something like NuGet.
However, such a use case is impossible, if it is needed to reference a class from 3rdPartyAddon within Godot editor. So, I also need the source bundle of the 3rdPartyAddon project and extract it under addons and reference them by source files.
But not only that, I also need to edit MyProject.csproj to include every source files from 3rdPartyAddon to make it compile within the IDE, and also find any external assembly references 3rdPartyAddon.csproj it may contain and manually add to the main project.
This is far from how a typical C# developer would want to manage their projects.
And I strongly disagree that people would very rarely assign scripts to existing nodes. Godot currently don't have tons of 3rd party addons like Unity have, but I believe (and hope) we will get there eventually.
And when I used Unity, I've used many framework or template type assets which provide scripts that you can attach to your own nodes. Even in Godot, I assign different classes to a node all the time, at least while I'm developing. So I believe it's not something we can assume to be true for all developers and all their projects.
If we ever become popular and have a growing ecosystem like Unity current has with their Asset Store, it'd be much more common to see projects to rely on many different types of addons and in large numbers.
In that case, navigating into a few different deep hierarchies (i.e. Addons/3rdPartyAddon/Scripts/Com/Acme/Controller/PlayerControl.cs) every time you assign a node can quickly become cumbersome.
At the very least, I believe it is best to support a workflow that is well established and optimized for each individual bindings, rather than simply forcing every binding languges for Godot to work like GDScript does.

@Xydium Again, I apologize, but will not add more complexity to GDScript to make it work like Java. It may bother you but this is still not a common case scenario and, for most users, GDScript is much simpler than Java.
I think there are more chances to get Java to work in Godot rather than doing this. Also If you are doing this in C#, I don't quite get why it wouldn't work.
@mysticfall This is clearly a problem for the case of a third party add-on that comes compiled, but i can imagine much simpler work arounds to this that do not require changing how Godot works. Also again, no matter how it works, that add-on will most likely register the custom types for you, so you may not need to assign them anyway.

Again, I would like to discuss regular use cases that are not corner cases. I don't want to discuss implementation complexity.
To me, the way it currently works, is fine in 99% of use cases, and usability is better than using classes. Rare use cases like the ones described should be workaroundable. Throwing away the system that has the best usability for something not often used really does not make sense to me.

@reduz That's fair, though I'm not looking for GDScript to become like Java, nor would I find Java preferable in any way to GDScript.
I consider this proposed feature more like the Built-In Script option. Built-In Script is an additional setting, thus, adds complexity, however it also simplifies things greatly by eliminating the requirement for a separate file when only implementing a handful of basic functions. There are projects which may never make use of it, but the feature exists for those that need or prefer it.
Similarly, class-based scripting can significantly simplify writing scripts (as shown above). Instantiating objects from scripts is not a corner case. It's fundamental to object-oriented programming. The above example of loading multiple scripts and storing them in an array has appeared in almost every project I have worked on in Godot, from platformers to space-shooters to real-time-strategy games. There are more situations than just that where classes would simplify script-writing. It should not replace the current file-based system. The two can coexist, and users can choose whichever they find more convenient for the use cases they encounter.
To further prevent any confusion for end-users, the class system could be disabled by default, and require explicit enabling from the project settings.

For GDScript at least, one way that this could be faked a bit is by declaring all of the scripts as constants in a singleton. The only thing you would need in order to make it work is allow people to inherit from a Script object instance declared in a Singleton's context.

@Xydium Actually, I did my best to avoid built-in from being used, because it generates some problems that need workarounds. It exists "for free" due to how Godot works, there is zero extra code to make it happen. Originally it was not possible to create a built-in script , but the option was added because users still really wanted it and it was pretty much a line of code (in the new script dialog).
I really don't see how it can simplify writing scripts, I only see a LOT more code complexity required for something that will definitely not be used often. I just can't see it being worth it.

@reduz Adding custom types would be nice, but I'd much like it to be a feature rather than something required only for C# (or other similar non-scripting languages) when GDScript doesn't suffer the same limitation.
And even if we can let users to use custom types as workaround, there still remains an issue of forcing users to manually merge and maintain source lists for every addons referenced in MyProject.csproj.
Unity does this by automatically parsing and generating .csproj file whenever something is changed in the project. I don't think this to be the best way to go as it's error prone and not really the idiomatic way of doing things in C#, and I'm not sure it'd be much easier either.

@willnationsdev if you want a script as a global class in GDScript, this is really easy to do and I thought about it many times, but it would be GDScript-only. I'm sure it would aid in usability for more complex projects.

@mysticfall it would work exactly as GDScript, the custom types are a C++ Node/Resource + Script, custom nodes/resources don't magically become part of the engine in GDScript either.

@reduz So there is a precedent of popular support overriding simplicity?
Here's full details on the use case I explained above:
I need a node to spawn different types of enemies. These enemies exist as scripts, and are a subclass of some generic Enemy which inherits from Node2D. In order to instantiate a script, I need a reference of some kind to it. In the current file-only system, I need to explicitly load every enemy subtype from each file path, and store it in an array. Each enemy file path consists of the directory, the enemy name, and the file extension. Consider the following hypothetical directory tree:
res://
    enemies
        ranged
            trebuchet.gd
            soldier.gd
            tank.gd
        melee
            mech.gd
            swordsman.gd
        support
            medic.gd
            transport.gd

As stated, I need to load each of these scripts from their paths. This is made worse by the fact that I organized enemies in folders by type, to keep things simple.
So, I could just write out explicit constants for each, and then put them in an array. Each time I make a new enemy type, I need another constant, and another load statement:
const TREBUCHET = preload("res://enemies/ranged/trebuchet.gd")
const SOLDIER = preload("res://enemies/ranged/soldier.gd")
#I was going to type these all out, but the fact that I don't want to proves my point
var enemy_types = [TREBUCHET, SOLDIER, ...]

To be clever, and to make adding new enemies slightly simpler, I can store the different directories and enemy types as strings in arrays, and then load them with a loop.
const ENEMY_TYPES = [
    "ranged", ["trebuchet, soldier, tank"],
    "melee", ["mech", "swordsman"],
    "support", ["medic", "transport"]
]

var enemy_types = load_enemy_types()

func load_enemy_types():
    var enemy_types = []
    for dir in range(0, 6, 2):
        for type in ENEMY_TYPES[dir + 1]:
            enemy_types.append(load("res://enemies/" + ENEMY_TYPES[dir] + "/" + type + ".gd"))
    return enemy_types

Contrast either of those techniques with:
import enemies.ranged.*
import enemies.melee.*
import enemies.support.*

var enemy_types = [Trebuchet, Soldier, Tank, Mech, Swordsman, Medic, Transport]

If this class-system existed, I would use it almost exclusively, not just in convenient use cases. I've heard rumors that statically-typed GDScript may also be implemented in the future, which I would use almost-exclusively too. The two together would make a valuable addition to the engine.

@reduz Thanks for the explanation. But in that case, probably it's less relevant to the problem that I initially mentioned.
All I want to do is a way to write a Godot addon in C#, and allow other people to either extend its functionality by extending some classes to create their own, or assign them to nodes in their projects.
In order to achieve that, I need to tell them something like "Download the source bundle and extract it somewhere, then open MyAddon.csproj to copy all Compile and Reference tags to merge them into your own .csproj file, and you'll need that whenever you upgrade it or for any other addon you may use", which is obviously not an optimal workflow for anyone.
And if I'm not mistaken, Godot's C# binding already tries to translate file paths into class names before asking Mono to resolve them. Currently, it seems that it's broken for addons because it doesn't use a proper namespace/domain for them.
In other words, we need to find some way to map file paths to class names properly anyway unless we want all addon writers to follow some weird namespace convention like Addon.MyAddon that exactly matches the file path.
I haven't looked into the C++ side much yet, but if I recall correctly, we already made it each binding's responsibility to resolve types from script references. Then why can't we also ask each bindings to present suitable list or hierarchy of types, so that C# can implement it using Mono's API that queries exposed types in each assembly, while GDScript can simply list all *.gd in the project path?
I don't think it would be a much difficult work, compared to writing some parser/generator for *.csproj that detects every file system changes like Unity does.

if you want a script as a global class in GDScript, this is really easy to do and I thought about it many times, but it would be GDScript-only. I'm sure it would aid in usability for more complex projects.

@reduz Wait, really? That would be okay? I don't see how that would be very different from registering names / namespaces in a HashMap for each language though. The entire concept of a TypeDB that could coalesce names and namespaces for all types of scripts and/or scenes is basically doing the same thing as using singletons, only the singletons route is LESS performant, not more (as far as I'm aware):

The editor creates a singleton node that has the same name as your project name.
If you add a plugin, the editor creates a singleton node with a name for the plugin (defined in the plugin.cfg). All of the generated singleton names are UpperCamelCase.
Any time a script file is saved, a new constant with an UpperCamelCase name is automatically added to the script that represents the singleton node. (would use the singleton that is most relevant, i.e. a script file in a plugin directory would go into that plugin's singleton script, etc.).
Enable GDScript and VisualScript to inherit from a Script object instance directly rather than having to supply a string literal filepath to them.

If you followed those steps, then you'd be able to do something like this:
//project my_project
my_project.godot
    addons
        my_plugin
            plugin_type.gd
project_type.gd
test.gd

# test.gd
extends MyPlugin.PluginType

func _ready():
    var obj = MyProject.ProjectType.new()

This would actually require minimal changes to GDScript, and I'm guessing you'd be able to do something similar to make VisualScript be able to access the singleton nodes by name as well.
So, if something like that would be permissible, how is that better than a centralized type / script database in core? I mean, any time you made changes to a script, the "namespacing" script would have to be completely reloaded, causing you to interpret the file and recreate all of the different constants, etc. Whereas if it's all in a core db of some kind, it's just a simple HashMap insertion in constant time, which is WAY faster than anything else.

@Xydium I understand your problem perfectly.
So, if I I have to choose between adding a lot of code complexity so your tiny bit of code, that you will not even use often, is snaller.
Or..
Leave as is, and you write a bit more code in this particular case.
Put yourself in my shoes. What do you think I should do?

@mysticfalls I think this is a mono specific problem that would need to be discussed with @neikeq. I personally dont understand why the restriction of same file name as class is in place. I imagine it should be possible to do away with it.

@willnationsdev TypeDB? Do you mean something like ClassDB? The singleton database of classes that was renamed and made accessible from scripts three days after I opened this issue in 2016 as per commit ce26eb7?

@Xydium It was a reference to this other issue I recently created. #17387

@willnationsdev I had something much simpler in mind, but I have the feeling this thread is kind of a mess, because each of you have a different idea in mind of what you need..

XD right. Well, @Xydium's issue seems pretty similar to mine in the sense of adding namespaces / typenames to GDScript for usability purposes.

@reduz Ok, then I'll ask the admin (anyone knows whom I can ask this?) to reopen #15661 so that we can discuss it from the Mono's side first. Thanks!

@reduz What was the "something much simpler" you had in mind? I wouldn't mind getting started on an implementation since I've already wasted a few months of my own time (my fault), lol. XD

@reduz I agree that it shouldn't be implemented if I'm the only one who would want such a feature. @karroffel's explanation of standard use cases is more complete, and again, the idea connects more with a separate, statically-typed GDScript than a mere enhancement of the current GDScript. The only way to know if it's a desired feature by the community would be to poll the community.

@Xydium Awesome. Well, the idea from there is virtually identical to the concept of adding tons of singletons for top-level namespaces. And if he's alright with doing that, then there's hope. Just need to hear what his idea is! excitement building~

@willnationsdev I'd still prefer to see optional statically-typed variables (for better code completion) and optional class-based scripts (so that scripts can be static types for variables and thus receive better code completion), which such a ScriptDB would assist in creating. However I understand @reduz's concern regarding simplicity, and mixing two paradigms in one language could be detrimental. At the same time, there are situations where dynamic types are better and vice versa, so the ability to employ static types only when they provide benefits would be nice.

Versus:
import enemies.*

Actually, I don't think this is any better tbh, in fact, it could even be a detriment. Because that doesn't give us the power to manually preload what we want, based on a certain map / scene that a player is loading. Having more control over what we preload and reference in dictionaries/array is a good thing! I feel like your example is over-exaggerating a problem that's easily solvable by GDScript already.

@girng I don't see why you would want control over loading code. I understand with scenes (and that wouldn't change) but code?

@QbieShay having control in what you preload in Godot is extremely powerful for smooth level transitions, low memory usage (only load what you need, instead of  * ).

@reduz  I don't think that adding the classDB would make the code that much more complicated.
I've been using Godot for some months now  and i already made some games with it. What i noticed, when the project started to be more and more complex, is that i felt:

More and more scared to refactor
Annoyed by having to search for some scripts of which i didn't remember the position

If classDB was there, I imagine it keeping track of where the scripts are and, when you need to move a script, classDB will update. So far, the only way to keep track of that is either having an external tool or run the game to see where it breaks.
What if the game becomes medium sized (no need for GDNative, still using GDScript)? How much time do you need to spend playing the game before noticing that something broke?
About the script searching, I tried to respect the guidelines on where to put resources and scripts, but sometimes scripts just don't fit anywhere.
I don't even want to start the static typing discussion here, but class DB would be a nice step forward for that. Two words about that here
I think that if you look around in open source Godot projects, you will soon find a lot of people that implemented something like classDB in their own projects. IIRC, @Faless  did.

I already commented on the other issue, but thought I'd chime in here too:

Type based scripting isn't more difficult than file based scripting. It could literally be the exact same UI to drag and drop project scripts (engine fills in type reference instead of path reference), PLUS a new script search window, from which you could also drag/drop scripts. Maybe I'm missing something, but I don't understand why working with types instead of files is more difficult. Actually seems like it would be easier, and certainly more flexible w.r.t. script library dependency management.
For refactoring/renaming types: If at any point a type reference becomes broken (type no longer exists, was renamed, different namespace, etc...), just help the user fix it. List all the broken type references in the project, let them pick a new type (from a searchable/filterable list). Fixes the broken reference wherever it's referenced. Simple. For types in the project, add a "Rename type" command to the context menu for .cs files in the project, that automates the process. Just like Visual Studio, if you rename the file first, ask the user if they want to rename the type as well, then update all the references to that type in the scene.

Renaming support is the responsibility of coder and IDE not the game engine IMO. This seems like a marketing team perspective to me.

@hubbyist I think a game engine is a kind of IDE in a way.

AFAIK godot editor is a godot engine game so the IDE like part is not that much coupled with the engine core. Renaming support may be even an official editor plugin but not a core feature. As well multi class in a file is a language specific functionality it seems and must be handled by either editor or the language binding. If PHP bindings would be added, having multiple classes in a file may help as well. But a language binding must not effect the core functionalities and lock engine to the methodologies of a specific language in any way. So binding must conform to engine not the other way around IMO.

Godot editor is a godot engine game so the IDE like part is not that much coupled with the engine core. And it is a good way of separating concerns I think. Renaming support may be even an official editor plugin but not a core feature. As well multi class in a file is a language specific functionality it seems and must be handled by either editor or the language binding. If PHP bindings would be added, having multiple classes in a file may help as well. But a language binding must not effect the core functionalities and lock engine to the methodologies of a specific language in any way. So binding must conform to engine not the other way around IMO.

It's not so much a language binding imposing methodologies of a specific language on the engine so much as the engine imposing the methodologies of a specific language and its binding on other languages and their bindings.
Maybe a little context and history would be useful here.
Historically, most game engines used a proper "scripting" language for game scripting, such as Lua or a custom language built for the engine. These were almost always FILE based scripts - one script per file. And scripts were expected to be small and self contained, essentially "content", and not making use of libraries of functionality beyond that file. The notion was, if something more complicated was needed it would get added to the engine code itself (because in the past engines were custom written on a game-by-game basis).
But in modern times, game engines are far more general purpose, and "scripting" has become less little bits of customized logic in content to pretty much all of the game logic of the game itself. As such, "scripts" are expected to do much more sophisticated things, and thus it makes sense to support the kind of abstractions you would use in traditional "programming" to scale up to more sophisticated code bases - such as using third party libraries, separating code into modules, code-reuse, and so on. But, the file-based methodology that worked well in the past hinders this, IMO.
In my view, the engine should abstract over the specifics of how a language binding handles scripts physically on disk and simply expect the binding to provide it a list of attachable scripts, which the user can then attach to objects in the scene, and let the language binding handle the best way to implement specifics beyond that. For some language bindings, that might be file paths (lua, etc...) or modules/bundles/etc... (python, javascript), or built assemblies (C#, Java, Rust, etc...).

@reduz Some months ago we were discussing this on IRC and IINW you were going to implement this. Is it still planned?

Feature and improvement proposals for the Godot Engine are now being discussed and reviewed in a dedicated Godot Improvement Proposals (GIP) (godotengine/godot-proposals) issue tracker. The GIP tracker has a detailed issue template designed so that proposals include all the relevant information to start a productive discussion and help the community assess the validity of the proposal for the engine.
The main (godotengine/godot) tracker is now solely dedicated to bug reports and Pull Requests, enabling contributors to have a better focus on bug fixing work. Therefore, we are now closing all older feature proposals on the main issue tracker.
If you are interested in this feature proposal, please open a new proposal on the GIP tracker following the given issue template (after checking that it doesn't exist already). Be sure to reference this closed issue if it includes any relevant discussion (which you are also encouraged to summarize in the new proposal). Thanks in advance!


Getting information on what triggers a given extension or other

Is there an option/way for this shader compiler to output reasons for a given extension or another ( GL_ARB_shading_language_420pack for example ) being pulled in?

This is currently not part of the code reflection, if you mean that.
What should such a reflection look like, when you say 'outputing a reason'?
I could think of it like this:
enum ExtensionRequirementReasonFlags {
    EarlyDepthStencil      = (1 << 0),
    MultiDimensionalArrays = (1 << 1),
    ExplicitBinding        = (1 << 2),
    BitwiseOperators       = (1 << 3),
    InitializerList        = (1 << 4),
    /* ... */
};

std::map<std::string, Flags> extensionRequirementReasonMap;

/* ... */

// Add 'initializer list' as reason for the
// "GL_ARB_shading_language_420pack" extension to the flags.
extensionRequirementReasonMap["GL_ARB_shading_language_420pack"] << InitializerList;

Is that what you are asking for?
If you just want to know which extensions or rather GLSL versions are choosen by the compiler for specific language features, take a look at GLSLExtensionAgent.cpp.

What I mean is, could there be some output, either in the console or in the generated shaders, that could explain why a given extension was introduced? It would be helpful to know so that some HLSL shaders can get altered to "fit" an earlier standard of GLSL.
Example of use case: We've got HLSL shaders right now, that by and large get converted to GLSL without any issues, but we have like 8 that need to bring 420 and I'm wondering exactly why that's pulled in, and more specifically which parts of the HLSL shader force 420 to be used.

Ok, as I said there is currently no output from the compiler that tells you what you want to know.
But I can tell you that there are currently only two reasons for the extension GL_ARB_shading_language_420pack you mentioned:

Explicit binding slots (-EB shell option)
Initializer lists, e.g. float2 x = { 1, 2 } instead of float2 x = float2(1, 2)

I think your problem arises from the latter one, because GLSL only supports initializer lists since GLSL 4.20,
but I'm already planning to avoid these initializers.
However, this requires a little more conversion, but I'm working on this ;-)

Baller, thanks for the intel.
The suggestion stands though, but I'll try changing the source shaders to reflect this.

Yes, I think it's a good idea to add this to the code reflection, but only when a specific shader output version is set (e.g. with the -Vout shell option) and extensions are enabled.

The compiler in the master branch now supports translation of initializer lists, to avoid this extension.
However, translation of initializer lists is still restricted, i.e. nested initializers are currently not translated correcty (e.g. { 1, { 1, 2 } } will result in a compiler error).
But maybe I will add your suggestion to the error output, when extensions are disabled, but the version is set too low.
This might look like this in the compiler output:

code generation error : GLSL extension 'GL_EXT_gpu_shader4' or shader output version 'GLSL 1.30' required (required for bitwise operator)
code generation error : GLSL extension 'GL_ARB_shading_language_420pack' or shader output version 'GLSL 4.20' required (required for explicit binding slot)

That would be awesome and grand.

Solved with 4a8e440.
Here is an example:

With commit ead2cbb there are now several warning options.
One is your requested extension feedback, which can be enabled with -Wall or -Wextension.
Use xsc --help for more details.


Misc.: Fixed invalid value, deprecation and test warnings

Fixes the following warnings raised in CI on Windows when running the tests:
venv_test\lib\site-packages\silx\utils\testutils.py:116
  C:\projects\silx-7wjwv\venv_test\lib\site-packages\silx\utils\testutils.py:116: PytestCollectionWarning: cannot collect test class 'TestLogging' because it has a __init__ constructor (from: gui/plot/tools/test/testTools.py)
    class TestLogging(logging.Handler):

gui/plot/test/testPlotWidget.py::TestPlotCurve_Gl::testPlotCurveInfinite
  C:\projects\silx-7wjwv\venv_test\lib\site-packages\silx\gui\plot\backends\glutils\GLPlotCurve.py:1147: RuntimeWarning: invalid value encountered in subtract
    self.yData = (yData - self.offset[1]).astype(numpy.float32)

gui/plot/test/testPlotWidget.py::TestPlotCurveLog_Gl::testPlotCurveErrorLogXY
  C:\projects\silx-7wjwv\venv_test\lib\site-packages\silx\gui\plot\backends\glutils\GLPlotCurve.py:993: RuntimeWarning: invalid value encountered in subtract
    xCoords[3:endXError:4] = self._xData - xErrorMinus

gui/plot/test/testPlotWidget.py::TestPlotCurveLog_Gl::testPlotCurveErrorLogXY
  C:\projects\silx-7wjwv\venv_test\lib\site-packages\silx\gui\plot\backends\glutils\GLPlotCurve.py:1019: RuntimeWarning: invalid value encountered in subtract
    yCoords[endXError+3::4] = self._yData - yErrorMinus

gui/plot3d/test/testSceneWidgetPicking.py::TestSceneWidgetPicking::testPickMeshWithIndices
  C:\projects\silx-7wjwv\venv_test\lib\site-packages\silx\gui\_glutils\utils.py:103: RuntimeWarning: invalid value encountered in true_divide
    barycentric = subVolumes[intersect] / volume[intersect].reshape(-1, 1)

gui/plot3d/test/testSceneWidgetPicking.py::TestSceneWidgetPicking::testPickMeshWithIndices
  C:\projects\silx-7wjwv\venv_test\lib\site-packages\silx\gui\_glutils\utils.py:108: RuntimeWarning: invalid value encountered in true_divide
    t = volAlpha / volume[intersect]  # segment parameter of intersected triangles

gui/plot3d/test/testSceneWindow.py::TestSceneWindow::testHeightMap
  C:\projects\silx-7wjwv\venv_test\lib\site-packages\silx\gui\plot3d\items\image.py:312: DeprecationWarning: `np.int` is a deprecated alias for the builtin `int`. To silence this warning, use `int` by itself. Doing this will not modify any behavior and is safe. When replacing `np.int`, you may wish to use e.g. `np.int64` or `np.int32` to specify the precision. If you wish to review your current use, check the release note link for additional information.
  Deprecated in NumPy 1.20; for more details and guidance: https://numpy.org/devdocs/release/1.20.0-notes.html#deprecations
    data = data[numpy.floor(y * data.shape[0] / height).astype(numpy.int),

gui/plot3d/test/testSceneWindow.py::TestSceneWindow::testHeightMap
  C:\projects\silx-7wjwv\venv_test\lib\site-packages\silx\gui\plot3d\items\image.py:313: DeprecationWarning: `np.int` is a deprecated alias for the builtin `int`. To silence this warning, use `int` by itself. Doing this will not modify any behavior and is safe. When replacing `np.int`, you may wish to use e.g. `np.int64` or `np.int32` to specify the precision. If you wish to review your current use, check the release note link for additional information.
  Deprecated in NumPy 1.20; for more details and guidance: https://numpy.org/devdocs/release/1.20.0-notes.html#deprecations
    numpy.floor(x * data.shape[1] / height).astype(numpy.int)]

gui/plot3d/test/testSceneWindow.py::TestSceneWindow::testHeightMap
  C:\projects\silx-7wjwv\venv_test\lib\site-packages\silx\gui\plot3d\items\image.py:386: DeprecationWarning: `np.int` is a deprecated alias for the builtin `int`. To silence this warning, use `int` by itself. Doing this will not modify any behavior and is safe. When replacing `np.int`, you may wish to use e.g. `np.int64` or `np.int32` to specify the precision. If you wish to review your current use, check the release note link for additional information.
  Deprecated in NumPy 1.20; for more details and guidance: https://numpy.org/devdocs/release/1.20.0-notes.html#deprecations
    rgba = rgba[numpy.floor(y * rgba.shape[0] / height).astype(numpy.int),

gui/plot3d/test/testSceneWindow.py::TestSceneWindow::testHeightMap
  C:\projects\silx-7wjwv\venv_test\lib\site-packages\silx\gui\plot3d\items\image.py:387: DeprecationWarning: `np.int` is a deprecated alias for the builtin `int`. To silence this warning, use `int` by itself. Doing this will not modify any behavior and is safe. When replacing `np.int`, you may wish to use e.g. `np.int64` or `np.int32` to specify the precision. If you wish to review your current use, check the release note link for additional information.
  Deprecated in NumPy 1.20; for more details and guidance: https://numpy.org/devdocs/release/1.20.0-notes.html#deprecations
    numpy.floor(x * rgba.shape[1] / height).astype(numpy.int)]

What's the problem with TestLogging?
If it is because its import triggers tests as test cases class, i think it would be better to rename the class itself to something else, and avoid further similar issues at other places.

Or maybe put a decorator to skip it by default.
I would prefer to rename it, cause even for us it's kind of weird.
For example, LoggingValidator

Yes, because of the Test prefix, when imported directly it is gathered as a test class.
Renaming sounds good to me.


Update lm-eval-harness to support offline evalution for ceval,cmmlu,h…

…ellaswag,mmlu,mathqa,gsm8k

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.同润 seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.


[WIP] Nearest Neighbor Operator

TODOs:

[ ] move into "Operators" package
[ ] update interface of NearestNeighborOperator::apply()
[x] get rid of NearestNeighborOperator::setup() (tree construction part will be common to all point cloud operators, the rest might have to go to the implementation details)
[x] cleanup history
[x] revisit testing of DistributedSearchTree (call copy constructor and assignment operator to improve coverage, define helpers to build trees from std::vector of boxes, etc.)

Codecov Report

Merging #324 into master will decrease coverage by 0.52%.
The diff coverage is 83.33%.

@@            Coverage Diff             @@
##           master     #324      +/-   ##
==========================================
- Coverage   95.71%   95.19%   -0.53%
==========================================
  Files          61       64       +3
  Lines        3595     3745     +150
==========================================
+ Hits         3441     3565     +124
- Misses        154      180      +26

Impacted Files
Coverage Δ

...ion/src/DTK_DetailsNearestNeighborOperatorImpl.hpp
100% <100%> (ø)

...kages/Search/src/details/DTK_DetailsAlgorithms.hpp
100% <100%> (ø)
:arrow_up:

...retization/src/DTK_NearestNeighborOperator_def.hpp
100% <100%> (ø)

...etization/src/DTK_NearestNeighborOperator_decl.hpp
100% <100%> (ø)

...Discretization/test/tstNearestNeighborOperator.cpp
58.73% <58.73%> (ø)

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 2be5a51...8d12811. Read the comment docs.

You also need a rebase on master

@dalg24 anything else you want to do? Otherwise just rewrite the commit messages when necessary and merge the PR.


Gonna close this; please feel free to reopen if it's still happening.


Syn parses 1f32 as syn::Lit::Int.

Expected result would be syn::Lit::Float
Cargo.toml:
syn = { version = "2.0.16", features = ["full"] }

This playground example illustrates the issue: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=bb660e25803da2ea7b4319c71680e126

This is behaving correctly. 1 is lexically a decimal integer literal (https://doc.rust-lang.org/1.70.0/reference/tokens.html#numbers).
Rustc's parser does the same thing as syn.
$ echo 'fn main() { let _ = 1f32; }' | rustc - -Zunpretty=ast-tree
...
                                Expr {
                                    id: NodeId(4294967040),
                                    kind: Lit(
                                        Lit {
                                            kind: Integer,
                                            symbol: "1",
                                            suffix: Some(
                                                "f32",
                                            ),
                                        },
                                    ),
                                    span: <anon>:1:21: 1:25 (#0),
                                    attrs: [],
                                    tokens: None,
                                },
...

That seems like a very strange decision on their end, but thanks for checking!


[building-webpack] Only remove

The current webpack build will remove all

pretty good idea :)
Do you care to take a shot at it?
currently, the removal is a very simple regex in a custom loader.
So you could either try to improve that regex or take the same approach as we use in the modern-config plugin - which use dom5/parse5 (probably simpler?)

Well, the best would be to only remove the dependencies found by the HTML webpack plugin.
I will try to have a look at it.


feat: add swoole 4.8.13 release

update swoole with release 4.8.13

:tada: This PR is included in version 1.81.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


[C# Calc][Cherry-Pick] Improving keyboard support in VariableValueSlider (#1559)

Cherry-Pick: Improving keyboard support in VariableValueSlider (#1559)
Description of the changes:

Fixes #1557
Description of the changes:

In the Slider control, StepFrequency is used by mouse and SmallChange is used by keyboard arrow keys. This change updates > SmallChange to match StepFrequency to align mouse and keyboard behavior.

How changes were validated:

Tested manually

Hi folks,
could you help review this PR? thanks.