AttributeError exception during find_changes execution - str has no attribute code

Description of issue:
I execute monkey find_changes and after retrieving at least some information it throws this exception:
2018-03-08 11:11:18,988 DEBUG: Adding issue: gcsbucket/EUROPE-WEST1/username/bucketname
	OWNERS max exceeded in bucket ACL. -- None [in /usr/local/src/security_monkey/security_monkey/auditor.py:636]
Traceback (most recent call last):
  File "/usr/local/src/security_monkey/venv/bin/monkey", line 11, in <module>
    load_entry_point('security-monkey', 'console_scripts', 'monkey')()
  File "/usr/local/src/security_monkey/security_monkey/manage.py", line 786, in main
    manager.run()
  File "/usr/local/src/security_monkey/venv/lib/python2.7/site-packages/Flask_Script-0.6.3-py2.7.egg/flask_script/__init__.py", line 397, in run
    result = self.handle(sys.argv[0], sys.argv[1:])
  File "/usr/local/src/security_monkey/venv/lib/python2.7/site-packages/Flask_Script-0.6.3-py2.7.egg/flask_script/__init__.py", line 376, in handle
    return handle(app, *positional_args, **kwargs)
  File "/usr/local/src/security_monkey/venv/lib/python2.7/site-packages/Flask_Script-0.6.3-py2.7.egg/flask_script/commands.py", line 145, in handle
    return self.run(*args, **kwargs)
  File "/usr/local/src/security_monkey/security_monkey/manage.py", line 91, in find_changes
    manual_run_change_finder(account_names, monitor_names)
  File "/usr/local/src/security_monkey/security_monkey/task_scheduler/tasks.py", line 183, in manual_run_change_finder
    find_changes(account, tech)
  File "/usr/local/src/security_monkey/security_monkey/task_scheduler/tasks.py", line 216, in find_changes
    audit_changes([account_name], [monitor_name], False, debug)
  File "/usr/local/src/security_monkey/security_monkey/task_scheduler/tasks.py", line 240, in audit_changes
    _audit_changes(account, monitor.auditors, send_report, debug)
  File "/usr/local/src/security_monkey/security_monkey/task_scheduler/tasks.py", line 292, in _audit_changes
    au.audit_objects()
  File "/usr/local/src/security_monkey/security_monkey/auditor.py", line 673, in audit_objects
    method(item)
  File "/usr/local/src/security_monkey/security_monkey/auditors/gcp/gcs/bucket.py", line 165, in check_default_object_acl
    process_issues(self, ok, errors, item)
  File "/usr/local/src/security_monkey/security_monkey/auditors/gcp/util.py", line 43, in process_issues
    sev = auditor.gcp_config.ISSUE_MAP[issue.code]['score']
AttributeError: 'str' object has no attribute 'code'

I'm wondering if this is the issue: https://github.com/Netflix/security_monkey/blob/d1a13649f74c03f466a1097aa725ac5ac028a00e/security_monkey/auditors/gcp/gcs/bucket.py#L134
That returns a list with a string. So it's assuming the string is an object and failing.

The solution is probably doing something like this:
https://github.com/Netflix/security_monkey/blob/d1a13649f74c03f466a1097aa725ac5ac028a00e/security_monkey/auditors/gcp/gcs/bucket.py#L91-L92


Problem with BigDecimal serialization

It looks like serialization of BigDecimal fields is corrupted. Since BigDecimal, for not inflated values, stores its value in transient field, it is not serialized when added to objectMapper. Is it possible to somehow add custom serialization of particular types or rather we should define field in class with different type?

In the case of BigDecimal, I think it makes the most sense to define the data as fields in a separate type, then add whatever logic is necessary to interpret these values on the consumer.
Assuming you can apply knowledge about the possible range of values for you use case, doing things this way may allow you to be more efficient than you would otherwise be if you tried to verbatim serialize the data contained in BigDecimal.

Thanks for clarification.


self._connection.setTimeout is not a function

Hi. From time to time I receive unhandled error when using this module:
TypeError: self._connection.setTimeout is not a function                                                                                at /home/node_modules/steam-client/lib/cm_client.js:175:21                                                                                at ClientRequest.<anonymous> (/home/node_modules/steam-client/lib/tcp_connection.js:76:4)                                                                                at emitThree (events.js:136:13)                                                                                at ClientRequest.emit (events.js:217:7)                                                                                at Socket.socketOnData (_http_client.js:472:11)                                                                                at emitOne (events.js:116:13)                                                                                at Socket.emit (events.js:211:7)                                                                                at addChunk (_stream_readable.js:263:12)                                                                                at readableAddChunk (_stream_readable.js:250:11)                                                                                at Socket.Readable.push (_stream_readable.js:208:10)
Any idea how to fix it?

Are you calling CMClient.connect more than once in short timespan by any chance?
After a few hours of thinking I came up with only one possible reason and managed to replicate it.
Using this minimal implementation of CMClient and TCPConnection I managed to reproduce the error with following code:
const httpProxy = 'http://<IP_ADDRESS>';
const server = { host: '<IP_ADDRESS>', port: 27018 }; // Steam server

const client = new Client();
client.connect(server, httpProxy); // The error comes from THIS call
client.connect(server, httpProxy); // But it's reason is `_connection` created here

Result:
TypeError: this._connection.setTimeout is not a function
    at _connection.connect (Z:\X\polygon\proxyRequest.js:55:22)

Important bit is that client.connect() calls doesn't have to be next to each other, there may be delay, max length of which seems to depend on response time.
Problem
It is happening, because we're overridding client._connection property when calling client.connect().
The request adds connection.setTimeout to itself after connecting, then invokes callback. callback calls client._connection.setTimeout, but client._connection may be already overridden by 2nd call.
Solution
client.connect() already calls client.disconnect() in case there's a connection, but it doesn't affect pending ones.
The solution would be to keep request object from client.connect() (https://github.com/DoctorMcKay/node-steam-client/blob/master/lib/tcp_connection.js#L56) and call request.abort() whenever new connection is created. Probably connection.end() is the most appropriate place for that.

I have interval set to 15 seconds where im checking if bot isLogged:
return this.user.publicIP && this.client.loggedOn && this.community.steamID && this.manager.apiKey;
If it's return false i logout:
this.community.stopConfirmationChecker(); this.user.logOff();
and relogin:
this.user.logOn({...})

I don't have much expirience with node's HTTP module, so on first glance req.setTimeout(5000) indicated that request will be aborted if not answered within 5000ms, yet tests shown that's not the case.
With <IP_ADDRESS> proxy address, I got ETIMEOUT after 21s:
callback: 21005.935ms

Error: connect ETIMEDOUT <IP_ADDRESS>:80
    at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1174:14)

I'm pretty sure 15 second interval/timeout may lead to behavior described in my comment above.


9694 Fix missing ITelemetryContext layer

For more information about how to contribute to this repo, visit this page.
For specific guidelines for Pull Requests in this repo, visit this wiki page.
Description
There is a missing layer where the ITelemetryContext object gets passed through. This was discovered after looking at telemetry and noticing all the events contained empty data.
See https://github.com/microsoft/FluidFramework/pull/10294

I'd suggest adding unit tests that either validate that proper logging happens (i.e. plug in at the highest level - logger passed to container) , or more targeted test that invokes summary and passes mock of context object and validates that it is being called.

Should this go into main instead?


Ethernet encapsulation required for LSO/RSC?

Miniport adapters must support Ethernet encapsulation for all of the types of task offload that they support. The other types of encapsulation are optional.

This snippet suggests that the driver must also be functioning at an Ethernet layer, to make use of any task offloads, even those for transport protocols. Is this the case?
Other docs hint at this, e.g. NDIS_OFFLOAD struct docs. Can a miniport driver/adapter operating with a media type of NdisMediumIP leverage transport layer task offloads such as LSO/RSC?

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

ID: f26b5e10-4d40-1ebe-6b49-4548149d08d3
Version Independent ID: f6010cdb-5f01-8c40-b47f-b6fc055b4f61
Content: OID_TCP_OFFLOAD_CURRENT_CONFIG - Windows drivers
Content Source: windows-driver-docs-pr/network/oid-tcp-offload-current-config.md
Product: windows-hardware
Technology: network
GitHub Login: @aviviano
Microsoft Alias: amvivian

