Merge Add-on and Stanalone modes

Discussion starting in: https://github.com/davidusb-geek/emhass/issues/262
EMHASS is probably in a sate where we could choose to use the local or external HA API automatically based on API key (SUPERVISOR_TOKEN). Removing the need of passing it via arguments.
Allowing for both Standalone and Add-on modes to merged into one.
This may be something I'll look into when I have some time. I am sure all help will be appreciated.

@davidusb-geek , I see the biggest decision being what we should do with the configuration files. If everyone should move over to the options.json or still have the two.

Yes if this merge is done the best idea would be to just keep one type of conf file. The options.json would make more sense as it is widely the most used along with the add-on.
As for this merge, what would be the consequences for people just using the add-on mode?

Yes if this merge is done the best idea would be to just keep one type of conf file. The options.json would make more sense as it is widely the most used along with the add-on.
As for this merge, what would be the consequences for people just using the add-on mode?

I think there will be any noticeable difference for add-on. It would be more the standalone users adjusting to using options.json.

My thoughts on the steps that would be carried out:

[ ] Integrate auto select local API, based on passed API key and if SUPERVISOR_TOKEN is present.

[ ] Add redundancy. (E.g. if passed API fails, try local)

[ ] Migrate all parameters naming conventions to options.json's?
[ ] Adjust Dockerfiles
[ ] Remove standalone and add-on naming convention on CI/CD
[ ] Adjust Documentation

[ ] Remove all documentation explaining differences between new modes
[ ] Adjust Readme
[ ] Adjust Development pipeline tests

[ ] Add documentation for both EMHASS & EMHASS-Add-on git repos

[ ] Remove config.json all together and hard code defaults?

This is supper ruff. I'll come back to this checklist after some more thought. Please feel free to comment.

It seems like a very complete planning.
We will still need two Dockerfiles right? One in the main emhass git repo and the other one in the add-on repo? At the end they will be fairly similar? Or even the same Dockerfile?

It seems like a very complete planning.
We will still need two Dockerfiles right? One in the main emhass git repo and the other one in the add-on repo? At the end they will be fairly similar? Or even the same Dockerfile?

Good question, I have been thinking about the idea of merging both repos together. (I know it's a long shot)
At the moment the EMHASS-Add-on Dockerfile is pulling EMHASS via pip before it creates the image.
If we don't mind building EMHASS locally for EMHASS-Add-om, I don't believe there will be many reasons why we can't merge the Dockerfiles.

I have been thinking about the idea of merging both repos together.

I don't like the idea of merging the repos. The add-on repo has the structure of a HA add-on repo, while this one has the structure of a Python package. I would like to keep that as I like the option that EMHASS can be used completely independent of HA, you just provide the correct data and it will crunch it and perform the optimization, it doesn't matter if this data comes from HA, a CSV file or a list passed by a REST command.


WIP: To hdf nolink optimization strategies

If you wanted to test behavior you could either explicitly check for the existence of link in the graph or you could compute the dependencies of all keys in the graph and make sure that the max was 1.  The function dask.core.get_deps might be of interest here.

Thanks for the comments, i'll try adding some relevant tests during the weekend.

Fixed the double-linking mistake, added more tests.
Still not satisfied with the tests.

There is one issue i'm bothered with in this solution. it shouldn't prevent merging this solution when i'm done but i feel it should be noted someplace.
when saving to multiple nodes in the same hdf file (which i feel is the best compromise between efficiency and clean output), there's a bottleneck created by all subsequent to_hdf tasks depending on the first.
It might be worth creating a fake "to_hdf" node that will not depend on any input for this case.

That seems reasonable to me

Add max_depth function to dask.core. it uses get_deps to calculate the height of the dependency tree. Its isn't too efficient (won't cache already calculated subtree heights) but it works.
It might warrant it's own tests, now that i think about it.
I'm using the max_depth with to_hdf(compute=False) to calculate the height of the dependency tree to test the number of links in the graph.

I recommend that we move max_depth to utils.py, perhaps just call it depth, and put a toolz.memoize decorator on the inner function to help with caching.  In order to maintain stdlib only on the core lets import toolz within the max_depth function rather than at the utils.py module level.

depth feels too general, what do you think about dask_depth or graph_depth? dep_depth?
I thought because core has all the other dask graph related functions it's a better place, i'll move it once we agree on a name.

Moving depth to utils.py will require importing get_deps from core.py, making sure that's ok because currently utils.py imports only basics and from compatibility.py.

I'm fine with max_depth or whatever you prefer.
I like to keep core.py minimal where possible.  At the moment max_depth is only used for testing and not actual operation.

renamed to dependency_depth and moved to utils.py.
Hope it's alright.
Any more comments? additional tests maybe?

This all seems fine to me

I fear saving to a single file in parallel might result in corruptions, as it's not supported by hdf.
Any ideas how we can easily test this?
passing lock=True to pandas might help, but we don't force or check for that right now.
I'll try testing this at work with a medium unbalanced dataset, hoping it'll reveal those issues.

I was positive pandas or dask had a lock parameter and will handle it if passed, but i can't seem to find it now.
Looks like i'll need to implement a lock before this gets too useful.
it seems that both multiprocessing and multithreading async saves break without a lock.

I've had some trouble fixing segfaults with the current to_hdf tests layout, so i moved some tests a bit and added more tests.
I also made a better default get selector, and commented the reasoning behind it.
writing to multiple hdf files is now optimized (using multiprocessing.get).
writing to multiple nodes simplifies the _link chain so we're able to write partitions as they're ready (instead waiting for all previous partitions), but scheduler is still sync until we have locking available.
writing to a single node is just as it was (defaults to sync, lots of _links).
we can either merge this as is (after adding a NotImplemented) on any value for lock or implement the locking in this PR.
Either way works for me, with a slight tendency towards the former as it carries enough improvements, birds at hand vs bush etc.

Probably to_hdf never got the lock treatment because it was synchronous until now.  I would look towards dask.array.core.store for current conventions on concurrent writes with locks.

Would you prefer delaying this PR until I add locks or should I remove the hardcoded multiprocessing and implement the locks in another PR after this one is merged?

Personally I see significantly more value if this has the locks included.  I can also add these if preferred.

Removed hardcoded dask.multiprocessing.get in favor of locks.
added tests for three schedulers available within dask (get_sync, dask.threaded.get and dask.multiprocessing.get).
There are two issues i'd like guidance for:

I couldn't use locks with the multiprocessing scheduler, and that seems to be the case with dask.array.core.store as well, so I explicitly used lock=False in those. We might want to save the trouble for the user and make lock=False the default when the multiprocessing scheduler is used.

Obviously multiprocessing.get won't work without a lock to when writing to multiple nodes in a single file (simultaneous writes) so i marked that test as expected fail. I also added a similar expected fail test to dask.array.core.store.
These tests sometimes fail with hdf exceptions and sometimes fail silently with erroneous results, so i'll appreciate any fix suggestions and if nothing comes we'll need to explicitly check of this case and raise an exception in to_hdf.

You're correct that threading.Lock objects will fail in multiprocessing.  There are multiprocessing-friendly locks around though.  This was the motivation behind passing an explicit lock into the da.store function.  It allows informed users to use a lock of their choice.

locket.lock_file uses threading.Lock so it's not an easy option.
I'll see what else i can do.

We could also just stick with lock=False and leave this concern for the user, perhaps warning if they're using multiprocessing in an unsafe way?

Yes, when i'll give up i'll add a warning/exception. any preference btw?
Also, should i only check against manually specified multiprocessing.get or should it warn when the default was changed using set_options?
I also wonder if this effects dask.distributed.

there's a third possibility: changing how _link is used in that case (multiprocess to single file with multiple nodes), although it might get messy

I think locks are good now. Failure is due to boto3 update.
We now find out if we're going to use the multiprocessing scheduler, and default to multiprocessing.Manager.Lock instead of Lock imported from threading.
Please make sure this is acceptable. If it is, it might be worth doing elsewhere?

This looks good to me.  +1

Rebase + squash + add forgotten include

I wonder if this issue has been resolved ?

This PR awaits it's merge, afaik. You (and anyone else, actually) are encouraged to suggest changes or offer comments.
I am currently testing this branch in some real use cases at work, and any additional experiments would be greatly appreciated.
This is a performance improvement and not a bugfix, so I won't consider merging it urgent.
I am however anxious to start using it as part of dask but It is my understanding that Matthew is a bit preoccupied this week and i see no reason to rush it.

The delay here was mostly due to my absence last week.  Merging now.

Thanks!

I can confirm that to_hdf works as I would expect, thank you!
P.S. I wonder if there is/will be a dask.dataframe.to_bcolz(...) function ?

@ankravch care to submit a PR for to_bcolz?


Switch from AppHelper to supertest

Took me long enough to catch on that someone else has already developed a proper HTTP request testing framework.
Also contains a minor change to throw an error from RedirectDb.updateProperty() when the specified property is undefined.

Coverage remained the same at 93.717% when pulling 596e0d43087ef01d3a115391311afc29d8a22f95 on supertest into da747d7900059ab1b53bd94caeeffbd04e6d8f62 on master.


Something missing?

Under the header "How retention labels work with retention label policies," there is a bullet under the second figure that seems to be missing something or simply has a typo:
"When you publish retention labels, they're included in a retention label policy. Retention label names are immutable, which means that they and cannot be edited after they're created."
"...which means that they and...." ?

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

ID: 315ad620-438b-dae8-26df-258406e97152
Version Independent ID: 6850f86a-00b4-cc5d-b1eb-ae48d5f7025a
Content: Overview of retention labels - Microsoft 365 Compliance
Content Source: microsoft-365/compliance/labels.md
Service: o365-seccomp
GitHub Login: @cabailey
Microsoft Alias: cabailey

@ferrety2006  Hi, thanks for reporting this.  It is indeed just a typo that we all missed until now. I'll make sure it gets fixed with a pending revision.  Should read "When you publish retention labels, they're included in a retention label policy. Retention label names are immutable, which means that they cannot be edited after they're created"


Fix wrong test method name in RUM config tests

Codecov Report

Merging #793 (1207740) into master (b9aa4ac) will increase coverage by 0.11%.
The diff coverage is n/a.


Bug in example: turn_based

The turn_based example scene doesn't run with F6.
There's a parser error. You're using id as a variable in the for loop when it has already been declared earlier in the function (redraw_movement_access).
3.2.3

I see it was fixed on master :slightly_smiling_face: With the recent changes in the project's structure, maybe it is time we release a new version on the asset store.
I think @MatejSloboda has the rights for this ?

I see it was fixed on master :slightly_smiling_face: With the recent changes in the project's structure, maybe it is time we release a new version on the asset store.
I think @MatejSloboda has the rights for this ?

There's a bug in the project_example too. I had it crash out when I was clicking around with the dragon:

I've tried replicating with a few hundred clicks but it seems to have been one of those annoying rare bugs. :-(
Figured I'd raise it here so you're aware of it. Feel free to create a new issue if you want.

There's a bug in the project_example too. I had it crash out when I was clicking around with the dragon:

I've tried replicating with a few hundred clicks but it seems to have been one of those annoying rare bugs. :-(
Figured I'd raise it here so you're aware of it. Feel free to create a new issue if you want.

good call, closing this as there's a new issue specifically for the bug unfixed ;)

good call, closing this as there's a new issue specifically for the bug unfixed ;)


Encryption Scope SAS

Adding encryption sas to blob, account, and identity sas

[x] The purpose of this PR is explained in this or a referenced issue.
[x] The PR does not update generated files.

These files are managed by the codegen framework at Azure/autorest.go.

[ ] Tests are included and/or updated for code changes.
[ ] Updates to CHANGELOG.md are included.


Event-info Plugin

This represents my work in progress for the event-info plugin.

Okay so there is a slight snag but it does not break binary compatibility in any way.
So like when an execution is performed in AWS it sends an input argument (from the remote end), to the method being invoked. When I designed it initially I had passed the value in but then I removed that passing of the value because when it comes to how lambdas and such work in Java, it was not actually needed at all by the IOpipeService class. Since event info will be needing this object to determine if it is a tracked event it has to be passed into the run() method.
Now, since in the normal case the user would extend SimpleRequestHandlerWrapper and SimpleRequestStreamHandlerWrapper we can pass this object through to run() without needing to have any user code changed at all. So this is no issue here.
However, if a user is using IOpipeService manually (like in the ManualHello example) then this extra object will need to be passed to the run() method.
My goal is to add an extra run() method which takes an extra argument that allows the input value to be exposed by IOpipeExecution (which is how the plugin would use it). Then the current run() method would just call the newly created one, so any manual service users will still have working code. However, the event-info plugin would be unable to detect where it came from unless their code is slightly adjusted as such.
So those using SimpleRequestHandlerWrapper and SimpleRequestStreamHandlerWrapper will automatically benefit from event-info, while those directly using IOpipeService will need to modify their code accordingly.

@XerTheSquirrel Why are arguments/variables prefixed with __? Is it to signify that they're private? Is this a Java idiom in addition to an explicit private?

@kolanos It is just a naming scheme so that input argument so that I know which variables come from method arguments. As for the _ on private it is mixed as to whether this is used or not.


Alternative to covers.

Describe the feature you'd like to have added
I know that a request for covers was already put in, and I would be happy with that. But I was thinking it would be nice to have a 'camouflage card' that you could put in and hand a block, and the laserio node would take on the appearance of that block. For advanced camouflage one could specify up to six blocks, and have a different texture on each side.
Additional information
No response

Its a cool idea I'll take under advisement, but its a lot of complexity to add :).  For now I'm gonna hold off, but maybe some day!


connection error displays username password

Connection error message shows username and password.
Running php 7.2, easydb 2.8.0.

Update to v2.9.0, and change your code to use the new Factory method:
- Factory::create($dsn, $username, $password, $options);
+ Factory::fromArray([$dsn, $username, $password, $options]);


(Do Not Merge) Testing refs

Trying to reproduce bot error in #749 with refs for file sizes (Chrome only)

@pdfjsbot test

@pdfjsbot makeref


Wrong Result from Tiflash when process Time

Bug Report
Please answer these questions before submitting your issue. Thanks!
1. Minimal reproduce step (Required)

Drop table if exists t1;
CREATE TABLE t1 (
    id INT PRIMARY KEY AUTO_INCREMENT,
    col1 TIME DEFAULT NULL
);

insert into t1 values(1, '838:59:59');
insert into t1 values(2, '-838:59:59');
insert into t1 values(3, '0');
ALTER TABLE t1 SET TIFLASH REPLICA 1;

2. What did you expect to see? (Required)
I find that the returned information is inconsistent across two queries.
3. What did you see instead (Required)
mysql> SELECT /*+ READ_FROM_STORAGE(TIFLASH[t1]) */
    ->     id,
    ->     col1,
    ->     ADDDATE(col1, INTERVAL 12 HOUR_MINUTE) AS updated_col1,
    ->     CASE
    ->         WHEN ADDDATE(col1, INTERVAL 12 HOUR_MINUTE) IS NULL THEN 'NULL VALUE'
    ->         ELSE 'VALID VALUE'
    ->     END AS value_status,
    ->     LENGTH(col1) AS col1_length,
    ->     CONCAT(ADDDATE(col1, INTERVAL 12 HOUR_MINUTE), ' processed') AS processed_value
    -> FROM
    ->     t1
    -> WHERE
    ->     ADDDATE(col1, INTERVAL 12 HOUR_MINUTE) IS NOT NULL;
+----+------------+--------------+--------------+-------------+----------------------+
| id | col1       | updated_col1 | value_status | col1_length | processed_value      |
+----+------------+--------------+--------------+-------------+----------------------+
|  1 | 838:59:59  | 839:09:59    | VALID VALUE  |           9 | 839:11:59 processed  |
|  2 | -838:59:59 | -838:49:59   | VALID VALUE  |          10 | -838:47:59 processed |
|  3 | 00:00:00   | 00:10:00     | VALID VALUE  |           8 | 00:12:00 processed   |
+----+------------+--------------+--------------+-------------+----------------------+
3 rows in set (0.04 sec)

mysql> SELECT /*+ READ_FROM_STORAGE(TIKV[t1]) */
    ->     id,
    ->     col1,
    ->     ADDDATE(col1, INTERVAL 12 HOUR_MINUTE) AS updated_col1,
    ->     CASE
    ->         WHEN ADDDATE(col1, INTERVAL 12 HOUR_MINUTE) IS NULL THEN 'NULL VALUE'
    ->         ELSE 'VALID VALUE'
    ->     END AS value_status,
    ->     LENGTH(col1) AS col1_length,
    ->     CONCAT(ADDDATE(col1, INTERVAL 12 HOUR_MINUTE), ' processed') AS processed_value
    -> FROM
    ->     t1
    -> WHERE
    ->     ADDDATE(col1, INTERVAL 12 HOUR_MINUTE) IS NOT NULL;
+----+------------+--------------+--------------+-------------+----------------------+
| id | col1       | updated_col1 | value_status | col1_length | processed_value      |
+----+------------+--------------+--------------+-------------+----------------------+
|  2 | -838:59:59 | -838:47:59   | VALID VALUE  |          10 | -838:47:59 processed |
|  3 | 00:00:00   | 00:12:00     | VALID VALUE  |           8 | 00:12:00 processed   |
+----+------------+--------------+--------------+-------------+----------------------+
2 rows in set, 1 warning (0.04 sec)

4. What is your TiDB version? (Required)

TiDB v8.4.0

/label affects-8.5

/label affects-8.4

I have found some additional bugs in TiFlash, which have been submitted in the TiDB repository. Could you please help check them as well? Thanks a lot, @JaySon-Huang.

The "updated_col1" value in tiflash is "00:12:00" instead of "00:10:00" with latest version, do I miss anything? @Dylan0222

I’m very sorry for my mistake. It is indeed 00:12:00, but there is one more row compared to TiKV. I will update the above information.

Tikv returns only two rows with the warning:
evaluation failed: Duration value is out of range in '(838:59:59 - 00:12:00)'
Check that mysql return two rows also, with warning:
Datetime function: time field overflow
And according to MySQL document, time data type should have a valid range: https://dev.mysql.com/doc/refman/8.4/en/time.html#:~:text=MySQL retrieves and displays TIME values in 'hh%3Amm%3Ass' format (or 'hhh%3Amm%3Ass' format for large hours values). TIME values may range from '-838%3A59%3A59' to '838%3A59%3A59'.
Thus, tiflash needs to be consistent with this behavior.

Tikv returns only two rows with the warning: evaluation failed: Duration value is out of range in '(838:59:59 - 00:12:00)' Check that mysql return two rows also, with warning: Datetime function: time field overflow And according to MySQL document, time data type should have a valid range: https://dev.mysql.com/doc/refman/8.4/en/time.html#:~:text=MySQL retrieves and displays TIME values in 'hh%3Amm%3Ass' format (or 'hhh%3Amm%3Ass' format for large hours values). TIME values may range from '-838%3A59%3A59' to '838%3A59%3A59'. Thus, tiflash needs to be consistent with this behavior.

But TiKV returns three rows. I believe that to maintain consistency with MySQL, both two engines should align and behave compatibly？


⚠ Bofrost.de has degraded performance

