Remove requirement for braces in html! macro

Problem

The html! macro currently requires braces ({ and }) for any expressions used as children (such as for raw text nodes). This is not a parsing limitation and could potentially be made more ergonomic.
// old
html! {

{ "Hello World!" }

}

// proposed
html! {

"Hello World"

}

Unanswered questions
Should only string literals be allowed or any valid expression? If the later is decided upon, that would mean we could also write
html! {
    <>

123

        if condition {
            html! { }
        } else {
            html! { }
        }

    </>
}

Questionnaire

[ ] I'm interested in fixing this myself but don't know where to start
[x] I would like to fix and I have a solution
[ ] I don't have time to fix this right now, but maybe later

I absolutely support this - I just haven't got to it because there are far more pressing issues.
I would prefer to only support string literals for this. We already have other plans to make flow control more ergonomic.

Actually, I don't think we could parse any arbitrary expression, e.g.
let test = ...;
let test2 = ...;
html! {

test
test2

}

This would be a nightmare to parse! We would need extremely powerful speculative parsing to tell whether the < in the
 tag is a operator or part of a html tag.
It reminds me of the proposal to remove the turbofish syntax. I guess only allowing string literals is the right choice.

That is absolutely out of the question, yes. Not just is it a nightmare to implement and test, it's also extremely inefficient.
By string literals I'm exclusively talking about "string like this".

I'll try to to implement this if nobody minds. I'm guessing I'll just extend the Peek and Parse implementations on HtmlBlock to special case string literals and implicitly convert them into blocks.

I'm 👎 on this one as well... I'd much rather see this align closely to JSX syntax than string literals... as proposed, I'd expect to see "string" with the quotes in the actual rendered output...  JSX has kind of become a defacto standard for this type of templating and is used in several tools beyond just React.

I'm 👎 on this one as well... I'd much rather see this align closely to JSX syntax than string literals... as proposed, I'd expect to see
"string"
 with the quotes in the actual rendered output, would rather keep the parens, or allow bare text
string
... JSX has kind of become a defacto standard for this type of templating and is used in several tools beyond just React.

There's no reason why
{"string"}
 would be closer to JSX.

@lukechu10
{"string"}
 would work directly in JSX...
"string"
 would be a different behavior between proposed and JSX... though being able to tokenize
string {value}
 would be preferred imo.

@lukechu10
{"string"}
 would work directly in JSX...
"string"
 would be a different behavior between proposed and JSX... though being able to tokenize
string {value}
 would be preferred imo.

Percy allows strings without quotes so it's definitely possible. One problem I see with this is that keywords would be tokenized differently and thus would appear differently in the IDE.
About
{"string"}
 vs
"string"
, the first one is not at all idiomatic JSX so I don't see any value in trying to mimic JSX semantics here.

IMO
"string"
 would be less ergonomic.

string
 or ,
{ "string" }
 is ok. Do you intend to use bare for string literals and the curly braces for variables?

I would also advocate for the current syntax being kept rather than the proposed syntax, as this just looks ambiguous as to whether we want to display the string "string" or string when we do
string
, as @tracker1 said.
For someone learning Yew for the first time, it would be confusing to write some expressions in curly braces and others without them. The extra two characters it takes to use the current syntax are a small price to pay for having clear and consistent syntax imo.

RE:

string

That is absolutely out of the question, yes. Not just is it a nightmare to implement and test, it's also extremely inefficient.

One problem I see with this is that keywords would be tokenized differently and thus would appear differently in the IDE.

I agree here that syntax is not going to be a pleasant experience for IDE users and I think would promote people to think that any arbitrary input is accepted, probably in the notion that this is all just being wrapped up and put into set_inner_html.
RE:

"string"

I'd expect to see
"string"
 with the quotes in the actual rendered output,

In Rust, you need to escape or use raw strings in order to display quotes so I don't think I'd have expected this to be the case when I first started using Yew, but hard to say for sure now I've gotten soo used to Yew 🙃. I think if you are not coming from Rust but from other JSX web frameworks then this could be confusing 🤔. I know we get all kinds of people, new to web but not Rust and vice versa so important to consider both sides and everything in between :)

I'd much rather see this align closely to JSX syntax than string literals

This feels like the root reason against this proposal, and I'd agree keeping closely aligned to JSX makes it easier for people who are accustomed to that syntax. I don't think that we have to be limited to the JSX syntax though.

For someone learning Yew for the first time, it would be confusing to write some expressions in curly braces and others without them. The extra two characters it takes to use the current syntax are a small price to pay for having clear and consistent syntax imo.

We do treat literals different with prop assignment 🙃
Also it might be worth noting that even with this implemented the brackets syntax could still be available to use so doesn't have to be one or the other :)
Less of a decision from me but more adding some thoughts and kicking the hive a bit 😅.

"string"
 is poor ergonomics. There are many comments sharing this sentiment. We should kick this option to the kerb.
The bare string approach,
string
, has merit. It is classic HTML after all.
On imitating JSX:
I have seen lots of comments in different threads about trying to be like JSX. Yet a lot of feature requests are not JSX-like (including
"string"
 or allowing for in the template.
It's worth mentioning the different audiences for React and yew. Lots of people who don't know JS at all reach for React when trying to build their first frontend. They choose to learn JS alongside React. Nearly all of those who reach for Yew already know Rust. Rust's steeper learning curve is well-known.
We can write something in the docs to help those coming from JS frameworks such as Angular, Vue, or React.
With respect to the template, I'm in strong favour of keeping Rust inside of braces the way React does with JS. It is the JSX way to leverage the power of JS. I wrote about why I am against for in html! to keep Yew more JSX-like. Simple strings are so commonly used that I think we can also make like JSX and adopt the bare string approach. If you want to put a string in the template, you usually don't care about its ownership. If you do, we can still use curly braces to do more Rust-y things.

Counting votes based on previous comments (I could have interpreted incorrectly sorry):
for
"string"

:+1: @siku2 @allan2
:-1: @tracker1 @Xavientois @allan2 @voidpumpkin
= -2
for
{"string"}

:+1: @allan2 @Xavientois @voidpumpkin
:-1:
= +3
for
string

:+1: @allan2
:-1: @siku2 @lukechu10 @Xavientois @mc1098 @voidpumpkin
= -4
Summary:

"string"
 and
string
 will not be implemented due to general agreement that adding {} does not hurt and no " might be hard to implement.
Thus I am closing this issue, feel free to reopen if majority of views change :)


sd_twizy_interface_node.cpp - Twist angular

twist_angular = 57.296 * twist_angular;
Why do you multiply 57.296? Where is this number coming from?

We multiply with 57.296 to convert Radians/Sec to Degrees/Sec
We do this to later on calculate the low lever steer command for the SD Twizy.


[Bug] 跃迁记录获取不全

Checklist

[X] My issue was not mentioned by others, and it is not a duplicate issue.

Description
使用Starward每个池子只能获取最近310抽(即16页)的记录,其他程序无该问题(URL从Starward 跃迁记录 设置 中复制),经过多次更新仍然重置该问题

Reproduction Steps
打开崩坏星穹铁道角色互动跃迁后点击Starward 跃迁记录中的更新记录
Expected Behavior
No response
Screenshots
No response
Starward Version
0.11-0.11.2
Windows Version
Windows10 专业工作站版22H2 ;Windows Feature Experience Pack 1000.19054.1000.0
Log
[21:58:46.945] [INFO]
Welcome to Starward v0.11.2
System: Microsoft Windows NT 10.0.19045.0
Command Line: H:\Starward\app-0.11.2\Starward.dll

[21:58:47.845] [INFO] Starward.Services.DatabaseService
Database path is 'H:\Starward'

[21:58:49.484] [INFO] Starward.Services.DatabaseService
Database version is 8, target version is 8.

[21:58:49.957] [INFO] Starward.Pages.MainPage
Last game region is hkrpg_cn

[21:58:50.384] [INFO] Starward.Pages.MainPage
Navigate to "LauncherPage" with param hkrpg_cn

[21:58:51.721] [INFO] Starward.Pages.LauncherPage
Game install path of hkrpg_cn: "H:\Starward\Games\Star Rail"

[21:58:51.748] [INFO] Starward.Pages.LauncherPage
Acutal version and gamebiz of hkrpg_cn is "2.0.0", hkrpg_cn.

[21:58:53.360] [INFO] Starward.Services.UpdateService
Start to check update (Preview: True, Arch: X64)

[21:58:53.768] [INFO] Starward.Services.UpdateService
Current version: "0.11.2", latest version: "0.11.2", ignore version: null

[21:58:54.028] [INFO] Starward.Services.GameService
Start game (hkrpg_cn)
path: "H:\Starward\Games\Star Rail\StarRail.exe"
arg: null

[21:58:54.072] [INFO] Starward.Pages.LauncherPage
Game started ("StarRail", 5652)

[21:58:56.089] [INFO] Starward.Services.PlayTimeService
Start to log playtime (hkrpg_cn, 5652)

[21:59:11.108] [INFO] Starward.Pages.LauncherPage
Game process exited

[21:59:26.020] [INFO] Starward.Services.GameService
Start game (hkrpg_cn)
path: "H:\Starward\Games\Star Rail\StarRail.exe"
arg: null

[21:59:26.041] [INFO] Starward.Pages.LauncherPage
Game started ("StarRail", 33096)

[21:59:28.057] [INFO] Starward.Services.PlayTimeService
Start to log playtime (hkrpg_cn, 33096)

[22:06:00.062] [INFO] Starward.Pages.LauncherPage
Game process exited

[22:06:05.325] [INFO] Starward.Services.GameService
Start game (hkrpg_cn)
path: "H:\Starward\Games\Star Rail\StarRail.exe"
arg: null

[22:06:05.352] [INFO] Starward.Pages.LauncherPage
Game started ("StarRail", 11992)

[22:06:07.354] [INFO] Starward.Services.PlayTimeService
Start to log playtime (hkrpg_cn, 11992)

[22:48:36.844] [INFO] Starward.Pages.MainPage
Navigate to "SelfQueryPage" with param hkrpg_cn

[22:48:40.078] [INFO] Starward.Pages.MainPage
Navigate to "HoyolabToolboxPage" with param hkrpg_cn

[22:48:40.085] [INFO] Starward.Services.GameRecordService
Change region to China.

[22:48:44.255] [EROR] Starward.Pages.HoyolabToolbox.SimulatedUniversePage
Get simulated universe data ("hkrpg_cn", 129432772).
Starward.Core.miHoYoApiException: Please login (10001)
   at Starward.Core.GameRecord.GameRecordClient.CommonSendAsync[T](HttpRequestMessage request, CancellationToken cancellationToken) in D:\a\Starward\Starward\src\Starward.Core\GameRecord\GameRecordClient.cs:line 163
   at Starward.Core.GameRecord.HyperionClient.GetSimulatedUniverseInfoAsync(GameRecordRole role, Boolean detail, CancellationToken cancellationToken) in D:\a\Starward\Starward\src\Starward.Core\GameRecord\HyperionClient.cs:line 335
   at Starward.Services.GameRecordService.GetSimulatedUniverseInfoAsync(GameRecordRole role, Boolean detail) in D:\a\Starward\Starward\src\Starward\Services\GameRecordService.cs:line 356
   at Starward.Pages.HoyolabToolbox.SimulatedUniversePage.GetSimulatedUniverseInfoBasicAsync(Boolean detail) in D:\a\Starward\Starward\src\Starward\Pages\HoyolabToolbox\SimulatedUniversePage.xaml.cs:line 128

