Make RTC_Millis immune to millis() rollover events

Every 49.7 days (232 ms), millis() rolls over to zero. When this happens, the RTC_Millis “soft RTC” jumps back in time by 49.7 days.
This pull request fixes the issue, provided that RTC_Millis::now() is called more often than the rollover period. The code relies on the fact that, owing to the rules of modular arithmetic, computing millis() - lastMillis is rollover safe.
Here is a test sketch coercing millis() to roll over early:
#include <Wire.h>
#include <RTClib.h>

void setup() {
    extern unsigned long timer0_millis;
    timer0_millis = -1500;  // 1.5 seconds before rollover
    RTC_Millis::begin(DateTime(__DATE__, __TIME__));
    Serial.begin(9600);
    Serial.println(" millis()    RTC_Millis::now()");
    Serial.println("-------------------------------");
}

void loop() {
    char buffer[48];
    DateTime t = RTC_Millis::now();
    sprintf(buffer, "%10lu  %04d-%02d-%02d %02d:%02d:%02d", millis(),
        t.year(), t.month(), t.day(), t.hour(), t.minute(), t.second());
    Serial.println(buffer);
    delay(1000);
}

The output produced by an Arduino Uno, without this fix:
 millis()    RTC_Millis::now()
-------------------------------
4294965796  2018-06-05 20:51:09
4294966830  2018-06-05 20:51:10
       535  2018-04-17 03:48:24
      1536  2018-04-17 03:48:25

And the output with the fix applied:
 millis()    RTC_Millis::now()
-------------------------------
4294965796  2018-06-05 20:51:27
4294966830  2018-06-05 20:51:28
       534  2018-06-05 20:51:29
      1536  2018-06-05 20:51:30

As a side effect of the changed algorithm, the “soft RTC” can now be set with sub-second resolution: once the time is set with adjust(), it will not change until a full second has elapsed. In a sense, the “implicit milliseconds field” of the time is cleared by adjust(), whereas in the current master branch it is always millis()%1000.
I am aware that this rollover issue has been addressed by pull request #55. However, the pull request I am submitting here is more efficient (fewer changes in the code, lower CPU and RAM usage) and more focused on this particular issue.

@edgar-bonet Quick question.
If i use your PR on a board and use t.unixtime() for Datetime t will the precision also be in milliseconds?

@shantanoo-desai: This PR fixes a rollover issue. It has no effect on the precision:

DateTime::unixtime() has a resolution of one second. It will not give you millisecond-level time stamps.
The elapsed time between successive “ticks” of unixtime() should be about 1,000±1 ms. The 1 ms jitter comes from the Arduino implementation of millis(), which is not accurate to the millisecond.
The long-term accuracy will likely be poor, especially if your Arduino is clocked off a ceramic resonator. Expect a drift of the order of ±0.1% (more than one minute per day).
The drift rate is not even going to be consistent. Expect random variations and high sensitivity to the ambient temperature.

See Arduino clock frequency accuracy for more information about the kind of accuracy you can expect from the Arduino's internal clock. In summary: if you need an accurate clock, use a real RTC. Alternatively, use an Arduino clocked off a real quartz crystal and correct the (almost constant) drift in soft.
I have implemented a variation of RTC_Millis that can be finely trimmed in order to remove the drift. I call it RTC_Micros. It can be significantly better than RTC_Millis if you take the time to measure and correct the drift. It is obviously still susceptible to the random frequency variations of the Arduino's internal clock, so it should perform way better on a crystal-clocked Arduino. Tell me if you are interested, in which case I will submit this as another pull request.

@edgar-bonet is there anyway I can club the millisecond timestamps to the unix epoch time. I wish to obtain some sensor values which are annotated with timestamps (epoch timestamps) but I want to the precision to be in milliseconds.

@edgar-bonet really quick question: how do I get the difference in ms acc. to your patch?
RTC_DS3231 rtc;
RTC_Millis software_time;

void setup() {
  // put your setup code here, to run once:
  Wire.begin(I2C_SDA, I2C_SCL, 400000);
  Serial.begin(9600);
  if (!rtc.begin()) {
    Serial.println("No RTC Detected");
  }
  // adjust RTC Time
  rtc.adjust(DateTime(F(__DATE__), F(__TIME__)));
  // adjust software timer
  software_time.adjust(rtc.now());

}

void loop() {
  // put your main code here, to run repeatedly:
  DateTime rtc_now_time = rtc.now();
  DateTime software_now_time = software_time.now(); // what goes here?
  Serial.println();
  Serial.print("RTC now: "); Serial.print(rtc_now_time.unixtime());
  Serial.println();

  delay(1000);

}

@shantanoo-desai: This is not the right venue for discussing issues that, at this point, are getting quite far from the original purpose of the pull request. You may try https://arduino.stackexchange.com/.

Just rebased on top of the current master. Is anyone still maintaining this repo?

we're focusing on some other Repos that have bugs in them, we'll get to this one at some point!


zulu17: <IP_ADDRESS> -> 17.0.10

Description of changes
https://www.azul.com/downloads/?version=java-17-lts&package=jdk
Things done

Built on platform(s)

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

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] 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
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
24.05 Release Notes (or backporting 23.05 and 23.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

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

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

1 package built:

zulu17


{site-recovery} HTML tags aren't allowed in published reference content

Describe the bug
Problem to solve:
HTML tags in source code are causing build warnings in MicrosoftDocs/azure-docs-cli. More importantly, customer-facing reference docs are not instantiating properly -- parameter values formatted with `<>` are missing. Here's an example:

Requested solution:
These values should be escaped with a backtick. Here's an example from az webpubsub.

Related GitHub issues:
This is the same issue as these GitHub issues.
List of HTML tag instances that need update:

File name
Build error

latest/docs-ref-autogen/site-recovery/alert-setting.yml
HTML tag 'indexToRemove' isn't allowed.  Replace it with approved Markdown or escape the brackets if the content is a placeholder.

latest/docs-ref-autogen/site-recovery/alert-setting.yml
HTML tag 'value' isn't allowed.  Replace it with approved Markdown or escape the brackets if the content is a placeholder.

latest/docs-ref-autogen/site-recovery/fabric.yml
HTML tag 'indexToRemove' isn't allowed.  Replace it with approved Markdown or escape the brackets if the content is a placeholder.

latest/docs-ref-autogen/site-recovery/fabric.yml
HTML tag 'value' isn't allowed.  Replace it with approved Markdown or escape the brackets if the content is a placeholder.

latest/docs-ref-autogen/site-recovery/network/mapping.yml
HTML tag 'indexToRemove' isn't allowed.  Replace it with approved Markdown or escape the brackets if the content is a placeholder.

latest/docs-ref-autogen/site-recovery/network/mapping.yml
HTML tag 'value' isn't allowed.  Replace it with approved Markdown or escape the brackets if the content is a placeholder.

latest/docs-ref-autogen/site-recovery/protected-item.yml
HTML tag 'indexToRemove' isn't allowed.  Replace it with approved Markdown or escape the brackets if the content is a placeholder.

latest/docs-ref-autogen/site-recovery/protected-item.yml
HTML tag 'value' isn't allowed.  Replace it with approved Markdown or escape the brackets if the content is a placeholder.

latest/docs-ref-autogen/site-recovery/protection-container.yml
HTML tag 'indexToRemove' isn't allowed.  Replace it with approved Markdown or escape the brackets if the content is a placeholder.

latest/docs-ref-autogen/site-recovery/protection-container.yml
HTML tag 'value' isn't allowed.  Replace it with approved Markdown or escape the brackets if the content is a placeholder.

latest/docs-ref-autogen/site-recovery/protection-container/mapping.yml
HTML tag 'indexToRemove' isn't allowed.  Replace it with approved Markdown or escape the brackets if the content is a placeholder.

latest/docs-ref-autogen/site-recovery/protection-container/mapping.yml
HTML tag 'value' isn't allowed.  Replace it with approved Markdown or escape the brackets if the content is a placeholder.

latest/docs-ref-autogen/site-recovery/recovery-plan.yml
HTML tag 'indexToRemove' isn't allowed.  Replace it with approved Markdown or escape the brackets if the content is a placeholder.

latest/docs-ref-autogen/site-recovery/recovery-plan.yml
HTML tag 'value' isn't allowed.  Replace it with approved Markdown or escape the brackets if the content is a placeholder.

Related command
az site-recovery
Errors
n/a
Issue script & Debug output
n/a
Expected behavior
n/a
Environment Summary
Azure CLI 2.62.0
Additional context
No response

Thank you for opening this issue, we will look into it.


Bug coming from pointnet2utils

Dear @Yochengliu ,
Do you have any idea where it is coming from ?
THCudaCheck FAIL file=/pytorch/aten/src/THC/THCGeneral.cpp line=663 error=11 : invalid argument
Traceback (most recent call last):
File "train_partseg.py", line 207, in
main()
File "train_partseg.py", line 92, in main
train(train_dataloader, test_dataloader, model, criterion, optimizer, lr_scheduler, bnm_scheduler, args, num_batch)
File "train_partseg.py", line 121, in train
pred = model(points, batch_one_hot_cls)
File "/home/thomas/.cache/pypoetry/virtualenvs/superpoint-graph-job-py3.6/lib/python3.6/site-packages/torch/nn/modules/module.py", line 477, in call
result = self.forward(*input, **kwargs)
File "/home/thomas/HELIX/research/Relation-Shape-CNN/models/rscnn_msn_seg.py", line 142, in forward
li_xyz, li_features = self.SA_modules[i](l_xyz[i], l_features[i])
File "/home/thomas/.cache/pypoetry/virtualenvs/superpoint-graph-job-py3.6/lib/python3.6/site-packages/torch/nn/modules/module.py", line 477, in call
result = self.forward(*input, **kwargs)
File "/home/thomas/HELIX/research/Relation-Shape-CNN/models/../utils/pointnet2_modules.py", line 51, in forward
new_features
File "/home/thomas/.cache/pypoetry/virtualenvs/superpoint-graph-job-py3.6/lib/python3.6/site-packages/torch/nn/modules/module.py", line 477, in call
result = self.forward(*input, **kwargs)
File "/home/thomas/.cache/pypoetry/virtualenvs/superpoint-graph-job-py3.6/lib/python3.6/site-packages/torch/nn/modules/container.py", line 91, in forward
input = module(input)
File "/home/thomas/.cache/pypoetry/virtualenvs/superpoint-graph-job-py3.6/lib/python3.6/site-packages/torch/nn/modules/module.py", line 477, in call
result = self.forward(*input, **kwargs)
File "/home/thomas/.cache/pypoetry/virtualenvs/superpoint-graph-job-py3.6/lib/python3.6/site-packages/torch/nn/modules/container.py", line 91, in forward
input = module(input)
File "/home/thomas/.cache/pypoetry/virtualenvs/superpoint-graph-job-py3.6/lib/python3.6/site-packages/torch/nn/modules/module.py", line 477, in call
result = self.forward(*input, **kwargs)
File "/home/thomas/HELIX/research/Relation-Shape-CNN/models/../utils/pytorch_utils/pytorch_utils.py", line 67, in forward
h_xi_xj = self.mapping_func2(self.activation(self.bn_mapping(self.mapping_func1(h_xi_xj))))
File "/home/thomas/.cache/pypoetry/virtualenvs/superpoint-graph-job-py3.6/lib/python3.6/site-packages/torch/nn/modules/module.py", line 477, in call
result = self.forward(*input, **kwargs)
File "/home/thomas/.cache/pypoetry/virtualenvs/superpoint-graph-job-py3.6/lib/python3.6/site-packages/torch/nn/modules/conv.py", line 301, in forward
self.padding, self.dilation, self.groups)
RuntimeError: cuda runtime error (11) : invalid argument at /pytorch/aten/src/THC/THCGeneral.cpp:663