Hi @jwhited,
Thanks for opening this issue. Here is the response from the development team:
The documentation is correct – miniport adapters must support ethernet encapsulation to support task offload.
TCPIP expects the encapsulation type to be either NDIS_ENCAPSULATION_IEEE_802_3 or NDIS_ENCAPSULATION_IEEE_LLC_SNAP_ROUTED for offloads to be enabled. I don’t believe either of these apply for raw IP packets.
Do you have any further questions?

Hi @jwhited, Thanks for opening this issue. Here is the response from the development team: The documentation is correct – miniport adapters must support ethernet encapsulation to support task offload.
TCPIP expects the encapsulation type to be either NDIS_ENCAPSULATION_IEEE_802_3 or NDIS_ENCAPSULATION_IEEE_LLC_SNAP_ROUTED for offloads to be enabled. I don’t believe either of these apply for raw IP packets.
Do you have any further questions?

No, thank you.


Converting FP16 ONNX model to TOSA MLIR?

Hi,
Does this project support exporting FP16 models to TOSA dialect? I am assuming from the isTOSAFloat implementation here https://github.com/onnx/onnx-mlir/blob/main/src/Conversion/ONNXToTOSA/ONNXToTOSACommon.hpp#L49 that FP16 is supported?
Any pointers for exporting FP16 onnx models is appreciated.
-Hashim

Hey @hashimSharif,
I think the TOSA export path isn't fully implemented. If I am not mistaken there is only really a a skeleton for an implementation.
I don't think there is a lot of active work on the TOSA path at the moment.

Yes, please let  us know if there is further interest in this path, or if maybe other paths out of ONNX dialects are subsuming this effort.
Thanks for your input on this.


Remove unused Mina_block.payments function

A trivial PR that removes a function that isn't used anywhere.
Explain how you tested your changes:

[x] Code compiles

Checklist:

[x] Dependency versions are unchanged

Notify Velocity team if dependencies must change in CI

[ ] Modified the current draft of release notes with details on what is completed or incomplete within this project
[x] Document code purpose, how to use it

Mention expected invariants, implicit constraints

[x] Tests were added for the new behavior

Document test purpose, significance of failures
Test names should reflect their purpose

[x] All tests pass (CI will check this if you didn't)
[x] Serialized types are in stable-versioned modules
[x] Does this close issues? None

!ci-build-me


Bug: Foundry does not respect optimizerSteps setting for Yul

Component
Forge
Have you ensured that all of these are up to date?

[X] Foundry
[X] Foundryup

What version of Foundry are you on?
No response
What command(s) is the bug in?
No response
Operating System
macOS (Apple Silicon)
Describe the bug
Foundry.toml configuration
[profile.default.optimizer_details]
# constantOptimizer = true
yul = true
# this sets the `yulDetails` of the `optimizer_details` for the `default` profile
[profile.default.optimizer_details.yulDetails]
stackAllocation = false
optimizerSteps = 'u'

Build output yields
optimizerSteps: u:fDnTOc

FWIW, fDnTOc is the default cleanup steps which you configure via the cleanup sequence delimiter :. If not set, the default of fDnTOc is applied. You should try to set optimizerSteps = 'u:' from what I understand.

friendly ping @Evalir

dhfoDgvulfnTUtnIf

my man.
@mattsse is there any possibility of exposing this argument on the CLI? It would make setting up a build matrix for comparison of compiled output using different optimizer steps easier to do and review.

## Run with no optimizerSteps
[⠊] Compiling 129 files with 0.8.19
[⠰] Solc 0.8.19 finished in 294.36s
Compiler run successful!

Contract
Size (kB)
Margin (kB)

Actor
2.638
21.938

Auth
0.982
23.594

AuthManager
2.151
22.425

Buffer
0.004
24.572

BytesLib
0.004
24.572

CompatibilityFallbackHandler
2.84
21.736

CryticERC4626FunctionalAccounting
8.45
16.126

CryticERC4626Harness
24.834
-0.258

CryticERC4626MustNotRevert
5.645
18.931

CryticERC4626PropertyBase
0.004
24.572

CryticERC4626PropertyTests
24.834
-0.258

CryticERC4626RedeemUsingApproval
8.157
16.419

CryticERC4626Rounding
6.536
18.04

CryticERC4626SecurityProps
2.904
21.672

CryticERC4626SenderIndependent
3.782
20.794

CryticERC4626VaultProxy
2.454
22.122

MevETHRateProvider
0.379
24.197

MevEth
22.352
2.224

## Run with optimizerSteps = 'dhfoDgvulfnTUtnIf'
$ forge build --sizes --force
[⠊] Compiling...
[⠘] Compiling 129 files with 0.8.19
[⠢] Solc 0.8.19 finished in 116.00s
Compiler run successful!

Contract
Size (kB)
Margin (kB)

Actor
3.113
21.463

Auth
1.283
23.293

AuthManager
3.039
21.537

Buffer
0.009
24.567

BytesLib
0.009
24.567

CompatibilityFallbackHandler
3.984
20.592

CryticERC4626FunctionalAccounting
9.032
15.544

CryticERC4626Harness
25.193
-0.617

CryticERC4626MustNotRevert
6.395
18.181

CryticERC4626PropertyBase
0.009
24.567

CryticERC4626PropertyTests
25.193
-0.617

CryticERC4626RedeemUsingApproval
8.429
16.147

CryticERC4626Rounding
7.067
17.509

CryticERC4626SecurityProps
3.951
20.625

CryticERC4626SenderIndependent
4.044
20.532

CryticERC4626VaultProxy
2.846
21.73

MevETHRateProvider
0.594
23.982

MevEth
26.2
-1.624

On second thought, it may in fact be an actual feature and not bug not to respect optimizer steps
https://soliditylang.org/blog/2023/07/19/full-inliner-non-expression-split-argument-evaluation-order-bug/

The use of custom optimizer sequences in the first place is uncommon. The feature is intentionally not widely advertised. Using it in a way that provides actual benefits is not easy. Anyone with enough knowledge to use it would also be likely to avoid inefficient sequences necessary to trigger this bug.

I now remember why I don't even bother: "We assigned the bug an overall score of "low". The bug has "high" severity in affected cases, but we deem the likelihood of it actually affecting deployed contracts as "very low"."

We can close this issue, my rage has subsided.
Though is it possible to have custom alerts for users using this setting in afflicted compiler versions? @mattsse

supportive for both

adding aliases for certain configs
checking versions

supportive for both

adding aliases for certain configs
checking versions

I only worry about the ongoing maintenance of providing such checks etc. It may create a false sense of security. The compiler team does provide a json file of all reported security issues that could be leveraged at the very least.


how to use raycaster in aframe-react?

How do I use raycaster on my cursor to work only on entities with certain id?
 <Entity
        raycaster="objects: [data-raycastable]" --> this doesn't work obviously.
        // color={cursorColor}
        primitive="a-cursor"
        animation__click={{
          property: "scale",
          startEvents: "click",
          from: "0.1 0.1 0.1",
          to: "1 1 1",
          dur: 150
     />

Hi @SaudTauqeer it might be that you're just missing a # in your selector to select an id.
It seems this is the recommended way to configure your components with this wrapper: raycaster={{ objects: ["#data-raycastable"] }}

Thank you that did the trick.


Katherine Soderberg's project outline

Sounds good. Try to break what you want to do into smaller chunks so that you can check them off as you go. It also means that at the end if you've only ticked off the first stepping stone you have a working program. Then rinse and repeat. Agreed about needing more python to know what you can and can't do. ask questions on the Gitter channel for pointers too.

Pasting update here for posterity:
I’m working on setting up my file structure (adding spreadsheets of data that I hope to filter/analyze) and hope to have a skeleton structure of code by next week. I have a sense of the outline of steps that includes 1) setting up the environment (importing pandas and other necessary packages), 2) loading in data (I’ll use pd.read_csv since my spreadsheets are in csv format), 3) using pandas methods to filter and reshape my data, and 4) turning my process into functions that can take different input files and perform various QC checks on them, in order to make the project useful for others in my research group