[22:48:46.245] [INFO] Starward.Pages.MainPage
Navigate to "GachaLogPage" with param hkrpg_cn

[22:48:47.869] [WARN] Starward.Pages.GachaLogPage
Request mihoyo api error: "authkey timeout (-101)"

[22:48:57.798] [INFO] Starward.Services.Gacha.StarRailGachaService
Last gacha log id of uid 129432772 is<PHONE_NUMBER>000530272

[22:49:13.232] [INFO] Starward.Services.Gacha.StarRailGachaService
Last gacha log id of uid 129432772 is 0

[23:07:24.111] [INFO] Starward.Services.Gacha.StarRailGachaService
Last gacha log id of uid 129432772 is<PHONE_NUMBER>001889372

[23:07:32.218] [INFO] Starward.Services.Gacha.StarRailGachaService
Last gacha log id of uid 129432772 is 0

Additional Context
No response

星穹铁道只开放半年的抽卡记录查询


writeTextFile: support large files,

see https://github.com/NixOS/nix/issues/473

Hashes for small texts don't change. So it should be safe to merge.

There is a danger here that if a store path hash is split across two files, Nix's hash scanner won't see it anymore, so the path won't be correctly detected as a dependency of the combined output...

In which use case does that matter? They are buildtime dependencies only, right?

I believe this should be better supported by nix as a primop @edolstra ?

Alternatively would this work?
cat <<EOF > "$n"
$text
EOF

@lethalman Have a look at the other discussion, cat > was suggested and fails for the same reason. I know that it should be a primop, but I needed a solution fast. I know its a hack - but it solves by httpd.conf problem - neither does it change existing hashes.

@MarcWeber if you writeTextFile "${foo} ${bar} ${baz}" and the split happens in between a nix store hash, you lose a runtime dependency.

Thanks Eelco! Fixed in https://github.com/NixOS/nix/commit/a70d275f3d25f6e1eb1b6d528ee07ecd7265ada5

Since NixOS/nixpkgs/pull/6411 isn't usable yet, I'm looking at this as a short-term workaround. However, I don't understand how a split in a hash would be a problem. Does the hash scanner parse the resulting file to determine runtime dependency?

@phunehehe yes

But in writeTextFile "${foo} ${bar} ${baz}", foo, bar and baz are all build dependencies, which I assume will be correct regardless of this change. Are they not available at runtime?
And BTW passAsFile is already in nixUnstable, so I was wrong and NixOS/nixpkgs#6411 should be usable actually.

@phunehehe build deps yes, but if the hash is split later then they won't at runtime.

Thanks I think I'm getting it. When is this scanning done? During some later stage of building? Please tell me it's not done at run time...

@phunehehe at build time... take some time to learn the basics, I've also wrote a post about it http://lethalman.blogspot.it/2014/08/nix-pill-9-automatic-runtime.html and there's the nix thesis. Let's not clutter this issue further :)

FYI, Nixpkgs in staging now uses passAsFile and I tested it by creating a 1.5MB text file with it.


Coudn't enable Cloud Access

pf 2.4.3
unifi controller ver. 5.7.23
/usr/sbin/pkg config abi = FreeBSD:11:amd64
"Cloud access is not compatible with this OS architecture."
UBNT Support wright: "You will need to install 64 Bit java on your computer"

Could you run this command on the shell and tell us what the output is?
/usr/sbin/pkg config abi

FreeBSD:11:amd64

Same problem here. Am a noobie. Should I just install 64bit Java?

I'm also having this issue, and running 64-bit pfSense. Anyone know what is going on? Cloud Access was working fine before I reinstalled pfSense (on the same hardware), and now I can't enable it.

Im having the same issue amd64, do you have any update?

Cloud access is not officially supported by Ubiquiti on non supported OS's such as UNIX. Closing this issue for now.

Cloud access is not officially supported by Ubiquiti on non supported OS's such as UNIX. Closing this issue for now.


NaN is an invalid value

Getting the following error.
Warning: NaNis an invalid value for theopacity css style property.
This is what the code looks like
<RouteTransition pathname={location.pathname} {...presets.slideLeft}>
    {children}
</RouteTransition>

Have you seen this before?

hi @zackargyle–i have not seen this before, though i have a hunch that one of the opacity values passed into react-motion's TransitionMotion are not numerical, thus tweening results in NaN. so i can repro, which version of react-motion do you have installed, 0.4.5?

@zackargyle any luck on this issue on your end?

closing this. feel free to reopen later.


Local Install: No rule to make target 'install-flash-attention-v2'

System Info
Release: v1.3.4, main branch
Target: x86_64-unknown-linux-gnu
Cargo version: 1.70.0
Commit sha: 630800eed37b15c4b0c9eb8e6ab47212026720f7
Docker label: N/A
nvidia-smi: Wed Jan  3 18:13:50 2024
NVIDIA-SMI: 535.54.03
Driver Version: 535.54.03
CUDA Version: 12.2
GPU Cards:
0  NVIDIA GeForce RTX 4090 48GB RAM
1  NVIDIA GeForce RTX 4090 48GB RAM
Information

[ ] Docker
[X] The CLI directly

Tasks

[X] An officially supported command
[ ] My own modifications

