commented out the wrong lines. trying again

these are the lines i meant to comment out in #9980.

Warnings

:warning:
Please add the JIRA issue key to the PR title (e.g. MB-123)

  Generated by :no_entry_sign: dangerJS against cd1b9b9b5cb580ddf5474c0f138da5437adf5c5d


Visdom does not display when accessed via a proxy (with a path in its URL)

Bug Description
I want to access visdom only via a proxy.
Visdom runs at the address 'http://visdomHost:8097'
The proxy runs at the address 'http://proxyHost:8080/path1'. It receives requests at this address and redirects them to visdom.
The issue is that visdom cannot find static files because it does not consider/support the proxy path ('/path1'). In the browser console, I see that visdom is looking for  the files 'http://proxyHost:8080/static/css/xxx', whereas the correct address is 'http://proxyHost:8080/path1/static/css/xxx'
How can I configure visdom to consider the path in the proxy URL.
Note that the proxy works fine when the path is simply '/'.
Thanks in advance.
Reproduction Steps

Run visdom
Configure a proxy (with a PATH in its URL) to redirect requests to visdom. For instance, you can configure nginx to redirect the path '/path1' to visdom.
See the errors that appear in the browser console

Hi @nebilbenmabrouk - thanks for filing. Proxy setups can get quite complicated and I don't intend to explore covering all of them. For this specific case though you may be able to use the -base_url path1 command line arg when starting the server. (You May also have to start accessing http://visdomhost:8097/path1 though, I'm not entirely sure)

Hi @JackUrb, Thank you for your answer. I tried to apply your suggestion but I faced two issues:
First, when I change the base_url  to '/path1' instead of '/', the websocket connection does not work (I see the red button 'offline') and in the browser I find this error:
WebSocket connection to 'ws://localhost:8097/path1/socket' failed: Error during WebSocket handshake: Unexpected response code: 200
Second, this solution is not applicable when the path is not static, which means it contains dynamic parameters. For example, when I go to the proxy address http://proxyHost:8080/services/{id}/ the proxy redirects me to the visdom service. The {id} is a dynamic parameter, that we cannot know in advance at the time of starting visdom.
I suggest (if possible) to consider the whole URL of the proxy (including the path) and not only its host and port.
Thanks

Sorry that didn't work out quite right. Feel free to investigate a solution to this further; I unfortunately won't have any bandwidth in the near future to dive deeper into proxy setups, but if you come across something I'd be happy to incorporate it.


Add option to choose between planetographic and planetocentric coordinates when plotting gridlines in the GUI

#394
Pull request checklist

[ ] Add a clear description of the change
[ ] Add any new tests needed
[ ] Run spell check on new text visible to user (documentation, GUI etc.)
[ ] Check any changes to requirements.txt are reflected in setup.py and conda-forge feedstock
[ ] Check code passes CI checks (run run_ci.sh or check GitHub Actions)

See CONTRIBUTING.md for more details.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>8
Details

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 99.617%

Totals

Change from base Build<PHONE_NUMBER>0:
0.0%

Covered Lines:
3157

Relevant Lines:
3169

💛  - Coveralls


Fix CSS discrepancy in issue #6508

fix: #6508
https://github.com/reactjs/react.dev/assets/73568310/b1018db5-df66-406d-98e8-fb3dbc32a28a

CLA signed done

@facebook-github-bot CLA signed.

cc @harish-sethuraman


[RFE] Add a --quiet flag

Whenever you call kubernaut claims create it spits out a big usage message:
$ ./kubernaut claims create --name "$(cat mycluster.knaut.claim)" --cluster-group main

 Your clusters kubeconfig has been written to the below path:

 /home/lukeshu/.kube/mycluster-lukeshu-1fe24e81-5104-476c-8983-288b4594da26.yaml

 Usage Instructions:

 There are several ways you can use this kubeconfig file:

 1. Pass --kubeconfig to the `kubectl` command:

    kubectl --kubeconfig=/home/lukeshu/.kube/mycluster-lukeshu-1fe24e81-5104-476c-8983-288b4594da26.yaml ...

 2. Set the KUBECONFIG environment variable:

    export KUBECONFIG=/home/lukeshu/.kube/mycluster-lukeshu-1fe24e81-5104-476c-8983-288b4594da26.yaml

This is surely helpful for interactive use.  However, when calling it from another program/script, this is just noise that the user would have to ignore.  I'm hesitant to just say >/dev/null because if there is diagnostic output, I don't want to hide it.
I think that it would be a good UI improvement to either

