Importing Diesel macros (Rust 2018)

In the 2018 edition, #[macro_use] is going away (kinda'), as use works with macros. Unfortunately, Diesel doesn't seem to play well with that, as a lot of macros are hard to find (e.g. no_arg_sql_function_body), or seem not to work even after being imported (although it's quite possible that I used a wrong path).
https://www.reddit.com/r/rust/comments/8tbah2/my_problems_with_understanding_rust_edition_2018/e166pdp/ suggests a simple work-around, but that might require a minimum compiler version bump.
#[macro_use] is probably still going to be supported, but it might be worth fixing this.
Related: https://github.com/rust-lang/rust/issues/35896#issuecomment-394553992.

I don't think there's anything actionable that we can do at this point in time. Even the comment you've linked to says "the lang team is looking into this but hasn't made a decision yet". As far as I can tell there's no compiler that demonstrates a concrete problem here, nor is there any change we can currently make that would address this potential problem today.
In a few months, if Diesel is unable to compile with stable Rust (which would be a pretty shocking step for Rust to take), please open a new issue.

As far as I can tell there's no compiler that demonstrates a concrete problem here

The issue can be observed on nightly, with the use_extern_macros feature enabled: https://play.rust-lang.org/?gist=51baef8107264c2aafaf140c4d045e86&version=nightly&mode=debug, and it affects Diesel in the same way.
I'll post here again if use_extern_macros gets stabilized and it's still hard to use it with Diesel.

@kamirr It's my understanding that the contributors' stance on issues like this is that, if there is an "easy enough" resolution, it should not be prioritized. This is similar with deprecation warnings with the Queryable derive macro. In my opinion, this does make the project feel less idiomatic and "hacky" compared to e.g. serde where you can just use serde::{Deserialize, Serialize}; in the modern way. This crate will come with the caveats of "don't forget to set this crate attribute and import all of its macros, unlike all of your other dependencies", which may not be a hard thing to accommodate as a user, but will negatively impact the image of the crate's polish and maintenance.
I personally don't care to discuss these issues if the maintainers don't care about it, but there are only so many times a project can brush off these requests before it builds up to a serious issue.

@rakenodiax @kamirr AFAIK all of the diesel warnings are fixed in master and will at some point be found in a future release.  If you want a solution now, please use the diesel master branch.

@technetos Seems like a good idea. There's this tiny problem that the master branch doesn't build ATM, but I guess I can wait.

I think those last comments mix some different things.

Those warnings issued on the latest release if a derive is used.
Making diesel compatible with importing macros by use statements.

The first point is unrelated to this issue and already fixed on master. Master currently builds fine, but our ci fails because some dependency bumped its minimal supported rust version above ours. So if you don't need to support rust 1.27 or something you could just use master.
The second point is somewhat more complex. I think we all agree that this should be fixed, but it's unfortunately quite complex to do this. I've already a branch somewhere that works in principal. The issue is that rustdoc does not allow me to document those macros in a way I would like. I need to find some time to look into how we could workaround this.

The standard solution of how to use 2018 macros and be backwards compatible is in the edition guide: macro changes. Someone could implement this for diesel now. The bit I wouldn't know how to do is how to generate the table! macro in schema.rs differently in the different editions. Maybe there could be an option on diesel_cli for the edition, and it tries to detect it from Cargo.toml otherwise.

@derekdreery There is already #1956. The only thing missing there is putting all macros exports in the right place.

This issue seems to have been closed a while ago, has it been fixed or just marked as wont fix ?

@weiznich , you have closed my issue #2386 with the reference to this issue. My apologies for opening a duplicate. This issue seems to be closed, however, there is still no way (at least in the docs) to use diesel without #[macro_use]. Should this be reopened, or am I missing something in the docs/examples?

@kdubovikov Please take the time to read to whole thread. The latest released diesel version just does not support importing macros without #[macro_use] as it's not just a documentation issue, but needs quite a lot of support from the crate offering the macros.

@kdubovikov Please take the time to read to whole thread. The latest released diesel version just does not support importing macros without #[macro_use] as it's not just a documentation issue, but needs quite a lot of support from the crate offering the macros.

@weiznich Thanks, I have read it before raising the question. I understand that this is not a documentation issue. The problem is that this ticket was closed without mentioning the final decision:

Diesel will support this and it will be implemented. If this is true, I am not sure why this issue should be closed. Is there any other open issue that adds this on the roadmap?
Diesel will not support this and this issue is closed. Nothing will be done further, at least for the current time

@mitermayer also asks the same question.
The last comment I see is:

@derekdreery There is already #1956. The only thing missing there is putting all macros exports in the right place.

#1956 is closed and merged. I have also found  #2248, which seems to be closely related to this issue. This pull request is also merged into the master branch. Does this mean that diesel already supports new-style macro imports, but this feature is not yet included in current stable release?
Thanks a lot for being supportive and answering on all questions in a very timely manner 👍🏻