Reproduction
Followed all steps found within the local install instructions (https://github.com/huggingface/text-generation-inference#local-install) up to make run-falcon-7b-instruct-quantize

Fork & pull from main branch, v1.3.4
Install and test Rust: 1.70.0 (90c541806 2023-05-31)
Install & test Conda: 23.11.0
Install and test libprotoc: 3.21.12
Execute export BUILD_EXTENSIONS=True
Execute make install
Execute make run-falcon-7b-instruct-quantize

Last step yields this warning:
WARN text_generation_launcher: Could not import Flash Attention enabled models: No module named 'vllm'

Execute cd server && make -f Makefile-vllm install-vllm
Re-Execute make run-falcon-7b-instruct-quantize

Last step yields new warning:
WARN text_generation_launcher: Could not import Flash Attention enabled models: Flash Attention is not installed.
Use the official Docker image (ghcr.io/huggingface/text-generation-inference:latest) or install flash attention with cd server && make install install-flash-attention

Execute cd server && make install install-flash-attention
Re-Execute make run-falcon-7b-instruct-quantize

Last step yields new warning before successfully starting server:
WARN text_generation_launcher: Unable to use Flash Attention V2: Flash Attention V2 is not installed.
Use the official Docker image (ghcr.io/huggingface/text-generation-inference:latest) or install flash attention v2 with cd server && make install install-flash-attention-v2

Running make command above yields the following error message:

make: *** No rule to make target 'install-flash-attention-v2'.  Stop.
Expected behavior
Make target should be found and executed. Solution below.
SOLUTION:
After poking around a bit, I found that the following file issuing the warning, server/text_generation_server/utils/flash_attn.py, is missing the proper target suffix:
make install install-flash-attention-v2
should be:
make install install-flash-attention-v2-cuda
I've already updated the string representing the command in my local repo, happy to file a pull request.

Simple solution above is a bit too simple minded: I need to check for both cuda and rocm before generating output w/ proper target name. Updating my code accordingly.


Error trying to build app.c

I get the following errors when trying to build app.c. I am including the app_defs.h and app.h header files. Not sure what's going on. Does anyone have any suggestions?
"_hal_plot_led", referenced from:
  _app_surface_event in app.o

  _app_cable_event in app.o

  _app_init in app.o

"_hal_read_flash", referenced from:
  _app_init in app.o

"_hal_send_midi", referenced from:
  _app_surface_event in app.o

  _app_midi_event in app.o

  _app_aftertouch_event in app.o

  _app_timer_event in app.o

"_hal_write_flash", referenced from:
  _app_surface_event in app.o

"_main", referenced from:
 implicit entry/start for main executable

ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

This ought to be fixed now (you were building the macOS project, right?)


Include Viva Topics Viva/index.yml

Viva Topics should be part of learning & knowledge management which is missed, please include Viva Topics
"Help your workforce learn, grow, and succeed with Viva Learning,Viva Topics."

Hello @PrasadKasireddy how are you?
I don't fully understand your request, can you please explain where you want to include that article?
Thanks

We appreciate any feedback that improves the content in the Microsoft docs but we haven't had any response from you so we are going to close this issue.
Please feel free to re-open this issue if there is a specific area of the docs that we can improve or make better. Thank you.


Add essentials to readme

Add to Readme:

links to what hardware we're using to start.
a link to how to download python code to the board.

Also a link to the webapp template you were thinking of using. I'm interested in helping transfer the data from the micro to the web, so that would be useful.


Equalize on medium and large only

Hi,
Is it possible to equalize on medium and small screens only?
e.g. the foundation equivalent:
data-equalize-on="medium"
Thanks.

it's not possible because it's a css declaration, you wouldn't be able to use it as-is unless you store the current viewport size somewhere


README: add/update links for k8s v1.25,26,27 kvm/vmware/xen templates

This updates the README for the repo and the website's introduction page with links to k8s v1.25-27 with CAPC templates for KVM, VMware and XenServer/XCP-ng.

/lgtm

Codecov Report
All modified lines are covered by tests :white_check_mark:

Comparison is base (93841c7) 25.45% compared to head (0aaaae1) 25.45%.

Additional details and impacted files
@@           Coverage Diff           @@
##             main     #318   +/-   ##
=======================================
  Coverage   25.45%   25.45%
=======================================
  Files          59       59
  Lines        5555     5555
=======================================
  Hits         1414     1414
  Misses       4002     4002
  Partials      139      139

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


(pound) characters not escaped in new editor

- Do you want to request a feature or report a bug?
bug, caused by #254
- What is the current behavior?
If a user types (#) pound character(s) at the beginning of a line in the regular editor, then switches to the markdown editor (and edits anything), the editor will convert the line to a heading.
- If the current behavior is a bug, please provide the steps to reproduce.

In the regular editor, add a line like this: ## this is a test.
Switch to the markdown editor and change any line (doesn't have to be the same line).

- What is the expected behavior?
The pound sign should be escaped, like in the old editor (\## this is a test).
We should probably check all other special MD characters as well.

Great catch - we need to escape any markdown characters entered in the visual editor, we're currently escaping none of them.
Characters to always escape: _, *, [
Characters to escape when at the beginning of a block: #, -
Characters to escape when more than one present: ~


WIP: test metadeps sys branch

Not meant to be merged, I just want to have the CI running.

@sdroege @GuillaumeGomez : this was a build test using my metadeps sys branch.
To my surprise all tests passed so I'm wondering what's the actual use case for all the current build.rs hacks: GTK_INCLUDE_DIR, GTK_LIB_DIR, windows specific paths, etc?

Maybe they're not even required anymore and are just cargo culted for future generations. @EPashkin would know.
But as I said on IRC, we should really get rid of those hacks and instead set up the Windows CI environment correctly. Which might've happened by now (maybe msys2 fixed their packages...).

I tested on Windows with last msys2x64 and seems hardcode_shared_libs branches in good pkgconfig case now not needed (I not remember why it was added).
But IMHO we still better have GTK_LIB_DIR and fallback.
Not sure about GTK_INCLUDE_DIR

But IMHO we still better have GTK_LIB_DIR and fallback.
Not sure about GTK_INCLUDE_DIR

The fallback is provided by metadeps in this branch, which allows to override things in a generic way for each dependency so that people can continue to work around their broken environments.

The fallback is provided by metadeps in this branch, which allows to override things in a generic way for each dependency so that people can continue to work around their broken environments.

I don't see fallback not in sys branch not in https://github.com/gdesmott/metadeps/blob/master/src/lib.rs

It's all in my wip branch for now.

I missed that it have branch, but IMHO it still don't have "similar" failure case  https://github.com/gdesmott/metadeps/blob/wip/src/lib.rs#L310

What do you mean? This feature is meant for crates building internally the underlying C library to statically link to it. That's not something we currently support in gtk-rs.

Yes, that why I say that you sys'es needed special fallback for this errors.

How so? metadeps will raise an error if user tries to use this feature as our sys don't implement a build closure.

How so? metadeps will raise an error if user tries to use this feature as our sys don't implement a build closure.

And pkgconfig error is lost and we can't find it by metadeps error.

But that only happens if user explicitly defined METADEPS_GTK_BUILD_INTERNAL=auto or always. The default value is never so metadeps will fail on pkg-config and report its error.

Sorry, I seems totally go to wrong direction.
So we just need don't forget to add it in your sys'es.

So we just need don't forget to add it in your sys'es.

Add what?

https://github.com/gtk-rs/sys/blob/master/gtk-sys/build.rs#L100-L106

That's something for metadeps to take care of. The goal here is to move away from all these custom hacks that work differently for every crate.
Also the above part you linked shouldn't be done unconditionally as that regularly causes problems for users, especially on Windows. It needs to be something to opt-in for the user, which is already possible with metadeps by setting the correct libraries for the corresponding crate.

This was merged


BUG: Mathing Pairs rule is not recognizing "heard" correctly

The Matching Pairs rule should mark a tile that is heard before and when it is clicked again as a second tile in a Turn, the small feedback at the bottom corner should say "misremembered" if it is not a match, but now it is saying "no match", also for tiles that has been heard before and made a match, the feedback should be "good job" but now it is a "lucky match". It seems like the times "heard" is not recorded or counted correctly, which means that the score we recorded are also wrong.
This bug has happened before, so hopefully there is a quick fix for this? We need to fix this problem asap.

Note: we need the files & csv of the playlist used for the Congo MatchingPairs experiments.

Hi Evert, is what I sketched the current setup? This hasn't included the number of times a card is seen though. So could you tell me if there is a file or issue documenting the MP rule, so I can also see how it is set up and if we understand it the same way? Thanks!


feat(UPDATE/DELETE): Enable path expressions for improved data manipulation

this change enables the usage of path expressions in where clauses of UPDATE and DELETE queries.
If there is a path expressions found in a where of an UPDATE or DELETE, the where clause is cut out of the query and is put into a where clause  in a dummy subselect. This subquery, selectes all primary keys. It is then transformed by cqn4sql. The result of the transformation is then put into the main queries where again, as <list of primary key> in <subquery>.

fixes #159

please let me merge my PRs, I had some more cosmetic changes to do :(

please let me merge my PRs, I had some more cosmetic changes to do :(

sry, I thought that's ready to merge.
Usually, I use the draft PRs until they are ready to merge. Maybe we can do that as a general rule?


*: bump prometheus and fix fallout

[ ] I added CHANGELOG entry for this change.
[ ] Change is not relevant to the end user.

Changes

bump prometheus to latest main
fix much fallout

Verification

rely on previous tests

Attribution

most of the work was done by @yeya24

Overall, this looks great! I retried the CI failure and we can merge if succeeds

=== NAME  TestStoreGateway
    store_gateway_test.go:117: store_gateway_test.go:117: ""

         unexpected error: block creation: add sample: 20 observations found in buckets, but the Count field is 9: histogram's observation count should be at least the number of observations found in the buckets

=== NAME  TestStoreGateway
    store_gateway_test.go:117: store_gateway_test.go:117: ""

         unexpected error: block creation: add sample: 20 observations found in buckets, but the Count field is 9: histogram's observation count should be at least the number of observations found in the buckets

So the reason is that we try to write a malformed histogram and tsdb appends now have validation for that.

This seems reproducible every time.
=== NAME  TestStoreGatewayLazyExpandedPostingsEnabled
    store_gateway_test.go:1215: store_gateway_test.go:1215: ""

         unexpected error: unable to find metrics [thanos_bucket_store_lazy_expanded_postings_total] with expected values after 50 retries. Last error: <nil>. Last values: [0]

Nice work! Merging now


Package request: severed-chains

Project description

A project to reverse engineer Legend of Dragoon into a high-level language with a modding API. This is not an emulator, but assembly code disassembled and rewritten in Java.
Metadata

homepage URL: https://legendofdragoon.org/projects/severed-chains/
source URL: https://github.com/Legend-of-Dragoon-Modding/Severed-Chains
license: gpl
platforms: linux, darwin

Add a :+1: reaction to issues you find important.

Java? Gradle? I will love the torture!


Fix table UI tag bug

Wait for the following PRs to be merged

#134

Codecov Report

Merging #141 (bb3640e) into master (2269121) will increase coverage by 0.12%.
The diff coverage is 59.74%.

@@             Coverage Diff              @@
##             master     #141      +/-   ##
============================================
+ Coverage     73.78%   73.91%   +0.12%
+ Complexity      658      631      -27
============================================
  Files            95       95
  Lines          1812     1771      -41
  Branches        194      190       -4
============================================
- Hits           1337     1309      -28
+ Misses          406      397       -9
+ Partials         69       65       -4

Impacted Files
Coverage Δ

...4hdb/logic/commands/modelcommands/EditCommand.java
94.59% <ø> (ø)

...ain/java/seedu/rc4hdb/logic/parser/ParserUtil.java
98.03% <ø> (ø)

.../logic/parser/commandparsers/AddCommandParser.java
100.00% <ø> (ø)

...logic/parser/commandparsers/EditCommandParser.java
93.93% <ø> (ø)

...gic/parser/commandparsers/FilterCommandParser.java
91.89% <ø> (ø)

...ain/java/seedu/rc4hdb/model/resident/Resident.java
98.24% <ø> (ø)

...eedu/rc4hdb/model/resident/ResidentDescriptor.java
100.00% <ø> (ø)

...n/java/seedu/rc4hdb/model/util/SampleDataUtil.java
27.27% <ø> (ø)

...c/main/java/seedu/rc4hdb/ui/ResidentTableView.java
0.00% <0.00%> (ø)

...n/java/seedu/rc4hdb/model/resident/fields/Tag.java
71.42% <66.66%> (ø)

... and 26 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.


customise mask shape.

would be amazing if the mask shape was customisable with a callback, perhaps something that lets use return an SVG shape or a valid CSS path rule?
then we can have mask shapes that are circles, stars, arrow etc.

We have no plans to allow that. But feel free to submit a PR.


Pool cards overflow: reduce sig figs

Problem
Cards will begin to overflow when fees and liquidity reach 9-10 significant figures.
Solution
Begin abbreviating in millions to avoid overflow on cards (e.g. $170,680,543 -> $170.6M)
ex)  large fee edgecase

Should we do the same for the tables?

Looks good✨

Closing this issue!

I think tables are fine for now. Unless they start overflowing as well, it's nice as a more detailed view. Cards are like quick call-outs that a user can dig into for more info!


Improve cmd/podman/shared/container.go documentation

Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)
/kind feature
Documentation inside cmd/podman/shared/container.go can be improved:

All periods should end with ..
Some syntax error can be fixed, e.g.: // PBatch is performs batch operations on a container in parallel
Documentation should follow Go reccomendations, .e.g. when documenting an element, the comment should being begins with the name of the element it describes.

@marcov Have you seen any improvements on this?  @TomSweeneyRedHat What do you think?

I think I just assigned it to myself so I won't forget it.  @marcov I'd be happy to hear what you think none the less.

@TomSweeneyRedHat thank you for taking care. I intentionally left the assignee open :wink:

I think the PR from @EmilienM cleaned this up.  I see two additional issues; one spelling error and one missing period at the end of a comment.  When i  look at this file all exported functions are documented which is the golang standard.  Unless we want to hold this issue open for the two nits, I consider this complete and ready for close.

Given the current state, I'm ok to close this


what's the appropriate version of the module ''gin''?

I wonder what version of the ''gin'' module will run the code correctly. I tried ''gin-config'' versions 0.5.0 and 0.1.4, but different errors occurred.

I changed the version of gin-config a few more times, restored it to 0.5.0, and the code worked fine again, although I didn't make any changes to the code. I will close this issue.


Didn't support permessage-deflate extension in WebSocket

Consider implements the permessage-deflate extension for WebSocket?

Dupe of #1733


Use editor.getGrammar().scopeName instead of editor.getGrammar().name

It seems unfortunate to use .name, as that is only the top-level name.
For instance, I recently discovered emmet expansion was broken in a source.css.postcss scope.
If emmet used the scopeName, which would be source.css.postcss instead of just name, which is just, postcss it wouldn't have to make exceptions for each sub-scope.
https://github.com/emmetio/emmet-atom/blob/master/lib/editor-proxy.coffee#L203-L204

---
Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/29178299-use-editor-getgrammar-scopename-instead-of-editor-getgrammar-name?utm_campaign=plugin&utm_content=tracker%2F535900&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F535900&utm_medium=issues&utm_source=github).

Another example of this:

You're in a Markdown file
Within that, you are in a code block, with html formatting, which changes the scope to:

source.gfm
markup.code.html.gfm
source.html.basic
3. At this point anything scoped to `source.html.basic` should work, but Emmet expansions don't work because it is only targeting the grammar "name", not the scope.

This seems related: https://github.com/emmetio/emmet-atom/pull/43

Within that, you are in a code block, with html formatting, which changes the scope to:  source.gfm markup.code.html.gfm source.html.basic

editor.getGrammar().scopeName won’t help here because editor.getGrammar() returns root grammar, not context one (which should be retrieved with editor.scopeDescriptorForBufferPosition().getScopesArray()

Thanks, @sergeche

This would fix #325 for vue files.


Long posts broken into short for twitter bug

Hi! Just wanted to let y'all know that the "Split long toots on Twitter?" option ended up taking this from Mastodon and turning it into this truncated section without previous attached.
Also, may I suggest that such broken-up tweets be actually threaded as replies to yourself on Twitter?
Thanks for this!

Hi, thanks for filing an issue. I think what might have happened is that the first piece failed to post to twitter and so only the second one came through. Normally the pieces are posted in order and they're threaded as replies. I'm sorry this happened!
I'll take a look at the logs and make sure moa can be more robust in this regard.

Thank you so much! This is really awesome and I'm so glad it's there to make Mastodon even more awesome for those of us who can't totally leave other social media dimensions. Appreciate your hard work!

I found the toot and the 1st part was posted to twitter at 276 characters and here's what twitter replied with [{'code': 186, 'message': 'Tweet needs to be a bit shorter.'}] 😑
So I guess I have to assume the pieces need to be smaller…

So, Twitter just increased their limit to 280. Do you think there's something in there that can be worked with?

I had already been assuming 280 characters was ok so the fact that they rejected one that was 276 is weird to me.

AGH. Gremlins!
Okay, well good luck on this one. ^^;

I'm going to reduce the max size to 275 and I'll add a notification for that error so I can track it.

Awesome. You are the best!

@foozmeat Just noticed the max size of 275; are there any plans to bump this back up to 280? i thought it was a bug when a mastodon post with 278 characters got split on twitter, but then i found this issue

@davidcelis I've run into problems when that limit is at 280. Twitter rejects tweets sometimes and I don't understand why. I'll take another look at it though.


chore(main): release 0.0.19

:robot: I have created a release beep boop
0.0.19 (2024-11-29)
Features

command to list all users (4963096)

Bug Fixes

smtp enable naming consolidated (39522b7)

This PR was generated with Release Please. See documentation.

:robot: Release is at https://github.com/eisenwinter/gotrxx/releases/tag/0.0.19 :sunflower:


x/website: error accessing "Writing Web Applications" section in docs

What version of Go are you using (go version)?

$ go version
go version go1.16.7 windows/amd64

Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (go env)?
go env Output
$ go env

What did you do?

I just visited https://golang.org/doc/articles/wiki/
What did you expect to see?
I expected to see the page describing how to create a simple wiki using Go.
What did you see instead?
I saw this error
template execution: template: doc/articles/wiki/index.html:77:2: executing "doc/articles/wiki/index.html" at <code "doc/articles/wiki/part1.go" `/^type Page/` `/}/`>: error calling code: open _content/doc/articles/wiki/doc/articles/wiki/part1.go: no such file or directory

CC @dmitshur who's listed as the owner of a bunch of other x/website packages.

This is likely introduced by recent x/website changes. @rsc Can you take a look?


ToneGenerator causes Android crash

It appears that the debug sounds are causing at least my app to crash on startup.
Your Environment

Plugin version: latest
Platform: Android
OS version: 7.1.1
Device manufacturer and model: Nexus 5 emulator
React Native version: 0.45.1
Plugin configuration options:

desiredAccuracy: 100,
stationaryRadius: 100,
debug: false,
distanceFilter: 100,
stopOnTerminate: false,
startOnBoot: true,
interval: 60 * 1000,
locationProvider: BackgroundGeolocation.provider.ANDROID_DISTANCE_FILTER_PROVIDER

Context
Note that debug is set to false, but the debug tones still are getting triggered.
Possible Fix
I've found this StackOverflow thread:
https://stackoverflow.com/questions/13439051/tonegenerator-crash-android/13868360#13868360
Steps to Reproduce
I run this in my componentDidMount on startup (right now, just to test the usage of BackgroundGeolocation):
BackgroundGeolocation.configure({
      desiredAccuracy: 100,
      stationaryRadius: 100,
      debug: false,
      distanceFilter: 100,
      stopOnTerminate: false,
      startOnBoot: true,
      interval: 60 * 1000,
      locationProvider: BackgroundGeolocation.provider.ANDROID_DISTANCE_FILTER_PROVIDER
});
BackgroundGeolocation.start();

Debug logs

Process: com.moodleiosandroid, PID: 9223
java.lang.RuntimeException: Unable to start service com.marianhello.bgloc.LocationService@4939359 with Intent { flg=0x4 cmp=com.moodleiosandroid/com.marianhello.bgloc.LocationService (has extras) }: java.lang.RuntimeException: Init failed
at android.app.ActivityThread.handleServiceArgs(ActivityThread.java:3343)
at android.app.ActivityThread.-wrap21(ActivityThread.java)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1582)
at android.os.Handler.dispatchMessage(Handler.java:102)
at android.os.Looper.loop(Looper.java:154)
at android.app.ActivityThread.main(ActivityThread.java:6119)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:886)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:776)
Caused by: java.lang.RuntimeException: Init failed
at android.media.ToneGenerator.native_setup(Native Method)
at android.media.ToneGenerator.(ToneGenerator.java:746)
at com.marianhello.bgloc.AbstractLocationProvider.onCreate(AbstractLocationProvider.java:52)
at com.tenforwardconsulting.bgloc.DistanceFilterLocationProvider.onCreate(DistanceFilterLocationProvider.java:86)
at com.marianhello.bgloc.LocationProviderFactory.getInstance(LocationProviderFactory.java:43)
at com.marianhello.bgloc.LocationService.onStartCommand(LocationService.java:237)
at android.app.ActivityThread.handleServiceArgs(ActivityThread.java:3326)
at android.app.ActivityThread.-wrap21(ActivityThread.java)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1582)
at android.os.Handler.dispatchMessage(Handler.java:102)
at android.os.Looper.loop(Looper.java:154)
at android.app.ActivityThread.main(ActivityThread.java:6119)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:886)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:776)