In e3f0dbe, Bofrost.de (https://www.bofrost.de) experienced degraded performance:

HTTP code: 200
Response time: 1508 ms

Resolved: Bofrost.de performance has improved in af107fe after 1 hour, 5 minutes.


Users/jikuma/docker tasks npm shrinkwrap

take or close

completed through another PR. Abandoning this PR.


feat: v18 upgrade handler logic to store the ID of the last V1 price range pool

Context
As part of lowering our min spot price to 10^-30 (V2), we will continue to support the existing pools with 10^-12 (V1) to avoid migrations.
As a result, we need to snapshot the last V1 pool ID in the upgrade handler
A/C

Design implemented
Upgrade handler tests

Superceeded by SF position migration:
https://hackmd.io/FrJNXgqySVyCxorFmNzgAA


chore: use ioutil

What type of PR is this?
chore
Check the PR title.

[x] This PR title match the format: <type>(optional scope): <description>
[x] The description of this PR title is user-oriented and clear enough for others to understand.

(Optional) Translate the PR title into Chinese.

使用 ioutil 避免 go 1.15 编译失败

Which issue(s) this PR fixes:

Does this pr completed revert the api changes in https://github.com/cloudwego/hertz/pull/508/files?
Seems changes in TestRouteStaticFile are missing, and not sure if there has any other missing revert?

TestRouteStaticFile

add go 1.15 ci to check

Very awkward...Does the new CI support ignore the "unused" issue in _test.go? @wzekin


adding a 3rd parameter to saveAs to allow other mimeTypes, such as im…

…age/jpeg.

Coverage decreased (-0.002%) to 3.856% when pulling f06f45f2aee40ea9c6a6583f5c841fb042906f4b on leonardorame:master into 5bd6175e39a090cc93c9c493352cee2d52d5a91d on chafey:master.

Hi Erik, could you review this again?.

Thanks!


Improved Rainclouds API

Description
This improves three related things about the current PR for rainclouds to make it behave more like all of the other plot recipes:

It makes the API more consistent with that of boxplot and violin: now you pass in a list of labels (integers or strings), one for each data point, and a flat array of data points.

It presumes that the color argument labels all data points rather than each category separately.

It implements the dodge keyword argument.

In addition to being a little more predictable from a user perspective, it also means that rainclouds works when calling it from AlgebraOfGraphics.
I updated some docs/NEWS.md which the original PR hadn't yet addressed.
Type of change
Delete options that do not apply:

[x] New feature (non-breaking change which adds functionality)

Checklist

[x] Added an entry in NEWS.md (for new features and breaking changes)
[x] Added or changed relevant sections in the documentation
[ ] Added unit tests for new algorithms, conversion methods, etc.
[ ] Added reference image tests for new plotting functions, recipes, visual options, etc.

I'm merging this into the other branch to get the tests etc running!


Nightly 2020-04-08 broke the v0.9.5 builds

latest update on 2020-04-08, rust version 1.44.0-nightly (42abbd887 2020-04-07)

It looks like with this nightly ver. builds might have been failing.
I haven't had deep look at that but it seems like overarching lifetimes are the issue.
error[E0495]: cannot infer an appropriate lifetime for lifetime parameter `'a` due to conflicting requirements
##[error]  --> /home/runner/.cargo/registry/src/github.com-1ecc6299db9ec823/proptest-0.9.5/src/arbitrary/_core/iter.rs:47:23
   |
47 |         base.prop_map(Iterator::cloned).boxed()
   |                       ^^^^^^^^^^^^^^^^
   |
note: first, the lifetime cannot outlive the lifetime `'a` as defined on the impl at 36:9...
  --> /home/runner/.cargo/registry/src/github.com-1ecc6299db9ec823/proptest-0.9.5/src/arbitrary/_core/iter.rs:36:9
   |
36 |         'a,
   |         ^^
note: ...so that the types are compatible
  --> /home/runner/.cargo/registry/src/github.com-1ecc6299db9ec823/proptest-0.9.5/src/arbitrary/_core/iter.rs:47:23
   |
47 |         base.prop_map(Iterator::cloned).boxed()
   |                       ^^^^^^^^^^^^^^^^
   = note: expected  `&'a T`
              found  `&T`
   = note: but, the lifetime must be valid for the static lifetime...
note: ...so that the type `strategy::map::Map<S, fn(A) -> core::iter::Cloned<A> {<A as core::iter::Iterator>::cloned::<'_, T>}>` will meet its required lifetime bounds
  --> /home/runner/.cargo/registry/src/github.com-1ecc6299db9ec823/proptest-0.9.5/src/arbitrary/_core/iter.rs:47:41
   |
47 |         base.prop_map(Iterator::cloned).boxed()
   |                                         ^^^^^

error: aborting due to previous error

The regression was reported to rust-lang/rust in https://github.com/rust-lang/rust/issues/70917.

I've published 0.9.6, and https://github.com/AltSysrq/proptest/pull/187 also merges the fix there into master.

Thanks


Fail to train in multi gpu

Hi,
i can try the codec model in single gpu, but i cannot train it in multigpu mode. the log is
the env is
CUDA Version: 12.2
alias-free-torch         0.0.6
pytorch-wpe              0.0.1
torch                    1.13.1
torch-complex            0.4.3
torchaudio               0.13.1
torchvision              0.14.1

the main log is
./run_freqcodec.sh: gpu_num: 2
stage 3: Training
log can be found at ./exp/freqcodec_mag_phase_16k_n32_600k_step_ds640/log/train.log.0

the detail log is
-rw-rw-r-- 1 test test   0 Jan 18 11:07 train.log.0
-rw-rw-r-- 1 test test 884 Jan 18 11:07 train.log.1

cat train.log.1
Traceback (most recent call last):
  File "/home/test/python_env/anaconda3/envs/fun_codec/lib/python3.8/runpy.py", line 194, in _run_module_as_main
    return _run_code(code, main_globals, None,
  File "/home/test/python_env/anaconda3/envs/fun_codec/lib/python3.8/runpy.py", line 87, in _run_code
    exec(code, run_globals)
  File "/home/test/code/enhance/FunCodec/funcodec/bin/codec_train.py", line 32, in <module>
    torch.cuda.set_device(args.gpu_id)
  File "/home/test/python_env/anaconda3/envs/fun_codec/lib/python3.8/site-packages/torch/cuda/__init__.py", line 326, in set_device
    torch._C._cuda_setDevice(device)
RuntimeError: CUDA error: invalid device ordinal
CUDA kernel errors might be asynchronously reported at some other API call,so the stacktrace below might be incorrect.
For debugging consider passing CUDA_LAUNCH_BLOCKING=1.

Thanks for your report, this issue cased by the different torch version for DDP. You can try comment line 32 at funcodec/bin/codec_train.py as follows:
torch.cuda.set_device(args.gpu_id)


Document ways to use sprites generated by loader

See #122 for more context.
E.g.

<use>
image in css, html, etc

@kisenka anything else?

Interoperability with:

css-loader
extract-text-webpack-plugin
html-webpack-plugin
Vue.js (see #125)
React

FAQ (TODO)
Extract configuration from README and move to docs folder

Further transpilation for custom runtime generators, see https://github.com/kisenka/svg-sprite-loader/issues/128#issuecomment-304345220

Clarify docs about using loader with style-loader (see #127)
Clarify docs about importing 1 image in both ways: runtime and from CSS

https://github.com/kisenka/svg-sprite-loader/issues/139#issuecomment-314093040

https://github.com/kisenka/svg-sprite-loader/issues/151#issuecomment-314107776

Update examples list

#142

Importing image from JS and from CSS works only in extract mode (#113)

Using with style-loader (#193)

Serve external sprite properly #143

Destroy symbol via JS API #202

Using with require.context

#149

Use publicPath property #215


Stuck with discovering any new versions of pivnet-product : install-pks pipeline.

preparing build
checking pipeline is not paused
checking job is not paused
discovering any new versions of pcf-pipelines-utils
_**discovering any new versions of pivnet-product
waiting for a suitable set of input versions**_
    pivnet-product - no versions satisfy passed constraints
checking max-in-flight is not reached

Make sure that you have your pivnet token filled out correctly in the params file.
Also, please check the latest README with notes about usage of  pks_params.yml, for the upcoming PKS 1.1.* tile, and `pks_params_1.0.yml, which is for PKS v1.0..
For v1.1., note that at this moment, it is only available for Pivotal internal groups for tests. For you to verify if you have access, login to the Pivotal Network website, search for PKS and verify which versions are available for your user ID. If you don't see version 1.1.* in there, then, for the moment, use the params file for v1.0.*.

Also, check the output of the product_release resource in the pipeline. It can tell you if there is any error happening as it tries to get the pivnet release files.

Thank you so much. Pivnet tokens were correct but it was stuck with PKS 1.1 which is not released to public yet. after changing to 1.0 version of PKS tile, it resolve the issue.


New SSG Feature: Support --config with JSON config file

Hello,
I would like to add a new feature to SSGifier. Through this new feature, it would be able to support the Config file with the
--config flag.
Here is the list of the changes I would implement, as described in the Lab 4 instructions:

The -c or --config flags accept a file path to a JSON config file.
If the file is missing, or can't be parsed as JSON, exit with an appropriate error message.
If the -c or --config option is provided, ignore all other options (i.e., a config file overrides other options on the command line).
The program should ignore any options in the config file it doesn't recognize. For example, if the SSG doesn't support stylesheets, ignore a stylesheet property.
If the config file is missing any options, assume the usual defaults. For example, use dist/ as the output directory if it isn't specified.

I will reach out to you via Slack.

Thank you very much for the contribution, but this feature has already been added. I will close this issue and hope we can collaborate in the future iterations.


Add version and commit revision metadata to operator metadata

This allows the operator to be upgraded by applying the new templates,
which will also update any operands like the address space controller,
authentication service and console.

@enmasse-ci run tests profile=upgrade

:heavy_exclamation_mark: Build Failed :heavy_exclamation_mark:

@enmasse-ci run tests profile=upgrade

:heavy_check_mark: Test Summary :heavy_check_mark:
TEST_PROFILE: upgrade
TEST_CASE:
TOTAL: 27
PASS: 25
FAIL: 0
SKIP: 2
BUILD_NUMBER: 986
BUILD_ENV: oc cluster up

@enmasse-ci run tests profile=shared

@k-wall We could do that, but it would mean that if a new image for address-space-controller was created with a major.minor tag (but would contain different revision), and it was restarted with the new revision, it would potentially end up auto-restart the router and broker as well, removing the 'choice' of when to do the restart of the messaging infrastructure. However, from what I can tell, it would not apply the new templates unless the infra configs or address space have changed, so it could be it would work as before.

:heavy_check_mark: Test Summary :heavy_check_mark:
TEST_PROFILE: upgrade
TEST_CASE:
TOTAL: 27
PASS: 25
FAIL: 0
SKIP: 2
BUILD_NUMBER: 994
BUILD_ENV: oc cluster up

:x: Test Summary :x:
TEST_PROFILE: shared
TEST_CASE:
TOTAL: 231
PASS: 216
FAIL: 2
SKIP: 13
BUILD_NUMBER: 990
BUILD_ENV: oc cluster up
:heavy_exclamation_mark: Test Failures :heavy_exclamation_mark:

testGoneAwayPageAfterConnectionClose in io.enmasse.systemtest.shared.standard.web.FirefoxConsoleTest
testConnectionClose in io.enmasse.systemtest.shared.standard.web.FirefoxConsoleTest

Sorry, I take back my suggestion - I think it makes for confusion.  The revision and version will only ever correspond to the operator's build, this is fine for address space controller/console/authservice since the operator is directly responsible for these deployments.  This is not the case where the admin/route/broker.  If we were to say the rev address space controller image or the standard-controller image. the propagated information would be stale.  It could lead someone to conclude that then update hadn't worked.
I suggest popping off the last commit. Sorry!


Contacts for Cashu & Private message

Description
Create a management of Contacts with NIP-5 and Nostr address.
This component need to be added in the Private message, and Cashu Wallet.
We already have the types and storage to used for the Contact type. We used Localstorage atm.
Screens of what we need to have:

I am applying to this issue via OnlyDust platform.
My background and how it can be leveraged
As a Computer Science graduate with practical expertise in JavaScript and TypeScript, I'm enthused about this frontend development opportunity. My expertise includes experience with online apps and state management, which complements this contact management capability.
How I plan on tackling this issue
Starting with the existing contact types and localStorage implementation, I'd design a modular component structure that could be shared by the Private Message and Cashu Wallet interfaces. I intend to build a clean UI for contact management that will handle both NIP-5 and Nostr addresses with correct validation. The system would contain:
Contact list view with search functionality.
Create/edit contact forms with field validation.
Seamless connection with the existing local storage structure.
Responsive design for desktop and mobile devices

I am applying to this issue via OnlyDust platform.
My background and how it can be leveraged
Hi, I'm part of Dojo Coding. For this task, I will create a contact management component that supports NIP-5 and Nostr addresses. The component will be integrated into the Private Messaging and Cashu Wallet sections. I'll make use of the existing contact types and local storage as shown in the provided designs. The functionality will include adding, removing, and viewing contacts, ensuring a smooth user experience while handling Nostr profiles and related data.

I am applying to this issue via OnlyDust platform.
My background and how it can be leveraged
i have experience in blockchain previously as personal projects and OS, so hoping to make use of them here and mark my first odhack contribution

I am applying to this issue via OnlyDust platform.
My background and how it can be leveraged
I'm from dojo coding with 2 year of experience in differents backend Developer lenguage
How I plan on tackling this issue

User clicks “Add Contact”.

User fills in the details (Name, NIP-5, Nostr Address).

Data is validated and saved in LocalStorage.

Contacts List is updated with the new contact.

Selecting Contact in Private Messages or Wallet:

User opens the contact picker when sending a message or transaction.

Contacts stored in LocalStorage are displayed.

Upon selection, the Nostr address is automatically populated for the message or transaction.

I am applying to this issue via OnlyDust platform.
My background and how it can be leveraged
Software Engineer with 10 years of experience. For the past 5 years, I’ve specialized in HR Tech solutions, now used by tens of thousands of companies and hundreds of thousands of users. I have also contributed to open source development at OnlyDust (My OnlyDust Profile).
I’m passionate about exploring new technologies and currently looking to deepen my expertise in blockchain, smart contracts, and decentralized applications.
How I plan on tackling this issue
First, I will review the existing data types and how contacts are stored in LocalStorage. Then, I will create an interface to manage contacts with support for NIP-5 and Nostr addresses. After that, I will integrate this component into the Private Message and Cashu Wallet sections. Finally, I will conduct testing to ensure everything works correctly.

I am applying to this issue via OnlyDust platform.
My background and how it can be leveraged
I have extensive experience in front-end development, particularly in building user interfaces that manage and display data effectively. My work with blockchain applications has equipped me with the skills to handle address management and local storage efficiently.
How I plan on tackling this issue
I will implement a contacts management component by leveraging existing types and local storage for data persistence. This will involve creating a user-friendly interface within the Private Message and Cashu Wallet sections to add, view, and manage contacts with NIP-5 and Nostr addresses. I will ensure the design aligns with the current application style, followed by thorough testing to guarantee functionality and usability.

I am applying to this issue via OnlyDust platform.
My background and how it can be leveraged
I am go dev. A new-comer here, willing and ready to contribute to contribute to solve the issue.


starlark: drop support for dict+dict

This feature (which Python does not have) has been deprecated for a long time.

@laurentlb

Thanks!


python310Packages.flax: 0.5.2 -> 0.6.0

Description of changes
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[x] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
22.11 Release Notes (or backporting 22.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

Fixes https://github.com/NixOS/nixpkgs/issues/187044

Result of nixpkgs-review pr 187267 run on x86_64-linux 1

4 packages failed to build:

python310Packages.elegy
python310Packages.treex
python39Packages.elegy
python39Packages.treex

6 packages built:

python310Packages.dalle-mini
python310Packages.flax
python310Packages.vqgan-jax
python39Packages.dalle-mini
python39Packages.flax
python39Packages.vqgan-jax


The non-scaffolded razor page "Register" does not recognise Password.RequiredLength.

Describe the bug
Setting password length through
public void ConfigureServices(IServiceCollection services){
  ...
  services.Configure<IdentityOptions>(options =>
  {
    options.Password.RequiredLength = 1;
  });
  ...

does not change the non-scaffolded razor page as it always says "The Password must be at least 6 and at max 100 characters long." if inputed password is < 6 characters.
To Reproduce
Steps to reproduce the behavior:

Create a new ASP.NET Core Web 2.1 application
Select "Web application (Model-View Controller)"
Select "Change authentication"
3.1. Select "Individual User Account"
Select Ok to have the project scaffolded.
Open file Startup.cs
Add

services.Configure<IdentityOptions>(options =>
{
  options.Password.RequiredLength = 1;
});

to method ConfigureServices.
7. Press F5 (or select your favourite start-debug method).
8. In the web browser that pops up
8.1. Select Register
8.2. Type<EMAIL_ADDRESS>as user name (or select your favourite fast-to-type email addresss).
8.3. Type "a" as password (or any password shorter than 6 characters).
8.4. Select Register
Expected behavior
The web page should have been updated with information about successful creation of user.
Actual behaviour
The web page says "The Password must be at least 6 and at max 100 characters long."
Additional context
I have a question at stack overflow https://stackoverflow.com/questions/53620708/how-do-i-set-password-options-in-aspnet-core-2-1 that explains the same issue if this is not clear enough.
This issue might be duplicate of #774.

Yeah its a dupe of #774 same issue, the UI has a model validation attribute which controls that error message, while the IdentityOptions is configuring identity itself

Does this mean the suggested solution would be to scaffold out the 4 pages and change the StringLength attribute?

Yep exactly

Thanks for the confirmation.


version metadata for 6.0.0 beta 2

We are hoping to release another beta in a few days.
As far as I know, this is the version metadata necessary? i.e. everything is version 6.0.0 beta 2

My thoughts on the separate package versions are that they are 2 distinct packages, and we shouldn't be updating the models package that often. So controlling this version separately reduces package version proliferation in the wild, it's a small burden here vs a larger burden to consumers.
That said, I don't feel that strongly about it, and happy to hear your thoughts.

I see the point, though we do have a change to the Message class here and we should indicate that this version of the Models package works with JustSaying v6.

I'm not great with semver, but wouldn't that be a minor release, as it's not breaking for current consumers?

KISS. In general the messaging that "JustSaying v6 matches JustSaying.Models v5.1" is IMHO imposing too much cognitive load and reading of docs on consumers. People will understand what matches if they both have version 6.0. They likely won't understand anything else.


feat: added explanatory text to Settings Keyboard Shortcuts

Checklist:

[x] I have read and followed the contribution guidelines.
[x] I have read and followed the how to open a pull request guide.
[x] My pull request targets the main branch of freeCodeCamp.
[x] I have tested these changes either locally on my machine, or GitPod.

Closes #47517

Everything looks good to me. The only thing is that the text inside the modal is centred to the right instead of the usual left. Please feel free to fix this too in a different pull-request.

It doesn't make sense to show it in the modal, to be honest. You have to enable keyboard shortcuts AND use the key combination to even see the modal.
It should only show the text in the settings page, IMHO.

I made the changes, please take a look


Converting joint positions to pixelvalues

Hello,
I do not have an issue but more a question.  I still hope this is the right place to ask those, if not please let me know
I use the offline_processor sample to extract the body joint positions from a mkv File. After that I want to compare the detected points with annotated shoulder data. For that I use Python.
I try to match the joint points of the azure kinect body tracking Algorithm to the depth image. The thing is, that the coordinates of the joints are in x,y,z. So far I tried to match it like so: I use NFOV unbinned mode with a resolution of 640x576 and a angle $$\alpha$$ of 75x65

Get distance to joint

calculate the pixel resolution for every axis of that distance in mm/pixel. With this formula:

Transform   and    from milimeters to pixelvalues according to factor calculated in step 2.

Transform the coordinates from Azure Kinect coordinate system to picture coordinate system like so:

plot the points.

The coordinate system of the azure kinect has the origin at the center of the frame. My image has the origin at the top-left corner of the image. So the transformation in step 4 should be correct.
Also according to the official documentation the joint position and orientation are estimates relative to the global depth sensor frame of reference. That means it uses the same coordinate system like the depth sensor right?
The coordinate system from the depth sensor is also tilted down 6° and if I correct for half of that I get better results but it does feel arbitrary. Do I have to correct for that tilt?
Am I missing something important? Picture two is taken from the simple sample programm and if you compare it with my picture it becomes evident that my coordinates are not correct.
Any help is greatly appreciated. Thanks
EDIT: Now i tried to implement the convert_3d_to_2d option from https://github.com/etiennedub/pyk4a but I could not get it to work.  If someone has input on that side I would also appreciate it.

Hi. The kinect sdk provides apis that can do this https://docs.microsoft.com/en-us/azure/kinect-dk/use-calibration-functions#convert-between-2d-and-3d-coordinate-systems
And since it is open source, you can see the code and algorithms that those API use in this git repo.

Tanks alot.

Hello, I do not have an issue but more a question. I still hope this is the right place to ask those, if not please let me know
I use the offline_processor sample to extract the body joint positions from a mkv File. After that I want to compare the detected points with annotated shoulder data. For that I use Python.
I try to match the joint points of the azure kinect body tracking Algorithm to the depth image. The thing is, that the coordinates of the joints are in x,y,z. So far I tried to match it like so: I use NFOV unbinned mode with a resolution of 640x576 and a angle α of 75x65

Get distance to joint
    [

        ![jointz](https://user-images.githubusercontent.com/82642606/114997318-fb6ac800-9e9f-11eb-9871-7f5aeed35ae3.gif)
      ](https://user-images.githubusercontent.com/82642606/114997318-fb6ac800-9e9f-11eb-9871-7f5aeed35ae3.gif)

      [

      ](https://user-images.githubusercontent.com/82642606/114997318-fb6ac800-9e9f-11eb-9871-7f5aeed35ae3.gif)

calculate the pixel resolution for every axis of that distance in mm/pixel. With this formula:
    [

        ![formel1](https://user-images.githubusercontent.com/82642606/114997114-ceb6b080-9e9f-11eb-93a4-723f749011e1.gif)
      ](https://user-images.githubusercontent.com/82642606/114997114-ceb6b080-9e9f-11eb-93a4-723f749011e1.gif)

      [

      ](https://user-images.githubusercontent.com/82642606/114997114-ceb6b080-9e9f-11eb-93a4-723f749011e1.gif)

Transform
    [

        ![jointx](https://user-images.githubusercontent.com/82642606/114997354-06255d00-9ea0-11eb-8554-98dc6d6ab62e.gif)
      ](https://user-images.githubusercontent.com/82642606/114997354-06255d00-9ea0-11eb-8554-98dc6d6ab62e.gif)

      [

      ](https://user-images.githubusercontent.com/82642606/114997354-06255d00-9ea0-11eb-8554-98dc6d6ab62e.gif)

    and  ![jointy](https://user-images.githubusercontent.com/82642606/114997402-14737900-9ea0-11eb-9389-360f85537acf.gif)

    [

        ![jointy](https://user-images.githubusercontent.com/82642606/114997402-14737900-9ea0-11eb-9389-360f85537acf.gif)
      ](https://user-images.githubusercontent.com/82642606/114997402-14737900-9ea0-11eb-9389-360f85537acf.gif)

      [

      ](https://user-images.githubusercontent.com/82642606/114997402-14737900-9ea0-11eb-9389-360f85537acf.gif)

    from milimeters to pixelvalues according to factor calculated in step 2.

Transform the coordinates from Azure Kinect coordinate system to picture coordinate system like so:

    [

        ![pixelcount](https://user-images.githubusercontent.com/82642606/114997617-56042400-9ea0-11eb-8a45-f349920131ef.gif)
      ](https://user-images.githubusercontent.com/82642606/114997617-56042400-9ea0-11eb-8a45-f349920131ef.gif)

      [

      ](https://user-images.githubusercontent.com/82642606/114997617-56042400-9ea0-11eb-8a45-f349920131ef.gif)

plot the points.

The coordinate system of the azure kinect has the origin at the center of the frame. My image has the origin at the top-left corner of the image. So the transformation in step 4 should be correct.
Also according to the official documentation the joint position and orientation are estimates relative to the global depth sensor frame of reference. That means it uses the same coordinate system like the depth sensor right?
The coordinate system from the depth sensor is also tilted down 6° and if I correct for half of that I get better results but it does feel arbitrary. Do I have to correct for that tilt?
Am I missing something important? Picture two is taken from the simple sample programm and if you compare it with my picture it becomes evident that my coordinates are not correct.
Any help is greatly appreciated. Thanks
EDIT: Now i tried to implement the convert_3d_to_2d option from https://github.com/etiennedub/pyk4a but I could not get it to work. If someone has input on that side I would also appreciate it.

hi. pingopalino1
Can I get an "offline_processor" written in python from you?
thank you


thx...

I'm learning...

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

ID: 8246b90a-efb1-03ce-f642-d3eb2441fc30
Version Independent ID: 2fdd20ef-7bd3-57bc-7957-93f4bb5377ce
Content
Content Source
Service: multiple

not able to download this MSI file

@derekbekoe - We're still experiencing problems with downloads, even though the windows MSI download links now point directly to azure-cli-latest.msi. Could this be due to region, firewall, or proxy blocking on the customer end?

@bharat19th please add your comments to https://github.com/Azure/azure-docs-cli-python/issues/607.
@sptramer we should close this issue.

Closing in favor of #607.


Restructure: Rename to dotnet-publish and rewrite for packit

Background
The buildpack builds dll files with the dotnet publish command that are  executed by the dotnet-core-conf buildpack.
Proposal
In order to conform the the restructure rfc, this buildpack should

Be rewritten to be packit compliant
Be renamed to dotnet-publish as that is a more descriptive name.

For now we should keep all functionality the same.
Note:
Make sure to go through the rest of the README's in the language family and change the references to theis buildpack to be correct.

The implementation for this buildpack is done as PR #88. There still needs to be an update to the README

PR #91 fixes the README


Supporting passing context to static rendering

Supporting passing context to static rendering. Not yet support .context() API

Hello there, is this still happening? I would really like this feature, thanks!

@hunterbmt are you still interested in completing this PR?
If not, @gerardmrk, if you can point me to a commit that adds the documentation, I can cherry-pick it onto this PR, and do the rebase.

@ljharb I will finish it today (GMT +7). Sorry for this delay, I thought I finished it already but obviously, I'm not 😿

@ljharb could you help me to double check and merge this PR ?
Please let me know if I need to update anything.
Regards,

or better:
const childContextTypes = objectAssign({}, node.type.contextTypes || {}, options.childContextTypes);

@ljharb nice catch. I updated the PR.

@ljharb could we merge this PR ?

@hunterbmt sure, could you rebase onto latest master?

@ljharb I already do that via github UI (you could check the last "merge" commit)

@ljharb I rebased master into my branch. Could you help me to merged this one ?

@hunterbmt would you also mind checking the "allow edits" checkbox in the right hand column?

@ljharb Already done.


Improve the types

Fixes #<issue_number_goes_here> (it's a good idea to open an issue first for discussion)

[ ] Tests and linter pass
[ ] Code coverage does not decrease (if any source code was changed)
[ ] Appropriate docs were updated (if necessary)

I ran into a compilation error due to types actually working 😆


Enable DRPC plugin on Service BC agents.

All but prod for now.

The updated configurations have been deployed and tested in their respective environments.

cc @marcos-carretero


Feat: Implemented the delete user functionality

fix : #71

@SAGARSINGH-1 nice work.

Currently we can see the border of the button (First image). Is it possible to not show the button's background (second image)?

@thtauhid here is the updated result:


Added 3 Sum in Java

Pull Request Template
What have you Changed(must)
Added 15. 3 Sum in Java
Write here what you have changed in the codebase
Added the code for 3 Sum in Java
Issue no.(must) - #1311
Pr will be close and marked as spam. If issue number not found or issue was assigned to someone else.
Marking as spam can block your account from HacktoberFest.
Self Check(Tick After Making pull Request)

[x] This issue was assigned to me if not it will be marked as spam.
[x] My file is in the proper folder
[x] I am following clean code and Documentation.
[x] I have added the title and what program will do first in the file
[x] I have named the file as (Problem #). (Problem Title(in Camel Case)).(extension)
ex. 2. AddToNumbers.py

README - How to Contribute

Please review my PR.

I have added the documentation.
I hope it helps.
Please review.


Openliero (real-time worms game)

Might need X:
https://github.com/albertz/openlierox
I need to look into it more.

I made an attempt at this before, but that was before I had glshim working properly. I'll take another run at it sometime after my move.

And even if things don't compile on the pi we can set x86 flags only as I run RetroPie on my Linux machine as well.

Just for reference: http://www.openlierox.net/wiki/index.php/Compiling_OpenLieroX_on_Linux It started to compile fine for me but ran into assembly errors, likely needs some cmake changes for the rpi platform based on what I gather from here but at least warmux works :)

I believe that the game is written specifically for x86 platforms so I'm not sure we'll be able to get this running. Pretty sure no distro for ARM out there has a package for this.

Yeah probably so. At least warmux works, that's good enough for me


Constants FIle

Constants File
Problem
There are multiple values that are used throughout many of the files that could be kept better by putting it in a single constants file. This could include max speed, takeoff altitude, and other values similar to that.
Solution
Create a python file to store all of the constants file for them to be used throughout the codebase.
Additional Information
Make sure the values added aren't values that are changed while the code is running, and make sure the values don't overlap with the config file.

Would this be in the same file structure as vision with a common folder or would this just be a constants.py file directly?

Just directly in the flight folder


Not deterministic _src_path in answers file

Describe the bug

When running pre-commit on CI, I get failures that I don't get locally:
copier-template-tester................................................... Failed
- hook id: copier-template-tester
- files were modified by this hook
Creating: /builds/moduon/ops/dct-private/.ctt/full
[...]
  conflict  .copier-answers.dct-private.yml
 overwrite  .copier-answers.dct-private.yml
[...]
pre-commit hook(s) made changes.
If you are seeing this message in CI, reproduce locally with: `pre-commit run --all-files`.
To run `pre-commit` as part of git workflow, use `pre-commit install`.
All changes made by hooks:
diff --git a/.ctt/full/.copier-answers.dct-private.yml b/.ctt/full/.copier-answers.dct-private.yml
index 205a1ef..4e44453 100644
--- a/.ctt/full/.copier-answers.dct-private.yml
+++ b/.ctt/full/.copier-answers.dct-private.yml
@@ -1,6 +1,6 @@
 # Changes here will be overwritten by Copier; do NOT edit manually
 _commit: v6.4.0-0
-_src_path: /var/home/yajo/prodevel/dct-private
+_src_path: /builds/moduon/ops/dct-private
user: yajo
org: moduon

#To Reproduce

Steps and/or code snippet(s) to reproduce the behavior:

Configure for pre-commit.
run it.
Commit it.
clone in another directory
pre-commit run -a

Expected behavior

The _src_path in the answers file, when it points to the local git directory (always, right?), should get stripped off the absolute paths.
Or maybe just harcode it to "." or similar.
In any case, the output should be deterministic.
Additional Information

copier_template_tester Version:
OS: [e.g. macOS/Windows]:
OS Version [e.g. Catalina/10]:

I ran into that in the test suite, but hadn't considered pre-commit in CI (or on another user's computer for that matter). I think I'll need to resolve the path to the git directory and convert the path to relative like I do here:
https://github.com/KyleKing/copier-template-tester/blob/1ca3a1faa40604143986dfbf0033837dd2759933/tests/helpers.py#L82
I'll open a PR when I'm back next week!

Looks like it works! Try now with v1.2.2
https://github.com/KyleKing/calcipy_template/commit/f2ba3283e0b79b234ace3cda0dc32b7acaec7941

Confirmed, thanks!


GCCs atomic ops should be automatically preferred over hand-rolled per-architecture ones

In src/base/atomicops.h, there is an #ifdef ladder for including the backing implementation for atomics. There are two problems with it:

The GCC atomics are only preferred if you both manually request them, by explicitly defining TCMALLOC_PREFER_GCC_ATOMICS and have a new enough compiler. There is almost no reason to prefer the hand-rolled versions if the GCC atomics are available. The logic here should be reversed to use the GCC atomics by default if available based on a compiler version check, and fall back to per-architecture implementations only if a new enough GCC is not available. There could be a flag like TCMALLOC_NO_GCC_ATOMICS to force that choice if needed.
The other problem is that even if you define TCMALL_PREFER_GCC_ATOMICS, it doesn't work with clang, since clang identifies as GCC 4.2, and the GCC version check fails. The check should be updated to account for clang as well.

I also have a question about TCMALLOC_PREFER_GCC_ATOMICS. Is it necessary only when building tcmalloc? Or is it required when including tcmalloc headers as well? Another way of putting the question: is the atomicops.h header part of the public interface of tcmalloc?

@alk - Any thoughts on this? I'm happy to put together a PR for it if you think it makes sense.

He Andrew. atomicops.h is not public interface.
My only tiny bit of concern about this idea is that in past I've heard that some versions of gcc had quite crappy atopic ops implementation. But perhaps this is not concern anymore.
IMHO existing atomic ops work and there is no pressing need to change them.

Thanks, for clarifying about atomicops being internal only. That was my belief, but I wanted to be sure.
I think your concern about old GCC is fair, but I would like to see TCMALLOC_PREFER_GCC_ATOMICS work correctly with clang, which it currently doesn't.

Interesting. Thanks for letting me know. I was not aware that clang builds fail on TCMALLOC_PREFER_GCC_ATOMICS.

@alk - Well, it doesn't exactly fail to build when using clang with TCMALLOC_PREFER_GCC_ATOMICS. The issue is that TCMALLOC_PREFER_GCC_ATOMICS isn't honored when using clang, because the GCC version check sees clang as GCC 4.2, so it ignores the request to use the GCC atomics. So it still builds, but just not with the atomics you intended.

@alk - Thanks for adding the fixup for clang, that is much appreciated. I still think there is a lot of value in standardizing on the GCC __atomic implementation when available. Those interfaces are direct analogues of the standard atomic operation APIs of C11 and C++11, and thus are aligned with the memory model of these languages going forward. By making this implementation the default, it ensures that the semantics of the gperftools atomics API in the subtle namespace can be correctly expressed given the semantics of the language memory model. It also allows compilers that aware of the specific target to potentially capitalize on new instructions as newer ISAs are rolled out, without the difficulty of maintaining several separate (and possibly subtly broken) hand-rolled assembly implementations. Finally, it is possible that the hand-rolled versions actually provide stronger ordering guarantees as implemented than are strictly required by the claimed semantics of the functions in subtle, and thus could mask real concurrency bugs that using the intended weaker ordering guarantees might reveal. While I generally agree with the principle of not changing things that are known to work, I think in this case it is important to change over, since it is too important to know if the GCC atomics don't actually work, and the only way to find that out is by making them the default and addressing any fallout.

If you're going to change the default implementation, wouldn't it be better to use the standard C11/C++11 atomics? I expect those to be the preferred solution for atomics moving forward.

@rauls5382 - Yes, but I don't think gperftools should be limited to C++11. It wouldn't be a problem for my usage, but probably would be for others.
I think the best order would be:

C++11 std::atomic API, if available
GCC/clang __atomic API, if available (or Win32 API/intrinsics)
Per-architecture hand-rolled assembly, to eventually be phased out.

So, I'd still start making the __atomic API implementation the default, as that implementation is already written. A C++11 option could be added later.

I agree with your proposed order, but I think that if defaults are to be changed, it is better to do that only once.

On Thu, Sep 22, 2016 at 8:25 AM, Andrew C. Morrow<EMAIL_ADDRESS>wrote:

@rauls5382 https://github.com/rauls5382 - Yes, but I don't think
gperftools should be limited to C++11. It wouldn't be a problem for my
usage, but probably would be for others.

I was thinking about c++11 recently. As long as we support rhel6 and, say,
visual studio 2013, that would be fine. Looks like rhel6 ships gcc 4.4 with
only few bits of c++11: https://gcc.gnu.org/gcc-4.4/cxx0x_status.html
atomics is mentioned as supported. But we'll need to check if this is
decent implementation.
As far as atomics, my thinking is not touching this stuff unless we need
(which doesn't seem to be the case) and until c++11 is widespread and all
implementations are great.

I think the best order would be:

C++11 std::atomic API, if available
GCC/clang __atomic API, if available (or Win32 API/intrinsics)
Per-architecture hand-rolled assembly, to eventually be phased out.

So, I'd still start making the __atomic API implementation the default, as
that implementation is already written. A C++11 option could be added later.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/gperftools/gperftools/issues/797#issuecomment-248936866,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAA6AsPdtMTaxYyYbTkJ-n2jvulIYOaoks5qsp3ugaJpZM4IN1SO
.

I think the C++11 part of this discussion is a bit of a misdirection. Mostly, I don't care whether the implementation is C++11 atomics or GCC __atomic. Either is fine, really, though C++11 is probably better. What is much more important though is that gperftools eventually migrate away from hand-rolled assembly over to an implementation that is aligned with the C11/C++11 memory model.
The PREFER feature is a good start. I also see the merit to the argument that there isn't anything forcing a change, right now, and I understand taking the conservative approach for something like a memory allocator. But I also think there is merit to getting more exposure and testing for the GCC __atomics based implementations. If compiler quality-of-implementation is a concern, how about a compromise: only prefer the __atomics implementation by default if using the as-of-today newest stable versions of GCC or clang (GCC 6.2 or clang 3.9)?

Looking at this some more, looks like red hat is shipping later gcc as part of their "devtoolset" software collection that works on centos/rhel 6. And interestingly, binaries compiled with such gcc (even 5.2) work on stock centos 6. So, looks like switching to c++ 11 might be possible.

we now run with c++11 atomics exclusively.


Stopping server does not actually skill server process

This should be fairly simple to solve. We already have a test for stopping the server:
https://github.com/kantord/SeaGOAT/blob/0356687f2cebd9a14c834d0a11ce9f12f77e60b9/tests/test_server.py#L127-L143
The only thing wrong with this test that it does not test that the server process is actually killed. And it seems like the implementation for the server stopping command does not actually kill the server process, it just does some things that fool the test:
https://github.com/kantord/SeaGOAT/blob/0356687f2cebd9a14c834d0a11ce9f12f77e60b9/seagoat/server.py#L184-L199
The correct way to solve it is by:

Making sure that the tests fails because the server process is not being killed
After seeing that the tests "fails correctly" fix the implementation and make sure that the tests now pass

The get_server_info function should already return the process ID, so you should be able to use that in the test in order to make sure that the process is running before the server is killed and that it is not running after it's killed. Also, you should be able to use that to actually kill the server process in the implementation!

Hello @kantord !
I would like to make it for the hacktoberfest event. Can you assign me on this ?
Is that ok to include the part part to terminate the process in remove_server_info function in the seagoat/utils/server.py file?
To me it sounds ok to consider that removing server info also terminate the process.

Aside, nice project here! I'll probably give it a try in my next open source project. :+1:

Hello @kantord !
I would like to make it for the hacktoberfest event. Can you assign me on this ?
Is that ok to include the part part to terminate the process in remove_server_info function in the seagoat/utils/server.py file?
To me it sounds ok to consider that removing server info also terminate the process.
Aside, nice project here! I'll probably give it a try in my next open source project. 👍

Sure, that sounds good to me. Though in that case I would probably rename the function to something more appropriate like stop_server

Can i work on this issue  ?

Can i work on this issue ?

hi @Jatinjain07Dazai looks like @tbetous is already working on it, maybe you can ask him if he needs any help? Or stay tuned, I will try to create more tasks


Fix for Dockerfile smell DL4006

Hi!
The Dockerfile placed at ".devcontainer/Dockerfile" contains the best practice violation (smell) DL4006 detected by the hadolint tool.
The smell DL4006 occurs when there is a RUN instruction with a pipe in and the -o pipefail option is missing. The issue is that the RUN instruction only evaluates the exit code of the last operation in the pipe to determine success. Thus, during the Docker build, if one of the statements contained in the RUN instruction fails but not the last, the build will continue even if there is an error.
This pull request proposes a fix generated by a fixing tool that I developed to fix this kind of smell. The patch was manually verified before opening the pull request. To fix this smell, specifically, the option -o pipefail is placed before the RUN instruction with a pipe in.
This change is only aimed at fixing that specific smell. If the fix is not valid or useful, please briefly indicate the reason and suggestions for possible improvements.
Thanks in advance

Closing issue as this repo is no longer used but only for information purposes, all work is done on the new client at https://github.com/Vidyano/vidyano


I hate it, but it works

it at least fixes Raicuparta's SpawnPoints

we either do this or recompile mods


turn on docs build

This should turn on the docs build in the swift package index (like we have for mlx-swift).  Once that is going I will follow up with a PR to link to the result (plus any docs fixes required).

What docs does this build?

It builds the docs for the libraries (MLXLMCommon, MLXLLM, MLXVLM, StableDiffusion, etc.). The methods mostly have documentation so it builds all of those.


PuppetAgent plugin

PuppetAgent plugin to collect local run summary stats. Uses external dependency to parse YAML file

please ignore/close will make a proper branch


make sure flanneld got QoS class "Guaranteed" to have lower oom_score_adj

Usually flanneld consumes 5m CPU and 15Mi memory according to "kubectl top".
Description
A few sentences describing the overall goals of the pull request's commits.
Please include

the type of fix - (e.g. bug fix, new feature, documentation)
some details on why this PR should be merged
the details of the testing you've done on it (both manual and automated)
which components are affected by this PR

Flannel pod gets default QoS class "BestEffort" when it doesn't specify cpu and memory resources,
this makes its oom_score_adj to be 1000 and thus is more likely killed first when free memory isn't enough.
This patch assigns same amount of  cpu/mem request and amount, makes Flanneld pod gets QoS class "Guaranteed" and oom_score_adj -998 as described at https://kubernetes.io/docs/tasks/administer-cluster/out-of-resource/#node-oom-behavior.

Should the limit be higher? Are these values suitable even for large clusters?

@tomdee ,  since flanneld is running per node, and most clusters don't frequently create and destroy PODs, I guess 10m cpu and 50Mi memory  are enough for small scale(~10 nodes) and medium scale(~100 nodes) Kubernetes clusters.  I believe the administrators of large scale cluster are able to optimize these parameters :-D
Maybe CoreOS has some test clusters to confirm the  appropriate resource limits,  or survey in some flannel mailing list.

I think this would be a great PR to merge but with the current values I'm worried that it will create (additional) hard to diagnose problems since the limits might be too low.

Maybe 50m cpu and 100Mi memory is safer, I'm not sure about the best numbers, need some benchmark and survey.

OK, my testing has shown that a 1000 node vxlan cluster (unfortunately with etcd backend) uses ~22MB, so I think a limit of 100m CPU and 50Mi memory would be OK. If you make this change to all the yamls in this repo I can merge it.

@tomdee  Thank you very much for your testing,  I just updated my PR and changed all the yamls in Documentation/.

In commit 014b2d52dfdc5008f5671c9aed4c5c9ebc34db80, @osoriano changed this line in Documentation/kube-flannel.yml:
@@ -100,7 +110,7 @@ spec:
         args:
         - -f
         - /etc/kube-flannel/cni-conf.json
-        - /etc/cni/net.d/10-flannel.conf
+        - /etc/cni/net.d/10-flannel.conflist
         volumeMounts:
         - name: cni
           mountPath: /etc/cni/net.d

Is this a mistake?

@Dieken 10-flannel.conflist should be read by CNI here https://github.com/containernetworking/cni/blob/master/libcni/conf.go#L177
Is there some error you are seeing?

@osoriano Sorry I didn’t know the difference between .conf and .conflist, I thought it was a typo, had’t upgraded to the latest kube-flannel.yml.
BTW, is that fix required to other yaml files in Documentation/ ?

@tomdee could you review the PR and merge it?  The discussion in the last three comments are irrelated.

@Dieken, thanks for pointing that out. The .conflist files are parsed differently since they contain a list of plugins for plugin chaining.
If both 10-flannel.conf and 10-flannel.conflist are both present, only 10-flannel.conf will be used (first file in the sorted list). You're right, the old file should be removed in an upgrade. Although, it won't break the upgrade either.
I only tested the change with kube-flannel.yml, but it seems like others could be updated as well.

@osoriano not exactly - Kubernetes prefers conflists over confs, regardless of the sorting.

@squeed Can you help me understand where this happens in the code?
I'm not that familiar with CNI, but saw that the conf files are first sorted, then we return on the first valid conf.

@osoriano argh, you're completely right.. And I even wrote that code. I was thinking of a different CNI loading shim I wrote for rkt :-).


grub2: apply security patches

Description of changes
Apply security patches for CVE-2021-3981, CVE-2021-3695, CVE-2021-3696, CVE-2021-3697, CVE-2022-28733, CVE-2022-28734, CVE-2022-28735, CVE-2022-28736, CVE-2022-28737, CVE-2022-2601 and CVE-2022-3775.
https://lists.gnu.org/archive/html/grub-devel/2022-06/msg00035.html
https://lists.gnu.org/archive/html/grub-devel/2022-11/msg00059.html
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[x] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[x] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
23.05 Release Notes (or backporting 22.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

Result of nixpkgs-review run on x86_64-linux 1

8 packages built:

grub2 (grub2_light)
grub2_efi
grub2_pvgrub_image
grub2_xen
os-prober
timeshift
woeusb
woeusb-ng

grub2.passthru.tests.nixos-install-grub1 and grub2.passthru.tests.nixos-install-grub-uefi-spec are failing but they also seems to fail on master for me.

Can look into the test failures.

it appears that its running out of memory
vm-test-run-installer-simpleUefiGrubSpecialisation> machine # building '/nix/store/i6l9z9rvjkflvbdapn8shfby7q709603-nixos-manual-html.drv'...
vm-test-run-installer-simpleUefiGrubSpecialisation> machine # [   81.680032] xsltproc invoked oom-killer: gfp_mask=0x1100dca(GFP_HIGHUSER_MOVABLE|__GFP_ZERO), order=0, oom_score_adj=0

i've pushed a fix

Good catch, thanks.
grub2.passthru.tests.nixos-install-grub-uefi-spec still failing on my end, it works if I disable the build of the NixOS documentation:
diff --git a/nixos/tests/installer.nix b/nixos/tests/installer.nix
index 300f6602789..258411305b1 100644
--- a/nixos/tests/installer.nix
+++ b/nixos/tests/installer.nix
@@ -452,6 +452,7 @@ let
     extraConfig = ''
       environment.systemPackages = [ pkgs.grub2 ];
       boot.loader.grub.configurationName = "Home";
+      documentation.nixos.enable = false;
       specialisation.work.configuration = {
         boot.loader.grub.configurationName = lib.mkForce "Work";

Is this good enough for what we are trying to test?
For grub2.passthru.tests.nixos-install-grub1 the error seems to come from soemthing else:
machine # updating GRUB 1 menu...
machine # installing the GRUB 1 boot loader on /dev/disk/by-id/scsi-0QEMU_QEMU_HARDDISK_drive1...
machine # [  111.029383] process 'store/m14gcv7hr5jzwm49dyyifa54vx3jamm5-grub-0.97-73/bin/grub' started with executable stack
machine # Probing devices to guess BIOS drives. This may take a long time.
machine # [  111.102785] blk_update_request: I/O error, dev fd0, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
machine # [  111.103646] floppy: error 10 while reading block 0
machine # Unknown partition table signature
machine # /nix/store/m14gcv7hr5jzwm49dyyifa54vx3jamm5-grub-0.97-73/sbin/grub-install: line 468: grub-probe: command not found
machine # Unknown partition table signature
machine # [  113.606769] blk_update_request: I/O error, dev fd0, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
machine # [  113.607634] floppy: error 10 while reading block 0
machine # Unknown partition table signature
machine # [  119.718740] blk_update_request: I/O error, dev fd0, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
machine # [  119.719860] floppy: error 10 while reading block 0
machine # Unknown partition table signature
machine # [  131.832669] blk_update_request: I/O error, dev fd0, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
machine # [  131.833542] floppy: error 10 while reading block 0
machine # Unknown partition table signature
machine # [  137.933613] blk_update_request: I/O error, dev fd0, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
machine # [  137.934336] floppy: error 10 while reading block 0
machine # Unknown partition table signature
machine # [  144.013657] blk_update_request: I/O error, dev fd0, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
machine # [  144.014462] floppy: error 10 while reading block 0
machine # Unknown partition table signature
machine # [  150.188611] blk_update_request: I/O error, dev fd0, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
machine # [  150.189445] floppy: error 10 while reading block 0
machine # Unknown partition table signature
machine # [  156.288559] blk_update_request: I/O error, dev fd0, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
machine # [  156.289406] floppy: error 10 while reading block 0
machine # Unknown partition table signature
machine # [  162.545476] blk_update_request: I/O error, dev fd0, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
machine # [  162.546327] floppy: error 10 while reading block 0
machine # Unknown partition table signature
machine # [  168.708465] blk_update_request: I/O error, dev fd0, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
machine # [  168.709326] floppy: error 10 while reading block 0
machine # Unknown partition table signature
machine # [  174.967421] blk_update_request: I/O error, dev fd0, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
machine # [  174.968249] floppy: error 10 while reading block 0
machine # Unknown partition table signature
machine # [  181.055388] blk_update_request: I/O error, dev fd0, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
machine # [  181.056256] floppy: error 10 while reading block 0
machine # Unknown partition table signature
machine # [  187.229321] blk_update_request: I/O error, dev fd0, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
machine # [  187.230414] floppy: error 10 while reading block 0
machine # Unknown partition table signature
machine # [  193.377277] blk_update_request: I/O error, dev fd0, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
machine # [  193.378123] floppy: error 10 while reading block 0
machine #
machine #
machine #     GNU GRUB  version 0.97  (640K lower / 3072K upper memory)
machine #
machine #        [ Minimal BASH-like line editing is supported.   For
machine #          the   first   word,  TAB  lists  possible  command
machine #          completions.  Anywhere else TAB lists the possible
machine #          completions of a device/filename. ]
machine # grub> root (hd0,1)
machine #  Filesystem type is ext2fs, partition type 0x83
machine # grub> setup  --stage2=/tmp/PXzqqrtILy/boot/grub/stage2 --prefix=/boot/grub (hd0)
machine #  Checking if "/boot/grub/stage1" exists... yes
machine #  Checking if "/boot/grub/stage2" exists... yes
machine #  Checking if "/boot/grub/e2fs_stage1_5" exists... yes
machine #  Running "embed /boot/grub/e2fs_stage1_5 (hd0)"... failed (this is not fatal)
machine #  Running "embed /boot/grub/e2fs_stage1_5 (hd0,1)"... failed (this is not fatal)
machine #  Running "install --stage2=/tmp/PXzqqrtILy/boot/grub/stage2 /boot/grub/stage1 (hd0) /boot/grub/stage2 p /boot/grub/menu.lst "... failed
machine #
machine # Error 6: Mismatched or corrupt version of stage1/stage2
machine # grub> quit
machine # /nix/store/bgdk99syw9bfg45irav36na1jiyrkqfz-install-grub.pl: installation of GRUB on /dev/disk/by-id/scsi-0QEMU_QEMU_HARDDISK_drive1 failed: No such file or directory

The line 468: grub-probe: command not found does not seem expected.

Good catch, thanks.
grub2.passthru.tests.nixos-install-grub-uefi-spec still failing on my end, it works
if I disable the build of the NixOS documentation:
diff --git a/nixos/tests/installer.nix b/nixos/tests/installer.nix
index 300f6602789..258411305b1 100644
--- a/nixos/tests/installer.nix
+++ b/nixos/tests/installer.nix
@@ -452,6 +452,7 @@ let
     extraConfig = ''
       environment.systemPackages = [ pkgs.grub2 ];
       boot.loader.grub.configurationName = "Home";
+      documentation.nixos.enable = false;
       specialisation.work.configuration = {
         boot.loader.grub.configurationName = lib.mkForce "Work";

Is this good enough for what we are trying to test?
For grub2.passthru.tests.nixos-install-grub1 the error seems to come from soemthing else:
machine # updating GRUB 1 menu...
machine # installing the GRUB 1 boot loader on /dev/disk/by-id/scsi-0QEMU_QEMU_HARDDISK_drive1...
machine # [  111.029383] process 'store/m14gcv7hr5jzwm49dyyifa54vx3jamm5-grub-0.97-73/bin/grub' started with executable stack
machine # Probing devices to guess BIOS drives. This may take a long time.
machine # [  111.102785] blk_update_request: I/O error, dev fd0, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
machine # [  111.103646] floppy: error 10 while reading block 0
machine # Unknown partition table signature
machine # /nix/store/m14gcv7hr5jzwm49dyyifa54vx3jamm5-grub-0.97-73/sbin/grub-install: line 468: grub-probe: command not found
machine # Unknown partition table signature
machine # [  113.606769] blk_update_request: I/O error, dev fd0, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
machine # [  113.607634] floppy: error 10 while reading block 0
machine # Unknown partition table signature
machine # [  119.718740] blk_update_request: I/O error, dev fd0, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
machine # [  119.719860] floppy: error 10 while reading block 0
machine # Unknown partition table signature
machine # [  131.832669] blk_update_request: I/O error, dev fd0, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
machine # [  131.833542] floppy: error 10 while reading block 0
machine # Unknown partition table signature
machine # [  137.933613] blk_update_request: I/O error, dev fd0, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
machine # [  137.934336] floppy: error 10 while reading block 0
machine # Unknown partition table signature
machine # [  144.013657] blk_update_request: I/O error, dev fd0, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
machine # [  144.014462] floppy: error 10 while reading block 0
machine # Unknown partition table signature
machine # [  150.188611] blk_update_request: I/O error, dev fd0, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
machine # [  150.189445] floppy: error 10 while reading block 0
machine # Unknown partition table signature
machine # [  156.288559] blk_update_request: I/O error, dev fd0, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
machine # [  156.289406] floppy: error 10 while reading block 0
machine # Unknown partition table signature
machine # [  162.545476] blk_update_request: I/O error, dev fd0, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
machine # [  162.546327] floppy: error 10 while reading block 0
machine # Unknown partition table signature
machine # [  168.708465] blk_update_request: I/O error, dev fd0, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
machine # [  168.709326] floppy: error 10 while reading block 0
machine # Unknown partition table signature
machine # [  174.967421] blk_update_request: I/O error, dev fd0, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
machine # [  174.968249] floppy: error 10 while reading block 0
machine # Unknown partition table signature
machine # [  181.055388] blk_update_request: I/O error, dev fd0, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
machine # [  181.056256] floppy: error 10 while reading block 0
machine # Unknown partition table signature
machine # [  187.229321] blk_update_request: I/O error, dev fd0, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
machine # [  187.230414] floppy: error 10 while reading block 0
machine # Unknown partition table signature
machine # [  193.377277] blk_update_request: I/O error, dev fd0, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
machine # [  193.378123] floppy: error 10 while reading block 0
machine #
machine #
machine #     GNU GRUB  version 0.97  (640K lower / 3072K upper memory)
machine #
machine #        [ Minimal BASH-like line editing is supported.   For
machine #          the   first   word,  TAB  lists  possible  command
machine #          completions.  Anywhere else TAB lists the possible
machine #          completions of a device/filename. ]
machine # grub> root (hd0,1)
machine #  Filesystem type is ext2fs, partition type 0x83
machine # grub> setup  --stage2=/tmp/PXzqqrtILy/boot/grub/stage2 --prefix=/boot/grub (hd0)
machine #  Checking if "/boot/grub/stage1" exists... yes
machine #  Checking if "/boot/grub/stage2" exists... yes
machine #  Checking if "/boot/grub/e2fs_stage1_5" exists... yes
machine #  Running "embed /boot/grub/e2fs_stage1_5 (hd0)"... failed (this is not fatal)
machine #  Running "embed /boot/grub/e2fs_stage1_5 (hd0,1)"... failed (this is not fatal)
machine #  Running "install --stage2=/tmp/PXzqqrtILy/boot/grub/stage2 /boot/grub/stage1 (hd0) /boot/grub/stage2 p /boot/grub/menu.lst "... failed
machine #
machine # Error 6: Mismatched or corrupt version of stage1/stage2
machine # grub> quit
machine # /nix/store/bgdk99syw9bfg45irav36na1jiyrkqfz-install-grub.pl: installation of GRUB on /dev/disk/by-id/scsi-0QEMU_QEMU_HARDDISK_drive1 failed: No such file or directory

The line 468: grub-probe: command not found does not seem expected.

Moving back this PR to draft.
It appears we are also missing patches for CVE-2022-28736, CVE-2022-28734, CVE-2022-28733, CVE-2021-3697, CVE-2021-3696 and CVE-2021-3695. I will try to deal with it later today or tomorrow.

Wouldn't mind if grub did another release.

Ready for review again. Hopefully all patches are applied.
All grub2 tests are successful on my side.

Result of nixpkgs-review pr 208614 run on x86_64-linux 1

9 packages built:

grub2 (grub2_full ,grub2_light)
grub2_efi
grub2_pvgrub_image
grub2_xen
os-prober
tests.testers.nixosTest-example
timeshift
woeusb
woeusb-ng

Result of nixpkgs-review pr 208614 run on aarch64-linux 1

1 package marked as broken and skipped:

woeusb

2 packages failed to build:

grub2_pvgrub_image
grub2_xen

4 packages built:

grub2 (grub2_full ,grub2_light)
grub2_efi
timeshift
woeusb-ng

It looks like the failures on aarch64 are not new:
https://hydra.nixos.org/build/202124533
https://hydra.nixos.org/build/202185637
configure: error: platform "xen" is not supported for target CPU "arm64"

Good catch, thanks.
grub2.passthru.tests.nixos-install-grub-uefi-spec still failing on my end, it works if I disable the build of the NixOS documentation:
diff --git a/nixos/tests/installer.nix b/nixos/tests/installer.nix
index 300f6602789..258411305b1 100644
--- a/nixos/tests/installer.nix
+++ b/nixos/tests/installer.nix
@@ -452,6 +452,7 @@ let
     extraConfig = ''
       environment.systemPackages = [ pkgs.grub2 ];
       boot.loader.grub.configurationName = "Home";
+      documentation.nixos.enable = false;
       specialisation.work.configuration = {
         boot.loader.grub.configurationName = lib.mkForce "Work";

Is this good enough for what we are trying to test?

did you forget to pull the fix because when you force pushed you removed my fix

Good catch, thanks.
grub2.passthru.tests.nixos-install-grub-uefi-spec still failing on my end, it works if I disable the build of the NixOS documentation:
diff --git a/nixos/tests/installer.nix b/nixos/tests/installer.nix
index 300f6602789..258411305b1 100644
--- a/nixos/tests/installer.nix
+++ b/nixos/tests/installer.nix
@@ -452,6 +452,7 @@ let
     extraConfig = ''
       environment.systemPackages = [ pkgs.grub2 ];
       boot.loader.grub.configurationName = "Home";
+      documentation.nixos.enable = false;
       specialisation.work.configuration = {
         boot.loader.grub.configurationName = lib.mkForce "Work";

Is this good enough for what we are trying to test?

did you forget to pull the fix because when you force pushed you removed my fix

Nope I tested with your fix and I was still OOM. With documentation.nixos.enable = false; I did not encountered the issue and the test was succeeding on the OfBorg run.

error: builder for '/nix/store/mpxfkmj5jdw4n3ny7zq4v58fxdc1rds0-CVE-2021-3695.CVE-2021-3696.CVE-2021-3697.CVE-2022-28733.CVE-2022-28734.CVE-2022-28735.CVE-2022-28736.CVE-2022-28737.29.patch.drv' failed with exit code 1;
       last 10 log lines:
       > Warning: Problem : HTTP error. Will retry in 1 seconds. 3 retries left.
       >   0   234    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
       > curl: (22) The requested URL returned error: 503
       > Warning: Problem : HTTP error. Will retry in 2 seconds. 2 retries left.
       >   0   234    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
       > curl: (22) The requested URL returned error: 503
       > Warning: Problem : HTTP error. Will retry in 4 seconds. 1 retries left.
       >   0   234    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
       > curl: (22) The requested URL returned error: 503
       > error: cannot download CVE-2021-3695.CVE-2021-3696.CVE-2021-3697.CVE-2022-28733.CVE-2022-28734.CVE-2022-28735.CVE-2022-28736.CVE-2022-28737.29.patch from any mirror
       For full logs, run 'nix log /nix/store/mpxfkmj5jdw4n3ny7zq4v58fxdc1rds0-CVE-2021-3695.CVE-2021-3696.CVE-2021-3697.CVE-2022-28733.CVE-2022-28734.CVE-2022-28735.CVE-2022-28736.CVE-2022-28737.29.patch.drv'.

weird ofborg is failing with lots of these

@ofborg build grub2 grub2.passthru.tests

FYI: the patch download failures were some kind of limiting (rate limiting / concurrent connection limiting? :shrug: ) (thanks Lily Foster on Matrix for the idea). After making ofborg rebuild it a few times, we finally got enough to continue. The only failure on x86 now is the grub1 test (which, as mentioned above, is also failing on master).

I think this is ready to be merged.

Uh, this caused a problem:
https://github.com/NixOS/nixpkgs/pull/211372


Use Apollo Nuxt Module with AWS Amplify (appsync) API

What problem does this feature solve?
I tried to stick with this module when working with a GraphQL AWS API. I couldn't configure how to attach to the request headers the requested API key.
When "edit and resend" the request to add ''x-api-key" as key with the related key as value, it works. See https://stackoverflow.com/q/60816883/3793161
What does the proposed changes look like?
If it is already possible, it's a feature request for the readme. If not, it does not look like a big leap to allow the addition of custom headers for cases like this.

This feature request is available on Nuxt community (#c301)

I'll show some support for this too. I'm trying to get Apollo to talk to my Rails GraphQL backend, but I'm using Devise Token Auth which requires setting specific headers for authentication:

client - unique string to identify this client
access-token - the token, expires every 2 weeks

It looks like the Apollo module is setup for Basic/Bearer authentication, so I presume it can't be too tricky to allow us to set custom headers.

I figured out a solution to my problem of dynamically setting headers.
In nuxt.config.js you can use clientConfigs to provide your own file, rather than a static options object. That file can export a function that accepts a context argument, where you can retrieve the token and append it to the headers for the apollo request.
// nuxt.config.js

export default {
  apollo: {
    clientConfigs: {
      default: '~/apollo/default-client.js'
    }
  },
}

// apollo/default-client.js

export default function(context) {
  const token = context.app.$cookies.get("apollo-token");
  return {
    httpEndpoint: `http://api.com/graphql`,
    httpLinkOptions: {
      headers: {
        "access-token": token.accessToken,
        client: token.client,
        uid: token.uid,
        expiry: token.expiry
      }
    }
  }
}

@Billybobbonnet Here's an example from one of my codebases of how to achieve normal connection (for mutations and queries):
notifications: {
    httpEndpoint: `https://${process.env.VUE_APP_WS_GATEWAY_ENDPOINT || 'localhost:4030'}/graphql`,
    httpLinkOptions: {
      headers: {
        'x-api-key': process.env.VUE_APP_WS_API_KEY || 'YOUR_API_KEY',
      },
    },
  },

@Stf-F did u find a solution?


Put all reexports of given entry in Suggestion Database

Pull Request Description

close #9351
Changelog:

update: deprecate the reexport suggestion field
add: reexports suggestion field containing the list of modules re-exporting this symbol
update: exports logic to gather all the symbols exported from a given module

Important Notes

Checklist
Please ensure that the following checklist has been satisfied before submitting the PR:

[x] The documentation has been updated, if necessary.
[x] All code follows the
Scala,
Java,
and
Rust
style guides. In case you are using a language not listed above, follow the Rust style guide.
All code has been tested:

[x] Unit tests have been written where possible.
[x] If GUI codebase was changed, the GUI was tested when built using ./run ide build.

I think it breaks compatibility, in a sense that GUI will now wrongly use it... unless "reexport" field is also filled? If yes, we should update GUI handlers in this PR as well (I may do them, however they should be fairly simple).
Also, update the protocol-language-server documentation.

@hubertp the reexport field still exists
https://github.com/enso-org/enso/blob/f9c74bf19d6e7d26e89d0660e3a42797715240fe/engine/language-server/src/main/scala/org/enso/languageserver/search/SearchProtocol.scala#L67-L73
it is deprecated in the doc
  /** The fully qualified module name re-exporting this module.
   *
   * @deprecated use reexports field instead
   */
  reexport?: string;


Ban std::thread (etc) in test/cpp and in C++ style guide

For consistency between test/cpp and src/cpp , we need to be using grpc::{thread, mutex, unique_lock, ...} in both test/cpp and src/cpp . We are currently only consistently using these in src/cpp and often using std::thread etc in test.
We need to clean these up from test and explicitly mention this in the style guide

:)

There are about 100 std::thread in the codebase. Do we give up on this?


Convert the docx created to pdf file

Can we convert the docx file created by python-docx to pdf or there is any way to save as the docx file to pdf.

Any other module because pywin doesn't work in ubuntu

I upload the docx to Google Drive and download a PDF version. It's not perfect, but works for me, and can be done with the Google Python libraries

For conversion have look at pandoc https://pandoc.org/

@pylang , do you have a solution that is not based on win32com? Our MS macro has been disabled by the firm. cannot use anything based on win32com.

You can use pandoc https://pandoc.org/
Keep in mind you have to install pdfTex which comes on the texlive package, so in general you would want to in Ubuntu/Debian like OS:

sudo apt install texlive
Download pandoc deb
sudo dpkg -i pandoc.deb

At the end you can run:
pandoc -s test.docx -o testt.pdf