@kdubovikov As you already figured out from the linked PR's it is already implemented on master, so there is no need to discuss anything else here. Additionally you can see there was no new major release since those PR's where merged, therefore no current diesel release supports this. (Please don't ask for a timeline for the next major release…)
Beside of that: Our issue tracker is a place for us developers to track thinks we are working on, not a place to answer support questions or anything like that. (Use our gitter channel or forum for that). A open issue here indicts that this is something someone could start working on, a closed issue is something  that cannot be worked on for whatever reason.

It would be really beneficial if the recommended documentation such as http://diesel.rs/guides/getting-started/  didn't lead you astray. The examples that are in the source tree (at the same tag) are helpful, but it's not obvious that the getting started guide will lead you to errors that are one or two steps removed from the origin source (e.g. "cannot find __diesel_parse_table!")

It would be really beneficial if the recommended documentation such as http://diesel.rs/guides/getting-started/  didn't lead you astray. The examples that are in the source tree (at the same tag) are helpful, but it's not obvious that the getting started guide will lead you to errors that are one or two steps removed from the origin source (e.g. "cannot find __diesel_parse_table!")

@jonringer I don't know why you feel that the getting started guide leads you astray, as it has a #[macro_use] extern crate diesel; in literally the first rust code block on that page. Anyway if you have some concrete suggestions for improvements: You will find the source code here, just open a PR with your improvements there.

@jonringer I don't know why you feel that the getting started guide leads you astray, as it has a #[macro_use] extern crate diesel; in literally the first rust code block on that page. Anyway if you have some concrete suggestions for improvements: You will find the source code here, just open a PR with your improvements there.

in literally the first rust code block on that page

I must have started from another post, then stumbled upon the getting started later and was selectively trying to "patch" my code to work. You're correct though, following the guide strictly does work. I apologize.

just open a PR with your improvements there.

absolutely.
Sorry for the noise.


[MLIR] Support structured control flow with catalyst.adjoint

Context: The current native adjoint lowering doesn't yet support Catalyst control flow.
Description of the Change: Restructure the adjoint lowering to be aware of structured control flow. Like classical automatic differentiation, this involves lowering into an augmented forward pass that records the gate parameters, dynamic wires, and control flow of the hybrid circuit, then a backward pass that generates the adjoint quantum gate operations in reverse order.
Benefits: The adjoint operation supports quantum functions with arbitrary classical control flow, including when the control flow produces values used as parameters for gates.
Possible Drawbacks: Supporting control flow implies a runtime overhead of storing what control flow happened so it can be replayed in reverse. The current implementation additionally uses an ArrayList to dynamically reallocate the caches, which has posed problems for buffer deallocation in the past. A potential future workaround is to have the memory for the ArrayList be statically managed, perhaps lowering to the LLVM dialect rather than the MemRef dialect.
[sc-41327]

Just checking in on this PR, is it good to merge @pengmai ?

Just checking in on this PR, is it good to merge @pengmai ?

Should be good now!


Add a progress bar to map of accommodations

It indicates data fetching in progress
New component ProgressBar can be animated with property animate
Usage: <ProgressBar /> or <ProgressBar animate />
Notice the thin gray line on top: that's the non-animated version that we use for this page.

It's great to have a progress bar, but unfortunately I can't preview it...

(the same message keeps displaying in dev and non-dev env, I just set up my email too, if it mattered...)

It's great to have a progress bar, but unfortunately I can't preview it...

(the same message keeps displaying in dev and non-dev env, I just set up my email too, if it mattered...)

If you have account on both dev and non-dev, it's likely the issue described in #48. The improved query system in #66 would be a first step to fix that. Until then, i think it would help if you remove string  dev:card, from your public type index. Then you would have to avoid signing in into dev app with the same account, until #48 is fixed. We can prioritize that...

i think it would help if you remove string  dev:card, from your public type index. Then you would have to avoid using dev app with the same account, until https://github.com/OpenHospitalityNetwork/sleepy.bike/issues/48 is fixed.

It works with another account, thanks! (I also fixed my primary one)


Update droplet creation

Use a new Debian 10 snapshot, enforce the firewall, and create fresh and secure erlang magic cookies.
Testing plan:
$ python3 ./tools/droplets/create.py alexmv -s alexmv-new --recreate
Creating Zulip developer environment for GitHub user alexmv...
Checking to see if GitHub user alexmv exists...
...user exists!
Checking to see that GitHub user has available public keys...
...public keys found!
Checking to see GitHub user has forked zulip/zulip...
...fork found!
...returning cloud-config data.
Checking to see if droplet alexmv-new.zulipdev.org already exists...
Deleting existing droplet alexmv-new.zulipdev.org.
Initiating droplet creation...
...[create]: in-progress
...[create]: in-progress
...[create]: in-progress
...[create]: in-progress
...[create]: in-progress
...[create]: completed
...droplet created!
...ip address for new droplet is: <IP_ADDRESS>.
Deleted 1 existing A records for alexmv-new.zulipdev.org.
Deleted 1 existing A records for *.alexmv-new.zulipdev.org.
Creating new A record for alexmv-new.zulipdev.org that points to <IP_ADDRESS>.
Creating new A record for *.alexmv-new.zulipdev.org that points to <IP_ADDRESS>.

COMPLETE! Droplet for GitHub user alexmv-new.zulipdev.org is available at alexmv-new.zulipdev.org.zulipdev.org.

Instructions for use are below. (copy and paste to the user)

------
Your remote Zulip dev server has been created!

- Connect to your server by running
  `ssh<EMAIL_ADDRESS>on the command line
  (Terminal for macOS and Linux, Bash for Git on Windows).
- There is no password; your account is configured to use your SSH keys.
- Once you log in, you should see `(zulip-py3-venv) ~$`.
- To start the dev server, `cd zulip` and then run `./tools/run-dev.py`.
- While the dev server is running, you can see the Zulip server in your browser at
  http://alexmv-new.zulipdev.org:9991.

See [Developing remotely](https://zulip.readthedocs.io/en/latest/development/remote.html) for tips on using the remote dev instance and [Git & GitHub guide](https://zulip.readthedocs.io/en/latest/git/index.html) to learn how to use Git with Zulip.

Note that this droplet will automatically be deleted after a month of inactivity. If you are leaving Zulip for more than a few weeks, we recommend pushing all of your active branches to GitHub.
------

...on the host:
(zulip-py3-venv) zulipdev@alexmv-new:~$ lsb_release -a
No LSB modules are available.
Distributor ID:	Debian
Description:	Debian GNU/Linux 10 (buster)
Release:	10
Codename:	buster
(zulip-py3-venv) zulipdev@alexmv-new:~$ sudo netstat -ltpn
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 <IP_ADDRESS>:5672          <IP_ADDRESS>:*               LISTEN      1552/beam.smp
tcp        0      0 <IP_ADDRESS>:25672         <IP_ADDRESS>:*               LISTEN      1552/beam.smp
tcp        0      0 <IP_ADDRESS>:6379          <IP_ADDRESS>:*               LISTEN      513/redis-server 12
tcp        0      0 <IP_ADDRESS>:11211         <IP_ADDRESS>:*               LISTEN      455/memcached
tcp        0      0 <IP_ADDRESS>:22              <IP_ADDRESS>:*               LISTEN      1826/sshd
tcp        0      0 <IP_ADDRESS>:5432          <IP_ADDRESS>:*               LISTEN      581/postgres
tcp        0      0 <IP_ADDRESS>:25            <IP_ADDRESS>:*               LISTEN      1079/exim4
tcp6       0      0 ::1:6379                :::*                    LISTEN      513/redis-server 12
tcp6       0      0 :::4369                 :::*                    LISTEN      1/init
tcp6       0      0 :::22                   :::*                    LISTEN      1826/sshd
tcp6       0      0 ::1:25                  :::*                    LISTEN      1079/exim4
(zulip-py3-venv) zulipdev@alexmv-new:~$ sudo cat /var/lib/rabbitmq/.erlang.cookie
6268985b23030253d78c3f094e87bfa8

Awesome, merged, thanks @alexmv!  I suppose we should announce this in #general or something?


Cache roots as 8 inline numbers

Motivation

We don't want to use Uint8Array as cached roots as it takes too much memory

Description

Store the root as 8 numbers inside the Node instead of a separate object to hopefully share the map memory with the Node itself
Use digestTwoHashObjects() from the new as-sha256 0.2.3
Both memory and hash performance was improved as below

Memory usage for 250k validators

branch
initial
create tree
calculate root
final

master
0 MB
+657 MB
+467MB
1124 MB

this branch
0 MB
+459MB
5MB.
464 mB

Hash tree root performance for 250k validators

branch
ops/s
s/op
note

master
0.223609
4.472079s
-

master - new as-sha256
0.2593184
3.856263s
new improvement of digest64

this branch
0.4116688
2.429137s
digestTwoHashObjects

we almost double the hash speed with this new update!

Amazing results!
Interesting that memory doesn't really grow after hashing, very different than before.

@wemeetagain the null as unknown as number trick helps save us ~13MB due to no hasRoot variable

Amazing results!
Interesting that memory doesn't really grow after hashing, very different than before.

Because all values are initialized to 0 on construction, even if you don't hash. Note that this means that consumers that don't hash will have to pay the cost of a hashing cache regardless.

Do we plan on exposing two types of Nodes and Trees? Such that consumers that want the hash object version can use it, otherwise use regular Uint8Arrays

Amazing results!
Interesting that memory doesn't really grow after hashing, very different than before.

Because all values are initialized to 0 on construction, even if you don't hash. Note that this means that consumers that don't hash will have to pay the cost of a hashing cache regardless.

@dapplion  Just want to add that the cost of hashing cache is really small. In master right after we create the tree (all branch nodes have _root=null) it takes +657MB while with this branch we initialize all branch nodes and leaf nodes and it takes only +459MB so it's really not a down side


stabilize cypress test case

Description
[Describe what this change achieves]
Issues Resolved
[List any issues this PR will resolve]
Check List

[x] Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

The workflow failed on main, maybe we can create one for 2.9 and backport to main and 2.x?

The workflow failed on main, maybe we can create one for 2.9 and backport to main and 2.x?

main branch has been fixed


[Test-1] Add unit test cases to BranchStatus, BranchType and GlobalStatus.

Ⅰ. Describe what this PR did
Add unit test cases to BranchStatus, BranchType and GlobalStatus.
Ⅱ. Does this pull request fix one issue?
fix #195

Codecov Report

Merging #554 into develop will increase coverage by 0.11%.
The diff coverage is n/a.

@@              Coverage Diff              @@
##             develop     #554      +/-   ##
=============================================
+ Coverage      31.81%   31.92%   +0.11%
- Complexity       769      775       +6
=============================================
  Files            200      200
  Lines           7908     7908
  Branches         935      935
=============================================
+ Hits            2516     2525       +9
+ Misses          5135     5128       -7
+ Partials         257      255       -2

Impacted Files
Coverage Δ
Complexity Δ

...va/com/alibaba/fescar/core/model/GlobalStatus.java
100% <0%> (+6.66%)
7% <0%> (+1%)
:arrow_up:

...va/com/alibaba/fescar/core/model/BranchStatus.java
100% <0%> (+8%)
7% <0%> (+1%)
:arrow_up:

...java/com/alibaba/fescar/core/model/BranchType.java
100% <0%> (+62.5%)
5% <0%> (+4%)
:arrow_up:

Continue to review full report at Codecov.

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

@guanlei1996 please dingTalk ping me

@github-ygy

由于前期Seata社区治理规范问题部分代码作者未签署CLA，可能引发社区知识产权风险问题。请所有在Seata社区贡献过代码（包含：主项目、官网、samples和多语言项目等）的 contributor 帮忙在这个链接登录github账号签署相应的开发者CLA，https://cla-assistant.io/seata/seata  。2023.1.31 未签署CLA的代码将会被rewrite，拜托大家帮忙签一下。


Add to bucket

Codecov Report

Merging #7 into master will decrease coverage by 1.48%.
The diff coverage is 0.67%.

@@            Coverage Diff            @@
##           master      #7      +/-   ##
=========================================
- Coverage    5.97%   4.49%   -1.49%
=========================================
  Files           3       4       +1
  Lines         435     534      +99
=========================================
- Hits           26      24       -2
- Misses        399     500     +101
  Partials       10      10

Impacted Files
Coverage Δ

cmd/claim/claim.go
30.90% <0.00%> (-1.85%)
:arrow_down:

cmd/distribute/dopisit.go
0.00% <0.00%> (ø)

cmd/distribute/distribute.go
2.06% <2.94%> (+0.07%)
:arrow_up:

Continue to review full report at Codecov.

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

Codecov Report

Merging #7 into master will decrease coverage by 1.44%.
The diff coverage is 0.68%.

@@            Coverage Diff            @@
##           master      #7      +/-   ##
=========================================
- Coverage    5.97%   4.52%   -1.45%
=========================================
  Files           3       4       +1
  Lines         435     530      +95
=========================================
- Hits           26      24       -2
- Misses        399     496      +97
  Partials       10      10

Impacted Files
Coverage Δ

cmd/claim/claim.go
30.90% <0.00%> (-1.85%)
:arrow_down:

cmd/distribute/deposit.go
0.00% <0.00%> (ø)

cmd/distribute/distribute.go
2.06% <2.94%> (+0.07%)
:arrow_up:

Continue to review full report at Codecov.

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


[Concurrency] Relax task-local mis-use prevention in task groups

We have a mechanism protecting task group child tasks from accessing values in "outer scope"  if they are defined like this:
await withTaskGroup { group in
  await $local.withValue(value) {  // push "value"
    group.addTask {} // would refer to "value" by "direct pointer" to parent task
  } // pop value ---- if we allowed the above "direct pointer" the child task now refers to trash memory
}

So to prevent this, today, we crash eagerly when we detect this.
The problem:
We crash to aggresively, also falsely triggering on this:
await withTaskGroup { group in
  await $local.withValue(value) {  // does crash, but shouldn't
  }
  group.addTask {}
}

This patch solves this behavior by more precise runtime detecting of the specific problem situation -- we now crash inside the addTask and NOT inside the withValue.
Future direction: We could start copying defensively when we notice the "bad situation" rather than just crash. @FranzBusch was arguing that behavior would be preferable -- because we cannot always control the shapes of APIs, and if someone were to offer a synchronous callback API and they had set a task local value inside a task group "by accident" without even knowing about it, today we would crash - causing weird non-local interactions.
I'll see if I can pull off the copying "only when we have to in the bad-bad and rare case".
resolves rdar://127156303

@swift-ci please smoke test

Note to self, on linux:
/home/build-user/swift/stdlib/public/Concurrency/TaskLocal.cpp:320:3: error: no matching function for call to 'free'
  320 |   free(message);
      |   ^~~~
/usr/include/stdlib.h:565:13: note: candidate function not viable: no known conversion from 'const char *' to 'void *' for 1st argument
  565 | extern void free (void *__ptr) __THROW;
      |             ^     ~~~~~~~~~~~

@swift-ci please smoke test

@swift-ci please smoke test

replaced by https://github.com/apple/swift/pull/73978


Emission being enabled unecessarily - Unexpected parameters set in imported materials using gITF, Collada and FBX from Blender

Godot version:
Godot 3.2.3
OS/device including version:
Windows 10 Pro v.2004 / Inspiron 7373 Core i7-8550U / Intel(R) UHD Graphics 620
Issue description:
When importing models including materials from Blender, I'm getting unexpected parameters set in the materials:
Using all three gITF, Collada and FBX, the parameter for Cull Mode is set to "Disabled", I believe it should always default to "Back". Even if you enable Backface Culling in the Eevee material settings, Cull Mode will still be "Disabled" when importing.
When using gITF the "Emission" property is enabled, even though the value is set to default black in Blender.
When using Collada, the Roughness value is set to 0.08, this does not match the value from Blender, which was the default of 0.4.
When using FBX, the Roughness value isn't set, it's left at 1.0, this does not match the value from Blender, which was the default of 0.4.
NOTE: I could not use the Better Collada exporter in Blender as it gives an error that you need to upgrade to Blender 2.8x when using both Blender 2.83.6 and Blender 2.90.1. So the Collada file used here is made using Blender's built-in Collada exporter.
Steps to reproduce:
Open attached project and observe the values in the 3 materials.
Minimal reproduction project:
ModelImportIssuesExample.zip

I checked the gltf:

it doesn't have a double sided property
culling is set to back when I do glb -> gltf.

I think the materials are overwriting each other. In particular, FBX's material is overwriting the other ones, since FBX's material is always set to cull double sided.

Regarding

When using gITF the "Emission" property is enabled, even though the value is set to default black in Blender.

This has no ill effects I think, so have "Emission" property" be toggled only on use could be a junior issue to PR on.
For Collada and FBX:
Blender doesn't support FBX's Arnold materials so any roughness and metalness values are guessed. The same goes for Collada. I'm not sure if there's a way to guess.

When using FBX, the Roughness value isn't set, it's left at 1.0, this does not match the value from Blender, which was the default of 0.4.

When using Collada, the Roughness value is set to 0.08, this does not match the value from Blender, which was the default of 0.4.

I'm seeing the culling set to Disabled on every material I import on two different machines. I made another new project and tried the three different type of glTF files and all of them did it for me.

Yeah the Emission thing doesn't affect the look, so it's not a big problem, but I'm gussing it still ads the emission code to the shader.

Did you put the fbx, obj and gltf in separate folders?

Did you put the fbx, obj and gltf in separate folders?

In the last example above I just did the three different types of gltf files, no other file types and yes I put each inside it's own folder so they didn't mess with each other.
I just made yet another new project, with just a single .gltf file that I imported and nothing else in the project, and again the Cull Mode gets set to Disabled.

AnotherImportTest.zip
I can make a video of it later tonight if that would help.

This material is double sided.
 "materials" : [
        {
            "doubleSided" : true,
            "emissiveFactor" : [
                0,
                0,
                0
            ],
            "name" : "gltf mat",
            "pbrMetallicRoughness" : {
                "baseColorFactor" : [
                    0.800000011920929,
                    0.800000011920929,
                    0.800000011920929,
                    1
                ],
                "metallicFactor" : 0,
                "roughnessFactor" : 0.4000000059604645
            }
        }
    ],

Ah damn, ok my bad. I must have been doing something wrong. I was sure I had tried using the "Backface Culling" setting in the Eevee material options, but not seen it working, but it works when I set it now, so it reads that value and sets Culling based of it.
I'd venture to say this is still not a great situation to read that Culling option and set Culling to disabled. 9 times our of 10 when you are using Blender you'll be modelling and want to see backfaces and not worry about that setting, but you don't expect Culling to be disabled when you then move over to a game engine. And if you are not using Eevee you won't even see this setting in the material panel in Blender.

What things can be improved?
Note that FBX is being rewritten from the ground up and there's a branch for that work. It should have this problem resolved. Need to check.

How about we just use this bug to fix the small error with emission being enabled?
I think a case could be made for never setting the Culling to Disabled, as I think it will very often not be what people actually want. But that seems like something that should be proposed as an improvement, not as a bug fix, since it is currently working as expected.

Logged a bug against blenders glTF export https://developer.blender.org/T82084

I think this is actually a problem for Maya too, what is happening diagnostically of modelling application.
Basically 'emission defaults to 1.0' but no properties are set, this is a misunderstanding in our importers of emission being set to a value.
I had to put some code in the FBX importer to deal with this property correctly too.

@Arnklit I will publish the material fixes which will resolve this for FBX.

I can confirm the disabled cull mode part on master fc09d783f. It seems that this is intentional however: https://github.com/godotengine/godot/issues/50552
My issue with this is that I'm often using GLB models downloaded from online sources such as Poly Haven. These models come with materials that have backface culling disabled, but they would render just fine with backface culling enabled. This reduces performance for no good reason, as backfaces don't need to be rendered.

I believe we can override the choice by force but we must respect the cull mode defined in gltf.

Emission checkbox may be a bug but it has very little performance impact. We will investigate later.
Collada is not currently being maintained.
FBX issue should be fixed now that we use FBX2glTF


[AutoPR apimanagement/resource-manager] [Hub Generated] Review request for Microsoft.ApiManagement to add version stable/2019-01-01

Created to sync https://github.com/Azure/azure-rest-api-specs/pull/5613

This PR has been merged into https://github.com/Azure/azure-sdk-for-js/pull/2198


CNV-32923: Fix clicking enter after copy console

📝 Description
When clicking paste in the console screen the button stays in focus and when clicking enter it pastes again.
the fix is those 2 lines of code:
e.currentTarget.blur();
e.preventDefault();
the rest is to remove React.*
🎥 Demo

Please add a video or an image of the behavior/changes

/lgtm

/retest

/retest


Update README.md

Update readme to with project website

Coverage remained the same at 94.034% when pulling 15374f2cc0f09b9ba5e2d7f38061eceabb1463bd on kexinrong:readme into 8c02554a1140dc71806697b0583ed6745ba57b44 on stanford-futuredata:master.

Coverage remained the same at 94.034% when pulling c3e910c60461020273dad50cedc653ce17e4e0b2 on kexinrong:readme into db6f165cb5cb96148fe5f0f11ba12f6d5e73520d on stanford-futuredata:master.


Dao class can't live in seperate file from Database class

This works because both classes are in the same file:
class AppDatabase extends _$AppDatabase { }

@UseDao(tables: [Users])
class UsersDao extends DatabaseAccessor<AppDatabase> with _$UsersDaoMixin
  final AppDatabase db;
  // Called by the AppDatabase class
  UsersDao(this.db) : super(db);
}

And _$UsersDaoMixin  shows error if UsersDao is at seperate code file

Hm, that doesn't sound right.
After you moved the dao in its own file (let's say it's called users_dao.dart), did you add a part "users_dao.g.dart"; directive in that new file? If so, please try to re-run the build runner with flutter packages pub run build_runner build. Moor should then write that _$UsersDaoMixin into a users_dao.g.dart file.

After adding the line
part "users_dao.g.dart";
This is error
[SEVERE] moor_generator:moor_generator on lib/components/moor/moor_dao/users_dao.dart (cached): Error running DaoGenerator NoSuchMethodError: The getter 'listValue' was called on null. Receiver: null Tried calling: listValue [SEVERE] Failed after 123ms pub finished with exit code 1
This is code of users_dao.dart
`
import 'package:myapp/components/moor/moor_create/moor_create_Users.dart';
import 'package:myapp/components/moor/moor_database.dart';
import 'package:moor/moor.dart';
import 'package:moor_flutter/moor_flutter.dart';
part 'users_dao.g.dart';
@UseDao(tables: [Users])
class UsersDao extends DatabaseAccessor with _$UsersDaoMixin {
final AppDatabase db;
UsersDao(this.db) : super(db);
}`

Looks like a bug in moor. Can you give me the full stacktrace (run with flutter packages pub run build_runner build -v)?

#0      throwToolExit (package:flutter_tools/src/base/common.dart:28:3) #1      pubInteractively (package:flutter_tools/src/dart/pub.dart:190:5) <asynchronous suspension> #2      PackagesPassthroughCommand.runCommand (package:flutter_tools/src/commands/packages.dart:223:11) <asynchronous suspension> #3      FlutterCommand.verifyThenRunCommand (package:flutter_tools/src/runner/flutter_command.dart:478:18) <asynchronous suspension> #4      FlutterCommand.run.<anonymous closure> (package:flutter_tools/src/runner/flutter_command.dart:383:33) <asynchronous suspension> #5      AppContext.run.<anonymous closure> (package:flutter_tools/src/base/context.dart:153:29) <asynchronous suspension> #6      _rootRun (dart:async/zone.dart:1124:13) #7      _CustomZone.run (dart:async/zone.dart:1021:19) #8      _runZoned (dart:async/zone.dart:1516:10) #9      runZoned (dart:async/zone.dart:1463:12) #10     AppContext.run (package:flutter_tools/src/base/context.dart:152:18) <asynchronous suspension> #11     FlutterCommand.run (package:flutter_tools/src/runner/flutter_command.dart:375:20) #12     CommandRunner.runCommand (package:args/command_runner.dart:197:27) <asynchronous suspension> #13     FlutterCommandRunner.runCommand.<anonymous closure> (package:flutter_tools/src/runner/flutter_command_runner.dart:396:21) <asynchronous suspension> #14     AppContext.run.<anonymous closure> (package:flutter_tools/src/base/context.dart:153:29) <asynchronous suspension> #15     _rootRun (dart:async/zone.dart:1124:13) #16     _CustomZone.run (dart:async/zone.dart:1021:19) #17     _runZoned (dart:async/zone.dart:1516:10) #18     runZoned (dart:async/zone.dart:1463:12) #19     AppContext.run (package:flutter_tools/src/base/context.dart:152:18) <asynchronous suspension> #20     FlutterCommandRunner.runCommand (package:flutter_tools/src/runner/flutter_command_runner.dart:356:19) <asynchronous suspension> #21     CommandRunner.run.<anonymous closure> (package:args/command_runner.dart:112:25) #22     new Future.sync (dart:async/future.dart:224:31) #23     CommandRunner.run (package:args/command_runner.dart:112:14) #24     FlutterCommandRunner.run (package:flutter_tools/src/runner/flutter_command_runner.dart:242:18) #25     run.<anonymous closure>.<anonymous closure> (package:flutter_tools/runner.dart:62:22) <asynchronous suspension> #26     _rootRun (dart:async/zone.dart:1124:13) #27     _CustomZone.run (dart:async/zone.dart:1021:19) #28     _runZoned (dart:async/zone.dart:1516:10) #29     runZoned (dart:async/zone.dart:1500:12) #30     run.<anonymous closure> (package:flutter_tools/runner.dart:60:18) <asynchronous suspension> #31     AppContext.run.<anonymous closure> (package:flutter_tools/src/base/context.dart:153:29) <asynchronous suspension> #32     _rootRun (dart:async/zone.dart:1124:13) #33     _CustomZone.run (dart:async/zone.dart:1021:19) #34     _runZoned (dart:async/zone.dart:1516:10) #35     runZoned (dart:async/zone.dart:1463:12) #36     AppContext.run (package:flutter_tools/src/base/context.dart:152:18) <asynchronous suspension> #37     runInContext (package:flutter_tools/src/context_runner.dart:56:24) <asynchronous suspension> #38     run (package:flutter_tools/runner.dart:51:10) #39     main (package:flutter_tools/executable.dart:62:9) <asynchronous suspension> #40     main (file:///Users/kaungzawhtet/flutter%20sdk/packages/flutter_tools/bin/flutter_tools.dart:8:3) #41     _startIsolate.<anonymous closure> (dart:isolate-patch/isolate_patch.dart:299:32) #42     _RawReceivePortImpl._handleMessage (dart:isolate-patch/isolate_patch.dart:172:12)

Sorry, it looks like Flutter appends its own stacktrace when the build fails, there should have been another exception in the logs containing trace entries from package:moor_generator.
That said, I think the error can only occur when the annotation isn't constant for some reason. Just to be sure, you are importing the file that contains the Users class, right? I just tried to reproduce your problem in this gist https://gist.github.com/simolus3/4ebece3fe0307370564163e0b3abcff8 but that's working for me, even if I put the Users class into its own file and import it from database.dart and dao.dart.

After creating your dao.dart in the same directory of database.dart, dao.g.dart was generated. And I re-created my users_dao.dart and now, my users_dao.g.dart is being generated and working meaninglessly now. Looks generator has unknown bug. Anyway, thx your ur help. This issue can be closed now

Just for reference. I had a pretty similar issue. I "fixed" it by actually doing the circular import.
That's importing database.dart from dao.dart and vice-versa.
Silly mistake but I hope it helps people that find this issue.

@simolus3 Could you confirm that the correct way to achieve this is to use a circular import? Seems to be the only way (DB imports model, DB imports DAO, DAO imports Model and DB). Not a Dart expert but it seems odd to have a circular import (but it seems to work?).

I don't see why the db would have to import the dao. I'm also not sure what you mean with "model". If you mean the generated table classes, those aren't really an import.
It's true that the dao has to import the main database file (which includes the generated tables), but apart from that I don't see a transitive import here.

If the DB doesn't import the DAO I can't specify the list of DAOs in UseMoor:
@UseMoor(tables: [Foo], daos: [FooDao])
class AppDatabase extends _$AppDatabase

Isn't that correct?

Good point, I overlooked that. (Technically you can omit the daos in @UseMoor and it will still mostly work)
In this case a circular import between dao and db is necessary indeed. So far I didn't run into any issues with that. If you don't want to use them you could remove the daos section from the annotation. You can still use MyDao(myDatabase) manually to obtain a dao instance.

Ah okay, yeah I think I'll just go with MyDao(myDatabase) then to have a tad more peace-of-mind :)
Thanks!

Based on this thread and this one: https://github.com/simolus3/moor/issues/241, we can seperate model(table)/database/dao into seperate folders, which model is the base, database depends on model, and dao depends on both.


File loader widget remains blocked

The problem is caused by the z-index

Thanks for info @GhilesHideur
Fix to be done in template.
I will do it


feat(metrics): generalize admission webhook metrics

Description:
This change adds the osm_admission_webhook_response_total metric to
track all mutating and validating webhook responses by Kubernetes
resource kind and whether the request was successful or not.
Example:
osm_admission_webhook_response_total{kind="TrafficTarget",success="true"} 4

Part of #4568

Testing done:

Updated unit tests
Did some manual smoke testing with the whole control plane running

Affected area:

Functional Area

New Functionality
[X]

CI System
[ ]

CLI Tool
[ ]

Certificate Management
[ ]

Control Plane
[ ]

Demo
[ ]

Documentation
[ ]

Egress
[ ]

Ingress
[ ]

Install
[ ]

Networking
[ ]

Observability
[X]

Performance
[ ]

SMI Policy
[ ]

Security
[ ]

Sidecar Injection
[X]

Tests
[ ]

Upgrade
[ ]

Other
[ ]

Please answer the following questions with yes/no.

Does this change contain code from or inspired by another project? No

Did you notify the maintainers and provide attribution?

Is this a breaking change? Yes, release notes updated

Has documentation corresponding to this change been updated in the osm-docs repo (if applicable)? Yes, https://github.com/openservicemesh/osm-docs/pull/341

Codecov Report

Merging #4597 (2612e95) into main (caaa189) will decrease coverage by 0.06%.
The diff coverage is 72.41%.

@@            Coverage Diff             @@
##             main    #4597      +/-   ##
==========================================
- Coverage   68.73%   68.66%   -0.07%
==========================================
  Files         217      216       -1
  Lines       14954    14919      -35
==========================================
- Hits        10278    10244      -34
  Misses       4624     4624
+ Partials       52       51       -1

Flag
Coverage Δ

unittests
68.66% <72.41%> (-0.07%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

cmd/osm-controller/osm-controller.go
15.31% <0.00%> (-0.07%)
:arrow_down:

pkg/metricsstore/metricsstore.go
91.90% <36.36%> (-4.25%)
:arrow_down:

pkg/httpserver/httpserver.go
84.61% <100.00%> (-1.83%)
:arrow_down:

pkg/injector/webhook.go
87.95% <100.00%> (-0.36%)
:arrow_down:

pkg/validator/server.go
77.08% <100.00%> (+0.32%)
:arrow_up:

pkg/webhook/webhook.go
94.73% <100.00%> (+1.87%)
:arrow_up:

pkg/crdconversion/crdconversion.go
74.81% <0.00%> (+6.66%)
:arrow_up:

Continue to review full report at Codecov.

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


cuda显存一直超出的问题/Persistent cudA video memory overruns

我目前训练yolox_l，batch_size设置的为4，img_size为416,但一直报显存的错，我的显卡是xp，显存12个g，应该不会出现这样的情况，之前yolov4,v5都设置的batchsize为8或者6。。。，请问有人知道是什么原因吗？
I am currently training yolox_L, set batch_size to 4, imG_size to 416, but the error of the video memory is always reported. My video card is XP, and the video memory is 12 G, this should not happen, yolov4, V5 set batchsize to 8 or 6 before... Does anybody know why?

@ZZM11 I think your GPUs may be occupied by other programs.

I confirm that the video memory is not occupied by other apps

你的问题解决了吗？我也遇到了这个问题，求教

你的问题解决了吗？我也遇到了这个问题，求教

没有，只能减少batchsize

batch size 调到了1还是不行

Hi,
Did you solved this problem ?


Hacktoberfest first PR

Hope you will merge this soon....
Happy Hacktober

Hope you will see the PR and merge it.

Hope you will see the PR and merge it.

make sure star🌟 Our repo before submit your pull request

Starred the repo

Hope you will merge it.


WAX ship cannot start from snapshot: deltas is too big

WAX node, 2.0.13wax01, with sip enabled, starting from a fresh snapshot, is impossible to start. Giving the error like this, and trying to start from a new block:
info  2022-01-27T11:37:15.125 net-0     net_plugin.cpp:1556           operator()           ] requesting range 163571776 to 163571875, from <IP_ADDRESS>:9876 - 825b55d
warn  2022-01-27T11:37:19.129 nodeos    controller.cpp:379            emit                 ] fc::exception: 3110000 plugin_exception: Plugin exception
deltas is too big
    <- timeout exception in to_detail_string: deadline 2022-01-27T11:37:18.985 exceeded by 143044us

info  2022-01-27T11:37:19.930 nodeos    state_history_plugin.c:486    store_chain_state    ] Placing initial state in block 163571777
info  2022-01-27T11:37:24.131 net-1     net_plugin.cpp:1619           sync_reassign_fetch  ] reassign_fetch, our last req is 163571875, next expected is 163571777 peer <IP_ADDRESS>:9876 - 825b55d
info  2022-01-27T11:37:24.131 net-1     net_plugin.cpp:1203           cancel_sync          ] sending empty request but not calling sync wait on wax.eu.eosamsterdam.net:9101
info  2022-01-27T11:37:24.131 net-1     net_plugin.cpp:1556           operator()           ] requesting range 163571777 to 163571876, from <IP_ADDRESS>:9880 - f234e88

Full installation procedure here, and nodeos log is attached.
AMD Ryzen 9 PRO 3900 12-Core Processor
128 GB RAM
900GB SSD
Ubuntu 18.04

root@7F0F499:~# uname -a
Linux 7F0F499 5.4.0-96-generic #109~18.04.1-Ubuntu SMP Thu Jan 13 15:06:26 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

fallocate -l<PHONE_NUMBER>00 /swap
chmod 600 /swap
mkswap /swap
swapon /swap

root@7F0F499:~# free -g
              total        used        free      shared  buff/cache   available
Mem:            125           0         125           0           0         124
Swap:           286           0         286

cd /var/local
wget https://apt.eossweden.org/wax/pool/stable/w/wax/wax_2.0.13wax01-1-ubuntu-18.04_amd64.deb
apt install -y ./wax_2.0.13wax01-1-ubuntu-18.04_amd64.deb

mkdir -p /srv/wax/etc
cat > /srv/wax/etc/config.ini <<'EOT'
chain-state-db-size-mb = 96000
reversible-blocks-db-size-mb = 2048
read-mode = head
wasm-runtime = eos-vm-jit
eos-vm-oc-enable = true
p2p-accept-transactions = false
api-accept-transactions = false
http-server-address = <IP_ADDRESS>:8888
p2p-listen-endpoint = <IP_ADDRESS>:9801
access-control-allow-origin = *
plugin = eosio::chain_plugin
plugin = eosio::chain_api_plugin
validation-mode = light
plugin = eosio::state_history_plugin
trace-history = true
chain-state-history = true
state-history-endpoint = <IP_ADDRESS>:8080
p2p-peer-address = wax.eu.eosamsterdam.net:9101
p2p-peer-address = peer.3dkrender.com:9880
EOT

curl https://snapshots-cdn.eossweden.org/wax/2.0/snapshot-163571775.bin.tar.gz | tar xzvf -

root@7F0F499:/var/local# ls -al snapshot-163571775.bin
-rw-r--r-- 1 1003 1003<PHONE_NUMBER>6 Jan 27 00:41 snapshot-163571775.bin

nohup /usr/bin/nodeos --data-dir /srv/wax/data --config-dir /srv/wax/etc --disable-replay-opts --snapshot snapshot-163571775.bin &

nohup.out.txt

Try reducing --sync-fetch-span from its default of 100  to something smaller.
https://developers.eos.io/manuals/eos/v2.0/nodeos/plugins/net_plugin/index

The delta is bigger than uint32_t size can hold. I believe this has been fixed in 2.1.x.

2.1 started fine from the same snapshot

https://github.com/EOSIO/eos/pull/11051

tested successfully, and released 2.0.13wax13 which includes the patch:  https://github.com/cc32d9/wax2.0


Adds KYC Wall trigger for Transfer Balance action

cc @stitesExpensify @nickmurray47
Details

Adds the KYC checks to attempts to transfer a balance
Fixes up the positioning of the "add payment method" popover

Fixed Issues
$ https://github.com/Expensify/Expensify/issues/187802
Tests
Note: In order to simulate a user instantly passing Onfido + IDOlogy we need to take a few additional steps that are explained here.

Start with an account that has a gold wallet + payment method added i.e. able to "Send Money"
Send money to an account that does not have a gold wallet
Navigate to the "Settings > Payments" screen and tap "Transfer Balance"
Verify that a popup appears asking you to add a "Bank account" or "Debit card"
Select one of these things and add it
Verify you are navigated to the "Verify identity" flow
Go through Onfido and enter the required information
Verify that you are brought to the balance transfer page

[x] Verify that no errors appear in the JS console

QA Steps
Internal QA ... maybe Production QA? Not sure if Onfido works on staging.
Tested On

[x] Web
[ ] Mobile Web
[ ] Desktop
[ ] iOS
[ ] Android

Screenshots

Web

Mobile Web

Desktop

iOS

Android

Will test and merge this morning

I got this error in step 3:

I'm going to test again with a different account.

Getting the same issue with another account with Gold wallet. Seems the userWalletproperty is missing here:
https://github.com/Expensify/App/blob/c857f8b1a5ccf1baf895770f00b2369cec727975/src/pages/settings/Payments/TransferBalancePage.js#L109
Because it's undefined in PaymentUtils.formatPaymentMethods:

Uh hmm,
https://github.com/Expensify/App/blob/a2f6349e41eed50344708be04328be1d58be019a/src/pages/settings/Payments/TransferBalancePage.js#L109-L112
We are not passing it here

Pushed a change to fix this here. Gonna re-test myself (last time I checked I had no issues accessing).

Hmm, I'm really confused why this is not working all of a sudden... the data is there

I have a feeling this is related to the IndexedDB change...

Ok it took me way too long to figure out that we need to pass a paypal me name to the formatPaymentMethods() method 😂
The SvgChase() error + propTypes were unrelated, but also fixing them here to avoid future confusion.

Updated.

Updated.

The Transfer Balance page is working fine now :D but for some reason I'm stuck in step 5; the button Instant (Debit Card) is selected but the Transfer button is disabled also I can't select the other option 1-3 Business Days (Bank Account)
https://user-images.githubusercontent.com/6829422/150391870-f3704cae-e640-4c04-afbc-d14e1c1d9266.mov

for some reason I'm stuck in step 5; the button Instant (Debit Card) is selected but the Transfer button is disabled also I can't select the other option 1-3 Business Days (Bank Account)

Which step 5? The QA for this PR is to just make sure you can get to the "Transfer Balance" page and looks like you were able to do it :)

I'll add some pics to show what I'm looking for here.

Just tested the flow again and added screenshots. @marcochavezf let me know if everything looks good to you!

Oh I see, thanks! I was using an account that was skipping the "Verify identity" step

:hand: This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.

🚀 Deployed to staging by @stitesExpensify in version: 1.1.31-2 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅

@marcaaron @marcochavezf @nickmurray47 @stitesExpensify This PR is ready to QA internally

Thanks, there is an issue where we can't access the production API so we will need to test this on production. This feature is still behind a beta so we can check this off I think.
https://github.com/Expensify/App/issues/7371

🚀 Deployed to production by @AndrewGable in version: 1.1.32-0 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅


n % m is always != 0 except for nm

n % m is always != 0 except for nm
to be correct according to the comment change "!=" into "=="
https://github.com/dashpay/dash/blob/e596762ca22d703a79c6880a9d3edb1c7c972fd3/src/pow.cpp#L142

impacts src/test/miner_tests.cpp if corrected

my bad review, influenced by bad comment near if statement, closed issue


preview not working

Error loading webview: Error: Could not register service worker: InvalidStateError: Failed to register a ServiceWorker: The document is in an invalid state..

The local IP address "" is not formatted correctly. Using default <IP_ADDRESS>.

Are you on a codespace or a different remote? or on desktop vscode locally?

I am on the local

@Swyom are you running into the issue from the first or second comment? The second comment is a duplicate of https://github.com/microsoft/vscode-livepreview/issues/588

I'm not able to operate live preview on my VS the thing is it's not shoeing it's logo

@anu034 see https://github.com/microsoft/vscode-livepreview/issues/680

i am unable to push command

i am unable to push command

what do you mean by pushing a command?

Yes

Yes

Sorry, I'm not sure I understand (?)


K8SPXC-342 mention that SmartUpdates with Latest and Recommended inst…

…all PXC 8.0 on new cluster

Basically for 5.7 from scratch you need to specify the version directly to SmartUpdate and then later change this to recommended or latest if you wish to have automatic upgrades turned on when the new version is released.


Add TLS server-side support

Add the ability to act as a TLS server. Accept key and secret as command-line parameters and add a new "secure port" option in both snapshot and change servers.
This work will likely happen in the "goscaffold" project so that we can use it later.

Added TLS to both servers with new parameters:
-sp for secure port number
-key for key file
-cert for cert file
The key has to be an unencrypted PEM file. Supporting all the key types and decrypting them is a lot of Go code right now.


Run WebStorm JSDoc inspection and fix all errors

Webstorm has an inspection titled JSDoc comment matches function signature which actually shows a lot of incorrect documentation throughout our codebase (115 warnings, though I'm sure some our false positives).  We should run this inspection and bring the result down to 0 (or some reasonable number if false positives are high).
To execute this, select Code -> Run Inspection by Name and then type JSDoc and it will show up.

If we plan to automate this, that can be a separate issue or part of #652

If we plan to automate this, that can be a separate issue or part of #652

Unfortunately this would be hard to automate (as it relies on webstorm), however when we finally switch to eslint, they have plugins for it.


Initial boot of Windows 2019 installation failed

I tried to create a Windows 2019 VM by running make build-windows-2019-virtualbox.
This created and started a VM, but it failed to boot with error message FATAL: Could not read from the boot medium! System halted..
I assume the reason is that the ISO images (VBoxGuestAdditions.iso and the installation disk) are added to the SATA Controller in the wrong order:

VBoxGuestAdditions.iso: port 14
installation disk: port 15
The VM tried to boot from the first iso image VBoxGuestAdditions.iso and failed.

Workaround
I used the following workaround:

Stop the VM (keeping the make command running)
Manually edit the VM in VirtualBox, swapping the SATA ports of the two iso images so that the installation iso comes first
Start the VM

Installation continued successfully.
Note
Using other SATA ports than 14 and 15 caused the installation to fail after 1:12h at the very end:
==> virtualbox-iso.windows-2019-amd64: Gracefully halting virtual machine...
    virtualbox-iso.windows-2019-amd64: Removing floppy drive...
==> virtualbox-iso.windows-2019-amd64: Error detaching ISO: VBoxManage error: VBoxManage: error: No storage device attached to device slot 0 on port 15 of controller 'SATA Controller'
==> virtualbox-iso.windows-2019-amd64: VBoxManage: error: Details: code VBOX_E_OBJECT_NOT_FOUND (0x80bb0001), component SessionMachine, interface IMachine, callee nsISupports
==> virtualbox-iso.windows-2019-amd64: VBoxManage: error: Context: "DetachDevice(Bstr(pszCtl).raw(), port, device)" at line 403 of file VBoxManageStorageController.cpp
==> virtualbox-iso.windows-2019-amd64: Error detaching ISO: VBoxManage error: VBoxManage: error: No storage device attached to device slot 0 on port 15 of controller 'SATA Controller'
==> virtualbox-iso.windows-2019-amd64: VBoxManage: error: Details: code VBOX_E_OBJECT_NOT_FOUND (0x80bb0001), component SessionMachine, interface IMachine, callee nsISupports
==> virtualbox-iso.windows-2019-amd64: VBoxManage: error: Context: "DetachDevice(Bstr(pszCtl).raw(), port, device)" at line 403 of file VBoxManageStorageController.cpp
==> virtualbox-iso.windows-2019-amd64: Step "StepRemoveDevices" failed, aborting...

Environment:

macOS 11.6
Vagrant 2.2.18
Packer 1.7.7
VirtualBox 6.1.26

A commit to the hashicorp/packer-plugin-virtualbox repo made on August 13th entitled Ensure boot ISO is attached on lowest numbered port, relative to other ISO may have fixed this. I was able to resolve the boot issue described in this issue by manually building and installing the latest version of the virtualbox plugin.

@kaklakariada were you able to make it work with the newer packer-plugin-virtualbox like @alpayne mentioned?

Hi @rgl,
Thank you for the reminder. I successfully ran make build-windows-2022-virtualbox with the following versions:

macOS 12.3
Vagrant 2.2.19
Packer 1.8.0
VirtualBox 6.1.32

I will close this issue.


Removed 1.21 jobs

Issue #, if available:
Description of changes:
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

/hold

/lgtm

/lgtm

/unhold
/approve


Leaking expressions

Something is causing the expression tree to grow to be much much larger than it aught to be.

Actually I think this is a duplicate of #15.

Actually I think this is a duplicate of #15.


Poor Soundcloud Artwork Quality

What version of Music Assistant has the issue?
2.0.6
What version of the Home Assistant Integration have you got installed?
2024.5.1
Have you tried everything in the Troubleshooting FAQ and reviewed the Open and Closed Issues and Discussions to resolve this yourself?

[X] Yes

The problem
Currently the app displays exceptionally blurry artwork with a 100x100px resolution. Images on the Soundcloud site look way cleaner. We should have bigger Images in Music Assistent as well.
eg.
https://i1.sndcdn.com/artworks-000166304222-fjxebe-large.jpg (returned from the Soundcloud API, displayed in MA)
https://i1.sndcdn.com/artworks-000166304222-fjxebe-t500x500.jpg (displayed on Soundcloud)
A quick look in the network requests on Soundcloud.com shows that the URL for the bigger image is not returned by the api but rather constructed with JS client code in the browser.
availableSizes: [[20, "t20x20"], [50, "t50x50"], [120, "t120x120"], [200, "t200x200"], [500, "t500x500"]],
availableVisualsSizes: [[1240, "t1240x260"], [2480, "t2480x520"]],
imageUrlRegex: /^.*\/(\w+)-([-a-zA-Z0-9]+)-([a-z0-9]+)\.(jpg|png|gif).*$/i,

How to reproduce
play Soundcloud track, look at artwork, be disgusted
Music Providers
Soundcloud
Player Providers
Upnp
Full log output
No response
Additional information
No response
What version of Home Assistant Core are your running
2024.6.2
What type of installation are you running?
Home Assistant OS
On what type of hardware are you running?
ODROID

The documentation for that call seems to have got lost a few years back, but a WaybackMachine capture of what it says is:

JPEG, PNG and GIF are accepted when uploading and will be encoded to multiple JPEGs in these formats:
t500x500: 500×500
crop: 400×400
t300x300: 300×300
large: 100×100 (default)
t67x67: 67×67 (only on artworks)
badge: 47×47
small: 32×32
tiny: 20×20 (on artworks)
tiny: 18×18 (on avatars)
mini: 16×16
The URL is pointing to the format large by default. If you want to use a different format you have to replace large with the specific format name in the image URL:
For example:
http://i1.sndcdn.com/avatars-000000011308-xq0whu-large.jpg?b17c165
to
http://i1.sndcdn.com/avatars-000000011308-xq0whu-crop.jpg?b17c165

I'll get a patch in for that after my current PR gets merged (don't want to have too many things on the go at the same time).

Cool, that the artwork is fixed! ❤ But the issue still persists for artist images:
Music Assistent

Soundcloud


Questions about VST ImGui implementation

Hi, Gustav!
I'm AnClark, trying to rewrite UI for Amsynth by Dear ImGui. Several days ago I discovered your NB-01 distortion processor in ImGui's gallery. It would be helpful for my future development, however it seems proprietary.
Here are some questions about NB-01 and this source tree:

To build NB-01, which VST API are you using? Official VST 2.4 SDK, or the free software vestige.h?
Once using MinGW-w64, it will automatically link against libwinpthread-1.dll. But in NB-01, no external thread lib will be required (checked via ldd in Msys2). So which compiler are you using? MSVC or Msys2 MinGW?

Hi AnClark and thanks for the interest.
NB-01 is closed source atm and I don't have any immediate plans to release it as open source, though it will remain freeware and I plan on providing updates and bugfixes in the future.
The Windows release of NB-01 is built with Visual Studio 2019, the linux release with GCC 10. I have built it with the official VST 2.4 sdk, not vestige.h (though that should be doable I think, but I have a license from Steinberg so don't need to). It shouldn't be too hard to port to VST3 either, as the editor part isn't very complex. Though the building and linking part might be more difficult.
NB01 doesn't actually use vstimgui per se, I built my own translation layer (kinda like JUCE, but very minimal) that vstimgui was sort of the prototype for, but the mechanism is essentially the same. And my intention is to update vstimgui with what I've learned since so it has essentially the same code as in NB-01. I've moved the reference counted initialization from glfw to the editor for instance.
I haven't put a license on vstimgui, but if I eventually do if it feels less like work in progress, it will be a permissive one, so feel free to use it for anything or copy code from it.

I haven't put a license on vstimgui, but if I eventually do if it feels less like work in progress, it will be a permissive one, so feel free to use it for anything or copy code from it.

Great! Vstimgui is really an essential to learn how to write a ImGui-based editor.
I'm continue implementing codes into Amsynth on Windows. And I've encountered in those issues.
Environment:

Windows 10
Msys2 MinGW-w64
vestige.h for VST implemention
REAPER as host

My codes:

ImGui editor class. I rewrote a class refered to vstimgui.
VST implementation

0x01 Too small embedded window
Finally ImGui can be embedded into REAPER's UI. However its size is too small (seems less than 200x100), no matter how I set sizes via different methods (via io.DisplaySize or glViewport).
What's more, when double-clicking REAPER's title bar, ImGui UI can be fully shown. But it will overlap REAPER's own UI elements.
0x02 Host window will lose focus
Normally, no matter how to interact with embedded editor, host window should still be in focus. But here when I click my editor, REAPER's FX window will automatically lost focus as if it's a totally external application. It would be terrible on production.
I wonder why it would happen.

0x02 Host window will lose focus

Solved via my modded GLFW.

You seem to have done quite a bit of progress, great! Reaper is probably the most challenging host out there in terms of plugin editor support. NB01 worked fine in all other hosts I tested, but most of the bugs reported came from Reaper users.
Of the tricks for Reaper was to call sizeWindow() in the idle call (Reapers gui thread apparently) and not in the editors draw thread. I added a timer so that that is called after the editor has finished setting up.
I haven't figured out exactly why the editor sometimes overlap Reapers own status bar, but my slightly hackish solution has been to call sizeWindow() twice, and first with an incorrect size (of by 1 pixel is enough). then with the correct size. That always seen to work for me. Though let me know if you figure something out as I believe most of the problems with Reaper and editor size/position is due to some race condition in how Reaper sets up the editor window.
Keyboard focus is a complicated thing I've realized. Does your trick for host window focus always work or does it only give focus back to the host when the editor is created? So that clicking in the editor again makes the editor take focus?
In NB01 I eventually changed it so that I don't even accept focus when the cursor enters the window. This required a change to the Imgui glfw frontend so that you accept mouse click even when you don't have focus though. But it means that keyboard events (start stop with space bar for instance) works while you're tweaking knobs in the editor. That gives an experience that more matches other plugins.
I tried various ways of having focus and passing keyboard events to the parent window, but couldn't make it work in a stable way.
You can have a look at the NB01_modifications branch here
https://github.com/noizebox/glfw

Hi AnClark, how's your progress been? The last week or so I've had some time to get back into the windowing issues. Thanks a lot for your glfw changes, I dunno why I wasn't able to create windows using the parent window directly and not re-parenting the plugin window after it has been created. Though with your branch it does work!
I was able to solve a few issues that showed up as well. One crash on Linux when closing the editor in Reaper (throwing a BadWindow error) was that glfw steals the x11 error handler and doesn't put it back. After not doing that, it seem to work. At least Reaper appears to handle it without crashing. Feel free to have a look at my glfw branch https://github.com/noizebox/glfw/tree/c8eb88448f7be0bfcc366096cd33d9ddcc5fa176
For windows, I found it best to actually call glfwDestroyWindow() in the same thread that calls close() on the editor, and not in the thread that created the window. Weird, but that seemed more stable. I haven't ported that bit to vstimgui yet, but planning on doing it when I have time.

Thanks a lot for your glfw changes, I dunno why I wasn't able to create windows using the parent window directly and not re-parenting the plugin window after it has been created. Though with your branch it does work!

My pleasure!
I've also asked Mr. Justin Frankel, the founder of Cockos and REAPER, for ideas of solving those issues. He gave me a lot of great advice. With his great help, everything works well. He also told me why GLFW crash in X11 (see commit 06ed4fd).
What's more, on my Windows, I always encounter some issues on embedded editor, such as UI misplacing. Mr. Frankel told me that I should effEditIdle to redraw editor instead of multi-thread.

Great, I see you also figured out the error handler issue on Linux.
Do you still get a good framerate from drawing in the effEditIdle callback.

Do you still get a good framerate from drawing in the effEditIdle callback.

It still hard for me to optimize. Mr. Frankel informed me that I can increase the "idle rate" on Windows (maybe via a Win32 API, but I cannot find what the API is). Usually the framerate can between 25fps ~ 28fps.
On Linux, the framerate could be faster than Windows. It could be up to 30fps on native format, while 25~28fps via Wine.
Currently they're enough for my project (my own fork of Amsynth).

That still sounds pretty good. I guess it you wan't a solid 60fps gui you would need to have a dedicated drawing thread.
I'm still keeping my drawing thread for now, maybe with an option to run it from the idle callback instead.

I found it best to actually call glfwDestroyWindow() in the same thread that calls close() on the editor, and not in the thread that created the window.

Does it mean you need to call glfwDestroyWindow() in the editor drawing thread? Maybe it would be helpful.
Now I'm using vestige.h instead of the official VST SDK. I'm not sure how those commercial products using official SDK handles UI drawing. (e.g. Memorymoon)

I found it best to actually call glfwDestroyWindow() in the same thread that calls close() on the editor, and not in the thread that created the window.

Does it mean you need to call glfwDestroyWindow() in the editor drawing thread? Maybe it would be helpful.
Now I'm using vestige.h instead of the official VST SDK. I'm not sure how those commercial products using official SDK handles UI drawing. (e.g. Memorymoon)

To my knowledge, everything build with Juce has its own thread for drawing and does not rely on effEditIdle being called. Otherwise I don't know how other commercial plugins handle it.
In the update to NB01 that I'm working on I'm calling glfwDestroyWindow() from the thread calling close_editor()  (I think that's opcode effEditClose), after joining the drawing thread. That seems more stable in Reaper, otherwise glfwDestroyWindow() could sometimes hang. For all other hosts, it didn't seem to matter. I haven't ported that part over to vstimgui yet, but planning on doing it.

I haven't ported that part over to vstimgui yet, but planning on doing it.

Great! Hope that those issues of drawing thread could be perfectly resolved.
No wonder Juce-based GUIs are smooth (for example, Helm).  Maybe effEditIdle is just a polyfill for me. I'll use effEditIdle first, and when I finish building my GUI, I'll turn to your solution.


Editing ReadME to address compatibility issues

Need to edit the ReadME file to address the compatibility issues for C++ version <11. It did not work for me initially since I was working on C++98. I believe it can be a useful addition.

@pranathibora14 That is right. Could you take a look and figure out the fix?

Sure. It's an easy fix. I'll do it.

Thanks for the help @pranathibora14. Closed the issue. 🥇


left sidebar: Update the @ sign alongside the "Mentions" label.

This PR replaces the font awesome @ icon with custom feather icon @ sign alongside "Mentions" label in the left sidebar.
Fixes part of #22816
CZO discussion for the change

Previous @ icon
Updated @ icon

Self-review checklist

[x] Self-reviewed the changes for clarity and maintainability
(variable names, code reuse, readability, etc.).

Communicate decisions, questions, and potential concerns.

[x] Explains differences from previous plans (e.g., issue description).
[x] Highlights technical choices and bugs encountered.
[ ] Calls out remaining decisions and concerns.
[ ] Automated tests verify logic where appropriate.

Individual commits are ready for review (see commit discipline).

[x] Each commit is a coherent idea.
[x] Commit message(s) explain reasoning and motivation for changes.

Completed manual review and testing of the following:

[x] Visual appearance of the changes.
[x] Responsiveness and internationalization.
[ ] Strings and tooltips.
[ ] End-to-end functionality of buttons, interactions and flows.
[ ] Corner cases, error conditions, and easily imagined bugs.

Okay. This PR needs a proper title, and your commit history needs to be cleaned up.

Okay. This PR needs a proper title, and your commit history needs to be cleaned up.

Thank you for the comment! I've updated the title. Could you please clarify what you mean by clearing up the commit history? Do I need to squash the commit messages into one? Or it's something else?

Okay @laiyingwong. Much improved commit and history here. It does seem like the icon is sitting too high relative to the Mentions text, though. I'm working on a rewrite of our layout of individual lines in the left sidebar, but I haven't gotten to these icons yet.

Why does the last commit switch to doing show/hide another way? The commit message would be a good place to explain that.
Can you also rebase this, confirm it doesn't have weird issues (like the @ location taking up space even when a message doesn't contain a mention), and address the CI failure?


DEV-1288 - add polygon

added polygon networks.
When I try to run yarn to install dependencies I'm getting
❯ yarn
yarn install v1.22.19
[1/4] 🔍  Resolving packages...
[2/4] 🚚  Fetching packages...
error An unexpected error occurred: "Commit hash required".
info If you think this is a bug, please open a bug report with the information provided in "/Users/georgepickett/otterspace/badges-subgraph/yarn-error.log".
info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.

added polygon networks.
When I try to run yarn to install dependencies I'm getting
❯ yarn
yarn install v1.22.19
[1/4] 🔍  Resolving packages...
[2/4] 🚚  Fetching packages...
error An unexpected error occurred: "Commit hash required".
info If you think this is a bug, please open a bug report with the information provided in "/Users/georgepickett/otterspace/badges-subgraph/yarn-error.log".
info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.

Not sure what happened to this build but I merged the dev branch to this and regenerate the yarn.lock file. It should be good now

@grp06 please see latest commit. Polygon network name in subgraph is actually called matic. I have deployed the subgraph here
https://thegraph.com/hosted-service/subgraph/otterspace-xyz/badges-polygon


OpenSSL failed to verify cms document

Hello, OpenSSL community,
I faced the problem and can't find any solution or explanation for this problem. I have built CMS file with Botan library tools, and my CMS document looks exactly the same as the document generated with openssl cms -sign command except for a signing time and the signature.
I have separately verified the signature with openssl command:
openssl dgst -sha256 -verify pub_key.pem -signature signature.txt signer_attributes.txt
And the output was: Verified OK
But I can't verify the CMS document itself with the command:
openssl cms -verify -CAfile ca_test.crt -inform der -signer cert.crt -in cms.p7b
I am getting error:
70288:error:04091068:rsa routines:int_rsa_verify:bad signature:../openssl-1.1.1l/crypto/rsa/rsa_sign.c:220:
70288:error:2E09809E:CMS routines:CMS_SignerInfo_verify:verification failure:../openssl-1.1.1l/crypto/cms/cms_sd.c:767:

ssl version is 1.1.1
Thank you in advance for any help!

The version 1.1.1 is not supported anymore. Closing. If this is still an issue with currently supported releases, please open a new issue.


Update stable version in repo from 1.0.0 to 1.0.1

Think about update stable version to 1.0.1
Version: stable=1.0.0 (34 days old) => latest=1.0.1 (30 days old)
Installs: stable=98 (45.58%), latest=60 (27.91%), total=215
Click to edit

A kind reminder.
Is there any reason to delay an update of stable revision?
Feel free to drop a simple note if I should trigger an update.

@Omega236
Is there any reason to delay updating stable any longer?
Please drop a commit if you know any reason to refrain from updating.
If there is no response within the next 30 days, we could decide to update anyway.

This issue seems to be outdated.
This issue suggests to update the stable version of this adapter to 1.0.1 but the current stable version is already 1.0.1.
So this issue should be closed.


Client Allocation Request for: snth

Client Allocation Questions
Core Information

Name: snth
Website / Social Media: snth, (snth, snth)
Region: North America
DataCap Requested: 320 GiB
Addresses to be Notarized: snth
Notary Requested: Irene Young

This user’s identity has been verified through filplus.storage


Parser should allow binary literals

They aren't explicitly supported by the Apache compiler, but I don't think they're disallowed, either.  They'd be neat.  Let's suppose that they should be hex strings.
The change would need to be in the ANTLR grammar first, then in the validation logic in Constant.kt.

This feature would allow the following Thrift syntax:
struct Example {
  1: binary SomeBinary = "0xDEADBEEF"
}

I don't have any experience with ANTLR grammar yet but I would gladly give this a go if it's okay :)

Please, go ahead!


vue-core module and coverage

Following the refactoring of vue-core module by @DamnClin, there are some missing configurations, as these code should be ignored, and not be included in coverage, if we decide it's an implementation details

Links:

https://sonarcloud.io/summary/overall?id=jhipster_jhipster-lite-sample-app
https://sonarcloud.io/component_measures?id=jhipster_jhipster-lite-sample-app&metric=coverage&view=list

See

maybe similar to https://github.com/jhipster/jhipster-lite/issues/10752 ?


Gift card details:Consistent language needed

Consistent language needed across.

On top it should say, " Gift sats details"
Status should be" Gift created", "Gift sent" etc.
Button text: "Send Gift sats"

This has already been addresses here: https://github.com/bithyve/hexa/issues/4772

Verified this issue on staging app v2.0.5(382)
Duplicate of #4772


Ship Leaves While Players Are Alive

Describe the bug
The ship leaves while one player is still alive, leaving them stranded. The end player death count is one higher than the number of players in the lobby.
To Reproduce
Steps to reproduce the behavior:

Start a game with at least one other player.
Have all but one player die, leaving one survivor.
Ship will state that everyone is dead, then leave the survivor stranded.

Expected behavior
Ship stays when at least one player is alive and it is not past midnight.
Additional context
Tested with the bigger lobby mod. Have not tested without that mod.

#6


returned non-zero exit status<PHONE_NUMBER>

I got this problem when I use it:
(bitnet-cpp) C:\Users\m.rahamneh\Desktop\GP\BitNet>python setup_env.py --hf-repo HF1BitLLM/Llama3-8B-1.58-100B-tokens -q i2_s
INFO:root:Compiling the code using CMake.
INFO:root:Downloading model HF1BitLLM/Llama3-8B-1.58-100B-tokens from HuggingFace to models\Llama3-8B-1.58-100B-tokens...
INFO:root:Converting HF model to GGUF format...
INFO:root:GGUF model saved at models\Llama3-8B-1.58-100B-tokens\ggml-model-i2_s.gguf

(bitnet-cpp) C:\Users\m.rahamneh\Desktop\GP\BitNet>python run_inference.py -m models/Llama3-8B-1.58-100B-tokens/ggml-model-i2_s.gguf -p "Daniel went back to the the the garden. Mary travelled to the kitchen. Sandra journeyed to the kitchen. Sandra went to the hallway. John went to the bedroom. Mary went back to the garden. Where is Mary?\nAnswer:" -n 6 -temp 0
warning: not compiled with GPU offload support, --gpu-layers option will be ignored
warning: see main README.md for information on enabling GPU BLAS support
Error occurred while running command: Command '['build\\bin\\Release\\llama-cli.exe', '-m', 'models/Llama3-8B-1.58-100B-tokens/ggml-model-i2_s.gguf', '-n', '6', '-t', '2', '-p', 'Daniel went back to the the the garden. Mary travelled to the kitchen. Sandra journeyed to the kitchen. Sandra went to the hallway. John went to the bedroom. Mary went back to the garden. Where is Mary?\\nAnswer:', '-ngl', '0', '-c', '2048', '--temp', '0.0', '-b', '1']' returned non-zero exit status<PHONE_NUMBER>.

have you installed MS-Build Support for LLVM-Toolset (clang)? You can search "clang" in the picture you shared and try it again.

@sd983527 Yes, it's already installed.
maybe because my OS is Windows Server or because I used AMD processor?
because I tried it on another PC (Intel i7, win11) and it's work.

Hi. Pls help. I have Windows 11 as above image, Visual Studio 2022 with the optional installations shown above, yet the command "python setup_env.py -md models/Llama3-8B-1.58-100B-tokens -q i2_s" ends with the output below... and the "logs\convert_to_f32_gguf.log" has nothing informative about the error...
INFO:root:Compiling the code using CMake.
INFO:root:Loading model from directory models/Llama3-8B-1.58-100B-tokens.
INFO:root:Converting HF model to GGUF format...
ERROR:root:Error occurred while running command: Command '['C:\Users\edindi\AppData\Local\Programs\Python\Python312\python.exe', 'utils/convert-hf-to-gguf-bitnet.py', 'models/Llama3-8B-1.58-100B-tokens', '--outtype', 'f32']' returned non-zero exit status<PHONE_NUMBER>., check details in logs\convert_to_f32_gguf.log

The issue may be caused by out of RAM issue since in the converting stage, it requires much more memory than actually inference stage. I'd suggest you to test with the 700mb model on this machine. Or you may just convert the model file in another machine with larger memory.

The issue may be caused by out of RAM issue since in the converting stage, it requires much more memory than actually inference stage. I'd suggest you to test with the 700mb model on this machine. Or you may just convert the model file in another machine with larger memory.

Let me try a few things in the light of this. I'll revert back. Thanks.

The issue may be caused by out of RAM issue since in the converting stage, it requires much more memory than actually inference stage. I'd suggest you to test with the 700mb model on this machine. Or you may just convert the model file in another machine with larger memory.

Let me try a few things in the light of this. I'll revert back. Thanks.

Same error code with 16GB RAM , it can be repeat and once accidently reboot caused by python.exe..., unbelievable!


Examples in README does not works

I tried examples in README, but they caused error and cannot process images.
example in Usage section,
require('hologram').add_image(0, img_path, 0, 0)
→ E5108: Error executing lua [string ":lua"]:1: attempt to call field 'add_image' (a nil value)
example in image.lua API section,
require('hologram.image'):new({ source = img_path, row = 0, col = 0, })
→ E5113: Error while calling lua chunk: ...config/nvim/plugged/hologram.nvim/lua/hologram/image.lua:32: Image source is not a valid string

You should try doing require('hologram').setup() before executing the example code, it should work

You should try doing require('hologram').setup() before executing the example code, it should work

It still raises same error 😢

In GIF above,

start Neovim by this setting (using vim-plug):

call plug#begin(stdpath('config') .. '/plugged')
Plug 'edluffy/hologram.nvim'
call plug#end()

lua require('hologram').setup({})

check hologram.nvim is loaded by :PlugStatus

run require('hologram').add_image(0, '~/hologram-test/sample.png', 0, 0), then ↓

E5108: Error executing lua [string ":lua"]:1: attempt to call field 'add_image' (a nil value)
stack traceback:
        [string ":lua"]:1: in main chunk

The README document seems a little outdated (quite different from the main branch).
Currently, the following code works for me.
function Test()
    local Image = require('hologram.image')
    local source = '/home/user/Pictures/unknown.png'
    local img = Image:new(source, {})
    local buf = vim.api.nvim_get_current_buf()
    img:display(1, 1, buf, {})
end

BTW the autocmd of automatic displaying images in a markdown file is working correctly, just add the auto_display = true option.
require('hologram').setup { auto_display = true }

You'll need to launch neovim in a terminal emulator like kitty, as the README mentioned that hologram.nvim only supports Kitty Graphics Protocol at present.

Thank you for detailed answer, but the code does not work for me... 😭

In GIF above,

start Neovim by this setting (function HologramTest is from @OmeletWithoutEgg 's answer, sample.png is my icon):

call plug#begin(stdpath('config') .. '/plugged')
Plug 'edluffy/hologram.nvim'
call plug#end()

lua << EOF
require('hologram').setup({auto_display = true})
function HologramTest()
  local Image = require('hologram.image')
  local source = vim.fn.expand('~/hologram-test/sample.png')
  local img = Image:new(source, {})
  local buf = vim.api.nvim_get_current_buf()
  img:display(1, 1, buf, {})
end
EOF

run :lua HologramTest() → image is not displayed
open markdown file that contains ![img](./sample.png) → image is not displayed, cursor flickers after entered visual mode

I'm using:
❯ kitty --version
kitty 0.25.2 created by Kovid Goyal

❯ nvim --version
NVIM v0.8.0-dev-853-g9a3877ff9
Build type: Release
LuaJIT 2.1.0-beta3
Compiled by kawarimidoll@kawarimidoll-mba

Features: +acl +iconv +tui
See ":help feature-compile"

      システム vimrc: "$VIM/sysinit.vim"
       省略時の $VIM: "/opt/homebrew/Cellar/neovim/HEAD-9a3877f_1/share/nvim"

Run :checkhealth for more info

@OmeletWithoutEgg This is correct - after adding inline image display I must have forgotten to change the example in the README - I have updated the docs now.
@kawarimidoll If I am correct in thinking this is an issue with macOS (just tested using a mac now and it seems to be) then the latest commit should fix your problem.

@edluffy The latest example in README shows image but that is narrow than I expected.

source image is square ↓

Image should be full size with latest commit now. Although there might still be some scaling issues when scrolling...

The problem is fixed, nice work 🥰
Thank you!


Assignment operator is used in filter instead of equality operator

I believe the line
row = dataset.filter(dataset.row_id = 'xxxx').rdd.first()
should instead use the equality operator like below
row = dataset.filter(dataset.row_id == 'xxxx').rdd.first()

Just added this fix to my PR where I'm messing around with the readme anyhow.


New beta release v2

Playable cards highlighting + spectator 'bug' fix

Going to leave this to be merged in the morning in case anything goes a bit wobbly


tickless mode: allow scheduling timer to stop when not needed

When NuttX is configure in tickless mode, the scheduling timer will continue to run even when there is a single task and no timeouts are pending. This means that unless the processor goes to sleep (thus disabling the timer), in some cases this interrupt can unnecessarily burden de processor which may be important in very low power applications.
This scheduling timer is currently triggered due to a "hack" which is documented as:

/* In the original design, it was planned that nxsched_reassess_timer() be
 * called whenever there was a change at the head of the ready-to-run
 * list.  That call was intended to establish a new time-slice or to
 * stop an old time-slice timer.  However, it turns out that that
 * solution is too fragile:  The system is too vulnerable at the time
 * that the ready-to-run list is modified in order to muck with timers.
 *
 * The kludge/work-around is simple to keep the timer running all of the
 * time with an interval of no more than the timeslice interval.  If we
 * do this, then there is really no need to do anything when on context
 * switches.
 */

#define KEEP_ALIVE_HACK 1

Some extra explanation from Greg:

Use of almost all internal OS interfaces require that the OS data structures always be in the correct state. During a context switch that internal state for one task is torn down and the new state for the news task is set up. In between those times, the OS is in an indeterminate state and the use of any OS internal interface (such as the timer interface) may not be reliable.

I don't recall the specific issue that I faced when I wrote that comment, but I do remember that there was no simple work-around. It is, however, certainly worth revisiting if someone is motivated to really dig into the guts of the OS.

This only applies to round robin scheduling, correct?  Changing this could be quite complex in the SMP case.

I have really no idea, my understanding of this part of NuttX is very limited.

This only applies to round robin scheduling, correct? Changing this could be quite complex in the SMP case.
Is it a work around to (1) make sure that all tasks have a unique priority, and (2) disable round robin scheduling?

Yes, KEEP_ALIVE_HACK only applies if round robin or sporadic scheduling is enabled.  See sched/sched/sched_timerexpiration.c
This issue is, as I recall, not that the timer is needed all of the time.  The issue is that the timer cannot be started when a a new round robin task is started.  The work around to avoid having to start the time is just to never stop it.
So the only real fix would be to improve the logic that starts the timer when a new round robin (or sporadic) task is started.

I have really no idea, my understanding of this part of NuttX is very limited.

And my memory is very limited.  People think that because I wrote most of this code (at least originally), I should understand it all.  That KEEP_ALIVE_HACK was added way back in 2014 with this commit:
commit 6546fa39c7a292e919d1ea396d67bea8242f2c4b
Author: Gregory Nutt<EMAIL_ADDRESS>Date:   Tue Aug 12 11:12:00 2014 -0600

    Tickless Stuff:  Back out the risky timer operations when the ready-to-run list is modified.
    That is unsafe.  An ugly workaround is just to keep an interval timer going all of the time
    with a minimum duration equal to the timeslice interval.

That was after some attempts to use the timer interfaces in that context.  That commit is a good reference because it shows some of the non-viable code that was removed.  Commit 0d71260bf2d which added Sporadic support brought that KEEP_ALIVE_HACK logic to its current state.

hi @patacongo I'm at a point where I would like to try to deal with the recurring interrupt of the RR scheduler in tickless mode. While the above discussed issue applies to any situation when no ready tasks are available (and thus the scheduler interrupts could be stopped until one becomes ready), I'm interested in the particular case of not having these interrupts fire while system is sleeping (entered with WFI). I'm thinking that since NuttX is not running in this case, I should be able to disable the scheduler altogether, and re-enable it when waking up. I imagine this should involve removing the periodic alarm and being reset when scheduler starts again, right? Is this implemented?
I found nxsched_suspend_scheduler but it does not seem to do anything for the RR case. Maybe this is not really what I think it is.
@xiaoxiang781216 do you have any insight into this? I think you did a lot of SMP stuff and imagine you understand the scheduler much better than me.

Note that I'm not suggesting to deal with the original issue directly (which would be the most correct way to do it) mostly because I don't feel confident about doing it (wouldn't even know where to start)

Looking at nxsched_reasses_timer makes me think I could do something like:
nxsched_cancel_timer()
wfi
nxsched_timer_start(MSEC2TICK(CONFIG_RR_INTERVAL));

Does this make sense?


feat:Added param for setting label font size

Added a new var to expose the label size and updated the readme to reflect the change.

Thanks for your PR


Add plugin support to loose parser

In response to #339. Adds the same plugin support to the loose parser as for the main acorn parser.
As a side note, the Eclipse CDT project implementing Qt requires that the loose parser be implemented for similar reasons to @angelozerr. We're trying to parse QML using acorn with promising results, but need to modify the loose parser so that we can perform static analysis properly with tern, which is where this pull request comes in.  :)

@MattBastien glad you need this feature too. I have hacked acorn to support loose parsing for typescript. Hope this PR will be accepted!

Looks good, but could you add a note to the README about it too?

@RReverser I know it's an hard task, but it should very fantastic if you could use this improvement to support JSX with loose parser https://github.com/RReverser/acorn-jsx/issues/32#issuecomment-149501274

@angelozerr  We are definitely planning on using tern.java for this.  Once we have our parser working with tern we were going to look into that.

@marijnh I've added the lines to the readme.  My IDE seems to have killed some trailing whitespace on  line 4, but I imagine that's not an issue.

Well, yes, trailing space is significant in Markdown. I've added it back. Merged as 02c40e6d43f1 and 848b7d4abbb99

@angelozerr Problem is not API, but JSX semantics which make it pretty confusing on how to restore code.

We are definitely planning on using tern.java for this.

@MattBastien Very cool news for tern.java. Don't hesitat eto contact me to integrate acorn-qml inside tern.java which provides an Eclipse extension point for that.

Problem is not API, but JSX semantics which make it pretty confusing on how to restore code.

@RReverser yes I have understood that. It seems that TypeScript supports now JSX, perhaps you could study how to they have supported that?


force_download argument for load_experiment()

Description of changes:
Adding a force_download argument for syne_tune.experiments.load_experiment(...) function that allows to redownload the results of the experiment if they were change since the last time this function was called and the results were cached locally.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Sorry for the long ping, there is a conflict that would prevent the merge, could you took a look?
Overall, LGTM.

I am closing this PR since it has been opened for a while but would require resolving merge conflict, feel free to reopen when you have the time!


Adds support for displaying text labels on POH portals.

For https://github.com/runelite/runelite/issues/12686

Also i dont think that you shoudl hardcode the names, you should be able to get the original portal id via the existing api most likely


Added relx/concrete to oc_bifrost

Hi. I am an automated pull request bot named Curry. There are commits in this pull request whose authors are not yet authorized to contribute to Chef Software, Inc. projects or are using a non-GitHub verified email address. To become authorized to contribute, you will need to sign the Contributor License Agreement (CLA) as an individual or on behalf of your company. You can read more on Chef's blog.
GitHub Users Who Are Not Authorized To Contribute
The following GitHub users do not appear to have signed a CLA:

@joedevivo

Please sign the CLA here.

:+1:
You ever gonna sign that CLA? :D

Hi. Your friendly Curry bot here. Just letting you know that all commit authors have become authorized to contribute. I have added the "Signed CLA" label to this issue so it can easily be found in the future.

dialyzing now


remove actor-classes template, as it doesn't exist

to avoid file not found errors in js console

Thanks but this is already done in the develop branch


Remove stack driver from Prometheus proxy

Please provide a description for what this PR is for: based on the review comments in https://github.com/istio/istio/pull/21050, stack driver is removed from Prometheus proxy. This PR is to apply the same change to the master branch.
[ ] Configuration Infrastructure
[ ] Docs
[ ] Installation
[ ] Networking
[ ] Performance and Scalability
[X ] Policies and Telemetry
[X ] Security
[ ] Test and Release
[ ] User Experience
[ ] Developer Infrastructure

@lei-tang: The following test failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

integ-istioio-k8s-tests_istio
6a797342f772a36cf091876c4bf5125a1cd342f7
link
/test integ-istioio-k8s-tests_istio

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

/test integ-istioio-k8s-tests_istio


Create new branch "patch/content/primary"

Create new branch "patch/content/primary" based on branch "feature/body"

Done.


The difference between original paper and released ckpt

Dear author,
Thanks for your wonderful work. I am following your repo to build a 3D detection framework. Do you mind telling me the difference between the results of original paper and released ckpt (especially on the test set) . And what causes the performance gap between them?

Hi, one difference is: we modify the model to predict variance rather than std. So we avoid the square and square root operation in equation (3). We find that this modification can lead to more stable results because the numerical range is small. Other things include tricks are equal.
Except that, it also exists a performance jitter between different chkps.

Got it. Thanks for your reply.


SmirnoffFrosst validation error

Currently, smirnoffFrosst forcefields can not be used in production as they fail validation due to the capitalization in their name.

I think this is best solved by a small toolkit change related to loading smirnoff99Frosst force fields https://github.com/openforcefield/openff-toolkit/issues/815.

I think this is best solved by a small toolkit change related to loading smirnoff99Frosst force fields https://github.com/openforcefield/openff-toolkit/issues/815.

This should now be fixed by https://github.com/openforcefield/openff-toolkit/pull/816https://github.com/openforcefield/openff-toolkit/pull/816

This should now be fixed by https://github.com/openforcefield/openff-toolkit/pull/816https://github.com/openforcefield/openff-toolkit/pull/816


Pusher error with bitstamp

I added my api key and secret to the conf.js and executed this:

zenbot trade --paper  bitstamp.XRP-EUR

This shows the following error:

Pusher : You should always specify a cluster when connecting. See: https://pusher.com/docs/javascript_quick_start
Pusher : You should always specify a cluster when connecting. See: https://pusher.com/docs/javascript_quick_start
fetching pre-roll data:
Pusher : You should always specify a cluster when connecting. See: https://pusher.com/docs/javascript_quick_start
Pusher : You should always specify a cluster when connecting. See: https://pusher.com/docs/javascript_quick_start
cannot backfill bitstamp.BTC-EUR: exchange does not offer historical data

It looks like you are using a configuration for the notification feature that is missing a property "app_cluster". Also: The exchange you are using does not support historical data as it seems.

Dear issue reporter,
We have slightly changed our github issue policy and would now kindly request folks that have questions that they ask them in our zenbot subreddit.
You can find it here: https://reddit.com/r/zenbot
This issue will be closed, but if you disagree with your ticket being marked as a question feel free to leave a comment defending your case.
Thanks for contributing time and effort!
Greetings,
🤖


Installation and build failures

I'm trying to install the package with
ember install ember-cli-notifications
But i'm getting an error
The 'ember generate' command requires an entity name to be specified.
If i install via NPM i get a build fail with the error.
File not found: \addon.sass
I see that the file is actually named .scss not .sass.

We're seeing the same issue (Ember-CLI-Notifications, version 1.2.1).  We were seeing the same issue with version 1.1.1, so it almost seems to indicate a different issue (either with our config or with dependencies for this package) ...

Clarification:

we are seeing the same issue

The issue we're seeing is File not found: \addon.sass on an install that was working previously.
Confirmed however that the 'ember generate' command requires error is coming up on a clean Ember-CLI install with Ember CLI 0.2.3.
We seem to need to run ember generate ember-cli-notifications but doing so doesn't fix issues on my end.

I'm having a look into this now but from what you mention @Kilowhisky it looks like this is related to an open Ember-Cli bug https://github.com/ember-cli/ember-cli/pull/3846

I've been using ember-cli-notifications in a project, and after upgrading Ember CLI i receive File not found: \addon.sass.
My app will no longer start, please help.

The Sass build issues are fixed in v1.2.3.
Closing this as other the install issue is related to https://github.com/ember-cli/ember-cli/pull/3846.


Assets writer (ROS map) urdf typo fix

The ROS map assets writer launch file can now find the default urdf file when no argument is provided.

@wally-the-cartographer merge

Merge requested by authorized user cschuet. Merge queue now has a length of 1.


Remove WORKSPACE support from Bazel builds

Description
As Mozc has already migrated to bzlmod from WORKSPACE in #1002, let's remove obsolete and unmaintained WORKSPACE-related files and configs to make it clear that WORKSPACE is no longer supported to build Mozc with Bazel.
Closes #1115.
Issue IDs

https://github.com/google/mozc/issues/1115

Steps to test new behaviors (if any)
A clear and concise description about how to verify new behaviors (if any).

OS: All
Steps:

Build Mozc with Bazel
The build succeeds.

We have merged your PR.
Thank you for the contribution!