Looks like this might affect Android versions 7 and above. After switching to Android 6 with the same configuration, I don't encounter this issue anymore.

Notice: this issue has been closed because it has been inactive for 141 days. You may reopen this issue if it has been closed in error.

We just experienced this issue on a Huawei P10 Lite after about 53 minutes of app uptime and continuous location update processing. Attached is a raw crashlog.
report-2518520634360549999-1c2588e3-da3f-4de6-8a3e-23c867bae29b.txt

I've created a proposal to avoid this in release builds as a PR: https://github.com/mauron85/background-geolocation-android/pull/28

Instrumentation test failure is because circleci is not set to pass credentials with forked builds.
Pass secrets to builds from forked pull requests: OFF

I'm having the crash happen on Android 11 (using an AppInventor extension based on ToneGenerator).


admin ghost features / requests

Creating this as a feature thread for admin ghost (aghost).
features / issues

[ ] Be able to teleport to ahelp locations as aghost by clicking on the name of the requester.

[ ] Be able to interact with the map such as doors and containers as aghost (Like AI can).

Second request is done

Second request is done

Is it merged or does it require more permissions?

Trial admins can only open access-less doors.


Add CONTRIBUTING.md

Objective
Inform contributors that we use conventional commits.

We could take inspiration from

https://mozillascience.github.io/working-open-workshop/contributing/
https://github.com/semaphore-protocol/semaphore/blob/main/CONTRIBUTING.md
https://mozillascience.github.io/working-open-workshop/contributing/


KAFKA-6753: Update controller metrics periodically instead of after processing every event

Update controller metrics periodically, e.g. once per second, instead of after processing every event
Committer Checklist (excluded from commit message)

[ ] Verify design and implementation
[ ] Verify test coverage and CI build status
[ ] Verify documentation (including upgrade notes)

One more thing: one of the metrics is the event we are currently processing. It seems a bit odd to only update that once a second. Have we done an analysis on the existing metrics to check if this makes sense for all of them?

@ijuma I discussed with @becketqin about this PR, and we agree that an alternative, and also probably better, way of solving the problem is to update the metrics only when necessary instead of letting the controller blindly update the metrics. So I'll close this PR and create another one using that approach.


Is the data encrypted always when in-transit for azure sql database?

We have a web server connected with the azure sql database, and the transactions are going in and out, our azure sql database is encrypted at rest, but what about in-transit data? is that always encrypted inside the pipeline?
How does that works?

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

ID: 16c7901b-497c-38bd-3615-defab17b572b
Version Independent ID: 9855d796-3469-8be5-c9a7-75516d9b8856
Content: Azure encryption overview
Content Source: articles/security/security-azure-encryption-overview.md
Service: security
GitHub Login: @barclayn
Microsoft Alias: barclayn

@Anmolgan81 I noticed that you closed the issue. I am assuming you got the info you are looking for. If you have any questions feel free to tag me and I will continue the conversation.


Frequency Issues

There seems to be an issue if the frequency is not set to 1 second, then it fails to check and we keep getting -1 instead of proper information.

Fixed the check, the timestamp that was looked at was the connectionstats rather than storagestats, so it was not being reached since UGR puts connectionstats often. Also the new -f/--force flag will cause this to happen regardless of timestamps.


Add docs examples to all exports

Done with several recent commits. Will raise something with docs-ts at some point so we could enforce this.


NavBar Changes on all pages

Related Issue

Issue No. #80

Changes you made :

NavBar has the same content on all pages. Also on the smaller devices, the navbar position is same now.

Describe the changes :

Earlier the navbar was not having all the links and on smaller devices it was not at a correct place.
Check list :

[x] I have followed code style of this project.
[x] I have read the CONTRIBUTING document.
[x] All the aspects mentioned in the issue are covered.
[x] The website is properly working after my changes.
[x] 🌟 ed the repo

Type of change :

[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)

Output Screenshots :

Good to go @Swastik1710
LGTM 💯


Consider renaming ClusterSystem.cluster

ActorSystem is renamed to ClusterSystem in https://github.com/apple/swift-distributed-actors/issues/879. As such, users may declare it as cluster instead of system:
let cluster = ClusterSystem()

which results in the cluster: ClusterControl member of ClusterSystem being accessed as cluster.cluster.

Looking at this again I think we're fine since typically it would be stored as let system = ClusterSystem() I think.
Let's close and keep as is, WDYT?


First off, thanks for making this.  In your example, you "require" eventbrite, but the module name is node-eventbrite....caused me to scratch my head for a moment

Fixed - thanks!


Fix unbonding purses serialization

This PR makes the Storage component aware that the UnbondingPurses struct has two different flavors:

Legacy one, i.e. without the new_validator field
Extended one, i.e. with the new_validator field

When retrieving the UnbondingPurses from DB, the Storage will always return the extended UnbondingPurses providing the conversion from the legacy struct on the fly, setting the new_validator field to None.
Closes #2964

bors r+


stats.truncnorm fails when providing values outside truncation range.

This follows from a posted question on stackoverflow by tcquinn
When truncnorm is provided a quantiles vector where some are inside the truncation range and some outside the truncation range, an error is thrown.
Reproducing code example:
This code throws an error
truncnorm.logpdf(
    np.array([3.0, 2.0, 1.0]),
    a=(1.5-np.array([6.0, 5.0, 4.0]))/3.0,
    b=np.inf,
    loc=np.array([6.0, 5.0, 4.0]),
    scale=3.0
)