you may check the variable 'batch_one_hot_cls' if it has correct dimensions or the value is right; I came across similar error (in classification task) because the label values are not from 0 to num_classes-1

you may check the variable 'batch_one_hot_cls' to see if it has correct dimensions or the values are right; I came across similar error (in classification task) because the label values ranges from 1 to num_classes (they should range from 0 to num_classes-1)


[Feature Anywhere] Ensure full plugin integration with OSD

To fully utilize the framework provided in OSD for collecting and visualizing plugin data correctly, we need to ensure the plugin does the following:
To ensure integration with auto-deletion:

[x] in the expression function to fetch results, determine whether a resource is deleted or just not visible due to backend roles
[x] if deleted, propagating the error by using RESOURCE_DELETED VisLayerErrorType (ref)

To ensure integration with saved objects:

[x] Double check that all saved objs created are using the latest ISavedAugmentVis interface - see here for the latest based off of the feature branch.
[x] Create the objs using the createAugmentVisSavedObject fn for automatic handling of UI settings (feature turned off, limit reached, etc.)

To ensure integration with chart tooltips:

[x] Ensure your produced VisLayers in the expression function include a pluginEventType (recently added via this PR)

To ensure integration with alerting:

[x] Add a notification with a an option to set up an alerting monitor after creating a detector, make sure this button is only shown if the alerting plugin is present.

Miscellaneous / best practices:

[x] the originPlugin field in the saved obj should be your plugin name. It does not have any strict standard but it should be consistent across your plugin. This value is used to aggregate results by plugin type, and is visible in the stats API
[x] the pluginResource.type field in the saved obj should be a human-readable value, e.g., Anomaly Detectors. This is the value visible on the view events page and custom tooltips. This also doesn't follow a strict standard, but should be consistent. This value is used to aggregate results by plugin resource type, and is visible in the stats API.

All these tasks were completed in multiple different commits that were squashed into main branch here: https://github.com/opensearch-project/anomaly-detection-dashboards-plugin/pull/539


Unable to remove role from the user, after the bot was online for a few days.

Steps to reproduce are simple:

Have a bot running for a few days.
Try to simply remove a role from a user.
Observe that the bot does everything without any errors or exceptions, thinking that it's done, but it did not remove the role from the user.
Restart the bot to fix the issue.

This was a problem since 0.91/92

Are you running the latest 0.9.x? I fixed a lot of role-related bugs in 0.9.3.

Unable to reproduce with the latest, as the bot just crashes (no exceptions, no logs) way too often to be able to test this... (It used to be stable for weeks before I updated.)

Without more information, we have nothing to go on. Even if you can't get a stack trace, logging at Debug level would be more helpful than nothing.
There's a few things that could cause crashes without exceptions, however the most likely one is a threading issue. Given no one else is complaining of this level of instability, I would suggest you review your code for anything that deviates from TAP, particularly look to see if you have any Tasks that aren't being awaited. If you have an exception being thrown in there that isn't caught, it would be fatal.

This is not an issue about crashes, hence why I will not provide any info on it here.

Closing until there is further information to go off of.


could not add more than one input field.

[ ] I have verified there are no duplicate active or recent bugs, questions, or requests
[ ] I have verified that I am using the latest version of Material Dialogs.
[ ] I have given my issue a non-generic title.
[ ] I have read over the documentation (before asking questions on how to do something).

Include the following:

Material Dialogs version: 0.x.x.x
Device OS version: 7.0
Device Manufacturer: Huawei
Device Name: Nexus 6P

Also, please wrap Java with correct syntax highlighting.
System.out.println("Hello, world!");

Reproduction Steps

Expected Result
Actual Result

You didn't include any information at all. This is not a valid issue at all.
To have more than one input field, you'll need to do it with a custom view.


How to apply required validation in date picker

Bug, feature request, or proposal:
What is the expected behavior?
What is the current behavior?
What are the steps to reproduce?
Providing a StackBlitz/Plunker (or similar) is the best way to get the team to see your issue.
Plunker starter (using on @master): https://goo.gl/uDmqyY
StackBlitz starter (using latest npm release): https://goo.gl/wwnhMV
What is the use-case or motivation for changing an existing behavior?
Which versions of Angular, Material, OS, TypeScript, browsers are affected?
Is there anything else we should know?

You could use reactive forms.

Please keep GitHub issues for bug reports / feature requests. Better avenues for troubleshooting / questions are stack overflow, gitter, mailing list, etc.


httpserver httpclient: Add support for unix sockets

Apologies for the API break. I think it's worth it, and it avoids breaks in the future for extra parameters by using a config struct.

Should only need 1 to 3 lines of change in each repo that updates ex


Support for git sub modules in vendoring in tools.nix

https://github.com/kolloch/crate2nix/issues/76 introduced tools.nix and nix functions for generating the build files in derivations. That allows users to skip checking in the generated Cargo.nix.
This does not work for "sub modules" yet.

Checking to make sure I'm on the right page, here:
In trying to build something using generatedCargoNix, I am getting
Checksum for interop_rust 0.5.1<EMAIL_ADDRESS>not found in crate-hashes.json
where interop_rust is a submodule.
This is done with the currently unreleased submodule functionality from fetchGit (introduced with https://github.com/NixOS/nix/pull/3166/).
Is it likely that I am encountering this issue?
Unless I'm misunderstanding the scope of tools.nix, it seemed sort of odd to need crate-hashes.json if I'm trying to refer to a remote repository that doesn't have Cargo.nix or etc checked in.


Is there any way to set xLabel array as Strings?

Hi.
According to the documentation xLabel is Float array but i want to set xLabel as String array such as ["foo" , "bar"].Any suggestion?

i figured out by examining other issues.thanks for great library.


[Proposed user happiness] Suggest for adding common headers in the reqwest::get method

Hello :)
When I try to make a request with reqwest.get(..).  It seems that the request doesn't contains any headers...  Here is my testing code:
    let client = reqwest::Client::builder()
        .build()?;
    let mut req = client
        .get("http://www.bing.com");
    println!("{:?}", req);

I think may be we can add the most common headers in the request.
python requests library, and postman both aoto-generates these headers:

User-Agent: PostmanRuntime/7.11.0 (or 'python-requests/2.21.0')
Accept: */*
accept-encoding: gzip, deflate
Connection: keep-alive

Especially, I found that some server will reject request without User-Agent.

The common headers are added just before sending, so that work isn't done hashing them into the header map if a user set them themselves. Try sending the request to httpbin.org/headers to see what is added automatically.

Ah.. I see it, very thanks for the useful httpbin.org/headers.
It's a big surprise to see that the "User-Agent" defaults to the default browser in my machine :)  And sorry for the disturb.


Hover on column is not removed when leaving the tree node

Hover class is only removed, when the cursor is moved to the next item.
https://github.com/mendix/TreeViewAndGridView/blob/master/src/TreeView/widget/TreeView.js#L654

Expect the hove to be removed whenever the move is not above the item.
Maybe it should be removed on the "mouseleave" event, but I am not sure if this will break the dnd

Adding a live connect did not do the trick.. : (
          lc(this, this.treeNode, "mouseleave", {
                "gg_column_wrapper": function (target, e) {
                    dojo.removeClass(this.hoveredCol, "gg_col_hover");
                    return true;
                }
            });

Fix from #20 added, thanks! Closing issue and creating a new release today


Node crashes when fetching blocks over RPC

When fetching blocks from the sidecar, a fully synced node sometimes crashes after sending a few thousand blocks.
2020-02-19 20:07:17          API-WS: disconnected from ws://<IP_ADDRESS>:9944 code: '1006' reason: 'connection failed'
2020-02-19 20:07:16          API-WS: disconnected from ws://<IP_ADDRESS>:9944 code: '1006' reason: 'connection failed'
2020-02-19 20:07:15          API-WS: disconnected from ws://<IP_ADDRESS>:9944 code: '1006' reason: 'connection failed'
2020-02-19 20:07:14          API-WS: disconnected from ws://<IP_ADDRESS>:9944 code: '1006' reason: 'connection failed'
2020-02-19 20:07:13          API-WS: disconnected from ws://<IP_ADDRESS>:9944 code: '1006' reason: 'connection failed'
2020-02-19 20:07:12          API-WS: disconnected from ws://<IP_ADDRESS>:9944 code: '1006' reason: 'connection failed'
2020-02-19 20:07:11          API-WS: disconnected from ws://<IP_ADDRESS>:9944 code: '1006' reason: 'connection failed'
2020-02-19 20:07:10          API-WS: disconnected from ws://<IP_ADDRESS>:9944 code: '1006' reason: 'connection failed'
2020-02-19 20:07:09          API-WS: disconnected from ws://<IP_ADDRESS>:9944 code: '1006' reason: 'connection failed'
2020-02-19 20:07:08          API-WS: disconnected from ws://<IP_ADDRESS>:9944 code: '1006' reason: 'connection failed'
2020-02-19 20:07:07.479  DEBUG libp2p_tcp  Dropped TCP connection to V4(<IP_ADDRESS>:30333)
2020-02-19 20:07:07.318 http.worker00 DEBUG tokio_reactor  dropping I/O source: 1
2020-02-19 20:07:07.319 async-std/net DEBUG libp2p_tcp  Dropped TCP connection to V4(<IP_ADDRESS>:30333)
2020-02-19 20:07:07.318 http.worker00 DEBUG tokio_reactor  dropping I/O source: 0
2020-02-19 20:07:07.318 http.worker00 DEBUG tokio_reactor::registration  scheduling Read for: 0
2020-02-19 20:07:07.319 http.worker20 DEBUG tokio_reactor  dropping I/O source: 0
2020-02-19 20:07:07          API-WS: disconnected from ws://<IP_ADDRESS>:9944 code: '1006' reason: 'Connection dropped by remote peer.'
2020-02-19 20:07:07.317 http.worker20 DEBUG tokio_reactor::registration  scheduling Read for: 0
2020-02-19 20:07:07.317 http.worker30 DEBUG tokio_reactor::registration  scheduling Read for: 0
2020-02-19 20:07:07.317 http.worker10 DEBUG tokio_reactor::registration  scheduling Read for: 0
2020-02-19 20:07:07.317 http.worker10 DEBUG tokio_reactor  dropping I/O source: 0
2020-02-19 20:07:07.317 main DEBUG service  Substrate service shutdown
2020-02-19 20:07:07.318 http.worker30 DEBUG tokio_reactor  dropping I/O source: 1
2020-02-19 20:07:07.317 http.worker30 DEBUG tokio_reactor  dropping I/O source: 0
2020-02-19 20:07:07.310 main-tokio- DEBUG libp2p_core::upgrade::apply  Successfully applied negotiated protocol
2020-02-19 20:07:07.310 main-tokio- DEBUG multistream_select::dialer_select  Dialer: Proposed protocol: /yamux/1.0.0
2020-02-19 20:07:07.308 main-tokio- DEBUG afg  Completed round 3856, state = State { prevote_ghost: Some((0x8fde89e3989f88b5b11b51f4fab805fa75e326e5946baae88d89f06ac75820be, 1111542)), finalized: Some((0x8fde89e3989f88b5b11b51f4fab805fa75e326e5946baae88d89f06ac75820be, 1111542)), estimate: Some((0x8fde89e3989f88b5b11b51f4fab805fa75e326e5946baae88d89f06ac75820be, 1111542)), completable: true }, step = None
2020-02-19 20:07:07.308 main-tokio- DEBUG afg  Round 3856: prevotes: 142/107/160 weight, 142/160 actual

Where is the panic? The log does not contain any information about a panic?

Where is the panic? The log does not contain any information about a panic?

2020-02-19 20:07:07.317 main DEBUG service  Substrate service shutdown
Not panic though, but still

I saw this, but there still could have been a panic. (Tokio catches panics)


Not translatable multi-site field shows HTML instead of source markdown

Steps to reproduce:

Start with a regular single site site_a.
Create a section with a Doxter field.
Create a new entry. Add some markdown content to the Doxter field.
Add a new site site_b.
Enable section for the new site site_b.
Value of the Doxter field in the new site_b is HTML. (Value of the entry on the old site_a is still markdown at this point of time.)
Save the entry.
Value of the Doxter field is now HTML on both the new site_b and old site_a variants of the entry.

Craft 3.0.32
Doxter 3.1.10

Wow, that's terrible.
Thanks for the report @rungta.
I'm in the middle of a big transition right now but I'll look into this as soon as I get a chance.
If you're able to track it down, I'd love to accept a PR.

@rungta I was able to replicate the issue you reported. Working on a fix!

@rungta Should be fixed in the latest release.


[Enhancement]: Add support for image pull policy configuration in JDBC-TC-URLs

Module
Core
Proposal
Hi,
Currently the JDBC-TC-URLs do not allow to configure the pull policy. E.g. we can define an URL as following
spring.datasource.url=jdbc:tc:postgresql:12:///MyDatabase
This starts a Postgres with the tag 12, but does not make sure that this is actually the latest Postgres with tag 12. In my case the code always used a 12.13 instead of the newer 12.15. It should thus be possible to configure the pull policy via the URL:
spring.datasource.url=jdbc:tc:postgresql:12:///MyDatabase?TC_PULL_POLICY=ALWAYS
Thank you and best regards
Nils

Hi, Thanks for raising the PR. However, Testcontainers JDBC URL server basic scenarios and currently there is no plans to support all features that are supported in PostgreSQLContainer. It is recommended in those cases to use PostgreSQLContainer directly.


Nested shape scoping bug in clauses

with module schema
select Constraint {
  name,
  params := (
    select .params { name }
    order by assert_single((
      with anc := (
        select Constraint.bases[is Constraint] limit 1
      ),
      select anc { params filter .name = Constraint.params.name }
       .params@index
    ))
  ),
  subject: {name}
}
filter .name = 'std::min_value'
and .subject.name = 'listen_port'
limit 1;

fails with
CardinalityViolationError: assert_single violation: more than one element returned by an expression

Trivial modifications don't change too much: putting a shape directly on params still breaks, using .name instead of @index breaks, putting the expression in a filter clause instead of an order clause still breaks, setting __internal_no_apply_query_rewrites to make sure the schema magic doesn't affect it still breaks, writing out Constraint.params in the top shape still breaks.
But declaring the ordering expression as a computed expression in the .params shape and ordering on that works.
The issue is that the inner reference to Constraint.params isn't binding correctly, and is fetching all the params for the constraint, not just the matching one.

Reduced version:
select User {
  deck: { name } order by { asdf := User.deck.name }.asdf
}
filter .name = 'Alice';

fails with InternalServerError: more than one row returned by a subquery used as an expression.
(It's a different error but the exact same problem. If you mark asdf as multi and add an assert_single you will reproduce the assert_single error.)

Any updates on this? Also, could you please provide an example of a workaround for this, cause I am currently stuck with pretty much the same issue and I don't understand exactly how to make it work


Update Docker Base Image to amd64/ubuntu:22.04 for Compatibility

This Pull Request introduces a change to the base image in our Dockerfile, standardizing it to amd64/ubuntu:22.04. This update is aimed at addressing compatibility issues observed when running our Docker containers on different architectures, particularly on macOS with M1 or M2 chips.
Previously, the Dockerfile used a generic ubuntu image, which led to architecture-related inconsistencies, especially in environments with ARM-based processors like Apple's M2 chips. By explicitly specifying amd64/ubuntu:22.04, we ensure that our Docker environment is consistent across all platforms, leveraging the emulation capabilities for AMD64 architecture on ARM-based systems. This change is crucial for maintaining a uniform development and deployment experience, especially for team members working across different hardware setups.
This update does not affect the functionality of our application but enhances the reliability of our Docker setup in diverse development environments. It's a step towards ensuring that our Docker containers run smoothly, both in development and production settings, regardless of the underlying hardware architecture.

Thanks.
I tested make install-for-dev and docker compose up on my Linux system and they still seem to work nicely.
I'll ask two reporters of problems if they can test on their ARM architectures.


Split preactivation from FNOBlock.forward()

Mainly, refactor FNOBlock.forward() for readability:

Create a separate method FNOBlock.forward_with_preactivation() where it is assumed preactivation=True for clarity of code flow. Likewise, assume preactivation=False in the new method FNOBlock.forward_with_postactivation(). The old method forward() now dispatches to one of these.
In multiple places, we were checking self.output_scaling_factors and calling resample like boilerplate. Refactor this check and call (with a no-op return if scaling_factors is None and output_shape is None).
Additionally, refactor out output_scaling_factors validation, which was being duplicated across 4 files.

Reviewer(s): @JeanKossaifi @zongyi-li

This is great, thanks for all the changes @m4e7! Merging.


Hide sidebars when searching and pressing enter

closes #62
No Modal, but also works

rename to left and right side bar


How can I prevent the user of block chomping indicators?

Hello,
I have a yaml file which looks like this
- question:
    en: This is a very long question
      with multiple lines

When parsing it and returning it again, it looks like this
- question:
    en: >-
      This is a very long question
      with multiple lines

How can I prevent using >-?

I know it is very similar to https://github.com/nodeca/js-yaml/issues/357 but I don't want to increase the line I just want to keep the previous structure.

That's not possible. This package is not designed for "text edit". Only for load and dump.

@puzrin Thanks a lot for your quick response. Can you explain what you mean with "text edit"?
Looking at ruby psych, for example, I can see that it doesn't change multi-line text in this way.

That means - respect original formatting. When js-yaml reads data, it knows only about data, not how it was formatted.

So, you are basically saying that the parser shouldn't care about the format, is this correct?

That depends on parser goals. This parser is for "data and speed", and it doesn't care about source format after load.

OK, thanks for clarifying this.


HASS errors

There is an error in the custom component. Namely on connection.py, on line
self._connection.set_eth(ip=await async_get_source_ip(self._hass))
HASS wont finalise setup of the integration and complains that the function "async_get_source_ip()" lacks required argument "target_ip". From official repo i was able to find that indeeed it needs this second argument. A possible fix i implemented to my own files was:
from homeassistant.components.network.const import IPV4_BROADCAST_ADDR
...
self._connection.set_eth(ip=await async_get_source_ip(self._hass,IPV4_BROADCAST_ADDR))
After that I got everything working and was actually able to turn the device on from HASS.

Thanks for contribution! It's actually pretty interesting since I've never encountered this error myself, and built-in local_ip integration uses this function without target_ip here.
I'll implement your fix though, since it doesn't brake anything.


Java

[ ] I am using the latest SDK version
[ ] This API is compatible with my vCenter version (You can get this info from the API documentation )
[ ] I have searched existing issues

Description
Environment

SDK version:

Java version:

vSphere version:

Steps or code snippet to reproduce
Actual behavior
Expected behavior

Insufficient data. Kindly reopen with appropriate details.


MVT layer with geometries other than 3857

Only EPSG:3857 geometries are currently supported for MVT layer. This seems to be a bug. Geometries in other projections should work as well.

This is fixed by checking for the layer srid and applying a transformation is necessary.


feat: Modify Helm chart to run alongside v1 driver

What type of PR is this?

/kind feature
What this PR does / why we need it:
Modifies Helm chart to allow V2 driver to run side-by-side with V1 driver
Which issue(s) this PR fixes:

Fixes #190
Requirements:

[x] uses conventional commit messages

[ ] includes documentation
[ ] adds unit tests
[ ] tested upgrade from previous version

Special notes for your reviewer:
Release note:
none

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+1.7%) to 44.391%

Totals

Change from base Build<PHONE_NUMBER>:
1.7%

Covered Lines:
186

Relevant Lines:
419

💛  - Coveralls

Verify fails because the package and repo need indexing:
$ helm package charts/v2.0.0-alpha.1/azuredisk-csi-driver -d charts/v2.0.0-alpha.1/
$ helm repo index charts --url=https://raw.githubusercontent.com/abhisheksinghbaghel/azuredisk-csi-driver/master/charts

The sanity test failure is a known issue with the test. It is not related to this PR.
Message: "rpc error: code = NotFound desc = Retriable: false, RetryAfter: 0s, HTTPStatusCode: 404, RawError: {\"error\":{\"code\":\"ResourceNotFound\",\"message\":\"The Resource 'Microsoft.Compute/disks/CreateSnapshot-volume-3' under resource group 'azuredisk-csi-driver-test-f18c2bc9-2ae4-11ec-9c2f-000d3a5df04a' was not found. For more details please go to https://aka.ms/ARMResourceNotFoundFix\"}}"


Feat/Hashers: Implement siphash24

U can watch how it implemented in rust.
We expecting from this PR:

hashing algorithm in Zig style (u can watch std.crypto.hash.sha2 family or other)
tests

For styling u can watch std siphash64

Hi @StringNick, can I work on this issue?


Realtime_price.py

I have added a web crawler which works for all cryptocurrency.

Error

File "main.py", line 20, in get_crypto_price
text=soup.find("div",attrs={'BNeawe iBp4i AP7Wnd'}).find("div",attrs={'BNeawe iBp4i AP7Wnd'}).text
AttributeError: 'NoneType' object has no attribute 'find'

Refer to
https://stackoverflow.com/questions/21421417/python-attributeerror-nonetype-object-has-no-attribute-findnext
https://stackoverflow.com/questions/46627234/im-getting-attributeerror-nonetype-object-has-no-attribute-find


Migration from legacy Edge to Chromium Edge failed

I just got (kinda forcefully) upgraded from legacy Edge to the new Chromium Edge, and now my Authenticator appears to have reset itself; the password on it is gone, and so are all of my codes. Since I could never export a backup ("due to a bug in Edge", it said), I don't have a backup to import. How can I have the Authenticator in Chromium Edge load the original codes from legacy Edge, as this doesn't appear to be documented anywhere?

The data should have been automatically migrated (I reached out to MS to make this happen), and dealing with old Edge was just a never ending headache of incompatibilities and bugs that were never fixed. There was a method to take a backup but it was very convoluted.
I can't really do anything about this outside of trying the following:
Legacy Edge's extension data used to be stored under the following folder, if it still exists and you can find your data, you should be able to just restore it as a text backup.
C:\Users\%username%\AppData\Local\Microsoft\Edge\User Data\Default\Extensions

I'm assuming that you were upgraded to new Edge via a feature update to windows, and there is a method to revert to a previous version of windows within 10 days of an update. This may restore the data and temporarily allow you to take a backup before migrating to new Edge again.
https://support.microsoft.com/en-us/windows/recovery-options-in-windows-10-31ce2444-7de3-818c-d626-e3b5a3024da5#bkmk_section6


:fire: :coffin: Remove Redis and Webhooks Web from Tilt

Remove Redis and Webhooks Web from Tilt
Make Endorser depend on NATS

EKS tests are failing, most likely due to the Alembic PR and DB migrations.
This doesn't affect EKS at all, so I think this is safe to merge @ff137 @cl0ete


imutils import error

i installed latest version of imutils by
pip install imutils
then i created a python file with single line of code in it
from imutils import face_utils
after building ironpython, i created new C# project and added all dll files (that were built)  as reference
below is the code i'm using    (added module path in searchPah to avoid module not found)
var engine = Python.CreateEngine();
var searchPaths = engine.GetSearchPaths();
searchPaths.Add(@"C:\Users\username\AppData\Local\Programs\Python\Python36\Lib\site-packages");
engine.SetSearchPaths(searchPaths);

var mainfile = "sample.py";
var scope = engine.CreateScope();
engine.CreateScriptSourceFromFile(mainfile).Execute(scope);

when i run above C# code, i was getting  "No module named future "
so i updated my python file with below code
import sys
sys.path.append(r'C:/Users/username/AppData/Local/Programs/Python/Python36/Lib')
sys.path.append(r'C:/Users/username/AppData/Local/Programs/Python/Python36/Lib/site-packages')
from imutils import face_utils

now when i run above C# code, i'm getting a different error

An unhandled exception of type 'IronPython.Runtime.Exceptions.TypeErrorException' occurred in Microsoft.Dynamic.dll
Additional information: _add_filter() got an unexpected keyword argument 'append'

how to solve this?
Thanks & Regards

IronPython3 is not ready for use at all.

No longer getting the TypeError described above but the following:

ImportError: No module named 'numpy'

Unfortunately numpy is a C extension and does not work with IronPython.


Text marked at the wrong place

https://www.netbank.de/nb/downloads/Informationsbogen.pdf
enter "obergrenze" in the search field. There are 5 hits, the 2nd, 4th and 5th are at the wrong place.
I am using FF 42 on a W7 system.

This appears to have been fixed by a recent commit as I cannot reproduce it with the latest PDF.js development version. Could you try opening the file with https://mozilla.github.io/pdf.js/web/viewer.html (Open File button in the toolbar) and see if you can still reproduce it? It works fine for me with that version.

That's the viewer I used... and I just retested it right now!

From looking at the screen-shots: it seems like the entire viewer (including the UI) is slightly zoomed in, which might explain the alignment issues.
@THausherr If you reset the zoom level of the browser (Ctrl+0), does the problem go away?

I can indeed reproduce the behavior in the screenshot when I zoom in to 110%. For 100% zoom there is no problem. This is now a confirmed issue, but I'm not sure if it is a regression from one of the text selection PRs.

@Snuffleupagus it happens also with CTRL-0. And with different zoom levels below 170%. However I have set up windows that it has slightly bigger fonts than normal (125%).
Btw I didn't receive a copy from your message, only from Tim. And nothing in my spam folder.

Yes, that font size change might also have something to do with this. Thank you for reporting it, we need to look into this.

I think I have a same problem with this. when I select text to copy and paste it into the editor, the text look like moved some letters from my selection.

I have tried with search:

I used this document:
C-View Letter to Vendor.pdf
This bug just happen on Firefox only. I am using version 42.0.
Please support this. Thanks a lot.

new example on this:
https://www.klinikum.uni-heidelberg.de/fileadmin/inst_hygiene/med_mikrobiologie/download/MB-Desinfektionsmittel.pdf
MB-Desinfektionsmittel.pdf
Enter "Rezeptur" into the search field, and see this:

The "offset" seems to be cumulative, it starts small when searching for "Sterillium® classic pure" and gets bigger and bigger. Searching for "standardmäßigen" shows this:

So it is now marked on two different lines!

Closing since this is now fixed after recent search normalization and text layer fixes.


[Feature Request] Loading component on v2

Is your feature request related to a problem? Please describe.
Ask about Loading component from v1
Describe the solution you'd like
Hello, I am starting to modify my project from v1 to v2, now I got this error: 'Loading' is not exported from '@nextui-org/react'
I tried to find the loading component on tailwind but can not find it, can you help?
Describe alternatives you've considered
I want to use component like Loading from v1
Screenshots or Videos
No response

For v2, please use Spinner


More granularity or making step offset configurable

Checklist

[x] I have searched for existing issues

Is your feature request related to a problem? Please describe.
I can only change volume in steps of 6%. But this sometimes is too loud/silent thus better granularity would be great.
Describe the solution you'd like
Either more granularity or making the offset configurable.
Describe alternatives you've considered
Having sound that is too loud/silent? 😉

Was just about to request this! My monitor volume is not linear, 0-15 goes loud and 16-100 is about the same. An input field for the step size would be great.

This is build into macOS by default.
Press and hold Shift + Option then use Volume Up and Volume Down keys to make a more granular adjustment.

Press and hold Shift + Option then use Volume Up and Volume Down keys to make a more granular adjustment.

Indeed. This (very non-obvious) shortcut is working perfectly!
Thank you!


[Search Directory] Use fd or fdfind unaliased to resolve apparent hang

A cursory search through GitHub code for "alias fd fdfind" reveals hundreds of pieces of code that aliases fdfind to fd instead of using symlinks (in spite of fd's instructions to symlink instead). And that's just the code that's public! The problem with this is that fish functions buffer their output, so when fd is aliased, Search Directory does not pop open fzf until fd is done outputting files. If Search Directory is triggered in $HOME or some other large directory, then Search Directory appears to hang unresponsively.
We fix this by using the fd binary directly. Since presumably many of fzf.fish users on certain Linux distros have it installed as fdfind, we look for either binaries and use it. Resolves #281.

The test "~/ is expanded to HOME" failed because the test works by capturing the fd arguments using a wrapper function, but now that we are using command, the wrapper function is bypassed. We'll need to rewrite the test. I'd test it now by creating a directory with an certain number of files in it, scope the search to that directory, select all, and test that the number of files outputted = number of files in that directory.

On Ubuntu there is a default fd which is a different CLI utility entirely (File & Directory tool)
So when the fd_cmd searches for fd first, it finds it but it still results in a broken directory search
set fd_cmd (command -v fd || command -v fdfind || echo "fd")

Intstead, if the first check is for fdfind
set fd_cmd (command -v fdfind || command -v fd || echo "fd")

this operates properly even though there is a preexisting, incorrect fd.

Thanks @zolrath for reporting this. My bad, this is why I need code reviews 😅
Just curious, is fd (File & Directory tool) a default tool on Ubuntu? I hope I didn't just break this for ALL Ubuntu users.

Fixed in https://github.com/PatrickF1/fzf.fish/commit/7b14fa7a54d1f91ce946c3f1651e26cc4a3dcd6c

Thanks @zolrath for reporting this. My bad, should've been an easy catch if I had thought it through. This is why I need code reviews 😅 Just curious, is fd (File & Directory tool) a default tool on Ubuntu? I hope I didn't just break this for ALL Ubuntu users.

Yep, it's at least installed by default in 22.04!


Patch-1: Administrator & Educator Prompts

This pull request includes additional prompts for Educators and Administrators, as well as updated Readme files that link to those prompts.

Thanks for the submission! We are reviewing these prompts.


Add 'dev' attribute for each building block

Hi all,
I'm trying to develop a workflow with these libraries, but I keep finding myself needing extra command line options that're not supported. This is to be expected as there're a ton of available tools, with a ton of options and they're only going to get even more numerous.
So that's why I think that the dev attribute of the mdrun building block is necessary to support real-life workflows. Currently I'm patching the code to add it on each class where I need it, but it'd be nice to have the extra flexibility, at the developer's responsibility.
Thanks.

Hi!
That's a very good idea! I have implemented this feature in the biobb_common generic object, so right now every block has the dev option. The downside is that this new features will not be in the conda installer until the next release (v3.8). As an advanced user I recommend you to download (clone) the git version of biobb_common and use that one to benefit from the latest features.
Regards,
Pau Andrio


lnwire: only check payload for proper size if encoding type is sorted…

… plain
In this commit, we fix a slight bug in the parsing of encoded short
channel ID's. Before this commit, we would always assume that the remote
peer was sending us the sorted+encoded variant of the short channel
ID's. In the case that they weren't (as there isn't yet a feature bit),
we would assert this check and fail early as atm we don't support any
sort of compression.

Yep, we'll just ignore their message.


Final script tweaks for g9 closing

Adds G9 lots and declaration fields we want to extract.
Also a small bugfix.
Tests are now dependent on this being merged:

[x] https://github.com/alphagov/digitalmarketplace-utils/pull/305

:+1:


chore: migrate build.ps1 to build.sh

IMHO this was a wrong decision. This made the script platform dependent.

IMHO this was a wrong decision. This made the script platform dependent.

We expect to have mingw/cygwin (aka. Git bash) available on win systems, which you can use to get a bash and run the script from.


Improve note commitment tree append performance

Motivation
Alfredo and I have been doing some timing tests on Zebra's CommitBlock and CommitFinalizedBlock state requests.
In some of my tests, Sapling note commitment tree appends were taking multiple seconds to run.
This is probably due to the large number of new Sapling notes in the chain.
We should try to improve performance of this code.
Suggested Changes
Add benchmarks for:

note commitment tree appends on random notes
note commitment tree appends on large sprout, sapling, and orchard blocks (#4774 & #4775)
note conversion to the correct type
the inner functions that do the update, without acquiring the ReadWriteLock

Once we have benchmarks, try to improve the performance of the code:

pass a vector to the append method, and only acquire the ReadWriteLock once
inline the functions that are called when appending note commitment trees
try different compiler options?

Performance improvements are a low priority for Zebra at the moment.


Update footer.hbs

I'm closing this PR as well basically due the same reasons as your previous PR, plus, if you want to delete the "Published with" part please only do it on your own fork because that part is a Ghost requirement for all themes ;)


update: add entry for templates

Added a templates entry with a link to my shuttle-template-yew repo.

Hey Jeff!
I think your repo is perfect for adding here instead https://github.com/shuttle-hq/shuttle-examples#community-examples
(We've been bad at marketing that list. At least I'm adding a link to it in #7)

Awesome! I will open a PR there to incorporate it.


Throw error if no GPUs supplied and GPUs=true or reverse

Easy to mess up before I've had my coffee; impossible to figure out currently except by experience. Write a statement to check if GPUs are available to the script and compare against the gpu line in the config file

Im going to delete this because it falls under Yaml validation now


Need clean way of freezing longitudinal coordinates

Users would like to have frozen and non-frozen tracking methods available at the same time
We want a general high-level way of handling compile flags. Something like:
tracker.config.freeze_longitudinal = True
tracker.config.synchrotron_radiation = False
...

Frozen var example available at:
https://github.com/xsuite/xtrack/blob/main/examples/full_ring/007_test_freeze_vars.py

Resolved


iPN seems to include both mALT and mlALT PNs but should only include mALT

Class def says they fasciculate with mALT, but also says:

but some are GABAergic (Wilson and Laurent, 2005; Jefferis et al., 2007).

when these neurons are the ventral cell body class sometimes referred to as vPN.

It's been corrected.


Older direct links stop working

I opened this message direct link from Jul 5
https://view.matrix.org/room/!wSdymYrEpBhsWlDJuk:decred.org/?anchor=$153090455433548QNlFj:decred.org
and it showed "Some error has occurred". Then I removed the anchor part from the URL to open latest messages in the room and pressed "Load older messages" until I reached Jul 5 and it showed the message I was after. Then I visited initial direct link again and it opened.
Example of direct link that doesn't work (until someone visits it via "Load older messages"):
https://view.matrix.org/room/!OfChXgczrIlpEZSFAv:decred.org/?anchor=$153125687135698lmQRO:decred.org

Yes because of the limitations of the peeking APIs it cannot access old events without having to paginate to them which would be very expensive

Does it mean a won't fix?

It'd mean having to persist things locally (duplicating data) but it's not completely out of the question

Thanks. I guess I shall be using matrix.to "dispatch" links then -- tried opening some "old" links in Riot and they open pretty fast.

Riot uses the context api which is relatively expensive and would have to be done for each event, matrix-static pulls pages of events in order and already runs into issues with hitting the server too much

Related: #115


[webinterface] add theme support

[ ] add support for themes/skins to the webinterface
this allows to create a mobile friendly theme, ref. #448

---
Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/26846090-webinterface-add-theme-support?utm_campaign=plugin&utm_content=tracker%2F164029&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F164029&utm_medium=issues&utm_source=github).

Will not implement.


Update haikus.json

dddd

አመሰግናለሁ እኔ ትክክለኛ የኤሜል አድራሻ የሚሰጠኝ አጥቻለሁ አና የትኛው ነው የምጠቀመው ?
vivo22
On Tue, Jan 9, 2024, 11:17 PM SultanAlZoubi @.***>
wrote:

Closed #273 https://github.com/github/haikus-for-codespaces/pull/273.
—
Reply to this email directly, view it on GitHub
https://github.com/github/haikus-for-codespaces/pull/273#event-11435060112,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/BEFVQ55KNLNOOVWOVVCULI3YNWQT5AVCNFSM6AAAAABBTVWLYKVHI2DSMVQWIX3LMV45UABCJFZXG5LFIV3GK3TUJZXXI2LGNFRWC5DJN5XDWMJRGQZTKMBWGAYTCMQ
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***
com>


feat: hivemind-plugin-manager

hivemind-core is starting to grow with implementation specific / non protocol related code
components to pluginify:

database
network protocol #21
agent protocol #22

https://github.com/JarbasHiveMind/hivemind-plugin-manager

network protocol plugins:

https://github.com/JarbasHiveMind/hivemind-websocket-protocol

binary protocol plugins:

https://github.com/JarbasHiveMind/hivemind-listener/pull/21

agent protocol plugins:

https://github.com/OpenVoiceOS/ovos-bus-client/pull/155
https://github.com/JarbasHiveMind/hivemind-persona

database plugins:

https://github.com/JarbasHiveMind/hivemind-sqlite-database
https://github.com/JarbasHiveMind/hivemind-redis-database
https://github.com/TigreGotico/json_database/pull/7

closes by #30


ruby1.9 support

Hi Joe,
What would be involved in getting this beauty working with ruby1.9?  We find your gem extremely useful for kerberized capistrano deploys.
Ciao,
Sheldon.

+1 Would really love to use this gem but the 1.9 limitation is a showstopper. Please update.

It looks like the dl module has a completely different api in ruby 1.9.  Pretty much all of the code in kerberos/drivers/gss.rb and sspi.rb would need to be thrown out.  The good news for the gss.rb is that it seems that it'd probably be do-able to use the gssapi module, which uses ffi.  The downside is that the gssapi maintainer is listing ruby 1.9.1 as the minimum compatible version even though ffi is supposed to work on 1.8.7.
I've taken a stab at adding the necessary support to gss.rb via the gssapi module, but I'm not up to the task with the time I can commit to it right now, but I can certainly help test and fix if someone (Joe?) can lead the way.

+1 -- I find myself in sudden need of this.


Serial and SoftwareSerial port comments

Added a description of the Stream parameters passed to TheThingsNetwork library. Elaborate about Software Serial and serial on other devices.

Maybe the description of the Serial ports belongs better in https://github.com/TheThingsNetwork/docs/edit/master/_content/devices/arduino/usage.md than in the API reference. Should I move it?
I should also add a comment about a level shifter and/or voltage levels (3.3V vs 5V) for when someone builds their own device.

Yes indeed


Entities provided by Articulate

Issues
Please describe the issue you are having here and answer the question below.
Not sure if it is the version causing this. When I was trying to use original entities provided by you. Like spacy.number or any similar.
I can not see any of those on the list. What this could be caused by?

You can only see my entities. That I have created.
Thanks !

Did you download a release or pull from Master? Which release?
--> v0.12.3
What operating system are you running?
--> Ubuntu
Are you running locally or in the cloud?
-->Locally
Which browser are you using?
--> Chrome

Oh sorry I see now, it is available. I just can not apply my own word to your entity straight away.
But I can only apply it in "Slots" is that correct ?

Just got mixed, as I think it used to be available to apply own words at "User Says" to your entities?#
Thanks

Alright I see your point, thank you.
That would be nice if u'd have a go on that and show me how it works, only if you can. I'd really appreciate.
Cheers !

@bkurowski same here, I dropped the ball on testing space money, did you get it working for you?

Did not get that fixed, was not required so much yet to use your built entities. But eventually i will use those. I've only tested it once/twice with no success. So I do not have any good news for you. But I will start testing it soon.
After Christmas 💃 🥇
Best Regards


Cross-compiling results in Path not ending in ;

Cross-compiling a Windows-rs project from Linux (ie. one of the test crates within this repo) result in the following build error:
$ cargo b -p test_bstr --target x86_64-pc-windows-gnu
...
error: proc macro panicked
 --> tests/bstr/build.rs:4:5
  |
4 | /     windows::build! {
5 | |         Windows::Win32::Foundation::BSTR,
6 | |     };
  | |______^
  |
  = help: message: Path not ending in `;`

The PATH variable on Linux is separated with colons, not semicolons.
It is worrying to see the same undocumented logic and error duplicated across three distinct places in the codebase. What is the first path in PATH supposed to point to? Why are the winmd files copied to ../../.windows/winmd relative to it? Do I need to worry about the bit that copies to %PROFILE%, too?
On a related note, is it worth turning the cargo build for ubuntu-latest in the CI into cargo check --all --target x86_64-pc-windows-gnu, to ensure cross-compiling remains in working order?

This issue appears to be causing the windows-app docs build to fail. Though I'm not a big fan of sinking too much time into getting cross-compilation to work, this is probably something that would need to be addressed, on way or another.

@tim-weis It appears these PATH changes (and the 5-or-so yanked releases with it) were made to accommodate broken docs.rs changes in the first place; curious to hear what it's all about (I hope the first path isn't pointing to system32) and how we can address this uniformly.
FWIW I have previously been told that cross-compiling support is a big deal for windows-rs (unfortunately natively using autogenerated COM bindings on Linux is not :|), and am personally rolling it out to quite a few projects as it is - especially on GH Actions - several orders of magnitude faster than natively compiling Rust projects on Windows.

This is a know issue. Would appreciate any suggestions as I've not found a satisfactory way to deal with problem. This started with the introduction of packaging support where crates like windows-app need to provide binaries to dependent crates. The difficulty is in determining the target directory so that such crates can copy their binaries to a location where the dependent crates can make use of them.
I have described this problem in more detail here and why the PATH environment variable is being used. I certainly don't like the current solution but haven't found anything better. And yes, it means that the windows-app docs are indefinitely broken.
I burned through a few published crate versions testing packaging support because Cargo behaves differently depending on whether dependencies are published or not and without a reliable way to find the target directory it became quite a problem to test reliably.

The PATH variable on Linux is separated with colons, not semicolons.

If the target directory is in the same location on Linux then perhaps that would at least solve the docs and cross-compilation issue.

@kennykerr That seems like an exceptionally annoying problem to have. Thinking out loud, let's go over the call-sites:
crates/macros/src/lib.rs seems to be the most complex, but ultimately results in copying .windows/{target_arch} to the target directory (as well as winmds provided by dependencies). On Windows, DLLs are loaded relative to the started binary. On Linux however, they are loaded relative to the working directory (disregarding standard search paths and RPATH logic). We can possibly just disable this codepath, simply bailing if %PATH% doesn't contain anything satisfactory (after all, this crate is not supposed to be built, or be building anything, for Linux).
Either way, I have not come across a crate that helps dependent crates copy extra libraries to the target folder, especially when that dependent (directly built) crate provides the libraries itself. It should probably have that as its own build step depending on how the crate is debugged and packaged (windows-app-rs being the prime example here).
Then, crates/gen/build.rs on cfg(windows) copies winmd files from crates/gen/.windows/winmd to the target directory, for crates/gen/src/workspace.rs to pick them up. Afaik this was working just fine for dependent crates before, what changed?

The PATH variable on Linux is separated with colons, not semicolons.

If the target directory is in the same location on Linux then perhaps that would at least solve the docs and cross-compilation issue.

The deps folder is not added to PATH anywhere on Linux.

Afaik this was working just fine for dependent crates before, what changed?

Previously this worked because the gen crate used include_bytes! rather than packaged files directly. This worked well enough (ignoring the fact that its really slow) for the windows crate (since the build macro knew about it) but not for other crates with binary dependencies. The build! macro needs to be able to discover these other binary dependencies so that it can index any potential winmd files.

Agreed include_bytes! is far from ideal. Perhaps CARGO_MANIFEST_DIR can be used without copying anything, though? As per the documentation this is available in build.rs (where build! is called) and always points to the manifest directory of the current crate being built, not the crate that uses it as a dependency. In theory it should be possible to:

Scan "custom" winmd files in %CARGO_MANIFEST_DIR%/.windows/winmd, for dependent crates;
Forward CARGO_MANIFEST_DIR from a build.rs in windows_gen to the built binary, so that it can find the base crates/gen/.windows/winmd files provided by this repository;

Without providing any copy-logic or PATH magic whatsoever. That leaves only the "dll copy" issue to be resolved, which IMO doesn't seem the responsibility of windows-rs.
However, I think you have already explored this solution?

https://github.com/microsoft/windows-rs/compare/master...MarijnS95:winmds @kennykerr Would something like this work for you?

Does this change affect consumers of the windows crate, in that they are now responsible for .windows deployment? That's unacceptable if so.

@riverar not at all. Winmd from win32metadata is still provided by the windows_gen crate, and crate users are still responsible for providing their own winmd and dlls for "external" bindings that are not within the windows SDK as provided by win32metadata.

OK but unless I'm misreading the changes (very possible), it looks like all the logic around copying files out of .windows was removed and that's now a task every single developer has to worry about?

Yes, its important to keep the different scenarios in mind. There are basically three.

Crate (A) only uses the default metadata provided by the Windows crate (B) in order to call in-box APIs. No problem.

Crate (A) also provides its own or additional APIs via a .windows folder local to crate A using the windows::build! macro. No problem again.

Crate (A) also depends on additional APIs provided by a third crate (C) where this other crate has a .windows folder. The windows::build! macro must find the .windows contents from crates A, B, and C. It is this three-crate scenario that is the problem. Other variations of this scenario may exist in future. A goal is to avoid having A write extra build macro goo to copy stuff from C.

Other non-Rust build systems make this possible by allowing shared target folders.

OK but unless I'm misreading the changes (very possible), it looks like all the logic around copying files out of .windows was removed and that's now a task every single developer has to worry about?

The goal is to get rid of copies entirely, at least for .winmd files and replace that with passing down the path to these files. That way there's no ambiguity with files parsed in the wrong order (ie. to supersede "builtin" files from windows-rs with a newer version) or identical-named files being overwitten by the order cargo builds the crates in. Nor (the main reason) do we have to figure out what shared target/ folder to use.
dll copies to the target/ folder on the other hand are IMO - since windows-rs doesn't provide any such files anyway - up to the dependent crates, if they need it at all. Otherwise it might be more sensible to provide a helper function like windows::please_copy_dll_files_to_the_right_target_folder_for_me(".windows/").

Scenario 3

Scenario 3 is the one I don't want to encounter, at least not in the implicit way it is now. What happens if I add a crate D, that has nothing to do with B nor C but only wishes to pull things from the .winmd provided by A (windows-rs) and by chance itself?
Would you be opposed to make .winmd inheritance explicit? Crate B could, through the build! macro, reexport its own .windows/winmd path for crate C to use (or not!), or reexport a build! macro that takes care of the windmd's of crate B. Then again we'd be combating the copy-to-shared-target-folder magic, and scan all files in the right order once again - without overlapping names.
A shouldn't have to write extra macro goo to deal with stuff from C. C however, should - to be explicit - need an extra line to specify it wishes to take into account the winmds "exported" (or otherwise explicitly provided) by B (and recursively A). Then one can easily add diamond inheritance, say where C wants to read winmds from B and an imaginary crate E.

Additionally, note that I don't expect crate A to ever see the winmds provided by B nor C; neither should B see the files from C.

dll copies to the target/ folder on the other hand are IMO - since windows-rs doesn't provide any such files anyway - up to the dependent crates, if they need it at all. Otherwise it might be more sensible to provide a helper function like windows::please_copy_dll_files_to_the_right_target_folder_for_me(".windows/").

The windows-app crate has dependencies that need to be deployed with the consuming crate's target app. Most Windows app developers will need to minimally author a fusion manifest (.exe.config), store it in .windows, and deploy it into the target folder post-build. Forcing every developer to write the code needed to copy those files, or explicitly call the same helper function, is not ideal.

Would you be opposed to make .winmd inheritance explicit?

Hm, any further details? Requiring developers to directly specify winmds for import (e.g. import Microsoft.Win32.winmd) means they would have to figure out what winmds a crate offers and figure out how those winmds correlate to the APIs they wish to use. I believe that'll be very confusing and awkward.

dll copies to the target/ folder on the other hand are IMO - since windows-rs doesn't provide any such files anyway - up to the dependent crates, if they need it at all. Otherwise it might be more sensible to provide a helper function like windows::please_copy_dll_files_to_the_right_target_folder_for_me(".windows/").

The windows-app crate has dependencies that need to be deployed with the consuming crate's target app. Most Windows app developers will need to minimally author a fusion manifest (.exe.config), store it in .windows, and deploy it into the target folder post-build. Forcing every developer to write the code needed to copy those files, or explicitly call the same helper function, is not ideal.

This sounds like a feature specific to windows-app and should hence reside in that crate instead?
Either way I'm fine disabling this with #[cfg(windows)] when cross-compiling.

Would you be opposed to make .winmd inheritance explicit?

Hm, any further details? Requiring developers to directly specify winmds for import (e.g. import Microsoft.Win32.winmd) means they would have to figure out what winmds a crate offers and figure out how those winmds correlate to the APIs they wish to use. I believe that'll be very confusing and awkward.

Downstream crates shouldn't have to explicitly specify the winmds they wish to pull in, given that they would probably have to scour the source of their upstream crate to find out. The name-ambiguity problem as outlined above remains.
Rather, downstream crates should specify - for example by means of calling the build! macro on a different crate/module (that is auto-generated) - of what crates they want to use their winmds. In Kenny's third example, crate A could call C::windows::build!, which is an autogenerated macro that passes its own $CARGO_MANIFEST_DIR/.windows/winmds path recursively into B::build!. That way some irrelevant windows crate D will call B::build! (B is this windows crate) without ever seeing the winmds provided by C. At the same time no copies are necessary, because the full path to all source folders containing winmds is known.

In practice, I don't think scenario 3 is going to be very common at all. It's just something we need for the windows-app crate and perhaps one or two others down the road. We'd just like it to work as smoothly as possible. But the vast majority of projects will be well served by scenarios 1 and 2. Ideally, Cargo itself can eventually pick up the slack and provide first-class support for binary packaging.

@kennykerr While it'd be nice for cargo to pick this up it's still a highly specific scenario (collecting a [list of a] bunch of files to take into account during a build.rs step), that can be implemented in a multitude of ways. Being able to find the current target folder as linked before doesn't seem to provide that anyway, but I don't think that's the solution you're looking for either?
Anyway, what is your view on the proposed solution above? It'll get rid of the PATH and copy magic for the time being, enabling cross-compilation again. I doubt cargo shows up with a reasonable solution for this specific problem any time soon.

I've decided to just rip out the binary packaging support for now. Its not an urgently-needed feature right now and we can always revisit in future. The Windows crate will thus continue to support the first two scenarios above.

@kennykerr So not just binary packaging support, but also recursively re-providing winmds during build/compilation to support scenario 3?
Anything I can help out with by rebasing and submitting the branch above?

I'm going camping so I won't get to this in the next week or so. All the scenario 3 code can disappear.

If the consuming crate/workspace doesn't have a .windows folder then the build macro simply uses the winmd files from the windows_gen crate.

If the consuming crate/workspace has a .windows folder then the contents of the .windows/ folder (if any) is copied into the target_dir so that cargo run "just works" and the contents of the .windows/winmd folder (if any) is included in the TypeReader.

I'm happy to take care of this upon my return, but feel free to jump start the process if you're confident you know what's required. I just won't be around to spot check. @riverar may be able to help keep an eye on things.

I'm going camping so I won't get to this in the next week or so. All the scenario 3 code can disappear.

Nice, enjoy and have fun on your week off!

If the consuming crate/workspace doesn't have a .windows folder then the build macro simply uses the winmd files from the windows_gen crate.

Yes, that makes the most sense.

If the consuming crate/workspace has a .windows folder then the contents of the .windows/<arch> folder (if any) is copied into the target_dir so that cargo run "just works" and the contents of the .windows/winmd folder (if any) is included in the TypeReader.

I thought we wanted to get rid of copying altogether? That shouldn't be necessary to support scenario 2 at all? My solution in https://github.com/microsoft/windows-rs/compare/master...MarijnS95:winmds simply passes the path from .windows/winmd relative to the currently built crate into the TypeReader, without any copies nor reading PATH.

I'm happy to take care of this upon my return, but feel free to jump start the process if you're confident you know what's required. I just won't be around to spot check.

I'll see what I can do, pending the above regarding removing copies altogether.

The winmd files don't need to be copied, but the <arch> files do for obvious reasons. Sorry if that wasn't clear. Thanks!

The winmd files don't need to be copied, but the <arch> files do for obvious reasons. Sorry if that wasn't clear. Thanks!

Ah, I thought that copy behaviour was going to be moved into windows-app-rs. We can probably #[cfg] it for Windows, and leave all the PATH magic it has to perform out of cross-compilation builds until someone actively needs that and can test it.

Every crate dependent on the windows crate relies on files getting copied out of .windows\<arch> for a bag of reasons. No PATH hacks needed for that as that hierarchal mess was canned. Back to the old days! 🥂
Ref:
https://github.com/microsoft/windows-rs/blob/49ecfbc2f99cbc4bac32d6d771eeb589fe9d4e76/crates/macros/src/lib.rs#L89-L102

@riverar Doesn't .windows\<arch> contain specific DLLs for features that are not shipped by default on Windows? Those were all moved to https://github.com/microsoft/windows-samples-rs, and are anyway only used in win2d and webview2 so it doesn't seem like "every crate" needs this?
That bit of code you linked:
https://github.com/microsoft/windows-rs/blob/49ecfbc2f99cbc4bac32d6d771eeb589fe9d4e76/crates/macros/src/lib.rs#L121
At least it uses OUT_DIR, so no PATH hacks there :tada:
What's the plan, revert to the state in that commit and then rip out the copy for winmds:
https://github.com/microsoft/windows-rs/blob/49ecfbc2f99cbc4bac32d6d771eeb589fe9d4e76/crates/macros/src/lib.rs#L140-L144
In favour of propagating its path using something akin to https://github.com/microsoft/windows-rs/compare/master...MarijnS95:winmds?
I'm not in a hurry to get this cross-compilation fixed; if my approach isn't close to what you're planning I'll leave this up to you :)

@riverar Doesn't .windows\<arch> contain specific DLLs for features that are not shipped by default on Windows? Those were all moved to https://github.com/microsoft/windows-samples-rs, and are anyway only used in win2d and webview2 so it doesn't seem like "every crate" needs this?

Yep!
The samples are just Rust development samples and don't represent the Windows app ecosystem very well.
There are a zillion reasons to ship files side-by-side with an app, as you can imagine. Could be an application compatibility shim/hook, a localized string or image bucket, libavcodec for video encoding, a manifest to enable access to newer controls and high-DPI support, etc.
To reduce developer friction and align with the Rust ecosystem's idiomatic cargo run experience, the crate sacrifices some purity and performs .windows deployment work for the developer.
Ideally, we'd move all this code elsewhere but I don't believe Cargo has any post-build hooks to latch onto. (Post-build scripts, deployment, etc. are hot asks in the Cargo repository but I haven't seen any major RFC work in that area.) So we're kind of stuck with what we got or "tell the developer to do it themselves", with the latter being antithetical to creating a great developer experience.
Open to other ideas!

What's the plan, revert to the state in that commit and then rip out the copy for winmds [...]

If you want to tackle this while Kenny is away, I would say the plan is: revert back to what we had, prior to the PATH/winmd hacks, and maintain the .windows deployment behavior. I believe this is generally referred to as "supporting scenario 1 and 2" earlier in the thread. That should fix/close out this issue.

[...] In favour of propagating its path using something akin to master...MarijnS95:winmds? [...]

The approach you had was great/solid but I don't think we need it now. The winmd dependency propagation logic is getting removed. The windows-app-rs crate will likely become a cargo-generate template instead.
Make sense?

The samples are just Rust development samples and don't represent the Windows app ecosystem very well.
There are a zillion reasons to ship files side-by-side with an app, as you can imagine. Could be an application compatibility shim/hook, a localized string or image bucket, libavcodec.dll for video encoding, a manifest to enable access to newer controls and high-DPI support, etc. Nearly all modern Windows apps ship with files at their side.
To reduce developer friction and align with the Rust ecosystem's idiomatic cargo run experience, the crate sacrifices some purity and performs .windows deployment work for the developer.

Hmm, I had assumed there are also quite a few applications that wish to use windows-rs as a replacement for winapi just to access the many APIs that are available default, but catering to apps that need something extra doesn't hurt those that don't.

Ideally, we'd move all this code elsewhere but I don't believe Cargo has any post-build hooks to latch onto. (Post-build scripts, lifecycle events, etc. are hot asks in the Cargo community/repository but I haven't seen any major RFC movement in that area.) So we're kind of stuck with what we got or "tell the developer to do it themselves / run a script", with the latter being antithetical to creating a great developer experience.
Open to other ideas!

For now I'm relying on Linux where libraries are generally easily installable through a package manager and end up in well-known locations that are searched by linkers, instead of having build scripts copy them to the target folder to sit next to an executable (which is only a problem for the few custom libraries one does not install to the system), so I can't really comment on a proper solution. Again, it's fine to revert this to the old system without PATH magic so that it doesn't panic cross-compilation builds anymore.

What's the plan, revert to the state in that commit and then rip out the copy for winmds [...]

If you want to tackle this while Kenny is away, I would say the plan is: revert back to what we had, prior to the PATH/winmd hacks, and maintain the .windows deployment behavior (for now!). I believe this is generally referred to as "supporting scenario 1 and 2" earlier in the thread. That should fix/close out this issue.

I would have submitted that branch (with the deployment behaviour reverted to the old state instead of being removed), but won't be able to test anything on Windows so that might be weird (but we have CI :tada:). Also, see below:

[...] In favour of propagating its path using something akin to master...MarijnS95:winmds? [...]

The approach you had was great/solid but I don't think we need it now. The winmd dependency propagation logic is getting removed. The windows-app-rs crate will likely become a cargo-generate template instead.

This branch doesn't contain "the propagation logic" as discussed above, just "propagating" the path to <windows_gen>/.windows/winmds in such a way that the build macros can find it. I don't exactly remember why I did it this way, as it was working before. Will have to check how it was working before, afaik it was include_bytes which was found to be slow:
https://github.com/microsoft/windows-rs/blob/8e7ce3de1c74e4e26e36ca5a0650c661ad72500a/crates/gen/src/workspace.rs#L83-L94
If we don't want to go back to include_bytes there should be some way to acquire the path to windows_gen when it's sitting somewhere in ~/.cargo/registry/src/../windows_gen-xxx/ or ~/.cargo/git/...`, which that branch would provide. I guess it makes sense to submit (a cleaned version of) it after all and see where we end up?

If we don't want to go back to include_bytes there should be some way to acquire the path to windows_gen when it's sitting somewhere in ~/.cargo/registry/src/../windows_gen-xxx/ or ~/.cargo/git/...`, which that branch would provide. I guess it makes sense to submit (a cleaned version of) it after all and see where we end up?

Agreed. I think the only blocker for your branch was us wanting to support winmds from a bunch of other crates (scenario 3). But since that's out now, I think your changes would be compatible/welcome. I'm happy to test on Windows when ready.
I'm sure if we missed something, Kenny will figure out how to yell at us from afar with just access to rocks and flora.

Agreed. I think the only blocker for your branch was us wanting to support winmds from a bunch of other crates (scenario 3). But since that's out now, I think your changes would be compatible/welcome. I'm happy to test on Windows when ready.

Sounds good, I'll get that set up in the coming days!

I'm sure if we missed something, Kenny will figure out how to yell at us from afar with just access to rocks and flora.

Will look for smoke signals in the meantime :)


[autotvm] fix #2617

Fix https://github.com/dmlc/tvm/issues/2617
Note: In future we should get avoid using localhost to avoid similar issue

Have you verified that this change won't break on other OS such as Ubuntu? Also why do you use "<IP_ADDRESS>" instead of "<IP_ADDRESS>"?

@icemelon9 I also tested on CentOS it works well. I use <IP_ADDRESS> because in origin codebase <IP_ADDRESS> and localhost are mixed and there is no <IP_ADDRESS>

Please also modify tune_relay_arm.py  and tune_relay_mobile_gpu.py in the tutorial folder

Done

Do we also want to update the old nnvm tutorials?

@eqy I think we should remove all old nnvm tutorials.

I agree we can remove corresponding nnvm tutorial once we have a relay version of it.

ping @eqy

Thanks @antinucleon, this is merged.


Code error in Avalonia.Themes.Default/TabControl.xaml

I found a code error in master branch, at Avalonia.Themes.Default/TabControl.xaml

This line should be removed, it will cause Margin to overlap repeatedly.

it will cause Margin to overlap repeatedly

Not sure if I understand it. You mean, it will double the margin?

You mean, it will double the margin?

Can confirm. Margin appears to be double what it should be. Also occurs in Fluent Theme as far as I know. The following code can reproduce the issue:
<Grid>
  <Grid Background="Orange" Margin="25" VerticalAlignment="Stretch" Name="Reference"/>
  <TabControl Background="LightGreen" Margin="25" VerticalAlignment="Stretch">
    <TabItem Header="Tab 1"></TabItem>
    <TabItem Header="Tab 2"></TabItem>
    <TabItem Header="Tab 3"></TabItem>
  </TabControl>
</Grid>

The grid named "Reference" (orange) shows what a margin of 25 should look like. Compare with the tab control (green) which has its margin doubled.

Ok, this Margin should be removed, since control add it automatically

Can you replace Grid with a Panel? Does it change anything?

Edit: There are scenarios where you don't want properties to apply to the entire control itself. For example, controls that have multiple distinct areas like Expander (both Header and Content). It is common that you don't want properties like Margin or Background to apply to both the Header and the Content areas. Instead it should apply to the Content area and new properties added for the Header. Decisions like this can only be made on a per-control basis and this is why it is all done in the default styles from what I've seen in the past. Having control automatically add a Margin generically is bad.

I would agree for many other properties, such as background or corner radius - they are already included only in the template per control.
But Margin? As for me it's similar to properties like Width/Height that are expected to be applied only in single possible way, not depending on the control itself. Including mentioned Expander. There is difference comparing to the Padding, which actually depends on the control and can't be applied automatically.

@maxkatz6 I can't find a counterexample so you may be right. My initial (and gut) thinking is to treat all properties the same. Of course my example really only works for Padding, Background, etc. As Margin directly affects the practical height/width of the control (as the user sees it) there is another good argument in your favor.
I also thought UWP behaves the way I described. However, I just searched all control templates and only found one Margin="{TemplateBinding Margin} case. This is for the NavigationViewItemPresenter used in the ControlTemplate of the NavigationViewItem and it may be a special case.
It is counter-intuitive for me to treat Margin different from other properties. However, the logic in doing so makes sense. I need to backtrack on my statements and you are likely correct. :)


Schema validation for cmake-variants.yaml doesn't work

Brief Issue Summary

https://vector-of-bool.github.io/docs/vscode-cmake-tools/variants.html says:

Note:      CMake Tools provides a YAML validation schema, which is only checked in the editor when using the YAML Support by Red Hat extension.

I installed YAML Language Support but get the error:
Cannot Load content for: cmake-tools-schema:///schemas/variants-schema.json. Unknown schema: 'cmake-tools-schema'

Expected:

Create file cmake-variants.yaml in project root directory
open file
get schema based auto completion

Apparent Behavior:

Create file cmake-variants.yaml in project root directory
open file
click on variants-schema.json shown directly above line 1
get error listed above.

CMake Tools Log

[variant] Loaded new set of variants
[kit] Successfully loaded 8 kits from /home/user/.local/share/CMakeTools/cmake-tools-kits.json

Other Logs
The output window for "YAML Support" is completely empty.
Platform and Versions

Operating System: Ubuntu 20.04.3 LTS
CMake Version: 3.16
VSCode Version: 1.16.1
CMake Tools Extension Version: 1.8.1
Compiler/Toolchain: GCC 9.3
Red Hat YAML Language Support: 0.22.0

Other Notes/Information

~/.vscode/extensions/ms-vscode.cmake-tools-1.8.1/dist/schema contains schemas in several languages
A created cmake-variants.json file gets successfully validated against the schema.

@TSlivede, thank you for opening this report. We reproduce the problem. We will investigate and fix this.

@TSlivede This should get resolved by #3720


Shadows dissappeared

Hello!
Using the new version (6.0.2) the menu shadows did disappear (no matter which animation i use).
Is there any way to show them again?
Thanks and best regards!

See the SideMenuPresentationStyle settings.

Hi @jonkykong !
Thanks for your answer! I did it and i tried all the possibilities, no one adds the shadow layer (i tried it in a new project that i've just started two days ago and in an old project that was using version 5.X with the shadows, after the update to the 6.0.2 i've lost them).
Best regards!

I'm curious about this as well. I'm using the slideIn presentation style and I'm trying to figure out how to get the semitransparent black overlap to show up over the view controller the menu is now partially covering.

The latest is currently 6.0.3.
You want to take a look at UISideMenuNavigationController.presentationStyle.onTopShadowOpacity.

Yeah! Thanks @jonkykong I've downloaded the version 6.0.4 and it worked just adding the line that you've commented ;)
Best regards!


Added pogchamp emote

Hi, I added the pogchamp emote in the emotedata file and public folder. Hope you like it!

This is a duplicate of #1320

Didn't see that. Sorry


The "--data-binary" option does not exist.

curl 'https://graphigo.prd.dlive.tv/' --data-binary '{"query":"query{userByDisplayName(displayname: "Potato") {username displayname avatar partnerStatus followers{totalCount}}}"}'

It does not. It'll get added.
In the meantime, there's really no reason to use it in this case. Just change it to --data or -d for short.

Thanks, @jasonmccreary It's working with the --data option


Applications are not built after pull request is merged

I just merged rtorrent and flood in https://github.com/onedr0p/containers/pull/21 and noticed (as expected) that no pipeline was kicked off. It isn't a huge problem as the container will be built on the next release schedule cycle. Not sure if we should bother with an implementation to fix this?

After thinking this over I think this is okay. The schedule runs every hour and maintainers can kick off a manual build after a PR is merge if we're impatient.

Agreed... doesn't add that much value when the release flow runs every hour anyway.

Well, implemented it anyway because some images were not being rebuilt when the base image changed 😄


Hyprland crashes when turning on one monitor (two monitor setup)

Hyprland Version
 System/Version info
Hyprland, built from branch  at commit 86be75dd97b5633b8c0aa6bdcb3346fa871a8480  ().
Date: 2024-02-20
Tag:

flags: (if any)

System Information:
System name: Linux
Node name: gza
Release: 6.1.78
Version: #1-NixOS SMP PREEMPT_DYNAMIC Fri Feb 16 18:06:32 UTC 2024

GPU information:
24:00.0 VGA compatible controller [0300]: NVIDIA Corporation TU104 [GeForce RTX 2070 SUPER] [10de:1e84] (rev a1) (prog-if 00 [VGA controller])
2f:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Navi 23 [Radeon RX 6600/6600 XT/6600M] [1002:73ff] (rev c1) (prog-if 00 [VGA controller])

os-release: ANSI_COLOR="1;34"
BUG_REPORT_URL="https://github.com/NixOS/nixpkgs/issues"
BUILD_ID="24.05.20240218.b98a4e1"
DOCUMENTATION_URL="https://nixos.org/learn.html"
HOME_URL="https://nixos.org/"
ID=nixos
IMAGE_ID=""
IMAGE_VERSION=""
LOGO="nix-snowflake"
NAME=NixOS
PRETTY_NAME="NixOS 24.05 (Uakari)"
SUPPORT_URL="https://nixos.org/community.html"
VERSION="24.05 (Uakari)"
VERSION_CODENAME=uakari
VERSION_ID="24.05"

plugins:

Bug or Regression?
Bug
Description
I have a two monitor setup
monitor=DP-2,preferred,0x0,1
monitor=DP-2,addreserved,0,0,700,700
monitor=DP-3,preferred,1800x-1080,1
If I turn off DP-2 and turn it back on hyprland will always crash.
It wont happen if I turn DP-3 on and off tho.
How to reproduce
Have two monitors turned on, turn one of the monitors off and turn it back on.
Crash reports, logs, images, videos
hyprlandCrashReport5179.txt

Issue does not exist on Hyprland, built from branch  at commit v0.35.0
Hyprland, built from branch  at commit v0.35.0  ().
Date: 2024-02-05
Tag:

flags: (if any)

System Information:
System name: Linux
Node name: gza
Release: 6.1.78
Version: #1-NixOS SMP PREEMPT_DYNAMIC Fri Feb 16 18:06:32 UTC 2024

GPU information:
24:00.0 VGA compatible controller [0300]: NVIDIA Corporation TU104 [GeForce RTX 2070 SUPER] [10de:1e84] (rev a1) (prog-if 00 [VGA controller])
2f:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Navi 23 [Radeon RX 6600/6600 XT/6600M] [1002:73ff] (rev c1) (prog-if 00 [VGA controller])

os-release: ANSI_COLOR="1;34"
BUG_REPORT_URL="https://github.com/NixOS/nixpkgs/issues"
BUILD_ID="24.05.20240218.b98a4e1"
DOCUMENTATION_URL="https://nixos.org/learn.html"
HOME_URL="https://nixos.org/"
ID=nixos
IMAGE_ID=""
IMAGE_VERSION=""
LOGO="nix-snowflake"
NAME=NixOS
PRETTY_NAME="NixOS 24.05 (Uakari)"
SUPPORT_URL="https://nixos.org/community.html"
VERSION="24.05 (Uakari)"
VERSION_CODENAME=uakari
VERSION_ID="24.05"

plugins:

Experiencing this as well. I have multi monitor that i toggle one between 2 different computers and will experience a crash when my other computer sleeps my one monitor and i wake it back up.
hyprlandCrashReport4513.txt

Hi, I have same problem. I patched my Hyprland and never crash again.
I created PR here https://github.com/hyprwm/Hyprland/pull/4782

do you also use pyprland or other plugins? I just realized I still use pyprland 1.7 and vaxerski's make it  throws some warning.

my crash went away, as well, on latest builds

Unfortunately, like I mentioned earlier. With the latest commit the system freezes when turning the monitor back on.
I'm not able to get a coredump and this is how the log file looks
hyprland.log
 System/Version info
Hyprland, built from branch  at commit f389f77015ebeee30a2527b8eb7488879dd626e0  ().
Date: 2024-02-23
Tag:

flags: (if any)

System Information:
System name: Linux
Node name: gza
Release: 6.1.78
Version: #1-NixOS SMP PREEMPT_DYNAMIC Fri Feb 16 18:06:32 UTC 2024

GPU information:
24:00.0 VGA compatible controller [0300]: NVIDIA Corporation TU104 [GeForce RTX 2070 SUPER] [10de:1e84] (rev a1) (prog-if 00 [VGA controller])
2f:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Navi 23 [Radeon RX 6600/6600 XT/6600M] [1002:73ff] (rev c1) (prog-if 00 [VGA controller])

os-release: ANSI_COLOR="1;34"
BUG_REPORT_URL="https://github.com/NixOS/nixpkgs/issues"
BUILD_ID="24.05.20240221.0e74ca9"
DOCUMENTATION_URL="https://nixos.org/learn.html"
HOME_URL="https://nixos.org/"
ID=nixos
IMAGE_ID=""
IMAGE_VERSION=""
LOGO="nix-snowflake"
NAME=NixOS
PRETTY_NAME="NixOS 24.05 (Uakari)"
SUPPORT_URL="https://nixos.org/community.html"
VERSION="24.05 (Uakari)"
VERSION_CODENAME=uakari
VERSION_ID="24.05"

plugins:

0.35 is working good for me, so its not critical. What else would be useful for identifying the issue?

What I can add is that if I build https://github.com/hyprwm/Hyprland/commit/94aeb06d6ba14d403c46b52d1d2e397acb5906a4 (which is the commit before https://github.com/hyprwm/Hyprland/commit/c4283abb9f5797e1ec054d1161a9632bf005b98e) I still get a regular crash and a coredump + hyprlandCrashReport like earlier. But when I build with any commit after the system freezes fully.

try launching latest with HYPRLAND_NO_CRASHREPORTER=1 and see if that doesn't fix the freezes.

try launching latest with HYPRLAND_NO_CRASHREPORTER=1 and see if that doesn't fix the freezes.

I tried, it didn't help

But your fix seems have solved the problem for most people. Seems like I have a different issue now. Do you want me to close this issue and open a new one for my specific problem?

@vaxerski, So I updated to latest commit. I still have the same issue with freezing if I turn of one monitor or disconnect it. But if I disconnect both the  monitors and reconnect them it goes from a freeze to a crash.  I have attached the crash report (slimmed).
In the original version the "[backend/drm/atomic.c:250] Failed to acquire FB for plane 98" line keeps going forever, the report is 23mb big. But its the last line.
Any guess what the issue could be?
hyprlandCrashReport5299.slim.txt

your display driver?
[backend/drm/atomic.c:250] Failed to acquire FB for plane 98

sounds like a kernel error

But your fix seems have solved the problem for most people.

Can confirm it did for me, using that patch on v0.35.0

your display driver?
[backend/drm/atomic.c:250] Failed to acquire FB for plane 98

sounds like a kernel error

@vaxerski  I have now gone through the commits from 0.35.0 everything works correctly all until this commit https://github.com/hyprwm/Hyprland/commit/d62e7a5125c551fe8a94e076e64d42b702d923b1
I went through the changes in this commit and found that if I comment out:
https://github.com/hyprwm/Hyprland/compare/main...goggi:Hyprland:damageWindow-test?diff=unified&w=#diff-dbcd1ce1e0b916536f17c999473ad9e22c014646ddb2df15c45d726884a3481cR1267
the freeze issue stops

patch.txt
does this do the trick?

patch.txt does this do the trick?

That did the trick! Thanks

Hi, everyone. I a newbie in Hyprland. How do I apply the patches that you are referring to to my Hyprland config?
Thanks!

That patch was added to hyprland on february 28th. So if you are not using an outdated version, you already have it.

I am using hyprland 0.40.0-1. But I still have the problem. :( When the 2nd monitor is connected with hdmi but turned off all goes well. But if then I turn it on, the session crashes and it logs out automatically.

I suggest you to first build hyprland from the latest git commit and try it because there are a lot of changes lately.
If it does not work, I would just open a new bug report and provide the requested info.
Good luck.

Thank you I will try that!


fix: Disable sourceMap to be able to use the library without warnings

The build does not bundle "src" into the distribution package. This will cause e.g. webpack bundled with react-scripts 5 to print lots of warnings about having source maps without the src files.
Disable sourceMap to fix #443

@Snaptags Thanks for the fix :)

@Snaptags bumped version on npm to 0.0.10


Add memory rss recording rule

What this PR does / why we need it:
We need this to determine the unreclaimable memory used by each component to inform setting component memory resource requests
Which issue(s) this PR fixes (optional, use fixes #<issue_number>(, fixes #<issue_number>, ...) format, where issue_number might be a GitHub issue, or a Jira story:
Fixes #
Checklist

[ ] Subject and description added to both, commit and PR.
[ ] Relevant issues have been referenced.
[ ] This change includes docs.
[ ] This change includes unit tests.

/lgtm


Create main.yml

Fixes #7 and #8

It shouldn't need the main.yml file, since linter-ci.yml is there and it seems like the same?

TobiahZ you're right, looks like they are the same thing...any specific reason for this .yml @Guilhermeslucas ?

Github wasn't allowing me to create a action from a yaml that was already done!


feat(client): refactor desktop-layout to ts

Checklist:

[x] I have read freeCodeCamp's contribution guidelines.
[x] My pull request has a descriptive title (not a vague title like Update index.md)
[x] My pull request targets the main branch of freeCodeCamp.
[x] I have tested these changes either locally on my machine, or GitPod.

Related to #42256
This targets next, but should not hold next back from being merged to main. I started this refactor because I wanted to find the cause of this error on next.
Warning: Failed prop type: checker is not a function
    in DesktopLayout (created by ShowClassic)
    in ShowClassic (created by withI18nextTranslation(ShowClassic))
    in withI18nextTranslation(ShowClassic) (created by Connect(withI18nextTranslation(ShowClassic)))
    in Connect(withI18nextTranslation(ShowClassic)) (created by PageRenderer)
    in div (created by DefaultLayout)
    in div (created by DefaultLayout)
    in DefaultLayout (created by withI18nextTranslation(DefaultLayout))

Need to update the import in the Show file.

This change seems to break the breadcrumbs for me.