Do you need any help? Are you struggling to push updates to GitHub or debugging things for now?

Hello, do you need help with anything at this point? You can post questions here or bring questions to the class today.

Thank you for checking in! I will update Github before this evening and
bring debugging questions to class!
On Thu, May 7, 2020 at 12:21 PM Suhwan Paul Lee<EMAIL_ADDRESS>wrote:

Hello, do you need help with anything at this point? You can post
questions here or bring questions to the class today.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/biof309/project_spring_2020/pull/19#issuecomment-625356762,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AKDUJXIZRWNAD2SMKEL7VBDRQLN2BANCNFSM4K5GUUMA
.

Well done on passing the tests. Always a cause for celebration!

Nicely implemented project. Overall it achieves something useful in a clean modular, reusable way.
Obviously the tests could be more extensive. Getting them working full stop is great  so well done for persevering with that but I encourage you to check out some of the other project to get a sense of the sorts of ways you can go about testing. In the long term, including tests as you develop code will make life much easier.
Some other minor points:
Your attention to python style was very good. There were a couple of time you slipped. Keep the style guide pep8 in mind. Revisiting it periodically allows you to constantly improve your style which will help others to interpret your code (and you will be able to quickly interpret the code of others inclined towards attention to such important details).
In general imports should occur at the top of a file. It prevents various annoying issues and makes your dependencies apparent to anyone with a quick glance at the top of a python module.
Also, adding comments within the code itself is a good idea. This is a nice guide. Code that is very obvious at the time of writing becomes a lot less clear to you a few months later. Be kind to future Katherine.


⚠ HDBits has degraded performance

In 37e813d, HDBits ($HDB) experienced degraded performance:

HTTP code: 200
Response time: 1981 ms

Resolved: HDBits performance has improved in 05650fb after 21 minutes.


Fix memory tracker count leak when actual memory allocation fails

Fix the memory tracker counting leak when used with ScopedMappedMemory
which will update the memory tracker before the actual memory allocation.
The non-contiguous memory allocation path doesn't have the rollback when
the actual memory allocation failure. Found this issue by memory tracker counting
check failure on the associated memory pool destruction.
Verify this fix by both unit tests and production workload replay on Prestissmo
staging cluster.
This PR also change test value notify method to adjust which captures a mutable
production execution state which allows to inject an allocation failure easily in
test.

@xiaoxmeng CircleCI jobs are failing.

@xiaoxmeng Thank you for tracking down this bug. Overall looks good, but the CI failures. Please, consider the comments before landing.

@mbasmanova Thanks for the quick review!


Is this a full node

Just wonder if this is a full node or you still rely on a bitcoind node running in order to get to use this.
Whats the difference between this project and pycoind?