Error message:
  File "try2.py", line 18, in <module>
    scale=3.0))
  File "anaconda3/lib/python3.6/site-packages/scipy/stats/_distn_infrastructure.py", line 1663, in pdf
    place(output, cond, self._pdf(*goodargs) / scale)
  File "anaconda3/lib/python3.6/site-packages/scipy/stats/_continuous_distns.py", line 4851, in _pdf
    return _norm_pdf(x) / self._delta
ValueError: operands could not be broadcast together with shapes (2,) (3,)

Scipy/Numpy/Python version information:
0.19.1 1.13.1 sys.version_info(major=3, minor=6, micro=1, releaselevel='final', serial=0)

Possible Reason
I have found that this error is coming from the division of the computed truncated pdf by the normalization factor _norm_pdf(x) / self._delta (_continuous_distns.truncnorm_gen._pdf()). In this case, the function check for any of the quantiles x outside the truncation range, and removes them. However, self._delta is still the original size.

Hey there!
I am newbie here and would like to work on this one.Can it be handled by a first-timer?

In general, there is no generic support for broadcasting with the support bounds of a distribution. If a parameter changes the support of the distribution, then it will most likely raise an exception in vectorized usage.
AFAIR, there are a few special cases where it works, but that is distribution and methods specific.

Should be addressed by #9900, which is now merged


fix: secret informer load

What does this PR do?
This PR starts the informer on secret before the cache synched.
Motivation
Fixes #1784,#3667
Avoid log on startup
level=error msg="Error while reading basic auth middleware: failed to load auth credentials: secret 'traefik/traefik' not found" middlewareName=traefik-auth providerName=kubernetescrd
level=error msg="middleware \"traefik-auth@kubernetescrd\" does not exist" routerName=traefik-traefik-86717a050e7497cf6af6@kubernetescrd entryPointName=traefik
level=error msg="middleware \"traefik-auth@kubernetescrd\" does not exist" entryPointName=web routerName=traefik-traefik-86717a050e7497cf6af6@kubernetescrd
level=error msg="Error while reading basic auth middleware: failed to load auth credentials: secret 'traefik/traefik' not found" providerName=kubernetescrd middlewareName=traefik-auth

More

[x] Added/updated tests
[x] Added/updated documentation

I think this looks good, but it will have the following consequence:  If users don't have RBAC access to secrets, the informer will hang, and then all the listers will fail (for all objects).
I don't think this PR fixes #1784, I think its the opposite. 1784 wants Traefik to load all the ingresses/ingressroutes/etc and then determine if it should start a secrets watcher. That way secrets aren't accessed if they aren't used.

I don't know why #6364 was close, issue still exist, with traefik v2.2.6


iOS 9 compatability/readiness?

Are there any known issues with iOS 9?

There was a crash bug, but I believe it got fixed in the latest release. That's all I know.

Thanks for the intel.


How To Get Return number of effected rows and last effected row id

execute method not return the newly created or updated row id.
we often require newly created id or data to show user.
and number of effected rows to display.
todo:: return ( effected_rows:  i64, last_effected_id: i64) from both execute methods

FWIW, the official sql plugin does support it, but it has other problems.


Support calling gufunc without output buffers

gufuncs have a restriction where the pattern out = gufunc(arg1, arg2, ..., argN) is not supported:
from numba import guvectorize
import numpy as np

@guvectorize('(n),(n) -> (n)')
def add(a, b, res):
    for i in range(a.shape[0]):
        res[i] = a[i] + b[i]

a = np.arange(5)
b = np.ones_like(5)
add(a, b)

# Traceback (most recent call last):
#   File "/Users/guilhermeleobas/git/numba/b.py", line 11, in <module>
#     add(a, b)
#   File "/Users/guilhermeleobas/git/numba/numba/np/ufunc/gufunc.py", line 186, in __call__
#     raise TypeError(msg)
# TypeError: Too few arguments for function 'add'. Note that the pattern `out = gufunc(Arg1, Arg2, ..., ArgN)` is not allowed. Use `gufunc(Arg1, Arg2, ..., ArgN, out) instead.

I do not know how hard this one is, as one needs to guess the dtype of res to compile the correct kernel.

FYI note this is only the case for dynamic gufuncs — with a signature no output is required:
@guvectorize([(numba.int64[:], numba.int64[:], numba.int64[:])],'(n),(n) -> (n)')
def add(a, b, res):
    for i in range(a.shape[0]):
        res[i] = a[i] + b[i]

a = np.arange(5)
b = np.ones_like(a)
add(a, b)


INA260 Power Sensor not getting configured

Summary
Writing to configuration register of the power sensor and reading from it results in default (a.k.a. reset) value 0x6127. Can write to another register of the power sensor (Alert Limit Register @ 0x07) just fine.
Description
Sensor address: 0x40
Configuration register address: 0x00
Default register value: 0x6127
Added a debug statement to read from config register right after writing to it:

imxrt_ina260initialize: Initializing INA260
ina260_access: start_register_address: 0x00 data_length: 2 register_value: 0x02 (0x0002) ret: 0
ina260_access: Reading back config register:
ina260_access: start_register_address: 0x00 data_length: 2 register_value: 0x61 (0x2761) ret: 0
ina260_register: (addr=0x40) registered at /dev/ina260

From datasheet, p.21:

The Configuration Register can be read from at any time without impacting or affecting the device settings or a
conversion in progress. Writing to the Configuration Register halts any conversion in progress until the write
sequence is completed resulting in a new conversion starting based on the new contents of the Configuration
Register (00h).

The register is available for read/write operations at any time.

On the screenshot in the header message, the format of I2C message is incorrect for writing to registers. It is similar to reading from the register (i.e. change the register pointer, then supply data MSB and LSB, figure 26 on the screenshot from the datasheet).
Instead, when writing to a register, the address needs to be followed by the destination register location and then followed by the data to be written into the register.
From the datasheet, p.19:

In other words, writing should look more like this (addr. 40, reg. 00, data 02 07):


Expose url args encode/decode functions

Middleware should have access to ngx.decode_args and ngx.encode_args as args.encode and args.decode. Maybe args is not the right name.
/cc @picsoung @kikito

args is a bad name for several things. In singular (arg) it's actually a kind-of-implicit name for functions (like self) in Lua (this functionality seems to be deprecated, but I am not 100% sure).
I would go with uri.encode_query and uri.decode_query. But then the user can not use uri as a variable name (well, he/she can, but then it masks the lib)


Move from Heroku to Rancher

[x] Get docker compose running
[ ] Configure travis to push to Docker hub if master
[x] Deploy rancher stack
[x] Get HTTPS cert
[ ] Flip over CNAME
[ ] File a ticket for psql backups
[ ] Update CONTRIBUTING.md

Let me know if I can do any of these tasks.


gltfio: Fix "uniform not found" errors.

The equality operator for MaterialKey was missing some fields (also, its
ordering was inconsistent with the struct), which caused faulty behavior
in the material cache.
I ran into this bug when testing against a Blender-exported model that
has some materials with texture transforms, and some without.

@pixelflinger sorry I merged before reading your suggestion.  Yes, let's just migrate over to memcmp next time we need to touch this code.
I wish that C++ would do this for us, since it's just a POD.  C++20 makes it a little easier to generate comparison operators, but not equality.  Sigh.


Bug (ETH): GET /wallet/transactions/eth fails to return unconfirmed and pending state txs

To replicate, send ETH to a node and monitor when the transaction appears in the list from GET /wallet/transactions/eth => it will only appear after 30-60 seconds and show a status of CONFIRMED.
We also need to check whether the websocket messages for unconfirmed and pending transactions are also appearing for ETH.

I believe this is an issue with Etherscan. Their endpoint takes time to show up.

I don’t believe adding to unconfirmed txs in the list is that valuable IMO because the confirmations come so quickly. In my testing I had a hard time getting to test this because it was so fast.
Etherscan does not return unconfirmed txs in its API call. Ashwin pointed out in a note to Chris how it could be done but it requires an additional call to a different API and some refactoring of our transactions API.
As for websockets I’m not sure yet why it’s ceasing to send for unconfirmed.

I don’t believe adding to unconfirmed txs in the list is that valuable IMO because the confirmations come so quickly. In my testing I had a hard time getting to test this because it was so fast.

It can take 30-60 seconds before a confirmation comes in and it is very disturbing to a user who has sent a transaction not to see it in their history for that period of time. We should at the very least display the transaction details with a state of UNCONFIRMED until the first confirmation comes in.
This is one of the first issues Rod brought up when he was testing ETH.


Fix generation_number_overflow 32-bit tag creation

Overview
In the "Coupling to gitoxide's own repo" section of #1687, I said:

Fortunately, for this 32-bit Debian container on CI, only one case of this had to be addressed, largely because GIX_TEST_IGNORE_ARCHIVES is not being used.

But the situation in containers is actually better than that. Setting GIX_TEST_IGNORE_ARCHIVES=1 on a 32-bit Debian 12 system--both in the container on CI or locally outside the container--only causes one failure. This failure is not related to coupling to gitoxide's repo, and it is a 32-bit specific failure.
This pull request describes and fixes that failure, but I don't know if this fix is optimal. Even if this fix is good, I suspect further changes are warranted.
The current test failure output
The failing test is gix-commitgraph::commitgraph access::generation_numbers_overflow_is_handled_in_chained_graph:
        FAIL [   0.036s] gix-commitgraph::commitgraph access::generation_numbers_overflow_is_handled_in_chained_graph

--- STDOUT:              gix-commitgraph::commitgraph access::generation_numbers_overflow_is_handled_in_chained_graph ---

running 1 test
test access::generation_numbers_overflow_is_handled_in_chained_graph ... FAILED

failures:

failures:
    access::generation_numbers_overflow_is_handled_in_chained_graph

test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 7 filtered out; finished in 0.03s