add a -q/--quiet flag to silence that message, or
promise that all diagnostic output would go on stderr (and not stdout).  This might already be the case (I'm not sure); if it is, that fact should be documented.

Another approach is to check stdout for a tty and only show interactive stuff if it has one.

If it's called from a shell script, the script has no real reason to capture stdout, so kubernaut's stdout would probably still be a tty, even if it's not being called interactively.  The "solution" to which would be for the caller to pipe it to cat, which is a real bad smell.

Kubernaut is dead.

Kubernaut is dead.


Null handle should be implement for the IPLoadBalancer in init.sh

Description:
Currently, if IPLoadBalancer parameter is not provided then there will add a host entry with empty IP. This should be handled as if it is not provided it should give an error.
Affected Product Version:
IS5.5.0 scripts
Steps to reproduce:

Run init.sh without passing value to IPLoadBalancer parameter.

Fixed with https://github.com/wso2/identity-test-integration/pull/254

fixed with #254


FetchService should support all fetch options

Currently we can only set credentials:
https://docs.rs/yew/0.8.0/yew/services/fetch/struct.FetchOptions.html
But there's a lot of other options that are very much needed:
https://developer.mozilla.org/en-US/docs/Web/API/WindowOrWorkerGlobalScope/fetch#Parameters (init parameter)

https://github.com/yewstack/yew/pull/602


Update gaze-targeting.md - Changed metadata, fixed image wrapping

Changed metadata, fixed image wrapping

:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

mixed-reality-docs/gaze-targeting.md
:white_check_mark:Succeeded
View

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


Automator: update<EMAIL_ADDRESS>in<EMAIL_ADDRESS>

Generated by Automator - 2024-05-09T23:58:58+00:00

@istio-testing: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

integ-security-istiodremote_istio_release-1.22
1a98b509112cd3d5d920f71035b8396ef0720e9c
link
true
/test integ-security-istiodremote

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here.

/test integ-security-istiodremote


gzip all of the things

sometimes, things can take up a lot of space. currently, we do a lazy job of minimizing space usage. make it better
one example: gq_subset.table files

it looks like most of all of the things are gzipped or bam compressed but we may be able to save more space using shadow rules (see #13) to discard unnecessary files
also it would be great if we could combine some of the rules in the variant calling pipeline so that they can be piped together (so that we don't create sam files, for example)
or else figure out how to use named pipes in snakemake (see #6)


Import envoyproxy and upstream wasm

The all_tests failure is a resource issue and lizan says we can't fix it so let's just submit over it.

All these CI failures seem to be fake and/or coverage which is being worked on.  Can someone verify and I'll merge.

all_tests - you can remove or comment out those extra test targets in ci/do_ci.sh instead of merging failing tests.
asan - you can disable test for integration with external workspaces using ENVOY_BUILD_FILTER_EXAMPLE or by removing it in ci/do_ci.sh (which I did multiple times, but you keep restoring it in merges).

all_tests - you can remove or comment out those extra test targets in ci/do_ci.sh instead of merging failing tests.

Actually, this should be passing, it's either bad merge or build image.

Everything passes in all_tests, it just doesn't have disk space.  Should I just remove some arbitrary core tests which we should not be effecting?  For the asan build do you have an example of the do_ci.sh change, e.g. SHA that I could back down to?

@lizan re: space issues.

@jplevyak @htuch I have no good way to fix CircleCI all_test, as azure pipelines is also enabled here, as long as envoy-wasm (Linux-x64 release)  is passed we should be good. Can you just remove that Circle job?

/retest

I tried to kick azure, but they had an outtage which seems to be ongoing.  If anyone knows how to kick this I think it is otherwise good to go.

clang-tidy seems to be getting stuck.  It normally takes under 10 min and it has been almost 2 hours now.  I  think we have an azure CI issue of some kind.


Strange behaviour with holdWhen and getValue

Take a look at the working CodePen here: http://codepen.io/djskinner/pen/JdpwyY
Pressing the balance button generates a new random number. A Property is created that uses holdWhen to restrict balance updates coming through until a stop event is received.
If I was interested in getting the initial state of the stream template, I might onValue and then immediately unsubscribe:
streamTemplate.onValue(function(initialState) {
      console.log(initialState);
})();

However, once I do this the balance Property behaves differently and I no longer receive updates. Why would this seemingly inert change make such a drastic different to the system? Surely the behaviour of the system shouldn't be dependent on whether someone has subscribe and unsubscribed to the streamTemplate at some point in the past?
I think this is potentially a bug in holdWhen.
Is there a better approach to this problem? I am using Buses and pushing rather than plugging it is is an accurate representation of my application but I'm not sure to what extent that has to the issue.

Also asked on StackOverflow:
http://stackoverflow.com/questions/31205107/bacon-js-strange-behaviour-with-holdwhen-and-onvalue

Indeed seems wrong. I reduced the problem to this pen: http://codepen.io/anon/pen/dodLjN?editors=001

Failing test case: 9e08a76

Well, there was a bug and it's fixed in 0.7.67. Thanks for the find!

In fact this lead me to find and fix a couple of other bugs too, in scan and bufferWithTime by adding more aggresive automatic testing. We're at 0.7.69 now!

This latest release has solved the issue. Many thanks for Bacon!

Good to hear that!


Error installing via Docker

Hello, I am trying to install the Surfsence as an alternative to Noteboolklm. Just for installing, with docker build, I get the following error.
WARN[0000] /mnt/****/surfsence/SurfSense/docker-compose.yml: the attribute `version` is obsolete, it will be ignored, please remove it to avoid potential confusion
[+] Building 0.1s (3/3) FINISHED                                                                                docker:default
 => [backend internal] load build definition from Dockerfile                                                                                0.0s
 => => transferring dockerfile: 445B                                                                                0.0s
 => [frontend internal] load build definition from Dockerfile                                                                                0.0s
 => => transferring dockerfile: 2B                                                                                0.0s
 => CANCELED [backend internal] load metadata for docker.io/library/python:3.12-slim                                                                                0.1s
failed to solve: failed to read dockerfile: open Dockerfile: no such file or directory

@Shahin-rmz Hi I will start looking into this issue in few days after my sem finals.

dockerfile

Hello,
You're supposed to run docker compose build in the git repository, not docker build.


update 1.12

Update the plugin to the new version 1.12 and fix the compatibility bug.

Please this.

is that a no? :(

Thanks!


⚠ Bofrost.at has degraded performance

In 2e9ab72, Bofrost.at (https://www.bofrost.at) experienced degraded performance:

HTTP code: 200
Response time: 1114 ms

Resolved: Bofrost.at performance has improved in df711d4 after 15 minutes.


Cannot Authenticate to Google Account

Getting the following error from Google when trying to connect from "google-drive-ocamlfuse" for the first time:
We can’t connect to the server at gd-ocaml-auth.appspot.com
I've never had this issue before. Is the server down?

Ok it is working today.
Mounting just fine now.


Time v0.3 tracking issue

Time v0.2 was an outstanding learning experience, and by all accounts is a massive improvement over v0.1. However, a number of ill-informed decisions were made which led to some inconsistencies and many deprecated APIs.
All deprecated methods and structs have ready-to-use alternatives, which will be detailed before a release. As such, I would like to remove all deprecated APIs. This currently includes the following.

Deprecated APIs

v0.1 APIs, currently behind a default feature flag

PreciseTime
SteadyTime
precise_time_ns
precise_time_s
Instant::to
Duration::num_weeks
Duration::num_days
Duration::num_hours
Duration::num_minutes
Duration::num_seconds
Duration::num_milliseconds
Duration::num_microseconds
Duration::num_nanoseconds
Duration::span
Duration::from_std
Duration::to_std

Panicking APIs, currently behind a non-default feature flag

Date::from_ymd
Date::from_yo
Date::from_iso_ywd
Date::with_hms
Date::with_hms_milli
Date::with_hms_micro
Date::with_hms_nano
Time::from_hms
Time::from_hms_milli
Time::from_hms_micro
Time::from_hms_nano

APIs that assume an offset of UTC, currently enabled unconditionally

Date::today
Time::now
PrimitiveDateTime::now
PrimitiveDateTime::unix_epoch
PrimitiveDateTime::from_unix_timestamp
PrimitiveDateTime::timestamp
OffsetDateTime::now

Other APIs that were deprecated during the course of v0.2, currently enabled unconditionally

Sign
Duration::sign
PrimitiveDateTime::using_offset

Goals for v0.3:

Remove all deprecated APIs
Revamped parsing/formatting (#236)
un-constify is_leap_year and days_in_year for performance. On Rust ≥ 1.46, cfg_if_match and cfg_loop are stable, which allows re-enabling this without runtime performance loss. As a result, the only "loss" is un-constifying methods on older compilers.
Place macros behind a feature flag.
Change any APIs that currently panics to saturate.
Change a number of methods to return Result, including all UtcOffset constructors.
Rename try_from_* to just from_*.
#![no_alloc] support
Rename OffsetDateTime::timestamp and OffsetDateTime::timestamp_nanos to OffsetDateTime::unix_timestamp and OffsetDateTime::unix_timestamp_nanos respectively.
Stabilize serde representations

Anything stricken on the above list is completed. Anything that was previously on the list but was removed was either done in 0.2 (if it's not a breaking change) or abandoned.

time-macros is no longer used internally, allowing MSRV to be lowered to 1.32.

One thing I've considered doing for a while: change some const fns that take no arguments into proper consts. I don't particularly care for the SCREAMING_CASE style, though, so it'd likely remain lowercase.

As a result of packing the Date struct into a single field, a number of structs have been reduced in size.

struct
bytes before
bytes now
reduction

Time
8
8
0%

Date
8
4
50%

UtcOffset
4
4
0%

PrimitiveDateTime
16
12
25%

OffsetDateTime
20
16
20%

A simple benchmark (not published) also shows a ~30% improvement in performance!

As a suggestion, I think it would be useful to have a release candidate for 0.3, when you feel it's ready, to work out any remaining issues in dependent crates. There are a few API nags in 0.2 that I'd love to see resolved in 0.3.

@SergioBenitez Definitely planning on a release candidate. Main thing I want to get done is the revamped formatting, as that's a major change.
Are there any APIs in particular you'd prefer changed that aren't addressed by the list above?

An update on no-alloc support:
Once revamped formatting/parsing is complete, I'll likely release an alpha for initial review.
While I'm designing the formatting/parsing with no-alloc support in mind, support for dynamic formatting strings seems unlikely, at least at first. The ability to have modifiers for the various specifiers would be quite inefficient (quadratic versus linear for checking in alloc environments). However, this doesn't preclude the possibility of statically known formats, namely those in the time::format mod or something procedurally generated via a macro).
I will investigate the possibility for no-alloc support for other operations. Given that error handling for constructors currently required Vec to be present (to store the year and month for whether a day is valid, for example), it seems unlikely no-alloc support will land in the initial 0.3.0 release.
I could use the arrayvec and/or heapless crates, but dependencies can't (currently) be disabled by enabling a feature flag (name alloc).

@jhpratt I'm not sure what's changed in 0.3 thus far, so these may be outdated, but, here are some notes:

Macros should be declarative, not procedural, where possible. At a first glance, this seems totally possible. This would remove the heavy syn, quote, proc-macro-hack, etc. dependencies.
Creating a constant date is very verbose. This is similar to #256. Why do I need to call assume_utc() and to_offset()? As far as I can see, there's no way to create an OffsetDateTime in one line. I should be able to do datetime!(2020-06-05 12:34pm GMT) or what-have-you.
Docs do a poor job of explaining the differences between PrimitiveDateTime and OffsetDateTime and how to move between the types. Why isn't there simply Date, Time, and DateTime, the latter of which could or couldn't have an offset? If the type difference is important, I'd still call it DateTime instead of PrimitiveDateTime; then OffsetDateTime, makes a bit more sense and establishes a more obvious hierarchy.
In general, the docs should describe common operations and why the types that exist do, and why we should care. Handling time correctly is hard which may lead to more complexity in a time handling library. When it does, you should explain this so we can appreciate it.
I'd encourage the use of modules. You currently have multiple structs whose names end with Error; these should all be in an error module without the Error suffix. Similarly, there are several free-standing functions that don't really seem to fit with the rest of the crate; should these be in a util module? In general, the catalog of top-level types and modules should already give me an idea of how the library is to be used.
I like this way of presenting features. It's easy to see which features exist.

I would love to be able to use macro_rules!. There are two things that can happen that would allow this to happen. Either would suffice.

Stabilization of const_if_match and const_panic. I'd have to check, but const_loop might also be necessary for some use cases. This would allow the macro to expand to Date::try_from_ymd($year, $month, $day).unwrap(), which would not compile if it was in a const context. I'm not sure on the semantics if it weren't in a const context — I presume it would continue to compile and panic at runtime, something that's undesirable.

const_if_match and const_loop are both well on their way to stabilization. const_panic is getting there, but it definitely won't land at the same time.

Re-interpretation of tokens inside of macro_rules! matchers. If this were possible, I'd be able to have one macro that verified a number is between 0 and 59, for example. A series of these could then be used to verify the full value.

I'm not aware of any plans for this to be allowed.

Essentially, the reason it's a proc macro now is because it allows you to statically verify the validity of a value, allowing it to be used in const contexts.

When you call .assume_utc().to_offset(…), you are performing two logical operations. Once the aforementioned const features land on stable, .assume_offset() will be usable in const contexts. Going from a PrimitiveDateTime to an OffsetDateTime should require explicitly assuming an offset, even if it is UTC.
I was planning on looking into a way to directly construct an OffsetDateTime. I'm not sure what form this would take, though. Macros would suffice for static values. I can look into whether a macro would be feasible, though I think it could work.

Funny you suggest merging them. I have actually looked into using typestate, but I believe the issue was the lack of ability to have const fn in traits. I can re-investigate this, though, as I may be misremembering things.

Any particular areas that could use improvement?

Modules is one thing I wanted to look into, but hadn't yet. Having a util module makes sense, at a minimum.

Can do! I knew the way I had it was a bit kludgey, but didn't have a better way.

I would love to be able to use macro_rules!. There are two things that can happen that would allow this to happen. Either would suffice.

I suppose I'm less concerned about the fact that it's a proc-macro and more concerned about the heavy-weight dependencies being pulled in. The macros are fairly straight-forward, so you should be able to accomplish the same thing without pulling in any dependencies whatsoever.

When you call .assume_utc().to_offset(…), you are performing two logical operations. Once the aforementioned const features land on stable, .assume_offset() will be usable in const contexts. Going from a PrimitiveDateTime to an OffsetDateTime should require explicitly assuming an offset, even if it is UTC.

I suppose I'm confused about calling assume_utc() on a PrimitiveDateTime. The "assume" part is odd; why isn't there simply a fn as_offset(..) -> OffsetDateTime? Presumably the entire point of PrimitiveDateTime is that there is no offset. Still, I'd really like a datetime!() macro where an offset can be specified to construct an OffsetDateTime directly.

Funny you suggest merging them. I have actually looked into using typestate, but I believe the issue was the lack of ability to have const fn in traits. I can re-investigate this, though, as I may be misremembering things.

I believe you're suggesting something like: DateTime<Raw> and DateTime<Offset>. This is easy enough to accomplish, but there's a trade-off here in terms of usability. I'm suggesting not disambiguating between a DateTime with and without an offset, or perhaps said differently, provide a default offset (of +/- 0) for a DateTime without an offset, and then allow it to be changed without it affecting the type. Thus, there would be a single DateTime, not two as it stands now. As mentioned before, this is only viable if the ability to disambiguate at the type-level isn't particularly important.

Any particular areas that could use improvement?

I've noted a few in my comment already. Each different date/time type needs to detail 1) why it exists, 2) how to create it, and 3) how it relates to the other types. There should also be a high-level overview of the library on common ways it's intended to be used.

I suppose I'm less concerned about the fact that it's a proc-macro and more concerned about the heavy-weight dependencies being pulled in. The macros are fairly straight-forward, so you should be able to accomplish the same thing without pulling in any dependencies whatsoever.

The original reason for pulling in the dependencies was proc-macro-hack. I can likely take a look at how that actually works and write the code myself. The parsing isn't terribly difficult by itself (that was my original goal), though I do wish Rust provided something more than "literal" for parsing. Casting to a string and re-parsing just seems…stupid.

I suppose I'm confused about calling assume_utc() on a PrimitiveDateTime. The "assume" part is odd; why isn't there simply a fn as_offset(..) -> OffsetDateTime? Presumably the entire point of PrimitiveDateTime is that there is no offset. Still, I'd really like a datetime!() macro where an offset can be specified to construct an OffsetDateTime directly.

Something like PrimitiveDateTime::assume_offset? It's not const due to compiler limitations.
Also, turns out it was trivial to create a datetime! macro to construct a PrimitiveDateTime. It's now possible to do datetime!(2020-01-01 0:00).assume_offset(UtcOffset::UTC), though that does require the end user to add in the offset themselves. Expanding it to generate an OffsetDateTime would require additional code duplication in the macros crate. I'm not necessarily opposed to that, though it honestly isn't a priority.

I believe you're suggesting something like: DateTime<Raw> and DateTime<Offset>. This is easy enough to accomplish, but there's a trade-off here in terms of usability. I'm suggesting not disambiguating between a DateTime with and without an offset, or perhaps said differently, provide a default offset (of +/- 0) for a DateTime without an offset, and then allow it to be changed without it affecting the type. Thus, there would be a single DateTime, not two as it stands now. As mentioned before, this is only viable if the ability to disambiguate at the type-level isn't particularly important.

Yes, that's the sort of thing I was referring to. One major reason to keep the types separate is that a PrimitiveDateTime doesn't require the storage of an offset. I don't care for the idea of assuming a given offset (even UTC) when none is specified, as that can lead to surprising behavior, particularly while parsing, though I could likely be convinced.
With regard to renaming PrimitiveDateTime, @KodrAus expressed concern over this naming prior to the 0.2.0 release.

I've noted a few in my comment already. Each different date/time type needs to detail 1) why it exists, 2) how to create it, and 3) how it relates to the other types. There should also be a high-level overview of the library on common ways it's intended to be used.

:+1:

Since you mentioned it, here is a minimal implementation of proc-macro-hack using macro_rules. It doesn't implement support_nested or fake_call_site, neither of which should be needed here.

Thanks @Plecra. I didn't realize it at the time, but proc macro hack actually no longer relies on syn and quote. So relying on that for a sufficient time period (such that my MSRV guarantees are upheld) is a non-issue. The time to compile it by itself is negligible enough that I'm fine keeping it.

Given the significant number of changes I've made on the main branch since originally creating the v0.3 branch, I'll almost certainly re-branch and cherrypick certain changes.
I've also re-implemented the various macros such that they have no dependencies. The macros will accept strings that are otherwise fully compatible with 0.2. This both makes parsing simpler and prevents rustfmt from making stupid decisions.

@jhpratt It seems that time-macros does indirectly depend on syn, through the time-macros-impl crate. Are there any plans on removing that in the nearby future? The syn crate isn't always the fastest to compile, and earlier today it even segfaulted (that may have just been bad luck).

@YorickPeterse It's already been removed on the v0.3 branch.

@jhpratt Ah thanks! In that case I'll keep an eye on this issue.

I don't know if that is the correct issue for this but it seems you're looking for feedback on the API, so I will just dump my thoughts here. The reason I am checking out this crate is that I want update an old crate of mine (I am talking about full face lift level update) and add the time crate as optional dependency to use its types or at least conversions. Overall I am not in a rush because there is so much work 😅
Naming Inconsistencies

The constructor methods essentially convert one ISO date to a Date. That's why Date::from_iso_ywd and Date::yo feel a bit random chosen because there are actual terms defined in the standard. The terms ordinal date or week date seems overall easier to find and search for. Otherwise rustdoc has now this alias feature to make it possible to search for those terms.

Date::from_ymd stays the same but I would note in the comment that the ISO calendar date representation is meant.
Date::from_iso_ywd -> Date::from_week_date (part of ISO standard anyway so redundant)
Date::from_yo -> Date::from_ordinal_date
Date::from_julian_day -> Date::from_julian_date (keeping consistenst with the other constructors)

The Date type also has methods to convert back into the desired ISO representation. Date::julian_day and Date::iso_year_week are named as getters even though they are not as cheap to access. The as-prefix is also only appropriate for Date::as_yo as it pretty much the underlying data structure and the others are more expensive to compute. into did not make sense because Date is Copy and not being converted to a completely different data type. They are still dates, so I chose the to-prefix.

Date::as_ymd -> Date::to_ymd
Date::iso_year_week -> Date::to_week_date
Date::as_yo -> Date::as_ordinal_date (to-prefix might still be the better choice)
Date::julian_day -> Date::to_julian_date

I prefer the and-prefix for constructing a new type from an instance because the with-prefix is usually used for constructors.

Date::with_hms_* -> Date::and_hms_*
Date::with_time -> Date::and_time

API Inconsistencies

Date::iso_year_week should return the week day too because every other method that changes the representation returns the same values that is used for the conversion constructor parameters. This way input and output would be the same and it would be easier to learn the API.
Why is Date::from_yo_unchecked public and hidden in the docs? Can't it be just pub(crate)?

OffsetDateTime
At first I wanted to suggest to rename it to DateTime but the situation is definitely more complex. I thought at first that the tyoes in this crate are not time zone aware but then  OffsetDateTime::now_local wouldn't be fallable. The problem is that the definition of date times as defined in ISO 8601 do not require time zone designators.
date-time = date "T" time [ ("Z" / "UTC") | utc-offset ]

There in fact two types of date times that are still date times at the end of the day. Floating date times are ambigious or relative to the observer. If I said I always want to go jogging at 17 o' clock, it wouldn't matter whether I am in Germany or China. Though for server logs one would prefer to have them in UTC time or at least local time because servers are not necessarily in the same time zone as the developer or customer.
The alternative would be an enum but I'm not sure how ergonomic that is and the size would be bigger.
Overall the current API for date times is fine but it lacks documentation. FloatingDateTime wouldn't be so bad but I'm unsure how many people would actually understand it.
Misc
Maybe add to the top level documentation that this crate is for working with gregorian dates and that fractal seconds aren't supported.
I hope that this long comment is useful for development!

I don't know if that is the correct issue for this but it seems you're looking for feedback on the API, so I will just dump my thoughts here.

This issue works!

The reason I am checking out this crate is that I want update an old crate of mine (I am talking about full face lift level update) and add the time crate as optional dependency to use its types or at least conversions. Overall I am not in a rush because there is so much work :sweat_smile:

I sure hope you're not in a rush, because I've still no solid timeline for time 0.3 :stuck_out_tongue:  My best guess is late this year or early next.

Naming Inconsistencies

The constructor methods essentially convert one ISO date to a Date. That's why Date::from_iso_ywd and Date::yo feel a bit random chosen because there are actual terms defined in the standard. The terms ordinal date or week date seems overall easier to find and search for. Otherwise rustdoc has now this alias feature to make it possible to search for those terms.

With regard to ywd, I chose to explicitly put in "iso" because there are a number of ways to number weeks. In North America, it's common (relatively speaking) to number weeks Sunday-to-Saturday. Outside North America, it's typically the same but Monday to Sunday. In both of these situations, the year is always the same as the calendar year. ISO, on the other hand, says that a week is Monday-to-Sunday but counts the weeks in a slightly different way. As such, I felt it best to be explicit about the counting method is expected to be passed as a parameter.

Date::from_ymd stays the same but I would note in the comment that the ISO calendar date representation is meant.

If we're changing the others, we may as well change this one to Date::from_calendar_date as well.

Date::from_iso_ywd -> Date::from_week_date (part of ISO standard anyway so redundant)

As noted above. Date::from_iso_week_date may be reasonable.

Date::from_yo -> Date::from_ordinal_date

:+1:

Date::from_julian_day -> Date::from_julian_date (keeping consistenst with the other constructors)

Technically what's being passed is actually the Julian day number. Admittedly, the difference between a JDN and Julian date is…confusing at best. A doc alias should certainly be added here.

The Date type also has methods to convert back into the desired ISO representation. Date::julian_day and Date::iso_year_week are named as getters even though they are not as cheap to access. The as-prefix is also only appropriate for Date::as_yo as it pretty much the underlying data structure and the others are more expensive to compute. into did not make sense because Date is Copy and not being converted to a completely different data type. They are still dates, so I chose the to-prefix.

Time for me to look over the API naming guidelines! From the table provided, to_ seems to be the correct choice.

Date::as_ymd -> Date::to_ymd

As with above, Date::to_calendar_date would be preferred for consistency.

Date::iso_year_week -> Date::to_week_date
Date::as_yo -> Date::as_ordinal_date (to-prefix might still be the better choice)

I'll probably wind up changing Date::as_yo to Date::to_ordinal_date for consistency, as the internal representation isn't guaranteed (it did change during v0.2).

Date::julian_day -> Date::to_julian_date

As with above, to_julian_day or to_julian_day_number may happen, with a doc alias as appropriate.

I prefer the and-prefix for constructing a new type from an instance because the with-prefix is usually used for constructors.

Date::with_hms_* -> Date::and_hms_*
Date::with_time -> Date::and_time

This one I don't quite like. with seems clearer to me, but if lots of people have found that confusing, I am willing to change it.

API Inconsistencies

Date::iso_year_week should return the week day too because every other method that changes the representation returns the same values that is used for the conversion constructor parameters. This way input and output would be the same and it would be easier to learn the API.

Agreed. I can change this to Date::to_iso_week_date, making the existing method internal.

Why is Date::from_yo_unchecked public and hidden in the docs? Can't it be just pub(crate)?

Macros! The macros provided guarantee a statically-known, const-compatible value. As all constructors have checks for the parameter validity, I needed some way to construct a Date using a public API (that is always const). It's doc-hidden because it really shouldn't be used by anyone, ever; the caller has to guarantee validity of the parameters, or odd (but deterministic) behavior could result. This is the same situation as with Time::from_hms_unchecked.

OffsetDateTime
At first I wanted to suggest to rename it to DateTime but the situation is definitely more complex. I thought at first that the tyoes in this crate are not time zone aware but then OffsetDateTime::now_local wouldn't be fallable. The problem is that the definition of date times as defined in ISO 8601 do not require time zone designators.
date-time = date "T" time [ ("Z" / "UTC") | utc-offset ]

Note that this crate makes near-zero effort to be ISO 8601 compatible.

There in fact two types of date times that are still date times at the end of the day. Floating date times are ambigious or relative to the observer. If I said I always want to go jogging at 17 o' clock, it wouldn't matter whether I am in Germany or China. Though for server logs one would prefer to have them in UTC time or at least local time because servers are not necessarily in the same time zone as the developer or customer.
The alternative would be an enum but I'm not sure how ergonomic that is and the size would be bigger.
Overall the current API for date times is fine but it lacks documentation. FloatingDateTime wouldn't be so bad but I'm unsure how many people would actually understand it.

I'm not sure if you ran across this, but PrimitiveDateTime is an OffsetDateTime without the UtcOffset. There is the ability to assume an offset on the former, which returns the latter. A PrimitiveDateTime has no way to directly get the "current" time, as doing so inherently requires an offset (which isn't present).
With regard to OffsetDateTime::now_local, obtaining the local offset requires information from the operating system. Not every operating system even has this information, and those that do may not provide a way to do so safely (see the recent security vulnerability on Unix-like operating systems for an example of this).

Misc
Maybe add to the top level documentation that this crate is for working with gregorian dates and that fractal seconds aren't supported.

Documentation definitely could use some work, no question there. Fractional seconds (which is what I presume you meant) are supported, though. The only struct that has a "seconds" component without a subsecond value is UtcOffset; this is because I'm not aware of any reasonably modern offset from UTC that is not a multiple of a full second in length.

I hope that this long comment is useful for development!

It definitely is! Thanks for making it :slightly_smiling_face:

I'm not sure if you ran across this, but PrimitiveDateTime is an OffsetDateTime without the UtcOffset. There is the ability to assume an offset on the former, which returns the latter. A PrimitiveDateTime has no way to directly get the "current" time, as doing so inherently requires an offset (which isn't present).

The PrimitiveDateTime::assume_* methods make indeed more sense now. So, OffsetDateTime are created from the "current" time and if the system does not support retrieving the local time it will return an error on the local methods. Is that correct?
For the top level documentation short lists for features, goals, non-goals, roadmap etc. could help without writing too much. Otherwise, I think the corrections you made to my comment could be a good starting point for documentation.

As a breaking release, I think the time::Result type should be made pub(crate) as it clashes with std::result::Result and forces user to re-import it.

@RagibHasin It's quite common for crates to have top-level exports named Result and Error. You don't have to import them; it's typically preferred to use the fully qualified path.

@RagibHasin It's quite common for crates to have top-level exports named Result and Error. You don't have to import them; it's typically preferred to use the fully qualified path.

Oh, my bad. I actually glob imported everything from this crate. Selectively importing items would solve this.
Thanks.

Glob imports generally aren't a good idea either, aside from foo::prelude::*.

Also, now as I came across serializing, it does something totally unprecedented for me. I used chrono before and am in the process of migrating to time and chrono serialized dates and times as RFC3339 format, which is user friendly.
My suggestion is to implement this for time also.

Serializing as in serde? Or formatting/parsing?

Serializing as in serde

In my experience, serde is generally used for things like message-passing and storage in a database/file. In either of these use cases an integer representation is almost certainly the most efficient or close to it. If you need something human-readable, using a fixed format is already supported in 0.2, and will have even better support in 0.3.

@RagibHasin I was also confused by the choice of representation when using Serde but it's actually very trivial to override: https://serde.rs/custom-date-format.html

@RagibHasin I was also confused by the choice of representation when using Serde but it's actually very trivial to override: https://serde.rs/custom-date-format.html

I'm also hoping it won't be terribly difficult to create a macro that will auto-generate modules like that based off of a format description. No promises though, as I haven't even looked into the feasibility of it.

I'm also hoping it won't be terribly difficult to create a macro that will auto-generate modules like that based off of a format description. No promises though, as I haven't even looked into the feasibility of it.

Something like #[time(format = "%F")]? That would be very cool.

Something like #[time(format = "%F")]? That would be very cool.

If feasible, I'm hoping it can be done as #[serde(with = time::serde::format!("[year]-[month]-[day]")). Like I said, though, I don't even know if this is possible. I just think it would be really cool.

If feasible, I'm hoping it can be done as #[serde(with = time::serde::format!("[year]-[month]-[day]")). Like I said, though, I don't even know if this is possible. I just think it would be really cool.

Wondering if there are any plans towards releasing an alpha version?

@reneherrero It's getting there! Main thing now is adding sufficient tests (and benchmarks derived from the tests) for formatting and parsing, along with documentation (the format description currently isn't documented anywhere, for example).
With regard to documentation at least, I've thought about a "time book" that would contain the full, detailed documentation, similar to how serde provides one on top of the basic API documentation. This wouldn't need to be completed for an alpha release, but testing I'd like to have done for that to happen.

I hear you.
Reason I'm asking is that, for my use case, the no_std thing is the big win, and works great as is.  Ported my lib to the master branch, but crates.io doesn't let you reference git repos.
An alpha might also help getting some feedback as it's easier to consume.
Food for thought

In my experience, serde is generally used for things like message-passing and storage in a database/file. In either of these use cases an integer representation is almost certainly the most efficient or close to it. If you need something human-readable, using a fixed format is already supported in 0.2, and will have even better support in 0.3.

Are you aware of [Serializer::is_human_readable](https://docs.serde.rs/serde/trait.Serializer.html#method.is_human_readable)? chrono also uses a timestamp for its efficient representation.

@Plecra I first saw that a few weeks ago. It's enabled behind the serde-human-readable flag on main! If serde is enabled without that, it will use a format intended for binary storage.

Today I was trying to use this crate just for getting formatted date time string. But unfortunately I don't see any examples, guides etc. I searched on duckduckgo but no luck.
After 10-15 minutes i found the answer but it would be nice to have guide like https://rust-lang-nursery.github.io/rust-cookbook/datetime.html which is for chrono.
println!("{}",time::PrimitiveDateTime::now().format("%Y-%m-%d-%H:%M:%S"))

@shirshak55 As I noted just three days ago in this issues, I still have to work on documentation for 0.3.

Using standard ISO 8601 for human readable output by default will simplify the use with web services / JSON.

That's a good point, and I'll certainly consider making the change. As a bonus, I'm pretty sure it's faster, but I haven't done a direct comparison yet.

Quickly looked into using RFC3339 for the human readable output of serde. This won't happen for a two reasons:

RFC3339 is limited in range to years 0-9999, whereas the time crate supports ±9999 with no flags enabled (±999,999 with large-dates enabled)
RFC3339 does not support UTC offsets with precision of one second.

While most people will need neither of these, I'm not comfortable putting a restriction like that in place when it should be general purpose. ISO8601 allows for larger & smaller years if I remember correctly, but the standard is not freely available (so I can't even verify this without paying a significant amount of money). I don't recall if ISO8601 supports UTC offsets with second precision.

I was thinking, what about create two features, serde-with-iso8601 and serde-with-large-dates, each with a default format? And for custom formats, provide modules for use with #[serde(with = "module")], regardless of the feature, so the current default doesn't matter.

Example:
#[derive(Serialize)]
struct Hello {
    // use the current default
    timestamp1: OffsetDateTime,

    #[serde(with = "time::formats::iso9601")]
    timestamp2: OffsetDateTime,
}

As I stated, it's not possible to use RFC3339 as a serde format for the general purpose. Changing defaults by toggling a feature flag would be dangerous, as this would mean that a library and end user could each enable one on their own (having both enabled would be a compile error).
I'm not opposed to adding more well-known formats (that's why it's an entire module), but they should be able to perform a roundtrip without losing information. In theory I could have a well-known format that could only be serialized or deserialized, but I'm not sure why that would be the case. I split the trait into two already, so the technical means to do so already exists.
Serde-specific formats would go under the time::serde module, which is where you'll find an alternative format that uses the Unix timestamp for OffsetDateTime. Given that all that's needed is a single line for the end user, there isn't much reason to place this behind a feature flag that would roughly double CI time.

Time 0.3.0-alpha.0 is out! The changelog is mostly accurate, though there's certainly some things to be updated. For documentation of the new format description, check out this page. I intend on filling out more of the book and updating some inline documentation before a final 0.3 release.

Looks like all of the items have been checked off. How do you feel about a proper stable release?

It's mostly documentation to be honest. I just started working on the book again yesterday, but I've got quite a bit else going on. I should figure out how to best present the format description info in the inline documentation. Other than that there's a couple places where I think documentation is inaccurate with recent changes. Once these happen it should be all set 🤞🏽

^^ a migration guide also needs to be made

If the functionality is complete, I would encourage you to publish even without the book or migration guide. I suspect that the utility of these extra pieces of documentation are not of significant enough value, given the nature of the library, to warrant delaying the releasing.

That's reasonable. I'll take a bit of time tonight to ensure none of the existing documentation is outright wrong and check that the changelog is up-to-date. Neither of those should take too long. If it goes well I'll cut a release tomorrow.

Pending the outcome of the full powerset on a number of targets (https://github.com/time-rs/time/actions/runs/1077701313), the current master branch will become v0.3.0. It normally takes a bit over an hour to run, so I'll get to it when I'm on my laptop next.

Looks like the CI is green!
One thing I noticed in giving this a go is that const_fn and standback are the only direct dependencies by default. This is fantastic, but I think it would be even better if there were no dependencies by default. After all, time should be a fairly lightweight dependency itself. Both of these dependencies exist purely to decrease the MSRV, but what if I'm not particularly concerned about the MSRV or am happy with whatever the MSRV would otherwise be? It would be great to shed the 4 (transitive) dependencies if I'm not benefiting from them.
The obvious approach is to feature gate these, perhaps via an aptly named compatibility feature. I would advocate for disabling the feature by default, documenting the MSRV, and noting that it can be reduced by enabling the feature. I'm happy to implement this, too!

Given that time us widely used, I think having the MSRV be that little bit lower is worthwhile, at least for now. After all, it's still a fourteen release bump from 0.2, which supports Rust 1.32.
I would like to state for the record that I will be tracking the six-month timeframe quite closely in the future though. I keep track of a number of unstable and recently stabilized features here along with the date on which time can use them per policy. I currently have (in my head) an MSRV bump to 1.51 scheduled for the end of September, as that will unlock a fair amount (particularly with const generics internally). Until that time, though, the dependencies are still lightweight compared to most libraries.

Welp, new release means new lints that I should probably fix before publishing! It'll be out tonight.

Given that time us widely used, I think having the MSRV be that little bit lower is worthwhile, at least for now. After all, it's still a fourteen release bump from 0.2, which supports Rust 1.32.

It's exactly because time is widely used that you should attempt to decrease the number of dependencies as much as possible. Here's the impact after making the changes I suggested, increasing the MSRV a single point release from 1.46 to 1.47:
~/Local/time ❯ time cargo build -j1
   Compiling version_check v0.9.3
   Compiling const_fn v0.4.8
   Compiling easy-ext v0.2.9
   Compiling standback v0.3.5
   Compiling time v0.3.0 (/home/sbenitez/Local/time)
    Finished dev [unoptimized + debuginfo] target(s) in 6.73s
cargo build 6.01s user 0.81s system 99% cpu 6.824 total

~/Local/time ❯ time cargo build -j1                                                                                main ●
   Compiling time v0.3.0 (/home/sbenitez/Local/time)
    Finished dev [unoptimized + debuginfo] target(s) in 1.43s
cargo build 1.38s user 0.15s system 100% cpu 1.529 total

That's a 4.7x speedup! I cannot imagine justifying a 4.7x slowdown to decrease the MSRV by a single point release.

If the .1 really matters, we can still do better by using version_check. I also tried rustcversion, but it triples the build time instead of just doubling it:
❯ time cargo build
   Compiling rustversion v1.0.5
   Compiling time v0.3.0 (/Local/time)
    Finished dev [unoptimized + debuginfo] target(s) in 3.43s
cargo build 3.11s user 0.42s system 99% cpu 3.529 total

❯ time cargo build
   Compiling version_check v0.9.3
   Compiling time v0.3.0 (/Local/time)
    Finished dev [unoptimized + debuginfo] target(s) in 2.46s
cargo build 2.29s user 0.27s system 100% cpu 2.561 total

Huh, didn't realize the dependencies added that much to compile time. Given that information, I'll bump MSRV to 1.48. 1.49 is the highest we could go given policy, so it's still in line with that.

Time 0.3.0 has been released.


Fast snake

Added a sample binary for a better and delightful play experience.
Just added a new switch to adjust the fps.
Usage:
bin/6502 resources/fast-snake.bin 800

Codecov Report

Merging #50 (6e6bd91) into main (5922977) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main      #50   +/-   ##
=======================================
  Coverage   89.38%   89.38%
=======================================
  Files           4        4
  Lines         678      678
  Branches       57       57
=======================================
  Hits          606      606
  Misses         43       43
  Partials       29       29

Continue to review full report at Codecov.

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

Just curious of what changes in snake would be need to run smooth on 60fps


tell me how to use java

Please clarify your question. In what way it relates to VK ID SDK?

I want user VK ID SDK ,from java ,I do not  kotlin

The code should be very similiar, the only difference would be java syntax instead of kotlin. If you can't do that yourself, you can tell what parts of sdk you will be using (plain auth, onetap, etc) and i will provide you with necessary code

plain auth

There is a method in VKID class that doesn't use coroutines:
vkid.authorize(this@MainActivity, vkAuthCallback)

The first parameter is the LifecycleOwner, for example an Actviity and the second one is the implementation of VKID.AuthCallback interface

I will close this issue, since it seems that the question. Feel free to reopen this, if you need any further help


Serialized data interface

Serialized measurement data will be used to store data on the FRAM chip and reduce packet size for LoRaWAN uploads. Needs to be determined if necessary for uploading via WiFi. Serialization will happen with protobuf.

Tried implementing nanopb through the platformio registry and got the following
...
In file included from .pio/build/stm32/nanopb/generated-src/soil_power_sensor.pb.c:4:0:
.pio/build/stm32/nanopb/generated-src/soil_power_sensor.pb.h:7:10: fatal error: google/protobuf/timestamp.pb.h: No such file or directory
 #include "google/protobuf/timestamp.pb.h"

Also I'm at an impass for implementing protobuf in this project. Here are the following solutions I have considered

Use standard protobuf with generated c++ code

Don’t like the idea of the added bulk of using C++ folder

Use protobuf-c in a separate folder

Would need to create a separate library that will be imported to the stm32 project
Needs the library to be compiled on the host device

Use nanopb in a separate folder

Same issues with above

use nanopb with platformio implementation

Does not seem to support well known types listed on the wiki aka timestamp
How do I then create something like a python package that can be used later by Dirtviz

Accidentally closed as part of #17


helperMissing misinformation

According to:
http://handlebarsjs.com/builtin_helpers.html
The helperMissing helper says:

Internal helper that is called when a potential helper expression was not found in either the environment helpers or the current context.

That's not entirely true: it's also (very unfortunately) triggering (with 379172e) for fields which exists but have a value of null. This is forcing me to loop over all my input data beforehand and replace nulls with empty strings :(. Interestingly, this only appears to affect {{blah}} references, not {{foo.blah}} references.

The commit you have referenced is a merge commit from 4.x to the master. It cannot be responsible for this problem. Can you identify the correct commit?
Please also provide a working example in the fiddle.

It's been far too long for me to remember what this was even about - i'm no longer using Handlebars, so can't add any relevant info about it and will close this ticket.

OK. Thanks. I didn't want to close it without trying to make sense of it.


Backport "HBASE-28539 Merge of incremental backups fails if backups are on a separate FileSystem (#5867)" to branch-2

When the backups are stored on a location that is not the DistributedFilesystem underpinning HBase itself merging of incremental backups fails. Detected with backups stored on S3A, but can be reproduced with any other (like LocalFilesystem).
Reviewed-by: Ray Mattingly<EMAIL_ADDRESS>

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
0m 53s
Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s
No case conflicting files found.

+1 :green_heart:
hbaseanti
0m  0s
Patch does not have any anti-patterns.

+1 :green_heart:
@author
0m  0s
The patch does not contain any @author tags.

_ branch-2 Compile Tests _

+1 :green_heart:
mvninstall
4m 23s
branch-2 passed

+1 :green_heart:
compile
0m 33s
branch-2 passed

+1 :green_heart:
checkstyle
0m 12s
branch-2 passed

+1 :green_heart:
spotless
1m  1s
branch has no errors when running spotless:check.

+1 :green_heart:
spotbugs
0m 41s
branch-2 passed

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
3m 54s
the patch passed

+1 :green_heart:
compile
0m 30s
the patch passed

+1 :green_heart:
javac
0m 30s
the patch passed

+1 :green_heart:
checkstyle
0m 10s
the patch passed

+1 :green_heart:
whitespace
0m  0s
The patch has no whitespace issues.

-1 :x:
hadoopcheck
1m  8s
The patch causes 10 errors with Hadoop v2.10.2.

+1 :green_heart:
spotless
0m 54s
patch has no errors when running spotless:check.

+1 :green_heart:
spotbugs
0m 46s
the patch passed

_ Other Tests _

+1 :green_heart:
asflicense
0m 13s
The patch does not generate ASF License warnings.

24m  5s

Subsystem
Report/Notes

Docker
ClientAPI=1.43 ServerAPI=1.43 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5969/1/artifact/yetus-general-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/5969

Optional Tests
dupname asflicense javac spotbugs hadoopcheck hbaseanti spotless checkstyle compile

uname
Linux 4ded237e6a60 5.4.0-1103-aws #111~18.04.1-Ubuntu SMP Tue May 23 20:04:10 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
branch-2 / f56248673a

Default Java
Eclipse Adoptium-11.0.17+8

hadoopcheck
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5969/1/artifact/yetus-general-check/output/patch-javac-2.10.2.txt

Max. process+thread count
78 (vs. ulimit of 30000)

modules
C: hbase-backup U: hbase-backup

Console output
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5969/1/console

versions
git=2.34.1 maven=3.8.6 spotbugs=4.7.3

Powered by
Apache Yetus 0.12.0 https://yetus.apache.org

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
0m 49s
Docker mode activated.

-0 :warning:
yetus
0m  5s
Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck

_ Prechecks _

_ branch-2 Compile Tests _

+1 :green_heart:
mvninstall
3m 41s
branch-2 passed

+1 :green_heart:
compile
0m 28s
branch-2 passed

+1 :green_heart:
shadedjars
6m 14s
branch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
0m 18s
branch-2 passed

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
3m 40s
the patch passed

+1 :green_heart:
compile
0m 20s
the patch passed

+1 :green_heart:
javac
0m 20s
the patch passed

+1 :green_heart:
shadedjars
6m 12s
patch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
0m 14s
the patch passed

_ Other Tests _

+1 :green_heart:
unit
12m  3s
hbase-backup in the patch passed.

35m 15s

Subsystem
Report/Notes

Docker
ClientAPI=1.45 ServerAPI=1.45 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5969/1/artifact/yetus-jdk11-hadoop3-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/5969

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux e2651a83f4fe 5.4.0-174-generic #193-Ubuntu SMP Thu Mar 7 14:29:28 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
branch-2 / f56248673a

Default Java
Eclipse Adoptium-11.0.17+8

Test Results
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5969/1/testReport/

Max. process+thread count
4090 (vs. ulimit of 30000)

modules
C: hbase-backup U: hbase-backup

Console output
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5969/1/console

versions
git=2.34.1 maven=3.8.6

Powered by
Apache Yetus 0.12.0 https://yetus.apache.org

This message was automatically generated.

Hadoop check failure appears to have been a network transfer failure in the build environment.
[ERROR] Failed to execute goal on project hbase-http: Could not resolve dependencies for project org.apache.hbase:hbase-http:jar:2.7.0-SNAPSHOT: Could not transfer artifact com.squareup.okhttp:okhttp:jar:2.7.5 from/to central (https://repo.maven.apache.org/maven2): transfer failed for https://repo.maven.apache.org/maven2/com/squareup/okhttp/okhttp/2.7.5/okhttp-2.7.5.jar: Connection reset -> [Help 1]

Come to think of it, I'm not sure why we're checking hadoop 2.x with JDK11 -- doesn't JDK11 require hadoop3 profile?

Oh, it is using JDK8,
[INFO] --- maven-enforcer-plugin:3.0.0:display-info (display-info) @ hbase ---
[INFO] Maven Version: 3.8.6
[INFO] JDK Version: 1.8.0_352 normalized as: 1.8.0-352
[INFO] Java Vendor: Temurin
[INFO] OS Info: Arch: amd64 Family: unix Name: linux Version: 5.4.0-1103-aws

Builds for me locally with java8 and -Dhadoop.version=2.10.2 -Dhadoop-two.version=2.10.2


Remove all segments button

Contains the following changes:

Adds a button to delete all segments
Adds a button for each segment to delete corresponding segment

Ref #1083

I think you misunderstood #1083. I think what @kweingaertne wants is not to mark the content for removal, but to be able to quickly remove all segments itself. Right now, you would do that by starting somewhere and hitting the “Merge Left/Right” buttons over and over again.
Marking all segments for removal doesn't really make sense because you would end up with a 0 seconds long video file which should then fail to process as Opencast would tell you that this doesn't really make sense :D

I'm also not the biggest fan of the icon on the timeline. The old editor had several of them and I would like to not see them creep back one after another. Maybe instead as a “pro” feature to easily access the functionality implement #943 instead?
What do you think, @kweingaertne?

Finally (for the next time), having one feature/change pre pull request makes these changes easier to discuss, review and merge.

Now the button allows to merge all segments into a single segment.
Additionally, the delete button on each segment is removed.

Usually when merging segments, the resulting segment inherits the "deleted state" of the previously selected segment. So if I select a "blue" segment and merge it with "red", the resulting segment is "blue". This is not true for the specific case in which I select a "red" segment" and merge it left with a "blue" segment. The resulting segment is "blue" instead of "red". Could you fix that?

Thanks for noticing. It should be fixed now.

Usually when merging segments, the resulting segment inherits the "deleted state" of the previously selected segment. So if I select a "blue" segment and merge it with "red", the resulting segment is "blue". This is not true for the specific case in which I select a "red" segment" and merge it left with a "blue" segment. The resulting segment is "blue" instead of "red". Could you fix that?

Thanks for noticing. It should be fixed now.

During solving the merge conflicts, I have noticed that this problem was still present. Hopefully, this is solved now.


Deis Router "no such container" CrashLoopBackoff

In my deployment of Deis Workflow v2.12.0, I am seeing a CrashLoopBackOff on the Router component:
deis                     deis-router-2126433040-drr9t                    0/1       CrashLoopBackOff   85         5d
looking at the logs with kubectl, I see the following:
no such container: "169d0df2740125110584a290b4b7da6b1fa8c3d9ebd82120ec93ee621fd2070e"
Is this a known issue?   Is there anything I can collect to help diagnose what's going on here?

Deleting the router pod seems to resolve this - but FYI in case you hear of a similar case.

Are you running with EXPERIMENTAL_NATIVE_INGRESS?

@kris-nova I don't think experimental native ingress was released in v2.12.0 :)
ping @krancour, any clues? This is one bug I have not seen before.
@timfpark would you mind dumping the entirety of kubectl logs for the router in a gist? I'd also check and see what's happening on the kubelet's side as well just in case; that no such container error usually indicates something wrong on the Docker level.

I have never seen anything like that before and cannot think of any reason the router itself would throw such an error. As @bacongobbler suggested, I'd love to see a more complete log if that's available.

This issue was moved to teamhephy/workflow#26


Remember to exercise bug

Starting the quest through /quests puts you in the floor under the house in Ione, and the next step involves going to old Ione making a lot of players confused (including myself). quest can still be completed though. might wanna fill in he hole in the floor.

This is the teleporting system picking a nearby spot that is safe to teleport to. The4bestgame filled in the area below the house so this shouldn't happen again.

This is the teleporting system picking a nearby spot that is safe to teleport to. The4bestgame filled in the area below the house so this shouldn't happen again.


[dockerfiles] Improvements and fixes to push_testing_images.sh script

add check that there are no unwanted .current_version files left in the repo after foobar/Dockerfile gets deleted.
revisit the logic for repo digest vs id digest of docker images.

Looks pretty good, just a few comment left inline.
To future-proof this a bit, I suggest adding a check to tools/dockerfile/push_testing_images.sh that ensures we don't commit any current_version files that are missing a digest. If docker image inspect ... fails for example, the version won't be updated, but the image will have been pushed anyway.

Good catch. I originally thought this is ok, assuming a sanity check would prevent you from submitting such a PR.
But then I realized that the sanity check actually runs in as LOCAL_MODE=true, and that wouldn't reveal the issue since it wouldn't query the artifact registry. So I'll have to add an extra check for this.
https://github.com/grpc/grpc/blob/19414da96d6235226c41063d607dfef2c7210df1/tools/run_tests/sanity/check_testing_docker_images.sh#L23

@drfloob @gnossen  PTAL, I added an explicit check for locally-built images that weren't pushed (see https://github.com/grpc/grpc/pull/33760#issuecomment-1645698061 for context)

@jtattermusch
FYI, this appears not be working as intended:

PR
Failing test with unknown docker image hash


Create "Global / External-agnostic" declaration files without exposing internal definitions

Say I'm writing a declaration file for an external library that both exposes a global and supports CommonJS. According to the handbook I would write that like this:
module zoo {
  function open(): void;
}

declare module "zoo" {
    export = zoo;
}

And then the usage would be this:
// Either
import x = require('zoo');
x.open();
// or
zoo.open();

The problem is that while the above would compile when using external modules, at run-time it would fail since the "zoo" identifier doesn't actually exist. Is there any way to write declaration files such that you can split them into two separate files (one for internal, one for external) so that you only reference the one you intend on using but not actually duplicate the definitions in those files? For example
// zoo.d.ts
declare module "zoo" {
    export = zoo;
}

// zoo-internal.d.ts

/// <reference path="zoo.d.ts" />
module zoo {
  // this doesn't work but illustrates what I'm trying to accomplish
  import zoo = require('zoo')
  export = zoo;
}

Or any thoughts on another way to accomplish the same goals in a single file?

It was brought to my attention that the TypeScript team actually solves this internally by scripting. https://github.com/Microsoft/TypeScript/blob/42c05453bd5f2b1c4e75cd2fff1d2b55434119c0/Jakefile#L352-L356
Any plans on supporting it at the language level?

The compiler can not force the existence of js code. Simply because it does not know about it. If you are exposing an internal module, then it is the responsibility of your users to load the library js code, either through a script tag, bundling it at build time or using a resource loader. This is the same in the case of most libraries definitions, say jquery.d.ts, you need to include the .js file independently from the definition.
If your library is available in two modes, e.g. a universal module implementation, then I would recommend releasing two declaration files, one for each mode just to avoid confusion. This is what we did for typescript package definition. What the compiler does not support is generations both files in the same compilation, namely multi file external modules, which is a highly requested feature and I would expect us to support it in the future. For the time being we worked around by copying the file and addng the export statement. There are a few tools out there that can help you out.
If however your module have global side effects, then that is a different issue. The language does not support modeling of these global side effects and I would argue that it should not be added in the future either.

@mhegazy Thanks for your response.

The compiler can not force the existence of js code.

To be clear, I wasn't asking for this.

If your library is available in two modes, e.g. a universal module implementation, then I would recommend releasing two declaration files, one for each mode just to avoid confusion.

This is exactly what I was asking about. I don't mind releasing two declaration files. The problem, currently, is that both declaration files have 99% duplication. I'm asking for a language feature which will remove this duplication. As one possible example of such a language feature, you could allow an internal module declaration to import an external module declaration and then append the external module's exports to that of the internal module's. (see my example in the original post)

What the compiler does not support is generations both files in the same compilation

I'm talking about writing declarations for pre-existing libraries, not for libraries written in TypeScript.

It seems like #1983 might provide a solution to this if it allowed usage within an internal module declaration. For example:
// zoo.d.ts
declare module "zoo" {
  export function open(): void;
}

// zoo-internal.d.ts

/// <reference path="zoo.d.ts" />
module zoo {
  export * from "zoo";
}

I am afaraid that is not going to work either. export  * from "mod" are only allowed in external modules.
You can do the oposite though:
// zoo-internal.d.ts
declare module zoo {
  export function open(): void;
}

// zoo.d.ts
/// <reference path="zoo-internal.d.ts" />
declare module "zoo" {
  export = zoo;
}

Unfortunately that gets back to the original issue, which is that by referencing zoo.d.ts you get both the external module and the internal module.
Is there any reason that the export * from "identifer" can't be allowed within an internal module declaration? Presumably it just re-exports the existing members.

The problem really is you can not mix external into internal. think of internal modules as namespaces, so they are just simple IIFE's that have a name.. external modules require loading and dependency resolution and detection. so  when i use the internal module zoo, would that be rewritten as a require call?

Keep in mind I'm only talking about declaration files here for an external module written in UMD.

For clarity: "third party library written in UMD"

We need a proposal for this one. I understand that this is a pain point, and we need a solution.

closing in favor of https://github.com/Microsoft/TypeScript/issues/7125


Set necessary env for system gtk themes to work and clean up content     interfaces

This also reverts a previous commit which disabled the usage of gtk2-common-themes.  This was originally done because gtk2-common-themes was only built for amd64.  We'll soon have gtk2-common-themes for all supported architectures.

This is no longer relevant as far as I can tell, and already fixed on both the candidate and preview branches. Thanks all!


Why I am not getting left SideMenu over the existing view in swift5?

I have read the guidelines for contributing and I understand

[x] My issue is happening in the latest version of SideMenu (older versions are no longer maintained).
[x] My issue was not solved in the README.
[x] My issue can not be answered on stackoverflow.com.
[x] My issue is reproducible in the demo project.

Describe the bug
I am using left SideMenu over the existing view from this framework, in swift 4 it was working fine, recently I have updated pod to Swift 5  pod 'SideMenu', '~> 6.0'  here I am not getting left SideMenu over the  existing view, here existing view also moving along with sidemenu
Expected behavior
Want left sidemenu over the existing view in swift 5 like below

Screenshots
in swift 5 getting like below why?

This is my demo project on swift 5 with issue https://github.com/SwiftSamples/sideMenuDemo
Please help me in the above issue.

Please do help some one.. here.. got stuck from long time

Please read the README carefully and change the presentationStyle.


MsBuild or Command Line Integration, CI and Publish

Can I publish WCF service library project with auto generated *.svc and web.config files that integrated CI pipeline. (VSTS, TFS, Task or Command Line).

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

ID: 74770e0d-c48a-8355-8e73-c8afb968a7ac
Version Independent ID: 686d2fa7-335b-8fb7-0c44-85231d49a4d8
Content: WCF Service Publishing
Content Source: docs/framework/wcf/wcf-service-publishing.md
Product: dotnet-framework
GitHub Login: @dotnet-bot
Microsoft Alias: dotnetcontent

@zhenlan is this something you or someone from your team can help?

@gencebay is your question about whether you can publish a WCF application as part of CI instead of inside Visual Studio? Are you thinking about publishing to IIS? If yes for both questions, publishing of WCF applications is very similar to publishing ASP.NET applications, so you should be able to use tools for publishing ASP.NET applications, for example, web deploy.
cc @Lxiamail


No "evals_result", empty dict as the "evals_result"

I got no result as evals_result  at xgb.train():
 params = {'objective': 'binary:logistic',
              'eta': 0.1,
              'max_depth': 9,
              #'min_child_weight': 50,
              #'gamma': 0.02,
              'subsample': 0.98,
              'colsample_bytree': 0.9,
              'silent': 1,
#              'alpha': 0.1,
#              'lambda': 0.001,
              'nthread': 4,
              }
    num_trees = 2

    watchlist = [(Xd_train,'train'), (Xd_valid,'eval')]

    res={}

    xgb_model = xgb.train(params, Xd_train, num_trees,
                          evals=watchlist,
                          early_stopping_rounds=200,
                          verbose_eval=True,
                          evals_result=res)

    print res

[Out]:
Will train until eval error hasn't decreased in 200 rounds.
[0]	train-error:0.292633	eval-error:0.297212
[1]	train-error:0.283822	eval-error:0.290464

{'train': [], 'eval': []}

ubuntu 14.04 LTS
64-bit
Python 2.7.11

I have the same problem here. The evals_result is empty.

Do you have the latest xgb version? There was a wrong regular expression, which caused empty evals_result, but it should be fixed. with latest xgb (compiled from sources), py 2.7.10 @ Windows I got:
{'train': {'error': ['0.081579', '0.084924']}, 'eval': {'error': ['0.08298', '0.08687']}}

@Far0n Thank you, it was really a version problem.


roku not responding

Hello-
great tutorial, trying to move this server from a windows system to my linux server.  Got the node server running, it discovered my roku, however when i make an alexis requests, the roku does not repsond.  the server shows the request going through (Unknown request URL:  /roku/netflix).
any suggestions?

this is the top portion of my server.js
var serverinfo = require("./serverinfo");
var rokuChannel = require("./rokuchannels");
var http = require('http');
var fs = require('fs');
var urllib = require("url");
var Client = require('node-ssdp').Client;
var dgram = require('dgram');
var ssdp = new Client();
var keyDelay = 100; //typing delay in ms. If you have a faster roku, you can probably reduce this, slower ones may have to increase it.
//null will cause the server to discover the Roku on startup, hard coding a value will allow for faster startups
// When manually setting this, include the protocol, port, and trailing slash eg:
exports.rokuAddress = "http://<IP_ADDRESS>:8060/";
var rokuAddress = "http://<IP_ADDRESS>:8060/";
var PORT=80;

You might need to pull the recent changes to RokuLambda/index.js and reupload them. A collaborator made a change to how launching Netflix works, now you use something like /roku/launch with the channel as a POST parameter.

Thank you I will check the POST commands.  To be clear, multiple commands didnt work, ie home, hulu, etc.
I did notice there were changes to most of the files even since I setup my first server a week or two ago. Thank you for the quick response and for keeping your projects current.

I loaded the server.js file from my old server to the new server and that fixed the problem.  I am not sure if the newest versions will all work together though.  Thanks

Great, glad you worked it out! It's possible that there's something broken since the last merge


C1218IOError('failed 3 times to correctly send a frame'

smart meter in Mexico, bran  IUSA.  to connect RS232 serial cable probe for meter.  use a Windows  a python. the same error.
I have done with communication program if there is response from the  samrt meter and if there is.

Can you set the log level to DEBUG and repeat the steps? My guess is that you're using incorrect serial settings so the probe can't communicate with the meter.

can you help me in the configuration of the Debug
what are the steps?
2018-02-19 12:51 GMT-06:00 Spencer McIntyre<EMAIL_ADDRESS>
Can you set the log level to DEBUG and repeat the steps? My guess is that
you're using incorrect serial settings so the probe can't communicate with
the meter.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/securestate/termineter/issues/7#issuecomment-366776723,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AJlhgScxMTeZZcecASaiy4eIJuV2ePOMks5tWcKxgaJpZM4SK036
.

Start the program with the -L DEBUG option. You can find more details from the --help menu.

I'm going to close this issue out due to inactivity. If you're still experiencing it, please respond to the preceding message in this thread and we'll re-open it. Thanks.

Good Day
One Cuestion Plase
did you program termineter  you can access to smart meter?
2018-02-27 16:40 GMT-06:00 Spencer McIntyre<EMAIL_ADDRESS>
I'm going to close this issue out due to inactivity. If you're still
experiencing it, please respond to the preceding message in this thread and
we'll re-open it. Thanks.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/securestate/termineter/issues/7#issuecomment-369052857,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AJlhgSM3C7YI-v5LZHLYi2WJX64wJV8Bks5tZIRRgaJpZM4SK036
.


Enhance Manifest Structure and Attributes

Add additional keys to manifest to support additional features like Upgrade, and Uninstall.
Several features will require additional fields in the manifest. In addition more complex manifests may benefit from being split into multiple files.
Proposed technical implementation details (optional)
All fields should be identified and defined well enough for everyone to understand. Where possible, character case, and the name of the field itself should be clear. In some cases, the field names may be drawn from other existing Microsoft products and field properties to help with clarity and consistency.
One of the primary goals is to ease the process for humans to author manifest files. A secondary goal is to simplify the process of localization. Many fields in the meta-data are available from localized URLs and some community contributors wish primarily to make packages more globally inclusive.
Most manifests today appear to be provided in a single language with a single installer. In those cases, we would like to continue to support a single file manifest structure. Once an additional language/locale is added, we would like to see the localized content split out into separate files per locale. The default values would come from the default locale (which would need to be specified at that point).
When there are multiple architectures, or target platforms (and a few other attributes), the installers would be split out into a file that focuses just on that set of meta-data.

The v1.0 schema has been released :smile:


Does this gem need a new owner?

I'm not seeing any activity on this gem in the past 2 years, but there are a number of apparently valid, open issues and PRs. I work at Stitch Fix and we use this gem heavily. Personally I love it, it makes my life easier and I'd love to see it continue to grow. I'd be interested in taking over ownership/maintenance if that's an option.

Given there's no response, I'd say just fork it and start pulling in PRs :)

Please let us know if you decide to do something with this.  It would be wonderful to have Stich Fix maintain this.

Hi! Yeah I don't spend any time in the Ruby world anymore and if there are active users of this gem I'd happily hand it over to anyone that wants to take on it's future maintenance and development. @adsteel Would you prefer being added to the contributors or I believe it's possible to transfer ownership of the repo. From memory I'd have to give push access to Ruby gems as well (been a while since I did anything on this space)

@philostler I spoke too soon about taking this on on behalf of Stitch Fix, but I'm still interested on a personal level. I reached out on LinkedIn, since your contact info here looks like it might be outdated.

Hm, thought I left a comment yesterday, but guess I didn't "send."
@philostler Seems like Linkedin isn't working for communication either. I'd love to be made a contributor, or even take ownership if you'd rather. I've taken this week to poke around and I'd love to help keep this gem alive if I could. If I make decent progress on my own I'll consider publishing a new version under a new name, but I'd love to use this repo if possible.
@packrat386. I see you're a contributor (at least) and a rubygems owner, any chance you're able to give me some permissions here?

Hi 👋 Fellow interested party in ownership and maintenance. I worked with @adsteel at Stitch Fix too. Happy to be a collaborator/maintainer/co-owner. This gem makes life much easier, and I want to see several of the open PRs/issues continue to make it useful for the Sidekiqs out here ❤

So, I can't transfer ownership of this repository because I don't have admin privileges on it. I can however merge PRs and release new versions to rubygems.
I've been reluctant to take on requests for new features/releases because I no longer use the gem myself. But @adsteel if you're willing to put in the time reviewing and approving PRs you can ping me when you're ready to have one merged. Similarly if you collate features into a new release version I'm happy enough to push it to rubygems on request. Bit of an awkward workaround for now, but could be workable in the short term?

Unfortunately, I've since left Stitch Fix and am not currently working in Ruby. So I'd suggest you take up @wspurgin 's offer.
@wspurgin here's work I did to bring rspec-sidekiq up to date with Ruby 3.2, and get a new build working on GitHub actions. You're welcome to use any, all or none of it.

Always a pleasure Adam :heart:

@wspurgin I can extend you the same deal then. If you want to take up the mantle just let me know when you want something merged or released?

@packrat386 That sounds like a reasonable plan for now. Until @philostler transfers ownership (you can also manage owners via the RubyGems UI which might be easier)

@philostler at your earliest convenience could you:

Transfer ownership to me (wspurgin), I'm happy to have the repo. Or at least give me "Maintainer" privileges if you want to keep the repo so I have full access for moderation/management
Make me the owner or grant push access on RubyGems to rspec-sidekiq - I'm wspur on RubyGems https://rubygems.org/profiles/wspur

Cheers! 🎉

I can add you as an owner on rubygems. I've sent an invite for that.
I can't give you repo access though unfortunately.

HI @wspurgin. I couldn't transfer you ownship. GitHub threw me this error when I tried...

wspurgin already has a repository in the philostler/rspec-sidekiq network

I have however just added you to the Collaborator list.

Hey @philostler! Thanks so much! That error is from the fact that I had a fork still. Could you try again? I just deleted it.

@wspurgin Transfer request done. I don't touch Ruby anymore now so I'm glad this project is moving on to those that have time to move it forward. Good luck!
P.s. Thanks @wspurgin for taking this on, and @packrat386 for your contributions up to now.

Thank you @philostler! Transfer complete. We wouldn't be here without your fine work to start with 🚀
+1 to @packrat386 for all the contributions and helping us out here during the transition.
p.p.s., You may quit Ruby, but Ruby doesn't quit you! 😉


Is it possible to pass battery Level from traccar to OpenGTS through forward.url gprmc ?

Hello
Is it possible to pass battery percentage from traccar (extended info/battery)
to OpenGTS Gprmc ('batt' parameter) through forward.url?
Forward URL is working without the batt parameter, for geozone / geofence notifications (it works because of the gprmc parameter).
But it would be good to have the batt parameter for battery low notifications..
Currently my config in traccar.xml is
<entry key='forward.enable'>true</entry>
<entry key='forward.url'>http://<IP_ADDRESS>:8080/gprmc/Data?id={uniqueId}&code=0x0000&batt={batteryLevel}&gprmc={gprmc}</entry>

I tried batt={batteryLevel} to pass battery level to forward.url, but no success..
INSERT INTO EventData (accountID, deviceID, timestamp, statusCode, latitude, longitude, speedKPH, heading, altitude, rawData, creationTime, address, batteryLevel)
            VALUES (@accountID, @deviceID, UNIX_TIMESTAMP(:fixTime), @statusCode, :latitude, :longitude, :speed * 1.852, :course, :altitude, :extended_info, UNIX_TIMESTAMP(NOW()), :address, ExtractValue(:extended_info, '/info/battery');

Thanks

It's possible to send all attributes using {attributes} parameter, but not battery separately.

Thank you so much Mr. Anton +1:  :D

The old Android APP Traccar sends message in gprmc protocol right? Where can i find that "old" app?
It can be used with traccar 3.4?

Do you mean Traccar Client app? Yes, it's supported by any version of server.
You can build it from source using one of the tags:
https://github.com/tananaev/traccar-client-android/releases

https://www.traccar.org/traccar-client-protocol/
It says that the old Traccar Client sends message in gprmc mode,
I know that there are alot of GPRMC OpenGts clients, but i want to use traccar, because its much more better, in performance, also it has many more protocols than OpenGTS, etc...

Traccar server does still support old protocol if that's what you are asking.
You can also compile older version of Traccar Client if you want.


ENH: add CITATION.cff

It was suggested at the CZI EOSS Kickoff meeting that projects should have a CITATION.cff file:

CITATION.cff files are plain text files with human- and machine-readable citation information for software. Code developers can include them in their repositories to let others know how to correctly cite their software.

The file format is described here.
A validation and conversion tool is here.
This PR would add a CITATION.cff file that meets the requirements of the format (e.g. version number and release date are required fields - how are we going to keep these up to date?) and also includes information about the preferred reference, the Nature Methods paper.
Unfortunately, the CFF format seems to prioritize citation of the software itself rather than a related article. For instance, the conversion tool produces the BIBTEX citation:
@misc{YourReferenceHere,
author = {

         },
title  = {SciPy},
month  = {1},
year   = {2020}
}

I don't think this is what we want. Perhaps we should not include a CITATION.cff?

At the end of the file, you have
title: "SciPy"
authors:
  -
    name: "SciPy Contributors"

How about removing that, and unindenting the rest of the file, so all annotations refer to just the paper in Nature Methods?  I don't know if that would cause a problem--I'm still reading the docs over at https://citation-file-format.github.io/

Now that I've read a bit more, I think the file as you have it now is arranged as it should be.  In particular, the paper is in the references section.
Are there other projects that have a published paper and have a CITATION.cff file in their repo?

This looks like the right format for the wrong thing - the stated purpose on the cff format's website is citing the software, while we want people to cite the paper.
I do agree adding easy to discover metadata is good though. We have scipy.org/citing.html, but a CITATION.someext that says "please cite this paper" (whether in machine-readable format or not) would be a nice addition.

Ralf, I was writing the follow at the same time that you responded...
I'm still figuring out how this file is supposed to work.  At the moment, the impact of including this file is not clear to me.   Will this end up encouraging authors to cite the package and not the paper?
The main intent of CITATION.cff seems to be to provide standard citation metadata for a software package.  I'll refer to this as "citing the package".  Included in that metadata is the option for references to traditional papers about the software.  In our case, the metadata within the references section describes the Nature Methods paper.
I think we want to encourage authors to cite the paper.  That suggests that the message in CITATION.cff should be something like
message: If you use this software, please cite the Nature Methods paper shown in the references.

But what if someone wants to cite a specific version of the software?  Then they should be cite the package--preferably in addition to citing the paper.  But will automated tools be aware of that?  Will authors end up using automated tools (such as https://citeas.org), and will those tools provide the instructions to cite the paper, or will they end up only providing the package as the recommended citation?

To me it's a solution looking for a problem. A single CITATION file should suffice.

To me it's a solution looking for a problem. A single CITATION file should suffice.

We don't have one though. I'd be fine with adding a CITATION.md that has the same content as https://scipy.org/citing.html#scipy-the-library
I propose to not bother with .cff, since it indeed doesn't do anything we want.

Not much interest in CITATION.cff, and I don't really care either. Just thought I'd mention it since it came up at the kickoff. I'll close this, but please consider updates to Nature Methods paper citation in scipy/scipy.org#366.


[BUG] Gradient text result not centered

Description
The result(text) of gradient text isn't centered in it's parent container
Screenshots

Additional information
Tasks:

[ ] Center the text in results section of gradient text

🥦 Browser
Mozilla Firefox
👀 Have you checked if this issue has been raised before?

[X] I checked and didn't find similar issue

🏢 Have you read the Contributing Guidelines?

[X] I have read and understood the rules in the Contributing Guidelines

Are you willing to work on this issue ?
No response

@Dun-sin Assign me please

@Dun-sin Assign me please

no, you only get one good first issue

@Dun-sin I can fix this little issue. Assign me if you want.

@Dun-sin I can fix this little issue. Assign me if you want.

No, it's for new contributors

Can i work on this issue

Can i work on this issue

Definitely, thanks for wanting to contribute, Make sure you follow the rules 👉🏽here👈🏽, else your PR will not be accepted and will be closed.
Good Luck

:tada: This issue has been resolved in version 2.29.1 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


#15868: use a buffer's size when creating its CB in groupnorm

Ticket
Link to Github Issue https://github.com/tenstorrent/tt-metal/issues/15868
Problem description

Some group norm tests are failing with Debug Build with an assert about CB size
The underlying reason is that the in0 CB was always sized to the nearest tile, even when the input was row major and therefore smaller

What's changed

Set the CB size for in0 based on the per bank size to get the right size for row major and tile input

Checklist

[x] Post commit CI passes across https://github.com/tenstorrent/tt-metal/actions/runs/12360041457 and https://github.com/tenstorrent/tt-metal/actions/runs/12374697868 all sub-jobs pass at least once
[x] Blackhole Post commit (if applicable) https://github.com/tenstorrent/tt-metal/actions/runs/12360044285
[x] Model regression CI testing passes (if applicable) https://github.com/tenstorrent/tt-metal/actions/runs/12360048449
[x] Device performance regression CI testing passes (if applicable) https://github.com/tenstorrent/tt-metal/actions/runs/12360046481
[ ] (For models and ops writers) Full new models tests passes
[x] New/Existing tests provide coverage for changes (in Debug)

@TT-BrianLiu added you as a reviewer to see if you're ok with this change.


Update README.md

HI， Can you help update our latest paper on diffusion segmentation?

The paper is added. Thank you.


import maps

is there any plan to have a reconciliation of the import maps proposal and this? having two different formats floating around to do basically the same thing is annoying, especially when we have the opportunity now to fix it.
cc @domenic

This proposal builds on top of the import maps proposal. On a conceptual level exports is a contribution to the import map. Pseudo code:
imports = {}
for each pkg in packages
  for each exportKey, resolution of pkg.exports
    imports[pkg.name + exportKey] = new URL(resolution, pkg.url).href
// `imports` is now a valid import map

The explanation above skips of scopes and nesting but the general idea is that just using package.json meta data and a rough package mapping, e.g. package-lock.json, you could build a complete in-memory import map and would never have to hit the disk to resolve anything.

I think the current semantics are aligned with import maps as much as we can (given that import maps aren't 100% finalized yet).