I think the only difference is the maintainer at pycoind at least responds the issues.
:-(


Resolves #877 Update storage location feature spec to system spec

Resolves #877 Update storage location feature spec to system spec
Description
Convert /spec/features/storage_location_spec.rb from a feature spec to a system spec. There are 4 steps to this:

Create storage_location_system_spec.rb under spec/system folder, delete the original storage_location_spec.rb
Set each spec’s type as type: :System
Use RSpec.describe to define system specs, instead of RSpec.feature
Replace the scenario alias in previous feature specs with the standard it syntax

:100: :100: :100:
Mergeable pending Travis :heavy_check_mark:


Map Integration with main website

IIITians-Network/Map#1

Preview
code view

@IIITians-Network/home-page review this PR


Wayland + GNOME: WindowConfig::size() sets size incorrectly

With the following app:
use notan::{draw::*, prelude::*};

#[notan_main]
fn main() -> Result<(), String> {
	notan::init()
		.add_config(DrawConfig)
		.add_config(notan::app::WindowConfig::new().size(400, 400))
		.draw(draw)
		.build()
}

fn draw(app: &mut App, gfx: &mut Graphics) {
	println!("{} x {}", gfx.size().0, gfx.size().1);
	let mut draw = gfx.create_draw();
	draw.clear(Color::BLACK);
	draw.rect((0.0, 0.0), (400.0, 400.0));
	gfx.render(&draw);
}

I get the following result showing the window is larger than 400x400. In the console it prints 420 x 455. Trying other resolutions, it seems like the width is always increased by 20 and the height by 55.
I'm using Arch Linux with GNOME on Wayland, and 125% display scaling.

It works properly if I use app.window().set_size(400, 400).
I'm not sure if this is related to #219 so I opened a separate issue.

Hey! Unfortunately I don't have access to wayland, and this seems not be an issue using Xorg. My guess is that something can be wrong with winit and wayland. Both ways to set the size use the same way to do it, the difference is that WindowConfig is doing it before the creation of the window and set_size is doing it after. Can you share what graphics card are you using? just to know if it's nvidia. And what screen dpi?
Let's see if we figure it a solution. Meanwhile I am marking this as need help for now to see if somebody with wayland can help us.

I am thinking another thing, can you set .resizable(true) on WindowConfig and see after you resize the window manually the surface get right the size?

Can you try with this branch? https://github.com/Nazariglez/notan/tree/log/size and paste here all the logs? Thanks

Thank you for the quick replies!

I'm using Intel Alder Lake integrated graphics (i5-1240P). Linux 6.2.12, mesa 23.0.3-1. Screen scaling is 125%, but GNOME is weird about that so I think it actually reports 200% scale and the wrong screen resolution to applications and then scales them down to look right. I also tried changing the scale factor to 100%, and all symptoms are the same.

With .resizeable(true), the initial size is 420x420 instead of 420x455. gfx.size() does seem to accurately report the size -- when I shrink the window until it prints 400x400 in the terminal, the white rectangle covers the whole area.

Here's the output from the version including resizeable:
1: config: WindowConfig { title: "Notan App", width: 400, height: 400, fullscreen: false, min_size: None, max_size: None, maximized: false, resizable: true, vsync: false, multisampling: 0, high_dpi: false, lazy_loop: false, transparent: false, always_on_top: false, decorations: true, visible: true, mouse_passthrough: false, canvas_id: "notan_canvas", window_icon_path: None, window_icon_data: None, taskbar_icon_path: None, taskbar_icon_data: None }
2023-05-06 00:21:37 [crossfont::ft] DEBUG: Loaded Face Face { ft_face: Font Face: Regular, load_flags: TARGET_LIGHT, render_mode: "Lcd", lcd_filter: 1 }
2: backend::size: (400, 400)
2023-05-06 00:21:37 [notan_glow] INFO: Using opengl graphics api
3: app::size: (400, 400)
4: graphics::size: (400, 400) - graphics::dpi: 1.0
5: app::size: (400, 400) - graphics::size: (400, 400) - graphics::dpi: 1.0
420 x 420
420 x 420
420 x 420

At this point my code starts printing 420x420 a lot. Here is the output from the non-resizeable version:
1: config: WindowConfig { title: "Notan App", width: 400, height: 400, fullscreen: false, min_size: None, max_size: None, maximized: false, resizable: false, vsync: false, multisampling: 0, high_dpi: false, lazy_loop: false, transparent: false, always_on_top: false, decorations: true, visible: true, mouse_passthrough: false, canvas_id: "notan_canvas", window_icon_path: None, window_icon_data: None, taskbar_icon_path: None, taskbar_icon_data: None }
2023-05-06 00:22:32 [crossfont::ft] DEBUG: Loaded Face Face { ft_face: Font Face: Regular, load_flags: TARGET_LIGHT, render_mode: "Lcd", lcd_filter: 1 }
2: backend::size: (400, 400)
2023-05-06 00:22:32 [notan_glow] INFO: Using opengl graphics api
3: app::size: (400, 400)
4: graphics::size: (400, 400) - graphics::dpi: 1.0
5: app::size: (400, 400) - graphics::size: (400, 400) - graphics::dpi: 1.0
420 x 455
420 x 455
420 x 455

I added some more logs to the branch, it's weird that at first everything is set right and then the draw method fails to get right the size. Can you test it again please? You can use cargo run --example window_open. I put your code there with an app.exit() on the end of the draw method.

Here's the output from that example. The size appears to actually be correct at first:
1: config: WindowConfig { title: "Notan App", width: 400, height: 400, fullscreen: false, min_size: None, max_size: None, maximized: false, resizable: false, vsync: false, multisampling: 0, high_dpi: false, lazy_loop: false, transparent: false, always_on_top: false, decorations: true, visible: true, mouse_passthrough: false, canvas_id: "notan_canvas", window_icon_path: None, window_icon_data: None, taskbar_icon_path: None, taskbar_icon_data: None }
2023-05-07 19:02:56 [crossfont::ft] DEBUG: Loaded Face Face { ft_face: Font Face: Regular, load_flags: TARGET_LIGHT, render_mode: "Lcd", lcd_filter: 1 }
2: backend::size: (400, 400)
2023-05-07 19:02:56 [notan_glow] INFO: Using opengl graphics api
3: app::size: (400, 400)
4: graphics::size: (400, 400) - graphics::dpi: 1.0
5: app::size: (400, 400) - graphics::size: (400, 400) - graphics::dpi: 1.0
2023-05-07 19:02:56 [notan_winit::backend] INFO: Winit Event: Focused(false)
7: app::size: (400, 400) app:dpi: 1.0 - graphics::size: (400, 400) - graphics::dpi: 1.0
8: app::size: (400, 400) app:dpi: 1.0 - graphics::size: (400, 400) - graphics::dpi: 1.0
400 x 400

If I remove app.exit() it seems that the size is actually messed up only after the first few frames:
1: config: WindowConfig { title: "Notan App", width: 400, height: 400, fullscreen: false, min_size: None, max_size: None, maximized: false, resizable: false, vsync: false, multisampling: 0, high_dpi: false, lazy_loop: false, transparent: false, always_on_top: false, decorations: true, visible: true, mouse_passthrough: false, canvas_id: "notan_canvas", window_icon_path: None, window_icon_data: None, taskbar_icon_path: None, taskbar_icon_data: None }
2023-05-07 19:03:09 [crossfont::ft] DEBUG: Loaded Face Face { ft_face: Font Face: Regular, load_flags: TARGET_LIGHT, render_mode: "Lcd", lcd_filter: 1 }
2: backend::size: (400, 400)
2023-05-07 19:03:09 [notan_glow] INFO: Using opengl graphics api
3: app::size: (400, 400)
4: graphics::size: (400, 400) - graphics::dpi: 1.0
5: app::size: (400, 400) - graphics::size: (400, 400) - graphics::dpi: 1.0
2023-05-07 19:03:09 [notan_winit::backend] INFO: Winit Event: Focused(false)
7: app::size: (400, 400) app:dpi: 1.0 - graphics::size: (400, 400) - graphics::dpi: 1.0
8: app::size: (400, 400) app:dpi: 1.0 - graphics::size: (400, 400) - graphics::dpi: 1.0
400 x 400
7: app::size: (400, 400) app:dpi: 1.0 - graphics::size: (400, 400) - graphics::dpi: 1.0
8: app::size: (400, 400) app:dpi: 1.0 - graphics::size: (400, 400) - graphics::dpi: 1.0
400 x 400
7: app::size: (400, 400) app:dpi: 1.0 - graphics::size: (400, 400) - graphics::dpi: 1.0
8: app::size: (400, 400) app:dpi: 1.0 - graphics::size: (400, 400) - graphics::dpi: 1.0
400 x 400
2023-05-07 19:03:09 [notan_winit::backend] INFO: Winit Event: Resized(PhysicalSize { width: 420, height: 455 })
6: app::size: (420, 455) app:dpi: 1.0 - graphics::size: (400, 400) - graphics::dpi: 1.0
7: app::size: (420, 455) app:dpi: 1.0 - graphics::size: (420, 455) - graphics::dpi: 1.0
8: app::size: (420, 455) app:dpi: 1.0 - graphics::size: (420, 455) - graphics::dpi: 1.0
420 x 455
7: app::size: (420, 455) app:dpi: 1.0 - graphics::size: (420, 455) - graphics::dpi: 1.0
8: app::size: (420, 455) app:dpi: 1.0 - graphics::size: (420, 455) - graphics::dpi: 1.0
420 x 455
2023-05-07 19:03:09 [notan_winit::backend] INFO: Winit Event: ScaleFactorChanged { scale_factor: 2.0, new_inner_size: PhysicalSize { width: 840, height: 910 } }
2023-05-07 19:03:09 [notan_winit::backend] INFO: Winit Event: Resized(PhysicalSize { width: 840, height: 910 })
2023-05-07 19:03:09 [notan_winit::backend] INFO: Winit Event: Focused(true)
2023-05-07 19:03:09 [notan_winit::backend] INFO: Winit Event: ModifiersChanged((empty))
7: app::size: (420, 455) app:dpi: 2.0 - graphics::size: (420, 455) - graphics::dpi: 1.0
8: app::size: (420, 455) app:dpi: 2.0 - graphics::size: (420, 455) - graphics::dpi: 2.0
420 x 455
7: app::size: (420, 455) app:dpi: 2.0 - graphics::size: (420, 455) - graphics::dpi: 2.0
8: app::size: (420, 455) app:dpi: 2.0 - graphics::size: (420, 455) - graphics::dpi: 2.0
420 x 455

And then the last three lines are repeated.

Hey @190n thanks for the logs, I was able to found (what I think is) the same issue https://github.com/rust-windowing/winit/issues/1446. I'll try to see if there is anything that we can do from notan in the next few days/weeks.

As far I can see on the issue in winit, they tell that the size set is a "suggestion" for the OS, and that it's possible that it doesn't respect it, like wayland and swap or similar can do their own thing, so I am not sure if we can do anything more than intestead of hardcode the size to draw the quad get it from app. To be sure, can I ask you for one more test? Just git pull and win. window_open until the size changes again please. I would like to see the size reported vs inner vs out and the size that is on gfx vs app.

1: config: WindowConfig { title: "Notan App", width: 400, height: 400, fullscreen: false, min_size: None, max_size: None, maximized: false, resizable: false, vsync: false, multisampling: 0, high_dpi: false, lazy_loop: false, transparent: false, always_on_top: false, decorations: true, visible: true, mouse_passthrough: false, canvas_id: "notan_canvas", window_icon_path: None, window_icon_data: None, taskbar_icon_path: None, taskbar_icon_data: None }
2023-05-09 18:13:25 [crossfont::ft] DEBUG: Loaded Face Face { ft_face: Font Face: Regular, load_flags: TARGET_LIGHT, render_mode: "Lcd", lcd_filter: 1 }
Winit inner_size PhysicalSize { width: 400, height: 400 }, scale: 1, logical LogicalSize { width: 400.0, height: 400.0 } inner_scale 1.0
2: backend::size: (400, 400)
2023-05-09 18:13:25 [notan_glow] INFO: Using opengl graphics api
Winit inner_size PhysicalSize { width: 400, height: 400 }, scale: 1, logical LogicalSize { width: 400.0, height: 400.0 } inner_scale 1.0
3: app::size: (400, 400)
Winit inner_size PhysicalSize { width: 400, height: 400 }, scale: 1, logical LogicalSize { width: 400.0, height: 400.0 } inner_scale 1.0
4: graphics::size: (400, 400) - graphics::dpi: 1.0
Winit inner_size PhysicalSize { width: 400, height: 400 }, scale: 1, logical LogicalSize { width: 400.0, height: 400.0 } inner_scale 1.0
5: app::size: (400, 400) - graphics::size: (400, 400) - graphics::dpi: 1.0
2023-05-09 18:13:25 [notan_winit::backend] INFO: Winit Event: Focused(false)
Winit inner_size PhysicalSize { width: 400, height: 400 }, scale: 1, logical LogicalSize { width: 400.0, height: 400.0 } inner_scale 1.0
7: app::size: (400, 400) app:dpi: 1.0 - graphics::size: (400, 400) - graphics::dpi: 1.0
8: app::size: (400, 400) app:dpi: 1.0 - graphics::size: (400, 400) - graphics::dpi: 1.0
Winit inner_size PhysicalSize { width: 400, height: 400 }, scale: 1, logical LogicalSize { width: 400.0, height: 400.0 } inner_scale 1.0
gfx: (400, 400), app: (400, 400)
Winit inner_size PhysicalSize { width: 400, height: 400 }, scale: 1, logical LogicalSize { width: 400.0, height: 400.0 } inner_scale 1.0
7: app::size: (400, 400) app:dpi: 1.0 - graphics::size: (400, 400) - graphics::dpi: 1.0
8: app::size: (400, 400) app:dpi: 1.0 - graphics::size: (400, 400) - graphics::dpi: 1.0
Winit inner_size PhysicalSize { width: 400, height: 400 }, scale: 1, logical LogicalSize { width: 400.0, height: 400.0 } inner_scale 1.0
gfx: (400, 400), app: (400, 400)
Winit inner_size PhysicalSize { width: 400, height: 400 }, scale: 1, logical LogicalSize { width: 400.0, height: 400.0 } inner_scale 1.0
7: app::size: (400, 400) app:dpi: 1.0 - graphics::size: (400, 400) - graphics::dpi: 1.0
8: app::size: (400, 400) app:dpi: 1.0 - graphics::size: (400, 400) - graphics::dpi: 1.0
Winit inner_size PhysicalSize { width: 400, height: 400 }, scale: 1, logical LogicalSize { width: 400.0, height: 400.0 } inner_scale 1.0
gfx: (400, 400), app: (400, 400)
2023-05-09 18:13:25 [notan_winit::backend] INFO: Winit Event: Resized(PhysicalSize { width: 420, height: 455 })
> Resized: evt:PhysicalSize { width: 420, height: 455 } in:PhysicalSize { width: 420, height: 455 } out:PhysicalSize { width: 420, height: 455 }, dpi:1
Winit inner_size PhysicalSize { width: 420, height: 455 }, scale: 1, logical LogicalSize { width: 420.0, height: 455.0 } inner_scale 1.0
6: app::size: (420, 455) app:dpi: 1.0 - graphics::size: (400, 400) - graphics::dpi: 1.0
7: app::size: (420, 455) app:dpi: 1.0 - graphics::size: (420, 455) - graphics::dpi: 1.0
8: app::size: (420, 455) app:dpi: 1.0 - graphics::size: (420, 455) - graphics::dpi: 1.0
Winit inner_size PhysicalSize { width: 420, height: 455 }, scale: 1, logical LogicalSize { width: 420.0, height: 455.0 } inner_scale 1.0
gfx: (420, 455), app: (420, 455)
Winit inner_size PhysicalSize { width: 420, height: 455 }, scale: 1, logical LogicalSize { width: 420.0, height: 455.0 } inner_scale 1.0
7: app::size: (420, 455) app:dpi: 1.0 - graphics::size: (420, 455) - graphics::dpi: 1.0
8: app::size: (420, 455) app:dpi: 1.0 - graphics::size: (420, 455) - graphics::dpi: 1.0
Winit inner_size PhysicalSize { width: 420, height: 455 }, scale: 1, logical LogicalSize { width: 420.0, height: 455.0 } inner_scale 1.0
gfx: (420, 455), app: (420, 455)
2023-05-09 18:13:25 [notan_winit::backend] INFO: Winit Event: ScaleFactorChanged { scale_factor: 2.0, new_inner_size: PhysicalSize { width: 840, height: 910 } }
2023-05-09 18:13:25 [notan_winit::backend] INFO: Winit Event: Resized(PhysicalSize { width: 840, height: 910 })
> Resized: evt:PhysicalSize { width: 840, height: 910 } in:PhysicalSize { width: 840, height: 910 } out:PhysicalSize { width: 840, height: 910 }, dpi:2
2023-05-09 18:13:25 [notan_winit::backend] INFO: Winit Event: Focused(true)
2023-05-09 18:13:25 [notan_winit::backend] INFO: Winit Event: ModifiersChanged((empty))
Winit inner_size PhysicalSize { width: 840, height: 910 }, scale: 2, logical LogicalSize { width: 420.0, height: 455.0 } inner_scale 2.0
7: app::size: (420, 455) app:dpi: 2.0 - graphics::size: (420, 455) - graphics::dpi: 1.0
8: app::size: (420, 455) app:dpi: 2.0 - graphics::size: (420, 455) - graphics::dpi: 2.0
Winit inner_size PhysicalSize { width: 840, height: 910 }, scale: 2, logical LogicalSize { width: 420.0, height: 455.0 } inner_scale 2.0
gfx: (420, 455), app: (420, 455)
Winit inner_size PhysicalSize { width: 840, height: 910 }, scale: 2, logical LogicalSize { width: 420.0, height: 455.0 } inner_scale 2.0
7: app::size: (420, 455) app:dpi: 2.0 - graphics::size: (420, 455) - graphics::dpi: 2.0
8: app::size: (420, 455) app:dpi: 2.0 - graphics::size: (420, 455) - graphics::dpi: 2.0
Winit inner_size PhysicalSize { width: 840, height: 910 }, scale: 2, logical LogicalSize { width: 420.0, height: 455.0 } inner_scale 2.0
gfx: (420, 455), app: (420, 455)
Winit inner_size PhysicalSize { width: 840, height: 910 }, scale: 2, logical LogicalSize { width: 420.0, height: 455.0 } inner_scale 2.0
7: app::size: (420, 455) app:dpi: 2.0 - graphics::size: (420, 455) - graphics::dpi: 2.0
8: app::size: (420, 455) app:dpi: 2.0 - graphics::size: (420, 455) - graphics::dpi: 2.0
Winit inner_size PhysicalSize { width: 840, height: 910 }, scale: 2, logical LogicalSize { width: 420.0, height: 455.0 } inner_scale 2.0
gfx: (420, 455), app: (420, 455)
Winit inner_size PhysicalSize { width: 840, height: 910 }, scale: 2, logical LogicalSize { width: 420.0, height: 455.0 } inner_scale 2.0
7: app::size: (420, 455) app:dpi: 2.0 - graphics::size: (420, 455) - graphics::dpi: 2.0
8: app::size: (420, 455) app:dpi: 2.0 - graphics::size: (420, 455) - graphics::dpi: 2.0
Winit inner_size PhysicalSize { width: 840, height: 910 }, scale: 2, logical LogicalSize { width: 420.0, height: 455.0 } inner_scale 2.0
gfx: (420, 455), app: (420, 455)

All the same after this.

The 3 sizes reported by winit are the same, I am not sure right now if this is intended or it's a bug, I am opening an issue on winit https://github.com/rust-windowing/winit/issues/2799

Hey @190n, good news! I was able to get a Fedora+Wayland working on my machine and did some test (this is good because I can test anything there from now on). And the issue is fixed using the latest changes in winit. The bad news is that winit's version isn't published yet. Once published we need to wait (or help) with glutin getting updated too.
So this will be a fix for notan 0.10.0 which is almost done, however, blocked now for this. Once a new version of winit and glutin gets published I'll update notan and probably release 0.10.
Thanks for reporting this, all the testing, and your patience.

This is going to be fixed in the next branch, because is the one that's using the latest winit.


SSAO Pass: Camera Scale affecting SSAO effect

I've found that if I change the camera scale (literally, camera.scale.set(10,10,10)); the SSAO diminishes it's effect.
I'm using SSAO effect from https://github.com/pmndrs/postprocessing as follows:
const normalPass = new NormalPass(scene, camera);
const effect = new SSAOEffect(camera, normalPass.texture, {
	worldDistanceThreshold: 20,
	worldDistanceFalloff: 5,
	worldProximityThreshold: 0.4,
	worldProximityFalloff: 0.1,
	luminanceInfluence: 0.7,
	samples: 16,
	radius: 0.04,
	intensity: 1,
	resolutionScale: 0.5
});

Here are some images on how camera scale affects the SSAO effect. (I exaggerated intensity of SSAO so it's more clear)
When Camera Scale is (1,1,1):

When Camera Scale is (2,2,2):

When Camera Scale is (5,5,5):

When Camera Scale is (10,10,10):

When Camera Scale is (20,20,20):

(All screenshots had the same intensity value for the SSAO)
What can I adjust on the SSAO effect so it's get "normalized" to whatever I set as the camera scale?
(Note: I've had other problems before because of using a different camera scale than (1,1,1), and I've solved it by just multiplying whatever's been affected by the scale of the camera. But in this case I haven't been able to figure out what parameters needs to be adjusted.)

What's the use case for changing the scale of the camera object? I didn't know this was possible / had any effect.
I've looked around and found this: https://github.com/mrdoob/three.js/issues/24800#issuecomment-1304716819

Cameras in three.js should not have a scale applied.

If you're trying to change the scale of all objects, you could change the scale of the scene instead. The different results that you're seeing with SSAO are to be expected since the effective world size of the objects is different with each configuration. You could try multiplying worldProximityThreshold and worldProximityFalloff by the camera scale. You might also want to set worldDistanceThreshold to some very high value (camera.far multiplied by camera scale?) and worldDistanceFalloff to 0 to make sure SSAO never fades out.

What's the use case for changing the scale of the camera object? I didn't know this was possible / had any effect.

I accidentally found one very good use some time ago. But I'm trying to find a workaround now to stop using this discovered characteristic to avoid issues like these... might stick with it if I don't find the alternative. Fixing mesh overlaps in dynamic unknown scenes (https://discourse.threejs.org/t/fixing-mesh-overlaps-in-dynamic-unknown-scenes/46194)
Scaling the camera basically helps three.js to do better calculations on the depths for meshes that are too close to each other.
Camera scale of (1,1,1) vs Camera scale of (10,10,10)

So, scaling the scene would be more problematic, because I'll be modifying world scale, camera scale does not modify it and I don't know if it fixes these meshes overlaps. Which is guy I'm scaling the camera.
I tried multiplying worldProximityThreshold and worldProximityFalloff by the camera.scale but didn't work. Also have set worldDistanceFalloff to 0 and didn't work.

This type of clipping is caused by insufficient depth precision which could mean that your dynamic scenes are too large. Have you tried limiting the size of the dynamic scenes to predefined bounds? You could scale the scene to make its bounding box match your world limits.
I don't know what changing the camera scale really does, but it looks like it affects depth precision in some way. Unfortunately, SSAO is already tricky enough to configure for common scenes so I'd also recommend not changing the camera scale if possible.

Closing this as it seems to be resolved.

This type of clipping is caused by insufficient depth precision which could mean that your dynamic scenes are too large.

I ended up fixing the root cause of the problem, which it was having very big difference between far and near camera's props.
Which fixed all of the related issues I mentioned in this post.


btn sizing

Hello there
I am trying to figure out the btn css dimensions rules, can you enlight me on how these values are picked ?
when I look at it in the metrics inspector it computes to

1px border + 5px padding  + 15px l-height +  6px padding + 1px border
so the total height is 28px, but the baseline is 18px, hence shouldn't the height of the btn be a multiple to maintain a vertical rhythm ?

I chose those because they felt right. Not everything is perfectly aligned to the baseline and I'm not too convinced we need to do that.


Externalize provider and types deps for web entry point

📦 Pull Request
We are examining an issue related to Magic SDK extensions related to the usage of @magic-sdk/provider and @magic-sdk/types as bundled deps instead of external deps.
🗜 Versioning
(Check one!)

[ ] Patch: Bug Fix?
[x] Minor: New Feature?
[ ] Major: Breaking Change?

We'll be testing this as a canary version first

:rocket: PR was released in<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>:rocket:


Issue generating Brueckner orbitals from CCSD

Hi
I am trying to build a program to generate Brueckner orbitals in PySCF via CCSD. However, my PySCF results do not align with ACES2 results starting at the second iteration. At this point, I start to see slight deviations in the energy that increase in magnitude as I continue to iterate, my T1 norms stop decreasing, and the second order amplitudes yield an MP2 energy that is appreciably different than ACES2.  All that to say ACES2 converges, while my implementation does not.
After I rotate the occupied and virtual orbitals with T1, I orthogonalize the set of C, construct a DM, feed that into the SCF class without iteration to rebuild the Fock matrix, re-transform 2 e- integrals, and then finally re-run CCSD.  I  feel like there is something that I am not seeing in my PySCF implementation, or there is something in my code I am overlooking.  I was hoping someone could lend me some help.
Disclaimer that there is a related  request open at  #1343, but I have not been able to track down any implementation to compare my code to. Perhaps you can direct me in this regard, @zhcui ? To conserve space, I have only posted the functions that drive the brueckner routine, which rotates orbitals and orthogonalize them., but will attach the entire python script for reference.
def orthogonalizeMO(mf,C):
    ovrlap=mf.get_ovlp()
    ovrlapMO=(C.T@ovrlap)@C
    roots,vecs=np.linalg.eigh(ovrlapMO)
[bruecknerCCSD.py.zip](https://github.com/pyscf/pyscf/files/9913594/bruecknerCCSD.py.zip)
[bruecknerCCSD.py.zip](https://github.com/pyscf/pyscf/files/9913596/bruecknerCCSD.py.zip)

    indx = roots.argsort()
    vecs = vecs[:, indx]
    roots=roots[indx]
    newroots=np.zeros((len(roots),len(roots)))
    for i in range(len(roots)):
        newroots[i][i]=1.0/np.sqrt(roots[i])

    X=(vecs<EMAIL_ADDRESS>    orthog_C=C@X
    print('Verify C^tSC==1',np.allclose((orthog_C.T@ovrlap)@orthog_C,np.eye(X.shape[0])))
    return orthog_C

# Performs Brueckner rotation on occ/virt orbitals
def T1rotate(coeff,t1):
    newcoeff=coeff
    nocc,nvirt=t1.shape

    C_occ=coeff[:,:nocc]
    C_virt=coeff[:,nocc:]
    C_virtold=C_virt

    C_virt=C_virt-C_occ@t1
<EMAIL_ADDRESS>
    newcoeff=np.zeros(coeff.shape)
    newcoeff[:,:nocc]=C_occ
    newcoeff[:,nocc:]=C_virt

    return newcoeff

def run_brueckner(mf,t1,coeff,nocc,mo_occ,t1TOL=10E-4):
    t1norm=np.linalg.norm(t1)
    newC=coeff
    for i in range(4):
        print('Norm of t1:',t1norm)
        newC=T1rotate(newC,t1)
        newC=orthogonalizeMO(mf,newC)

        # Rebuild Fock matrix
        mf=scf.RHF(mol)
        dm1=mf.make_rdm1(newC,mo_occ)
        mf.init_guess=dm1
        mf.run(max_cycle=0)

        # Converge CCSD eqns & extract new T1
        mycc=cc.CCSD(mf)
        eris=mycc.ao2mo()
        mycc.kernel(eris=eris)
        t1=mycc.t1

        print('max of t1: ',np.max(np.abs(t1)))
        t1norm=np.linalg.norm(t1)

    return mf,dm1

Hi Zach, I've never tried to implement Brueckner but the first thing that came to my mind is that the straightforward attempt to rotate the orbitals by T1 may suffer from the same problem as SCF calculations with the original Roothaan method, that is, the wave function changes too much and the solution blows up. Maybe one needs some sort of damping or DIIS?
Note that the link to your file got pasted twice in the code section; the link should be in the text part as
bruecknerCCSD.py.zip

I did this some time ago. I think @susilehtola is right, that it needs dampening or DIIS.
Try DIIS on the T1 amplitudes, with the error vector being T1 itself, as it should be zero at convergence.
Alternatively, you can try DIIS on the mean-field density-matrix. the problem beeing that mixtures of idempotent matrices won't be idempotent: You could look into PC-DIIS (J. Chem. Theory Comput. 2017, 13, 11, 5458–5467) or have a "purificication step" a la projected DMET, where you diagonalize the non-idempotent DM and use the eigenvectors of the nocc largest eigenvalues as your new occupied orbitals.

Hi,
There is a repo Here  think it's a spin-restricted treatment but it might help.

I really appreciate your suggestions and insight, @susilehtola, @maxnus, and @pwborthwick. I will look into incorporating DIIS into my algorithm to see if this changes anything. I was originally of the mindset that I have made a mistake somewhere, since ACES converges so rapidly and seemingly without trouble. ACES similarly does not use DIIS to converge Brueckner, so I figured I would be in the clear. Also, @susilehtola: I tried damping T1 rotation by factor of 0.5 with no impact to the convergence behavior.
@pwborthwick I looked at the psi4 implementation, and it looks like they are choosing to rotate orbitals with T1 every CC iteration; is my understanding correct?
I will report back when I find out more. Thanks

Hi,
Sorry for the delay.
I just commit a PR for a BCCD implementation:
https://github.com/pyscf/pyscf/pull/1497
Could you test whether it works for your system and the reference number from ACES?
Best,
Zhihao

The BCC algorithm is

Update non-singles amplitudes $t^{ij..}_{ab...}$
Update the singles amplitudes $t^i_a$
Build your orbital rotation matrix eg $\boldsymbol{U}=e^({\boldsymbol{T}  - \boldsymbol{T^\dagger})}$ with $\boldsymbol{T}=t^i_a$
do the rotation $\boldsymbol{C^\prime} = \boldsymbol{CU}$
Transform all integral (1 and 2 body) to the new spin orbital basis using $\boldsymbol{C}$
If $||t^i_a|| != 0$ or other $t^{ij...}_{ab...}$ amplitudes are not converged then return to first step.

So yes the rotation is performed at each step.

I guess there are two differences then- the first one is the iteration scheme (rotate every iteration vs converge for given mean-field and rotate in an outer loop). I would think that in many cases these two schemes should have the same fix-point though? The second is the rotation itself, I think @zww-4855 you only "rotate" with (1+U), the expansion of exp(U) to linear order?

I agree, @maxnus . I will mention that the algorithm I am familiar with rotates the coefficients with T1 (and so on) only after the CCSD residuals have converged. This is how I wrote my code and is how ACES2 is written as well. It looks like @zhcui algorithm also follows this logic. But I feel this is not the only way to converge toward the fixed point, and clearly there isn't a unique algorithm since Psi4 implementation ala @pwborthwick is different. So I then suppose convergence behavior for different Brueckner algorithms has not been investigated. very interesting.

From Bartlett & Shavitt 'Many Body Methods in Chemistry and Physics: MBPT and Coupled-Cluster Theory' pg 419

Brueckner orbitals can be defined, within a given one-electron Hilbert space, by either of two equivalent conditions on the orbitals occupied in the reference determinant: (a) the requirement that single-excitation contributions to the exact wave
function vanish (Nesbet 1958) or (b) the requirement that the reference determinant has maximum overlap with the
exact wavefunction (Löwdin 1962b). The equivalence of these conditions can be seen by considering the overlap
between |Φ B >, the Brueckner reference determinant, and the exact wave function |Ψ>.

In Shavitt & Bartlett they explain an approach in which

The transformed orbitals are orthonormalized, and the process is repeated by re-solving the CCSD doubles equations for T̂ 2

There are then two equivalent methods I'm sorry if I confused things by pointing you in the direction of the psi4 repo which did things in a different way to how you were trying. I guess it's down to which way is most efficient  or convenient.

No problems at all, @pwborthwick , I have learned something new.
@maxnus I missed this comment earlier: We have found that including nonlinear terms in the series do appreciably impact convergence rate. So in practice, we truncate the expansion at (1+T1).
I tested @zhcui implementation, where both ACES2 and pySCF converge toward the same CCSD energy. One thing I found interesting is that  his implementation also rotates the initial T1 and T2 amplitudes at each Brueckner iteration.  To my knowledge, ACES does no such thing. I have not been able to convincingly explain why my python implementation fails; I am assuming I have overlooked some formal technicality in python and/or PySCF. I will gradually look more into this.
In the end, this implementation converges faster than ACES for H2O. I expect this to generally be the case for arbitrary systems as well, since ACES does not employ DIIS for Brueckner.
I appreciate the commentary everyone. Take care.
Zack

We have found that including nonlinear terms in the series do appreciably impact convergence rate. So in practice, we truncate the expansion at (1+T1).

Do you mean it does not impact convergence rate?

@maxnus YES!! That was a bad typo to make. Expanding the exp beyond 1+T1 does not appreciably impact performance.

Good to know the implementations agree with each other. The DIIS of BCC orbitals indeed may influence the convergence rate. Please update with us after you have more tests or information.

@zhcui , I'm curious why you have a custom logm routine rather than using scipy.linalg.logm? As far as I can see there is no difference to speed or numerical accuracy when using scipy. You also use $e^{(-\boldsymbol{U} +\boldsymbol{U^\dagger}) }$ rather than e^{(\boldsymbol{U} - \boldsymbol{U^\dagger}) } which I've seen elsewhere, and the former seem to lead to better convergence, why is this?
Peter

@zhcui , I'm curious why you have a custom logm routine rather than using scipy.linalg.logm? As far as I can see there is no difference to speed or numerical accuracy when using scipy. Peter

Hi Peter,
scipy's logm may return a complex matrix.
Best,
Zhihao

@zhcui , I'm curious why you have a custom logm routine rather than using scipy.linalg.logm? As far as I can see there is no difference to speed or numerical accuracy when using scipy. Peter

Hi Peter,
scipy's logm may return a complex matrix.
Best, Zhihao

np.real
Best Peter

@zhcui , I'm curious why you have a custom logm routine rather than using scipy.linalg.logm? As far as I can see there is no difference to speed or numerical accuracy when using scipy. Peter

Hi Peter,
scipy's logm may return a complex matrix.
Best, Zhihao

You could use np.real(scipy.linalg.logm) save you a subroutine. Best Peter
Try la.logm(np.eye(2) * -1)

@zhcui , I'm curious why you have a custom logm routine rather than using scipy.linalg.logm? As far as I can see there is no difference to speed or numerical accuracy when using scipy. Peter

Hi Peter,
scipy's logm may return a complex matrix.
Best, Zhihao

You could use np.real(scipy.linalg.logm) save you a subroutine. Best Peter

Try la.logm(np.eye(2) * -1)

Sorry not to get back sooner - it was night on this side of the Atlantic. Before I try np.eye(2)*-1 what I expect is since $ln(\boldsymbol{A})$ is diagonal if and only if $\boldsymbol{A}$ is diagonal I expect scipy to produce a diagonal matrix with diagonal elements ln(-1) = ln( $e^{i \pi}$ ) = $i\pi$. The real part of which is a matrix entirely of zeros.,,this is exactly what it produces (with some numerical noise). However, the original matrix has negative real eigenvalues so there doesn't exist a principal logarithm and the logarithm is not unique. Your algorithm is better as it finds a non-zero matrix among the possible solutions (determinant still zero), which is essentially lemma 2 from Sherif and Morsy I take your point then that there are (pathalogical?) situations that can occur where scipy will fail and your (rather neat) algorithm will not. Thank you for pointing out the potential problems with the scipy logm - When I find a case in practice where scipy fails I'll report back.

@zhcui , I'm curious why you have a custom logm routine rather than using scipy.linalg.logm? As far as I can see there is no difference to speed or numerical accuracy when using scipy. Peter

Hi Peter,
scipy's logm may return a complex matrix.
Best, Zhihao

You could use np.real(scipy.linalg.logm) save you a subroutine. Best Peter

Try la.logm(np.eye(2) * -1)

Sorry not to get back sooner - it was night on this side of the Atlantic. Before I try np.eye(2)*-1 what I expect is since ln(A) is diagonal if and only if A is diagonal I expect scipy to produce a diagonal matrix with diagonal elements ln(-1) = ln( eiπ ) = iπ. The real part of which is a matrix entirely of zeros.,,this is exactly what it produces (with some numerical noise). However, the original matrix has negative real eigenvalues so there doesn't exist a principal logarithm and the logarithm is not unique. Your algorithm is better as it finds a non-zero matrix among the possible solutions (determinant still zero), which is essentially lemma 2 from Sherif and Morsy I take your point then that there are (pathalogical?) situations that can occur where scipy will fail and your (rather neat) algorithm will not. Thank you for pointing out the potential problems with the scipy logm - When I find a case in practice where scipy fails I'll report back.
PS. The most 'pathalogical' case I've found so far is H2 in STO-3G where the initial rotation matrix is I2 and both scipy and your algorithm return a 2x2 matrix of zeros. The iterations converge after 1 iteration to the same value as with diis switched off.

Ok, sounds great.


Desired behavior of shortest paths algorithms when the goal is not reached

The shortest paths API allows to specify a goal vertex:
let result = ShortestPaths::on(&graph).goal(target).run(start).unwrap();

What should be the behavior when the target vertex is not reachable from the start vertex?

Silently ignore that. Then getting distance to the target returns None.
Return an error from run.

I am in favor of (2), returning an error from run. Because when the goal is specified, the user desires to find the shortest path and its distance to that target vertex and has right to expect their availability after getting a successful result. In that case, returning None from dist could be confusing. Returning error early should prevent such confusion.
In general case, when no goal is specified, it is fine to return None for unreachable vertices, because the user should keep in mind that a graph in general can contain unreachable vertices.


Update Getting Started Kit to use the Stellar wallets kit

Add to  Getting started guide here to use the wallet selector kit: https://github.com/Creit-Tech/Stellar-Wallets-Kit
Context: https://docs.google.com/document/d/1zkWiCiGtLn6rCvlGI5JvulSA_1PG4KFwfqnbnIPiDTE/edit
Related issue: https://github.com/Creit-Tech/Stellar-Wallets-Kit/issues/29

This is a Q2 OKR Item!

Duplicate.  This issue is 443. Is there another issue that you are referring to?

linked the wrong one by accident. https://github.com/stellar/stellar-docs/issues/766

Great, got it, thank you


Update to v1.23.17-k3s1

Also looks like the v1.23.17-k3s1 tag is missing from k3s-io/k3s, although we have staging/src/k8s.io/api/v1.23.17-k3s1 and all the other staging tags.

good catch! added

looks like go mod needed to be tidied


Structs and records as indexer parameter type

Help us make content visible
I found the following guideline for Indexed Property Design.
The guideline states the following: AVOID indexers with parameter types other than System.Int32, System.Int64, System.String, System.Object, or an enum.
So my question is what about structures and records? Should those types also be avoided or if not, should they be added to the list in the guideline?

ping @IEvangelist Do you know of any updates on this guidance?

Hi @BillWagner - no, I'm not familiar with any updates to that guidance, and it feels as though it wouldn't make sense to include a struct or a record as an indexer. If you take a step back and think about it, these have value comparison semantics - great, but using them as a key on an indexer does what exactly? The indexer property is intended to be used to access a value, whereas using a struct or a record as the index seems as though you're using the value as the key. Using the canonical Person record, let's create an indexer.
using System;
using System.Collections.Generic;
using System.Linq;

PeopleIndexer indexer = new();

Person david = new(7, "David", "Pine");
indexer[david.Id] = david;

Console.WriteLine(indexer[0]); // No one's home...
Console.WriteLine(indexer[7]);

indexer[david.Id] = david with { Id = 999, LastName = "Fowler" };
Console.WriteLine(indexer[999]);

public class PeopleIndexer
{
    readonly HashSet<Person> _people = new();

    public Person this[long id]
    {
        get => _people.FirstOrDefault(p => p.Id == id);
        set => _people.Add(value);
    }
}

public record Person(long Id, string FirstName, string LastName);

This would output (sharplab.io link):

Person { Id = 7, FirstName = David, LastName = Pine }
Person { Id = 999, FirstName = David, LastName = Fowler }

But if you're to use the record as the indexer, what is the value you're expecting? My argument is that it doesn't really make sense. I guess I'd have to see an example of what usage you'd reasonably expect a record or struct as the key to an indexer property, that would be really helpful.
Do you have a valid use case for this @csaba-sagi-sonarsource? Happy to talk through it more and try to understand its validity.

HI @IEvangelist, thank you fir the quick answer and the nice example.
I created a simplified example with structs. It is similar to a use case I saw at my previous company while working with industrial equipment and communication protocols. Please take a look at the example and feel free to give me a feedback why such an indexer should or should not be used.
public class IndustrialDevice
{
    readonly HashSet<IndustrialComponents> components = new();

    public IndustrialComponents this[ComponentAddress address]
    {
        get => components.FirstOrDefault(p => p.Address.Equals(address));
        set => components.Add(value);
    }
}

public record IndustrialComponents(long Id, ComponentAddress Address);

public struct ComponentAddress
{
    public int AddressPart1 { get; set; }
    public int AddressPart2 { get; set; }

    public ComponentAddress(int addressPart1, int addressPart2)
    {
        AddressPart1 = addressPart1;
        AddressPart2 = addressPart2;
    }
}

Hi again @csaba-sagi-sonarsource - that's an interesting use case and it does feel valid. I'd probably suggest that the struct should be made readonly, but other than that - I'm not too worried about that as that key to an indexer. I'd be curious if there should be any guidance as to the size of the struct or record, or if that should matter. Here is a sharplab.io with your code.
@BillWagner what do you think? Are there any other concerns that we're not considering here?

From language perspective, there is nothing wrong with using anything as indexer parameter. However, I tend to agree with the guidelines that using anything other than a numeric type is usually a bad idea.
For your case, I feel it's more natural to  an `IDictionary<

Hey @bartonjs - would you mind looking this issue over, as it is related to Design Guidelines? What should be the official suggestion for this sort of thing?

This rule did get modified in FDGv3:

AVOID indexers with parameter types other than System.Int32,
System.Int64, System.String, System.Range, System.Index, or an
enum, except on dictionary-like types.

(5.2.1, Indexed Property Design, p. 161)
We obviously need a plan for getting the updated guidance in the docs pages (or removing / redirecting the docs pages to another location) -- the current ones seem to be mostly FDGv1 rules with their FDGv2 updates applied (there are sections of v2 guidance that don't appear at all).  Though the last time this got spun up (when FDGv3 was in final edits) it hit a pause with legal about making sure that ts are crossed and is are dotted with regards to the portions that require the "Reprinted by permission of Pearson Education, Inc." notice.

Hi @bartonjs - I love the idea of putting together a plan for this. Do we have permission from Pearson Education to replicate this content, if not what does that look like and what is the timeline? Is the FDGv3 fully published and publicly available now? Happy to proceed as you deem necessary. Thank you

Do we have permission from Pearson Education to replicate this content

Practically speaking? Yes (IANAL), but not in a manner that CELA likes, so no.

if not what does that look like and what is the timeline

Don't really know, probably better dealt with over an internal channel.

Is the FDGv3 fully published and publicly available now?

Yep.  https://www.informit.com/store/framework-design-guidelines-conventions-idioms-and-9780135896327 "and quality bookstores everywhere".

We do not have permissions to update this content with information that is part of edition three. With that said, I'm going to close this and point you to https://www.informit.com/store/framework-design-guidelines-conventions-idioms-and-9780135896327.


Try to use DataFrameTreeReduction but it starts concatenating strings...

Trying to work on a part of #72, but for some reason when I make this change it starts concatenating strings instead of histograms.
pytest 'tests/test_boost.py::test_obj_5D_strcat_intcat_rectangular_dak[True]' is a good example.

So after some further digging what I'm finding is that:
https://github.com/dask-contrib/dask-histogram/blob/main/src/dask_histogram/core.py#L1041-L1044
Is returning some really wonky types. In particular if I try to use the keys it only wants to add the strings rather than using the keys to get the collections, if I am using the DataFrameTreeReduction.

I am investigating, and finding some inconsistency between keys named like (name-hash, 0) and just name-hash, as if the tree reduction isn't sure if it is partitioned or not.
(it seems to me that this ought to be a pretty simple pattern to write out in layer "generator" style, but (as usual) the dask docs on how to use it)

Superseded by #74


Updated README

Heyt here @fallacy321, are you having any issues running let's chat without sudo?

Hi @hhaidar Yes, without sudo, I was not able to update the packages. I see now, npm start works though but for updating sudo was required. I am using Kubuntu 13.04
Regards

Seems like there are 3-4 features in one PR. Do you mind splitting this up?
Also we can't accept the changes to README as npm update is not necessary :(