--- STDERR:              gix-commitgraph::commitgraph access::generation_numbers_overflow_is_handled_in_chained_graph ---
failed to extract 'tests/fixtures/generated-archives/generation_number_overflow.tar': Ignoring archive at 'tests/fixtures/generated-archives/generation_number_overflow.tar' as GIX_TEST_IGNORE_ARCHIVES is set.
thread 'access::generation_numbers_overflow_is_handled_in_chained_graph' panicked at tests/tools/src/lib.rs:567:17:
fixture script of cd "tests/fixtures/generated-do-not-edit/generation_number_overflow/2968487077-unix" && env -u GIT_ALTERNATE_OBJECT_DIRECTORIES -u GIT_ASKPASS -u GIT_COMMON_DIR -u GIT_DIR -u GIT_INDEX_FILE -u GIT_OBJECT_DIRECTORY -u GIT_WORK_TREE -u SSH_ASKPASS GIT_AUTHOR_DATE="2000-01-01 00:00:00 +0000"<EMAIL_ADDRESS>GIT_AUTHOR_NAME="author" GIT_COMMITTER_DATE="2000-01-02 00:00:00 +0000"<EMAIL_ADDRESS>GIT_COMMITTER_NAME="committer" GIT_CONFIG_COUNT="4" GIT_CONFIG_GLOBAL="/dev/null" GIT_CONFIG_KEY_0="commit.gpgsign" GIT_CONFIG_KEY_1="tag.gpgsign" GIT_CONFIG_KEY_2="init.defaultBranch" GIT_CONFIG_KEY_3="protocol.file.allow" GIT_CONFIG_NOSYSTEM="1" GIT_CONFIG_VALUE_0="false" GIT_CONFIG_VALUE_1="false" GIT_CONFIG_VALUE_2="main" GIT_CONFIG_VALUE_3="always" GIT_TERMINAL_PROMPT="false" MSYS=" winsymlinks:nativestrict" "/__w/gitoxide/gitoxide/gix-commitgraph/tests/fixtures/generation_number_overflow.sh" failed: stdout: Initialized empty Git repository in /__w/gitoxide/gitoxide/gix-commitgraph/tests/fixtures/generated-do-not-edit/generation_number_overflow/2968487077-unix/.git/
[main (root-commit) 631f540] future-1
 Author: author<EMAIL_ADDRESS> 1 file changed, 1 insertion(+)
 create mode 100644 future-1.t

stderr: fatal: Timestamp too large for this system:<PHONE_NUMBER>

note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Analysis of the current failure
The test calls graph_and_expected:
https://github.com/GitoxideLabs/gitoxide/blob/438ee4718b67d0eba8f4c6ebdfac64bd39f68ec7/gix-commitgraph/tests/access/mod.rs#L58
graph_and_expected calls graph_and_expected_named, which calls scripted_fixture_read_only to run the generation_number_overflow.sh fixture. It wasn't immediately obvious, from the output shown above, what the failure is. But temporarily adding set +x revealed it:
+ commit future-1 '@4147483646 +0000'
+ local message=future-1
+ local 'date=@4147483646 +0000'
+ local file=future-1.t
+ echo future-1
+ git add -- future-1.t
+ '[' -n '@4147483646 +0000' ']'
+ export 'GIT_COMMITTER_DATE=@4147483646 +0000'
+ GIT_COMMITTER_DATE='@4147483646 +0000'
+ git commit -m future-1
+ git tag future-1
fatal: Timestamp too large for this system:<PHONE_NUMBER>

git commit accepts the timestamp<PHONE_NUMBER> as the committer date. But then, when git tag is run to tag that commit, it rejects the timestamp!
Deeper analysis
The situation becomes even more interesting when we examine how git interprets the timestamp on the commit. Here's a simplified experiment:
$ git init repo
Initialized empty Git repository in /home/ek/src/repo/.git/
$ cd repo
$ touch a
$ git add a
$ GIT_COMMITTER_DATE='@4147483646 +0000' git commit -m 'Initial commit'
[main (root-commit) 99b1de4] Initial commit
    1 file changed, 0 insertions(+), 0 deletions(-)
    create mode 100644 a
$ git log --pretty=fuller
commit 99b1de4e0610ff715e784bd4089dc315e8071332 (HEAD -> main)
Author:     Eliah Kagan<EMAIL_ADDRESS>AuthorDate: Sat Nov 23 01:05:12 2024 -0500
Commit:     Eliah Kagan<EMAIL_ADDRESS>CommitDate: Thu Jan 1 00:00:00 1970 +0000

    Initial commit
$ git tag t
fatal: Timestamp too large for this system:<PHONE_NUMBER>
$ git tag -a t
fatal: Timestamp too large for this system:<PHONE_NUMBER>

The timestamp was accepted, but the reported commit date in git log is:
Thu Jan 1 00:00:00 1970 +0000

This is, as one would imagine, specific to 32-bit systems. (I also do not know for certain that it happens on all 32-bit systems, but my guess is that it happens with all 32-bit builds of Git on at least some prominent 32-bit platforms, including 32-bit x86 where I have observed it.) On 64-bit systems, we get a future date and there are no errors.
Why it passes without GIX_TEST_IGNORE_ARCHIVES: 32-bit git uses the tag if present
A repository with such a tag can be cloned on a 32-bit system. The commit has the overflowed date in 1970. But the tag is present. It is a packed tag, in that scenario. But git on a 32-bit system has the ability to recognize it as a loose tag just as well, which happens if we bring the repository over from another system, as happens with a generated archive.
It also works if we create the tag by manually creating a file in .git/refs/tags. This allows a repository that, as far as I can tell, is equivalent to what we get when we unpack a generated archive, to be created on a 32-bit system where git tag would produce an error. I wonder if there's a Git feature that just lets us tell it to go ahead and create the tag, but I looked for such a feature and did not find it. I also wonder (as detailed below) if this general approach--of trying to create the tag on 32-bit systems at all--is good...
Changes in this pull request
...but that's what I've done here. This PR:

Sets GIX_TEST_IGNORE_ARCHIVES=1 in the test-32bit CI job. Ideally we would test both with and without it, either in separate jobs or with a partial clean, covering just generated archives, in between. I'm not sure the added work on CI of running the tests another time on the same 32-bit platform is justified, though. For now it only runs with that set. But I've verified locally that, after all changes here, all tests pass both with and without GIX_TEST_IGNORE_ARCHIVES on a 32-bit Debian 12 system.
Modifies the fixture script so that, if it cannot create the tag with git tag, then it checks if git is a 32-bit build and, if so, writes a loose tag file explicitly. The logic for checking if Git is 32-bit and attempting the fallback tactic of creating the loose tag file explicitly is in its own function.
Refactors the fixture script so that it is clearer what is going on. The fixture script had a commit function that performs multiple operations including committing and creating a tag. This renames it to tagged_commit and makes a few other changes.
Regenerates the committed archive.

Further analysis / alternatives and future directions
It may be that more substantial changes should be made. Some of the operations in the fixture script had been inspired or derived from one of the tests in the Git test suite:
https://github.com/GitoxideLabs/gitoxide/blob/438ee4718b67d0eba8f4c6ebdfac64bd39f68ec7/gix-commitgraph/tests/fixtures/generation_number_overflow.sh#L32
That test in Git is t5328-commit-graph-64bit-time.sh. The test description is "commit graph with 64-bit timestamps" and it only runs when prerequisites are satisfied related to the availability of 64-bit timestamps.
I don't think this necessarily means that gitoxide's test suite should not run tests on a repository with such timestamps. The test does pass on 32-bit Debian 12 when it uses the repository from the committed archive, as well as when it generates the repository using the modified fixture script introduced in this PR.
The other issue--I'm not sure if it's related--is that it looks like the test that uses this fixture is believed already, and presumably not specifically on 32-bit systems, not to be fully effective. The assertion in the test is:
https://github.com/GitoxideLabs/gitoxide/blob/438ee4718b67d0eba8f4c6ebdfac64bd39f68ec7/gix-commitgraph/tests/access/mod.rs#L64-L68
So maybe there is another change that should be made to the fixture script.

I think this should be related to size_t used for time_t so Git probably isn't capable of holding this number.

Some platforms have time_t as the same size as size_t, but not all. For example, in sufficiently new versions of Debian, all 32-bit architectures other than 32-bit x86 have 64-bit time_t. The armhf architecture is a fairly prominent example of a 32-bit architecture that has 64-bit time_t on recent GNU/Linux systems. This required an ABI change to do, but was still done, due to the continued significance of armhf and the need to solve the Year 2038 problem. (Since 32-bit x86 is often used for binary compatibility with existing executables, it is the exception, at least so far.)

I wonder if it has to be a problem for gitoxide thought, we could just declare the respective types as u64 and be good - for gix-date I am pretty sure that's done as well. This is probably no more than a note.

If gitoxide is using a type like usize or isize anywhere for timestamps--especially if it is not conditional on the target being known to require 32-bit time_t--then I think that should be changed to u64 or i64 if at all possible. 32-bit architectures will tend to have 64-bit time_t as 2038 approaches and passes. (I think it is likely that some 32-bit architectures will continue to be used for significant purposes, including in new devices. However, even if that is not the case, I think this would be a correctness issue when targeting a 32-bit ABI where time_t is 64-bit.)
But I acknowledge that "if at all possible" is an important qualification. Timestamps that are stored in indexes or caches, if git represents them differently on different platforms, will have to be readable and, if created, will have to be created in a way that git on that platform can understand them, at least in data that are not available elsewhere, or in caches that cannot be recreated inexpensively enough.
It occurs to me that the failures on s390x mentioned in #1687 might be relevant to this and might be illuminating. I have not yet investigated them. Their significance there was merely that none of them involved any data structure size assertions--that is, I mentioned s390x there merely as evidence that our asserted 64-bit data structure sizes don't seem to vary across platforms.
But, while not related to anything being done in #1687, on s390x there are a few tests that fail, and the failures do seem related to some data structures having unexpected representations. s390x is 64-bit, but bigendian. The failures even when reusing generated archives are:
gix::gix remote::fetch::blocking_and_async_io::fetch_pack
gix::gix remote::fetch::blocking_and_async_io::fetch_pack_without_local_destination

When ignoring generated archives with GIX_TEST_IGNORE_ARCHIVES=1 to re-run all fixture scripts, those failures occur, as well as three others. One of those three others is probably not relevant to s390x because it usually occurs on other platforms and is due to changes in git 2.47.0; this is due to #1622. But the other two failures are--like the two above--s390x-specific:
gix-pack-tests::pack pack::multi_index::access::general
gix-pack-tests::pack pack::multi_index::verify::integrity

At this time, I haven't opened an issue about this or looked into it in detail. But full test output on s390x, showing those failures, for both runs, can be seen in this gist.

I see, that probably explains why 32bit systems are not able to read 64 bit timestamps: by design. I still wonder if a 32bit built could be made to handle this fixture, but maybe there isn't any problem and it's really just about Git not being able to produce the fixture on 32 bit systems.

Even if git is built with a 32-bit time_t and cannot represent 64-bit timestamps, that still does not explain the curious behavior observed here, all of which is observed even when no git commit-graph command is involved:

The commit is given the timestamp that overflows if interpreted as 32-bit time_t, and git creates that commit on the 32-bit system without objection.
When git log is run on the 32-bit system to view the time, it is shown as having rolled over to the Unix epoch in 1970.
Attempting to create a lightweight tag fails on the grounds that the timestamp of the commit git just created is out of range. (The same thing happens when creating an annotated tag, but this fixture doesn't exercise that.) Creating a tag that refers to a commit does not inherently involve processing a timestamp: the tag holds the object ID of the commit, not other information about the commit. Somehow, more stringent validation happens on the commit's timestamp when a tag referring to the commit is created, than when the commit itself is created.
There is no loss of information in the commit's own timestamp. The timestamp in the repository has not rolled over, even though at this point all operations have been performed with a native build of git on a 32-bit platform where time_t is 32-bit, and even though this git shows the date as having rolled over. The rollover in git log output apparently happens when formatting the timestamp as text, and should possibly be considered a bug in git, depending on the intended semantics of that formatting operation. I can push the repository to a remote, then clone it on a 64-bit system, and it has the originally intended non-rolled-over future timestamp.

It is because of (4) that the change in this PR does not (as far as I know) add any new incorrect behavior. If not for (4), we would not want to allow a non-.gitignored archive to be generated when  the fixture script uses a git command built against a libc implementation with a 32-bit time_t, since such an archive would have the wrong timestamp and other systems would be able to observe the difference in the actor metadata in the archived fixture's commit history.
To elaborate, here's an experiment that verifies this, involving two machines: Zim, a 32-bit x86 system; and catenary, a 64-bit x86 system.  Furthermore, the first commit has the intended 1970 epoch date on both, so the 32-bit system on which the repository is created really is creating the commits with different timestamps, even though that 32-bit system has 32-bit time_t.
(As noted above, some 32-bit systems have 64-bit time_t. But the test system here is known to have 32-bit time_t, both because it is a Debian i386 system, and because and I have verified that sizeof(time_t) is 4 on this system, with a small C test program.)
That the commit timestamp has not really overflowed is, I want to say, no surprise--git objects are meant to be shared across systems of different architectures, after all, and git repositories are intended to be able to hold 64-bit timestamps. But I do find it surprising that the subsequent tag creation operation fails on the 32-bit system.

I think that's a convoluted way of wondering if a 32bit build can read commit-graph caches that are created on 64 bit systems. Probably that's not really an issue even if the answer is negative as one can always recreate these

Since 32-bit git accepts and preserves 64-bit timestamps in some cases, including a case where it writes the timestamp into a Git object (git commit), while rejecting them in other cases, including a case where it does not write the timestamp and where (as far as I know) the timestamp is not part of the semantics of the operation at all (git tag, where the timestamp at issue is the already-present one in the commit object being tagged), it seems to me we cannot conclude from any of what has been seen here what 32-bit git is able to do with commit-graph caches.
Although git commit-graph is involved in the actual fixture script, the simplified experiments--both the one described in the PR description (see also 595929b) and the one shown above the 64-bit timestamp in the commit is shown to be preserved--do not use it.

Thanks a lot for sharing!

At this time, I haven't opened an issue about this or looked into it in detail. But full test output on s390x, showing those failures, for both runs, can be seen in this gist.

This is very interesting. What stuck out to the difference in compressed size, which was 49 but should be 46. I have no idea how that comes to be though, but also didn't look into it.

4. The rollover in git log output apparently happens when formatting the timestamp as text, and should possibly be considered a bug in git, depending on the intended semantics of that formatting operation. I can push the repository to a remote, then clone it on a 64-bit system, and it has the originally intended non-rolled-over future timestamp.

I assume this was done because git cat-file commit <commit> didn't work due to validation as well?

It is because of (4) that the change in this PR does not (as far as I know) add any new incorrect behavior. If not for (4), we would not want to allow a non-.gitignored archive to be generated when the fixture script uses a git command built against a libc implementation with a 32-bit time_t, since such an archive would have the wrong timestamp and other systems would be able to observe the difference in the actor metadata in the archived fixture's commit history.

Indeed!
Thanks again for sharing these details, they are illuminating.

This is very interesting. What stuck out to the difference in compressed size, which was 49 but should be 46. I have no idea how that comes to be though, but also didn't look into it.

Ordinarily, I would guess that this is due to different data structure layouts across architectures, which due to alignment restrictions can result in data structures being of different sizes. The reason I had tested with s390x when researching #1687 was the idea that maybe some 64-bit size assertions with == could fail on s390x. None tested did.
That's a very weak guess. If I figure out more about that, I'll let you know (probably in an issue, unless I also figure out how to fix it).

The rollover in git log output apparently happens when formatting the timestamp as text, and should possibly be considered a bug in git, depending on the intended semantics of that formatting operation. I can push the repository to a remote, then clone it on a 64-bit system, and it has the originally intended non-rolled-over future timestamp.

I don't think tag creation via git tag runs most git fsck checks though, so I don't think the git fsck output, by itself, explains the situation.
The successful invocations of git cat-file commit shown above pass OIDs, but HEAD and HEAD^ produce the same output. Likewise, git tag t, git tag t HEAD, and git tag t 5baa3b82fccabc8f071e877977d3f57ce5eee897 all fail with the same message. So the way these commands are being told what commit to use does not seem important to the problem.


Create s.pasumpon.yml

Hi @pasumps1 sorry for my delay, I believe all of your records have now been fixed, your member record, homepage, your course records for vSphere with Tanzu 101 and ModernApps Skills 101, and your digital badges have been provisioned.
Now that your member record has been corrected, going forward you should not have these problems and your course enrollments, tests and certificate requests should process automatically. Thanks!


Bass.ChannelGetLevelLeft/Right returns negative values if paused

Added a check in TrackBass to prevent amplitudes being updated to crazy values if the track is paused.
Related to: https://github.com/ppy/osu/pull/1243
Possibly also a fix for: https://github.com/ppy/osu/issues/1284

Confirmed, fixes #1284.


Fix add task button both for desktop & mobile

The add task button is not aligned correctly, which makes it look unappealing. Clone the repo and fix the button.

I would like to take up this issue.


updated baselines for new member CI/CD IAM role

Added additional baseline for new member Ci/CD role

will fix with module version


Review WA POU layer

We received this issue through WestDAAT feedback.

This single domestic use is mapped as a giant polygon. Is that correct? https://westdaatstaging.westernstateswater.org/details/right/WAwr_WR61184?state=N4IgtgziBcIQhgFwKYBtUEsUFoBuBOEAGnHgAcZQAvAexrABllc0Z8A6ANgGYAGAVgAsvQQCZO%2BfLxEB2EqiRYArgBNkMQTPYyZnMQA5%2BARhkme-TvJoA7AObK1MbEdGj2RscKOTuM0f1FuAF8goA

Why are municipal service area polygons in the (Seattle/Tacoma/Everett) area not showing up?
Comment by Adel: I'm not sure if the original dataset has them. Let's go over it. Here is a link for the area. We might need to double-check the beneifial use mapping in Washinton. Domestic should be for indicial owners, not cities. Cities should have a Public water supply. Not suggesting anything is wrong, but worth reviewing.
https://westdaatstaging.westernstateswater.org/?state=N4Ig7gTiBcoEYFMB2CBmBLAxughgGwFUBnBImAbXmTS10JIDkcBbBGEAEQHtWiAXLCAA0ITFyREArswAOA8QGEcfBAHMuEAJ4wAjAF8hVFBmz5iCJq3YBZSUloz8AAgCSECOlXL044aPFSsvJISirqWjAATAZGNKb0Fixs0CAACpJweFhOAMqSMjJ42iJiEtJyPiHKahra0PoAuiLM6EgAalx40sk6AAwiMlwAJqlckuypAPIEfoNFWSgUTSBIeEPoAGLoeCoQHMo4MKB43nySQ8lIknh4InjiquhnFzBXNyLrEAiYwWTQAMwfA6jVp8P4Adj0BhAzBwMiOIAAXlweAAZBAANwQeF0vQAdL0dABWAAshIAHOSdAA2SLUqngu6nc7JEngvFEzkkyIATiJkX%2BlPB5KJdweTxZMAAtDpIpE8X0eTydOCib1Of8%2BVCgA

Feedback
First Name:
Andrea
Last Name:
Lauden
Satisfation:
Somewhat satisfied
Comments:
I see some issues with Washington State polygons - ex. Allocation UUID WAwr_WR61184 is a single domestic use mapped as a giant polygon. And I'm not seeing the municipal service area polygons identified as the water right authorizations that I would expect to see in that (Seattle/Tacoma/Everett) area.
Email:
<EMAIL_ADDRESS>Organization:
WA Dept. of Ecology
Data Usage:
- General Interest
- Regulatory

Q: This single domestic use is mapped as a giant polygon. Is that correct?

That WA water right (i.e., WR Doc ID = 2274342) is being mapped to both a single POD (link) and that larger POU (link).  That connection is being made as both sites share the same WR_DOC_ID, used to identify water right ID, as identified from the provide source data found here (link).
Interesting enough, WA’s own water right resources are not accrediting that larger POU to the same WR, only on the single POD (see record link here).  Whether that is an issue with our mapping approach or a fault in the provided source data is not known.

Q: Why are municipal service area polygons in the (Seattle/Tacoma/Everett) area not showing up?

The provide source data found here (link) does not give site name for any POU areas.

@rwjam This is the original issue reporting the problem in WA data

the westdaat stagging link to the WAwr_WR61184 (i.e., the single domestic ue mapped as a giant polygon) is no longer viable and we can no longer follow up on this.
This GitHub issue was created before we made changes to how we create UUIDs, so it's not really possible anymore to track what site they were refering too.
Everett westdaat Link
Seattle Public Utilities  westdaat Link
Seattle City Water Department  westdaat Link
Tacoma  westdaat Link

Thanks for the review and making the fixes. Looks great to me


Creating a post with special characters in the title causes problems

I created a post with a question-mark at the end via ember g post "Why build a Vans RV-14A?". Since the question mark is added to the end of the file name, the app can't resolve the json data. Once I realized what what happening it was easy to just remove the question mark from the filename to get everything working. Seems like maybe the generator should escape or otherwise remove any special characters from the title?

Just a thought here - is the right solution to add in a custom fileMapTokens method into the post blueprint returning an updated __name__ key?
I'm assuming the options. dasherizedModuleName passed into that method is not removing the ?
Which makes we wonder what else we should be looking to remove from the filename?


Task - new collecting event - Soft validation

The soft validation is not upated once the georeference and/or geographic area is added, even after I press Save button.
For some reason, the georeferences show "2", although I have only one georeference. Before I created the georeference, it showed "1" (whene there were non). Is it because the label has verbatim fields? I do not expect as those be treated as a georeference.

I can't replicate it the soft validation issue. Georefrence warning dissapear after save.
After test it, i think you're getting 2 records, because it's counting the geographic area shape like a georeference record. I have to fix this

I tested this in sandbox before. In production the sv disappears after save. Still have 2 records for georeference.
Minor unrelated, would be nice to have an Edit button from Browse collecting event to this task.

I think it's already there

Aha, I did not even look there, I was looking for green button in the same place where we have radial. It would be nice to unify.


The difference between string and hadoopystring

Under the quickstart folder of druid, there is a example file: wikiticker-index.json.  It defines a ingestion task with task type "index_hadoop" and parser type "string".
But in the official doc(http://druid.io/docs/latest/ingestion/) about parser type, you mentioned:

This should say string in general, or hadoopyString when used in a Hadoop indexing job.

So what's the difference between string and hadoopyString?

The difference is that in addition to the String type, hadoopyString also supports the Hadoop Text and BytesWritable types. This isn't always necessary but it does let Druid work with more kinds of Hadoop InputFormats.
I raised this PR to adjust the example: #3263. Thanks for the report.


Trim down file chunking dependencies

This project currently depends on iroh-unixfs for its FileBuilder functionality, which is used to chunk up a file into IPLD blocks. Unfortunately the iroh-unixfs crate brings in a variety of other dependencies and functionality which is not needed merely to chunk up a file.
Find a way to trim down these dependencies to the bare minimum needed to chunk a file up into blocks. Options include...

Break out the FileBuilder functionality into a separate crate
Find another crate which already does the chunking with fewer dependencies
Roll new FileChunker functionality by building directly on libipld

This is resolved by #62


Preview pane, when viewing a gif picture, the picture will not play the animation effect

Microsoft PowerToys version
0.58.0
Running as admin

[ ] Yes

Area(s) with issue?
General
Steps to reproduce
Preview pane, when viewing a gif picture, the picture will not play the animation effect

✔ Expected Behavior
No response
❌ Actual Behavior
No response
Other Software
No response

I'm not sure how this is related to PowerToys. If PowerToys in uninstalled, does it suddenly start working? /needinfo

The gif diagram cannot be moved with the picture viewer that comes with Windows, and can only be accessed by opening it with a browser or other third-party software, so what I hope is that it can also be moved in the preview of powertoys.


incorrect table names in setup_ddb.sh

table names in setup_ddb.ssh (incorrectly, I believe) create:
vote-open2
vote-options2

instead of:
vote-open
vote-options

LGTM +1


When I click to List icon the cursor resets to the beginning

steps to reproduce:

write two lines of text
select them
click 'unordered list'
4 your cursor is in the beginning of the text, selection is dropped

It doesn't reproduce on demos on https://simplemde.com/ :(

fixed in 3.6.10


WiFi 5Ghz Radio Button always selected

After switching to 2.4Ghz Radiobutton, picking a WiFi Channel and then doing 'Apply WiFi Settings' the screen reloads and rather then reflecting how the Control Hub is now configured reverts to selecting the 5Ghz button.    The WiFi network name / control hub name reflect the applied changes and/or current name, but the radio button always reverts back to 5Ghz.
Should reflect the on-hub settings when it loads as to not accidently change this if other changes are being made (name and/or password)

The upcoming 1.1.2 version of the Control Hub OS will allow the Robot Controller app to determine what the current channel is. Until then, the Robot Controller app has no way of knowing what the current channel is, so it selects the 5 GHz band, and doesn't select a specific channel.

Control Hub OS 1.1.2 is out, closing this issue.

Control Hub OS 1.1.2 is out, closing this issue.


Allow customizing daily notes path

🚀 The feature, motivation and pitch
In Obsidian, I customized my daily notes path to a subfolder of the main space. I'd like to be able to set it as a custom option in obsidian.nvim, so that when I type :ObsidianToday, it creates the daily note in that path instead of the root of the obsidian space.
Alternatives
Right now I'm manually moving the daily note to the specified path, but if I already created it inside Obsidian, I have to manually merge the two files and it's not the ideal workflow.
Additional context
No response

Hey @metalelf0, I'd be happy to have this feature. Are you interesting in making a PR?
You'd just have to edit the command function here:
https://github.com/epwalsh/obsidian.nvim/blob/e3d10fe6bf19f99e7ce289a13f0fc720c2cb276f/lua/obsidian/command.lua#L52-L59
And then add a field for this setting in the Obsidian client class and config.

Hey @epwalsh ! Sure thing, but my lua-fu is still not that great. I tried hacking a solution here:
https://github.com/metalelf0/obsidian.nvim/commit/dc9956a24ca1c4235f406bcd22bb237f7dc878c9
But it seems something is not working.
Here's my reasoning: I added a client options called dailies_path, that should be relative to the main dir. This has a default value of "" (empty string), so that it can seamlessly be joined to the dir. In the client initialization, I convert it to a dailiies_dir variable, so that it can be used without ifs in the command. Loading the plugin with my changes, however, breaks with or without the option set.
What am I doing wrong?
Thanks a lot for your work!

Hey @metalelf0, can you open a draft PR so I can leave suggestions? Also the last few commits I made yesterday touch some of the same code, so you'll want to update your branch first.

Also I was thinking instead of adding a top-level field like dailies_path: "", we should add a field daily_notes: { folder: "", ... } that mimics the exact JSON structure in ~/.obsidian/daily-notes.json.

I opened a PR for this: #21 .

Closed via #21


Can this model used for other object background matting？

Can this model used for other objects background matting？  I try other object eg. toys,  the results seem not expected
Now, this model is only for body?
thanks

The model is only trained for human matting.

The model is only trained for human matting.

Thanks， Looking forward  your training code~  . I want to use for special object background matting.


ruler_offer_tribute_to_recipient shouldn't be shown if they are your vassal or if they are unlanded. I fixed it on my end but wanted to let you know

Fixed by latest commit


Copy URL to Clipboard feature does not work on recent versions of Chrome

Supposedly new ClipboardEvent('copy') works on Firefox, but it does not work on Chrome 40ish+.
Details here.
TypeError: Illegal constructor
at TypeError (native)
at Scope.scope.copyUrl (http://localhost:9000/components/footer/footer.directive.js:19:22)
at fn (eval at <anonymous> (http://localhost:9000/bower_components/angular/angular.js:1:0), <anonymous>:4:316)
at callback (http://localhost:9000/bower_components/angular/angular.js:23298:17)
at Scope.$eval (http://localhost:9000/bower_components/angular/angular.js:15846:28)
at Scope.$apply (http://localhost:9000/bower_components/angular/angular.js:15945:23)
at HTMLButtonElement.<anonymous> (http://localhost:9000/bower_components/angular/angular.js:23303:23)
at HTMLButtonElement.jQuery.event.dispatch (http://localhost:9000/bower_components/jquery/dist/jquery.js:4435:9)
at HTMLButtonElement.elemData.handle (http://localhost:9000/bower_components/jquery/dist/jquery.js:4121:28)

ClipBoard API support is really bad across browsers. I don't think that it is even worth using for this use case. All we're doing is allowing the user to copy the URL to the ClipBoard, but they can just do that in the URL bar of the browser.
I think that we should just remove this field and button from the footer to eliminate this issue.

Makes sense to me.
On Fri, Oct 2, 2015, 5:34 PM Michael Prentice<EMAIL_ADDRESS>wrote:

ClipBoard API http://caniuse.com/#feat=clipboard support is really bad
across browsers. I don't think that it is even worth using for this use
case. All we're doing is allowing the user to copy the URL to the
ClipBoard, but they can just do that in the URL bar of the browser.
I think that we should just remove this field and button from the footer
to eliminate this issue.
—
Reply to this email directly or view it on GitHub
https://github.com/gdg-x/firefly/issues/49#issuecomment-145040832.

Closed by 61b549cb9343ae4c2b4a93734451250ce90ce187.


Simple import give me nlpcloud' has no attribute 'Client' (most likely due to a circular import)

client = nlpcloud.Client(
         ^^^^^^^^^^^^^^^

AttributeError: partially initialized module 'nlpcloud' has no attribute 'Client' (most likely due to a circular import)
with nlpcloud 1.0.41

In pip this is the best version we have when in github it is tag v1.1.41
https://pypi.org/project/nlpcloud/
Maybe a github taging problem ?

Hello @slamer59 thanks for you message,
Such an error usually happens when you have a directory that has the same name as the library that you are trying to import.
Maybe you have a folder called "nlpcloud" that is messing up with your lib import?


Export on Windows Latest fails with C:\Users\runneradmin\bin\godot' is not recognized as an internal or external command

  export-windows-chickensoft:
    name: Windows Export (Chickensoft)
    runs-on: windows-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4
      - uses<EMAIL_ADDRESS>        name: Setup Godot
        with:
          version: 4.2.1
          use-dotnet: false
      - name: Check Dependencies
        shell: cmd
        run: |
          rustup default
          rustc --version
          echo %GODOT%
          echo %GODOT4%
          where godot
          %GODOT% --version
      - name: Rust and Godot export
        working-directory: ${{github.workspace}}/godot_action_test
        shell: cmd
        run: |
          mkdir ../build/windows
          export_win.bat
      - name: Upload Artifact
        uses: actions/upload-artifact@v4
        with:
          name: windows_chickensoft
          path: build/windows
          retention-days: 1

On the Setup Godot step I see that godot is installed
🔧 Adding environment variables...
    GODOT=C:\Users\runneradmin\bin\godot
    GODOT4=C:\Users\runneradmin\bin\godot

    // But Godot Executable is installed in a different place
    C:\Users\runneradmin\godot\Godot_v4.2.1-stable_win64.exe

On the Check Dependencies step I get the following log output
stable-x86_64-pc-windows-msvc (default)
rustc 1.76.0 (07dca489a 2024-02-04)
C:\Users\runneradmin\bin\godot
C:\Users\runneradmin\bin\godot
C:\Users\runneradmin\bin\godot
'C:\Users\runneradmin\bin\godot' is not recognized as an internal or external command,
operable program or batch file.

Raw Logs reference:  job-logs.txt
Probable issues

Symlinks are not being created properly
GODOT and GODOT4 env variables point to the wrong path

@coder137 thanks for investigating! can you see if this also fails from a bash shell? I'd like to take a closer look later when I have a chance, but finding that out would help tremendously.

Yes, When using the default shell as bash I could do godot --version now!
  export-windows-chickensoft:
    name: Windows Export (Chickensoft)
    runs-on: windows-latest
    defaults:
      run:
        shell: bash

So maybe the problem is with using cmd / default windows shell.
Either way, This solves my issue. I can just use bash instead

Please close this issue as you see fit.


Add button to test server connection

Allows the user to test the server connection, which helps in troubleshooting the initial setup.

I have implemented support for API tokens (added in latest version), and opened a PR for that. #3
Since this PR will need a modification to accommodate tokens it would be good to look at that one first.

Hmm, this PR does not work because it is missing the token input box. That leads to document.querySelector('#token') giving null and so document.querySelector('#token').value gives an exception and testAPI can not complete.
Also, I am not  positive but in the debugger it seemed like document.querySelector() was giving null for #username and #password. Those boxes were visible,, but I hadn't put anything in them yet. It might be necessary to test them before using .value for the case where someone enters a token and never enters a username/password.

I was not sure if I should've rebased onto master and force push, haven't had much experience with PRs, so the input field is missing because those changes were not included. I have updated the branch now.
As for #username and #password, did you enter document.querySelector(...) in the console opened by inspecting the extension? Because it will show the generated html document for the background script, not the options page. Otherwise I can't understand how they could be null as the script will load after they are created.

I was using the console in the debugger. I'm not sure how the scoping works there. I could print out local variables of the function being debugged but maybe document.querySelector(...) still works the way you suggest there. I will just check that this PR works with entering only one of username/password or token in a fresh profile.