First Android app: Android Basics in Compose

URL of codelab
https://developer.android.com/codelabs/basic-android-kotlin-compose-first-app?continue=https%3A%2F%2Fdeveloper.android.com%2Fcourses%2Fpathways%2Fandroid-basics-compose-unit-1-pathway-2%23codelab-https%3A%2F%2Fdeveloper.android.com%2Fcodelabs%2Fbasic-android-kotlin-compose-first-app#4
In which task and step of the codelab can this issue be found?
5. Update the text
Describe the problem
The text The Greeting() function under the onCreate() function is a Composable function. Notice the @Composable annotation above it.  gives me the impression that there's code above that should be there but it isn't! In fact, such code is below this text instead!
In other words, The Greeting() function isn't above at all, there's a function call, but it is inside, not under, the onCreate() function.
There's no @Composable annotation above! And there's no way to scroll down inside the above code(so, the code that's visible is all the code), see screenshot below.
So there's likely code missing above. Or maybe, I'm supposed to look only at my project contents and notice that code there?
Additional information
Include screenshots if they would be useful in clarifying the problem.

The missing code is duplicated below though:

@correabuscar
Thank you for reaching out to us. The text was modified and published:


covidout

Hello Sibesh,
I'm jitesh currently pursuing engineering, and working on a app named Help
next door, in which i want to include your website for access to live
updates on corona cases.
Thank you.
On Tue 24 Mar, 2020, 10:23 PM Sibesh Kar<EMAIL_ADDRESS>wrote:

Closed #29 https://github.com/someshkar/covid19india-network/issues/29.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/someshkar/covid19india-network/issues/29#event-3160617822,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AI5TKER7GAO4ZPTAIA53MI3RJDQSDANCNFSM4LSNK42Q
.


Update to bot API v5.3

The only thing I omitted there is what was added in #26

LGTM on first sight.
I'm gonna do a few tiny tweaks to formatting and style because I'm a pedantic weirdo when it comes to typegram, but I don't need to bother you with that 😅

What about husky hook plus prettier to make it automated?

That's beyond what prettier can do, or what it's meant for. Wait until you see the changes :D

@kraftwerk28 that should be it. I am going to merge and publish if you confirm I did not make any unresolved mistakes.


feat: define the category of extremally disconnected compact Hausdorff spaces

Co-authored-by: Adam Topaz<EMAIL_ADDRESS>@adamtopaz
Basics of the category Stonean of extremally disconnected compact Hausdorff spaces. This work was done during the 2023 Copenhagen masterclass on formalisation of condensed mathematics. Numerous participants contributed.

I've modified everything according to Adam's suggestions

@dagurtomas Please click "resolve conversation" on all the conversations above that you consider done. (Unless you still want a maintainer to look/reply to a conversation.)

Merging master and waiting for CI to build to be able to use #find_home

Two comments, but apart from that, LGTM

Two comments, but apart from that, LGTM

Done

Hmm, CI canceled the check "Detect changes to header SHAs / Add annotations (pull_request)". What does that mean?

That check broke following a change in the way we do those headers. Please merge master. That should fix it.


Update doc with the other error that can be thrown.

The error is raised here: https://github.com/nouiz/jax/blob/f578d78f2b93cfba49f158f3f916097de982b725/jax/_src/distributed.py#L194

Did you intend to add that additional commit to this branch?

Did you intend to add that additional commit to this branch?

Yes. But I can split that to another PR if you prefer. I won't modify it again unless you tell it is needed.

It's just a bit awkward when new changes are added after I've already approved initial changes and started the process of pulling them in – it might lead to partially-merged PRs.

Sorry about that. I didn't saw that you approved and started the merge. Will double check/comment about that next time.

Initial commit was merged as 48b90181e54618bf80d5ca99074b8878d94ce479.
If there are other changes you want to make, please open a new PR.


Make drawvis great again

A series of changes which bring the performance of draw vis from "grinding to a halt in the main menu when visualizing a bunch of triangles" to "can zoom out fully inside song select with 120 fps".
Also makes behavior slightly nicer by fixing input regressions related to overlay container changes, and making the root visualised drawable interactive.

👍 💯 ⚡


Failed to commit epoch and reset compute nodes failed

Describe the bug
As the title, one WARN and one ERROR appear in the meta's log.
Then nothing keeps running, compute node seems to exit.
Compactor and Computer node's logs do not contain error/panic.
meta-node-5690.log
compute-node-5688.log
compactor-6660.log
Probably detected before in other issues
To Reproduce
EC2 c5.4xlarge
Use datagen as the connector for nexmark's bid table and then run nexmark q10.
work_node_parallelism = 12
checkpoint_interval_ms = 250
./risedev d
CREATE SOURCE bid (
    "auction" BIGINT,
    "bidder" BIGINT,
    "price" BIGINT,
    "channel" VARCHAR,
    "url" VARCHAR,
    "date_time" TIMESTAMP,
    "extra" VARCHAR
) with (
    connector = 'datagen',
    datagen.split.num = '12',
    datagen.rows.per.second = '2000000'
)
ROW FORMAT JSON;

create materialized view mv_q10 as SELECT
    auction,
    bidder,
    price,
    date_time,
    TO_CHAR(date_time, 'YYYY-MM-DD') as date,
    TO_CHAR(date_time, 'HH:MI') as time
FROM
    bid;

Not necessarily produced every time, but high chance.
Expected behavior
Not sure.
Seems something fails but is expected to be recovered?
Additional context
commit 85722d34d22b3582c5f351bd54a2697f08790412

Sometimes, the entire EC2 is stuck.
Cannot ssh to it.
If there is another bash session window, cannot issue commands and totally no feedback

I saw Mon Sep 12 07:33:48 UTC 2022 [risedev]: Program exited with 137 in the compute node log.
I think exit code 137 means OOM.

I saw Mon Sep 12 07:33:48 UTC 2022 [risedev]: Program exited with 137 in the compute node log.
I think exit code 137 means OOM.

I see, is it expected to OOM right now, i.e. a known issue, for a stateless query but with MV?
If so, maybe I close the issue now as memory management is not done yet.

After #5416, this issue should not occur.
Will check frequently in the near future.


long command display bug

Strip whitespace and newline characters from TTY displayed commands.
Fixed a TTY display bug that occurred when a command was longer than the allocated space in the terminal.
Updated unit tests.

Closes #46

Codecov Report

Merging #50 (49a8e04) into main (247c25e) will increase coverage by 0.07%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##             main      #50      +/-   ##
==========================================
+ Coverage   94.89%   94.96%   +0.07%
==========================================
  Files          10       10
  Lines        1429     1431       +2
==========================================
+ Hits         1356     1359       +3
+ Misses         73       72       -1

Flag
Coverage Δ

unittests
94.96% <100.00%> (+0.07%)
:arrow_up:

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

Impacted Files
Coverage Δ

build_magic/output.py
98.98% <100.00%> (+0.52%)
: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 247c25e...49a8e04. Read the comment docs.


Gets scrolled to last clicked anchor

I am using the inline system to pop up my content . Its an article post which i am popping up , so overflow is there and also a scroll-bar . If I click any other anchors (not related to pop-up , just normal anchor links , tabs or in-page menu )  before opening the pop-up and then  close the pop-up  it gets scrolled to the last clicked anchor !
I am using bootstrap and the scenario is one page based site .

fixed the problem ..
comment line 449
if(mfp._lastFocusedEl) {
    $(mfp._lastFocusedEl).focus(); // put tab focus back
}
...


Fix keyboard shortcuts on macOS

All the CTRL+left, CTRL+right are not working.
We should maybe replace CTRL by ALT on macOS (because the %command+left is used for switching between windows).

Fixed by commit 9a58ac2


Updating only a child in a large vnode/tree

So I realize this may be against the main principle of entrusting differences to the virtual Dom, but on many occasions, I really would prefer to avoid updating 90% of my components and update simply the child that caused the change, reusing all other partial vnodes.
I tried to accomplish this by directly modifying the vnode I've already applied to the DOM, but realized quickly that I probably need to clone the vnode before I can do this.
Before I venture any deeper in this endeavor, is there any advice you can possibly offer me? Would be very grateful for it!

It is not that simple because the old structure (from the parent) holds a reference to the original vnode, which means that if you plan to update the child vnode manually, and eventually update the root vnode, it will be out of sync. I have seen cases where the mutation of the original vnode is ok, but a clone of it is used as the old vnode for the off-cycle mechanism, and that might help.

@caridy Thanks for your assistance. I had to do a lot of re-writes today to get snabbdom and snabbdom-pragma to work in my project, but I've arrived at the point where I need to do child vnode manipulation in order to make my components stateful.
If you have any references to previous attempts at this, do let me know. I will report back my findings here tomorrow.

This is tricky.
I do something similar in my (currently private) fork of this library, so let me share my experience.
First of all, this should be difficult (if not impossible) with Snabbdom's current implementation.
It might be possible via a custom module—taking advantage of Snabbdom's hooks—but I gave up on the idea after playing around with it for a while.
So, what is the problem? You might already understand it, but let's recap; as @caridy mentioned:

the old structure (from the parent) holds a reference to the original vnode, which means that if you plan to update the child vnode manually, and eventually update the root vnode, it will be out of sync

What does this mean? Imagine the following example:
let item1 = h('li', {id: 1}, 'hello')
let item2 = h('li', {id: 2}, 'world')
let list  = h('ul', [item1, item2])

Where you want to change the first list item to h('li', {id: 1}, 'goodbye').
You could do:
let newItem1 = h('li', {id: 1}, 'goodbye')
patch(item1, newItem1)

And it would work; as in: the DOM would be updated.
However, list will still maintain a reference to item1 instead of to newItem1: which will likely cause problems if list is ever updated.
What did I do to allow updating sub-trees?
I changed the core of Snabbdom.
Currently, Snabbdom works with the notion of virtual nodes: which are an abstract representation of element nodes, text nodes, or even comment nodes. I extended Snabbdom to also allow the usage of references to virtual nodes.
This lets us do something similar to the following:
let item1 = ref(h('li', {id: 1}, 'hello'))
let item2 = h('li', {id: 2}, 'world')
let list  = h('ul', [item1, item2])

item1.patchWith(h('li', {id: 1}, 'goodbye'))

I made it so that Snabbdom renders the content of a ref but, at the same time, I allow patching the content of a ref against a new virtual node—keeping everything synchronised. This effectively allows the kind of sub-tree patching you seem to desire.
Is this easy to implement? Well, conceptually it isn't very complicated; but one has to dive into the core of the library.
For multiple reasons (mainly due to the particular way I'm using Snabbdom) this was my approach; I hope the insight is useful.
Again: it might be possible to achieve this using a custom module. Give it a try and let me know!
On another note: Have you looked at Snabbdom's thunks? If you're having performance issues, they might be something to look at.

@nunocastromartins it sounds indeed quite tricky.. I guess a deep clone will not cut it then, as it sounds like snabbdom will keep trying to reference the old and "outdated" vnode inside its entire vnode tree.
It feels like a big drag on performance for me to have to draw up a brand new vnode tree every time. I will look into this tomorrow.

There is actually another (much simpler) option; I didn't test this, but I'm confident something like this should work (I believe Snabbdom never clones the children):
let list  = h('ul', [h('li', {id: 1}, 'hello'), h('li', {id: 2}, 'world')])

list.children[0] = patch(list.children[0], h('li', {id: 1}, 'goodbye'))

Downsides: you're directly manipulating the children array, so you'll have to keep track of the index of the element you wish to mutate.
I'm unaware of any other downsides (except that it feels hacky); someone with a fresher memory of the source code might provide a couple more. :-)

what I normally do is the following:
let list = h('ul', [
  h('li', {id: 1}, 'hello'),
  h('li', {id: 2}, 'world')
])

const cachedVNode = list.children[0];
const oldVNode = Object.assign(cachedVNode);
Object.assign(cachedVNode, h('li', {id: 1}, 'goodbye'));
patch(oldVNode, cachedVNode);

Of course, this only work if the new vnode created by calling h has the same shape as the previous one, including key, sel, etc. As a side effect, you're mutating the original vnode (cachedVNode), and its corresponding elm from the DOM, so anyone holding a ref to it will diff correctly in a separate tick. But as you can see, this is not pretty, and it is still tricky, e.g.: if the new h does not have children, and the old one has children, you will have to set children to an empty array, otherwise it will keep the old ones in the DOM. We get away with all this in our internal implementation because we have a very restrictive shape for things that can be rehydrated in a separate fiber.

Hi guys.
I'm still having trouble getting this to work well in my case. I have complex trees and the only way I find to be able to fix this is to generate new children all the way down to the component that has changed. I can leave other children unchanged in the tree.
It feels like I'm left with a couple options.

Ask for an enhancement request for Snabbdom, for a feature I'm not myself sure how it can be implemented.
Do deep-cloning. Not sure what the performance loss is.
Re-render each component down to the bottom component that requested the update in my lifecycle engine.

Right now I am using the last option, but it feels really wasteful to re-render components that should theoretically not have changed at all (except for the child at the very bottom of its children tree).

New thought.
snabbdom uses hooks for all sorts of things, maybe this is the way to go?
Would snabbdom allow me to pass an element with tag "MyComponent", and let me "resolve it" with a hook to actual html ('s etc.)?
So say I pass this to snabbdom's patch method:

  <MyComponent>

Some text

  </MyComponent>

Would a hook let me "resolve" it to the below?

MyComponent

Some text

If this is possible, I may have under-estimated the power of snabbdom. 😄

Would snabbdom allow me to pass an element with tag "MyComponent", and let me "resolve it" with a hook to actual html (
's etc.)?

I don't think you can do this with hooks. 😞

Right now I am using the last option, but it feels really wasteful to re-render components that should theoretically not have changed at all (except for the child at the very bottom of its children tree).

Rerendering these components should be fast, exactly because the patching algorithm will figure out that nothing has changed; it will only effectively rerender (in the DOM) the child that changed.
Maybe you should provide us a more concrete example so that we can figure out why you're having performance issues.

@caridy your thoughts on passing custom "unresolved"  components (eg. ) and resolve them inside snabbdom hooks (aka modify the vnode inside the hook to regular html elements)? Will the snabbdom code crash and burn or is this what I should have been thinking from the start?

@wbern that's a no go for me. I will recommend you to look at web components, specifically web components semantics / shadow-dom etc. You can probably barrow some ideas from that and apply it to a thunk-like implementation in snabbdom. Essentially, you need to make a cut in the fiber of components, so you always render and patch until that cut, and while patching the node that makes the cut, you can decide if (based on some internal state) you need to patch its internals.
I know, I know... a lot of words and a little to hold onto, but this is not a trivial problem. I don't think you will be able to solve it if you don't introduce some sort of stateful vnode that can rely on the diffing algo to determine how to process and patch its internals based on its own state.

Hi @caridy. I think what you're saying makes sense.
In the end, I don't think I need to integrate that tightly with Snabbdom for custom components. Granted, it takes a bit of wits to do some sort of pre-processing prior to letting Snabbdom generate content on the page, but it is possible with your own JSX-generator that wraps snabbdom-pragma.
Closing this issue, thanks for the input everyone.

It can be very simple
function partialPatch(vNode, newVNode) {
    return Object.assign(vNode, patch(vNode, newVNode))
}


Update Ropsten TTD to XXL

Clone of https://github.com/ChainSafe/lodestar/pull/4072  to be merged to the new branch

nvm, see https://github.com/ChainSafe/lodestar/pull/4072#issuecomment-1139686445


Vulnerability roundup 108: go-ethereum-1.10.8: 1 advisory [5.7]

search, files

[ ] CVE-2021-41173 CVSSv3=5.7 (nixos-21.05, nixos-unstable)

CVE details
CVE-2021-41173
Go Ethereum is the official Golang implementation of the Ethereum protocol. Prior to version 1.10.9, a vulnerable node is susceptible to crash when processing a maliciously crafted message from a peer. Version v1.10.9 contains patches to the vulnerability. There are no known workarounds aside from upgrading.

Scanned versions: nixos-21.05: 4f37689c8a2; nixos-unstable: 942eb9a335b.
Cc @RaghavSood
Cc @adisbladis
Cc @kalbasit
Cc @lionello

We no longer support nixos-21.05, but this has been fixed in the currently supported NixOS versions:

nixos-22.05: go-ethereum-1.10.18
nixos-unstable: go-ethereum-1.10.25


#where method refactor to allow Model.index_name('index').where(...)

Hi there,
I've tried to implement a feature you have in your TODOs.
With this PR, you can now use this syntax.
Post.index_name("user_id").where(category_name: "Entertainment")

To allow this, I've introduced a new class to imitate ActiveRecord: Dynomite::Query.
When you call one chain-able method like where or index_name, a new instance of Dynomite::Query is created. This class is itself an enumerable, so you can map/select/reduce it like a standard array.
This is a very fast implementation, loving to hear any feedback!

@tongueroo ... I've just seen the edge branch :
Too bad I haven't seen it earlier. Let me know if you need help to make it ready.

Thanks. Yup. The new version will be ActiveModel compatible. Found the interface to be much easier to use.
For now, thinking running the edge version to some QA would probably help. It may be a long while before will look at it. Been running the edge branch on a few internal jets projects though.


TS-4653: esi plugin - disable HTTP_COOKIE variable by default and imp…

…lement a whitelist mechanism to allow the specified cookies for it
Original code and idea contributed by Chris Rohlf<EMAIL_ADDRESS>@bryancall / @jpeach , pls help to review. Thanks a lot.

Linux build failed! See https://ci.trafficserver.apache.org/job/Github-Linux/322/ for details.

FreeBSD build successful! See https://ci.trafficserver.apache.org/job/Github-FreeBSD/428/ for details.

[approve ci]

FreeBSD build successful! See https://ci.trafficserver.apache.org/job/Github-FreeBSD/429/ for details.

FreeBSD build successful! See https://ci.trafficserver.apache.org/job/Github-FreeBSD/430/ for details.

Linux build successful! See https://ci.trafficserver.apache.org/job/Github-Linux/323/ for details.

Looks like this version of the patch leaves out wildcard support https://github.com/apache/trafficserver/pull/798/files#diff-a6bc69fbcc52f7fff04507b2a650ac4fR370 I think its sane to support that functionality as long as its not the default

@struct , i can add the wildcard support tonight.
e.g. whitelistCookie *
That will mean we allow all cookies when we are using HTTP_COOKIE esi variables

@zwoop can you take a look at this as well?

wildcard support is added.

FreeBSD build successful! See https://ci.trafficserver.apache.org/job/Github-FreeBSD/431/ for details.

Linux build successful! See https://ci.trafficserver.apache.org/job/Github-Linux/324/ for details.

@bryancall / @jpeach / @zwoop any comments here? thanks.

@zwoop , i just did the cleanup. Good to merge?

FreeBSD build successful! See https://ci.trafficserver.apache.org/job/Github-FreeBSD/442/ for details.

Linux build successful! See https://ci.trafficserver.apache.org/job/Github-Linux/336/ for details.

@sudheerv can you help to do a review for me?

@shukitchan Overall it looks good.  I had one minor comment.

updated just now. will merge after squashing commits into one. thanks.

Linux build failed! See https://ci.trafficserver.apache.org/job/Github-Linux/353/ for details.

FreeBSD build successful! See https://ci.trafficserver.apache.org/job/Github-FreeBSD/457/ for details.

Linux build successful! See https://ci.trafficserver.apache.org/job/Github-Linux/352/ for details.


Rename this project

I was made aware [1] the name Yahc might be confused with a rust community member who goes by the name Yaahc. Therefore I am planning to rename this project using one of the following:

ht: This would have been the best pick, but it is already being used by a similar project https://github.com/mark-burnett/ht
rq: This name is being used by a popular python job queue library. Although it is possible to append -rs at the end to avoid a name clash.
htyr: Not sure what it means but for some reason I like it.

[1] https://www.reddit.com/r/rust/comments/k0aika/yahc_yet_another_httpie_clone_in_rust/gdgza01?utm_source=share&utm_medium=web2x&context=3

It seems that https://github.com/mark-burnett/ht is unmaintained. Maybe it is still possible to use the same name if those projects can be merged.

I'd be happy to transfer the name.  I definitely didn't intend to name squat ht, and would be happy for it to be taken over by this project :)

@mark-burnett Thank you very much for entrusting the name ht to this project! I will start the process of renaming yahc shortly.
As for transferring the crate name, I think it would be more involved but still doable.

yahc has been renamed to ht and the crate name transfer is now complete 🎉.
Thanks to @mark-burnett for agreeing to transfer the name and @andresv for initiating the conversation.

yahc has been renamed to ht and the crate name transfer is now complete 🎉.
Thanks to @mark-burnett for agreeing to transfer the name and @andresv for initiating the conversation.

If you're not aware, /usr/bin/ht is also used for a TeXLive program (Debian: texlive-plain-generic, Arch: texlive-core) and causes a collision when installing (AUR comment).

As a random passerby (cool project btw), I vote for xh or "eXtra Http". Some quick searching doesn't seem to show it existing.

hey, debian maintainer here, there's a policy in debian that no two packages are allowed to install a binary with an identical name so we'd need to rename it there too. You can research if the name is already taken using the search:
https://packages.debian.org/search?suite=default&section=all&arch=any&searchon=contents&keywords=usr%2Fbin%2Fht
(you might need to check all of usr/bin/foo, usr/sbin/foo, bin/foo and sbin/foo)

Thanks, @kpcyrd, would it be possible to do something similar to the ht package in Arch, i.e apt install ht which installs a binary named ht-rust? I think bat does something similar.

I think this is a horrible hack and not a solution. Upstream should at best provide a unique name for the binaries which is defined upstream. this would also create diversity in which binary is being called when ht is installed using cargo. A uniform experience should be the goal of a CLI tool.

Although I'm very of the name ht, I am open to the idea of renaming ht to a different name. I am saying this because it would become harder as the number of places ht is published increases. Some of the names that come to my mind include:

rq:  stands for request
hr: stands for http-request
xh which was suggested by @mehcode

rq is taken by python3-rq/Redis Queue (on Debian) and Record Query (on NixOS).
hr is the name of several horizontal ruler programs (1, 2, 3). One of them is on crates.io, and multiple are in the AUR.
I can't find anything called xh, except an empty NPM package. So that would be suitable.

That settles it then. Moving to the new name would require the following steps (correct me if I am missing anything):

Replace any ht references with xh (including the demo).
Temporarily remove the installation section from README.md.
Make a new minor release (should be ok since we haven't hit v1.0 yet).
Upload the renamed binary to crates.io

ht is currently being published in the following places:

homebrew: contributed by @dtrodrigues
Arch: contributed by @orhun
nixpkgs: contributed by @payasrelekar
scoop (pending): contributed by @myty

After some googling, I found docs on how to rename a package in homebrew. However, I am not sure how it would be done for others.

Make a new minor release (should be ok since we haven't hit v1.0 yet).

Do you mean a final release on crates.io pointing people towards the new name? How heavy-handed would it be?

No, I meant the new xh release to be v0.7.0.

Do you mean a final release on crates.io pointing people towards the new name? How heavy-handed would it be?

I think a simple message like this would suffice:
ht has moved to [xh](https://crates.io/crates/ht). For more context behind the change, see
[#1](https://github.com/ducaale/ht/issues/1)

ht has now been successfully renamed to xh. Thanks to @mehcode for suggesting the new name, and thanks to everyone who raised the tex-live name collision issue.

I renamed ht to xh: https://archlinux.org/packages/community/x86_64/xh/
You can add the same (s/ht/xh/) Arch Linux instructions back (#43) (if you like) or I can submit a PR again.

Thanks, @orhun. I've added it back to README.md.


Is there a way to clear the text field back to the "placeholder" text?

I have a X that I want to make it clear back to what the placeholder is showing. Is there a way to revert back?

This should do it:
closeButton.onClick ->
  someInput.input.value = ""

I'm closing the issue, please reopen if you need more help


Define DAQ Interface

The Interface of AbstractDAQ is currently not well defined and the RedPitaya implementation is certainly leaking too much implementation details. This needs to be sorted out. This issue is for summarizing ideas around this.

From my perspective, the params dict pretty much replicates the MDF. If we just require a function startTx(scanner, mdf) with a given MDF file with the parameters from the acquisition group filled and then a function readFrames(scanner, mdf, isBackground) we should be fine, shouldn’t we? This also avoids replicating stuff from MPIFiles.

So yes the params dict replicates the MDF which is quite nice since it helps us directly storing the measurement data into an MDF. Regarding your example its is not clear what the mdf is. Currently an MDF has no in-memory representation (i.e. a proper type) but we read MDF data on demand. If mdf is really meant to be a file I kind of see an egg and a chicken problem. One then first needs to generate an MDF before making the measurement. This is IMHO not  really a good interface. In particular it will be not so nice when performing measurements that are never stored in a file (i.e. online measurements). That would require building some dummy measurement. And actually in order to generate an MDF one right now would need a parameter dict anyway.

Yes, I thought about just using a scratch MDF file but I get the point about the online measurement which might live in some network storage. But in principle you agree that the MDF acquisition  group is all we need? Would it then make sense to create a MDF representation (maybe using Configurations.jl) and have methods to convert between the duct, the file and the representation? We could then forward all methods working on an MDFFile to the representation which would also give us the benefit of being typed correctly. A possible name could be MDFInMemory.

I agree that using types / structs instead of dicts can be better in the long run. There is also a performance issue with dicts since the type information is not preserved. For this reason I actually introduced the DAQ params: https://github.com/MagneticParticleImaging/MPIMeasurements.jl/blob/master/src/DAQ/Parameters.jl
If the MDF/acquisition is sufficient is not so clear to me. For calibration scans certainly also the calibration group is required. But I agree that MDF/acquisition is the core of it
If I get it right you are mostly struggling with that I mix up acquisition parameters and hardware parameters in the DAQ section of the TOML. I 100% agree that this is not good and that we should better structure this.
In my opinion we should make improve the Sequence and make it control all SeFo but also the drive field parameters. Or is your take that we should unify the sequence infrastructure and the MDF/acquisition object you were talking about above.

I am pinging @hofmannmartin since he has been working on actually the same topic in the context of MPISimulations. There the idea was also to use TOML files for describing sequence parameters and so on. Makes sense to unify the thought and move the infrastructure to MPIFiles and not MPIMeasurements.

I agree that using types / structs instead of dicts can be better in the long run. There is also a performance issue with dicts since the type information is not preserved. For this reason I actually introduced the DAQ params: https://github.com/MagneticParticleImaging/MPIMeasurements.jl/blob/master/src/DAQ/Parameters.jl
I will make a pull request for MPIFiles with a proposal for a struct. I think this is better placed in there since it is strongly linked to the MDF. After the MDFInMemory is filled it can be converted to an MDFFile after applying checks on the data consistency.
If the MDF/acquisition is sufficient is not so clear to me. For calibration scans certainly also the calibration group is required. But I agree that MDF/acquisition is the core of it
It sounds like we really need a definition of sequences and protocols first. A calibration procedure definitely fits into a protocol scheme.
If I get it right you are mostly struggling with that I mix up acquisition parameters and hardware parameters in the DAQ section of the TOML. I 100% agree that this is not good and that we should better structure this.
Yes, thats my main concern. I will come up with an extended proposal for the hardware definition and then we can see if that split can be done nicely.
In my opinion we should make improve the Sequence and make it control all SeFo but also the drive field parameters. Or is your take that we should unify the sequence infrastructure and the MDF/acquisition object you were talking about above.
See above.
I am pinging @hofmannmartin since he has been working on actually the same topic in the context of MPISimulations. There the idea was also to use TOML files for describing sequence parameters and so on. Makes sense to unify the thought and move the infrastructure to MPIFiles and not MPIMeasurements.
Do you think it fits in the scope of MPIFiles or should we have a package MPIProtocols with definitions for sequences and protocols? This can be shared between MPISimulations and MPIMeasurements and can also provide tools for creating protocols and sequences.

I will make a pull request for MPIFiles with a proposal for a struct. I think this is better placed in there since it is strongly linked to the MDF.
I agree 100%.

Do you think it fits in the scope of MPIFiles or should we have a package MPIProtocols with definitions for sequences and protocols?
I think it fits into the scope of MPIFiles. We can split things off later if we need to. Best is to put things into dedicated folders and then one can move things around (if needed). MPIFiles right now already has a little bit larger scope since it should provide the base infrastructure for everything else. So having things there MPIMeasurements and MPISimulations can nicely share infrastructure.  (Side note: In Julia one can nowadays also have multiple packages within a single Git repository, see https://github.com/timholy/SnoopCompile.jl  This can have advantages when wanting to structure out smaller things without the need to make dedicated repositories, which have a higher maintenance cost. This is nothing we need to do right now but just wanted to point this out.)

In the context of MPISimulations It would really great split between acquisition parameters and the hardware setup. This would be similar with an actual measurement, where an acquisition parameter describing a 12 mT excitation does not necessarily mean that a 12 mT excitation field was actually present in the hardware.I see the acquisition parameters more as a way to achieve reproducibility. Such that if I put the same parameters into the same hardware, I get the same excitation.
What is missing is maybe a generalized and unified way to describe a hardware setup. At least from the simulation point of view.

With a clear definition of a sequence as proposed in #22 we should also have a clear interface for the DAQ, at least from my perspective. This means that resolving https://github.com/MagneticParticleImaging/MPIFiles.jl/issues/37 also resolves this issue at least partially. The DAQ should then accept all electrial transmit channels and set up this part of a sequence on its own. The receive side should also work with the current definition of a sequence.
Am I missing something here?


Troubles with docs/Boycott.md

Is there any reason for Google not being in the Boycott list, and also not being in the allow list? It seems like it's been forgotten at all.
I also don't see how are Telegram and Nginx considered Russian products (and much less businesses), apart from being vaguely originated from Russia (as well as Google).

There are several companies on the boycott list that I'm not familiar with, so I have for sure missed some of them.

Also, there are indeed some missing companies that are both definitely Russian and a business (e.g. Tinkoff, Alfa and other banks).

What's written next are my pure opinionated thoughts with almost no intended facts underneath.
As a developer in open-source community, I believe nothing should be deleted or suspended forever. And what I want much less is digging through all of my dependencies to see if they have any Russian origins. Even if I wanted to do this, I would probably also write a script that automatically turns every package and repository affected by the boycott back to stable functioning after Russian leadership is suspended.
I don't consider Google, Telegram, and Nginx Russian products. I would as well be interested to know how "Russian" should something be to be included in the boycott. Does something that was not Russian but is now in Russia become boycotted (if a coin from another country is taken to Russia), and vice-versa (if a Russian-originated open-source developer takes a flight to Florida and ditches his Russian passport).
I think concepts and recipes should not, for sure, be included in the boycott, like dumplings or beef stroganoff. This includes all of the Russian-originated open-source software (because source code is a recipe of some kind).

Unrelated to the issue: we have a saying here, "Moscow is not Russia" (can be googled easily). After 24 Feb, my brain just asked "Well, if it's not Russia, then what it actually is?". The answer made many people laugh and since lives in the location field of my GitHub profile: "Moscow, Ukraine".

I don't want to spend time on philosophy here.
If you think Google needs to be on any of the lists, explain why and maybe we can include it.


Expose get_tree_structure

https://github.com/rootpy/root_numpy/blob/master/root_numpy/src/tree.pyx#L65-L83
I've got code that will want to grab a list of branches for a given TTree (well a TChain). All current methods require a filename. Probably would be nice to extend the functionality. Perhaps something like updating https://github.com/rootpy/root_numpy/blob/master/root_numpy/_tree.py#L56-L73 to be
def list_branches(*args, **kwargs):
    """Get a list of the branch names of a tree in a ROOT file.
    Parameters
    ----------
    filename : str
        Path to ROOT file.
    treename : str, optional (default=None)
        Name of tree in the ROOT file.
        (optional if the ROOT file has only one tree).
    ==========
    tree : ROOT TTree instance
        The ROOT TTree to list branches of
    Returns
    -------
    branches : list
        List of branch names
    """

    if args[0].Class() in ['TChain', 'TTree']:
        return list(_librootnumpy.get_tree_structure(args[0]))
    elif type(args[0]) is str:
        return _librootnumpy.list_branches(args[0], kwargs.get('treename', None))

This might also require exposing get_tree_structure perhaps using cpdef instead of cdef.

Note that there is an equivalent way with just PyROOT:
branches = [i.GetName() for i in t.GetListOfBranches()]

so I'm not sure if it's a good idea to add this.

Right, list_branches is really just a convenience function for interactive use (ipython, etc).
On a related note, I would like deprecate list_structures and implement get_structure. list_structures currently returns an ordereddict of branch names to lists of (leaf_name, leaf_type). Since it's not a list (it's a dict), I don't think it makes sense to call it list_structures. get_structure will go beyond that to handle subbranches, and include the leaf shape (akin to numpy's dtype shape) for array branches. Internally, tree2array no longer uses list_structures to avoid looping over the branches multiple times. This is really just a function to help debugging by providing an easy way to extract the layout of a tree.

Closing for now. Will be deprecating list_structures (targeting 5.0.0) in favour of a possible future more powerful get_structure function.


Go through and make sure everything is linked as much as possible.

We need to make sure we link to all external resources. Also, within our own docs we need to make sure that when we refer to something, it links to the page for more details. Specifically on the FAQ page and the different functions we talk about.

Fixed


error: torch 0.1.12.post2 is installed but torch==1.2.0 is required by {'torchvision'}

when i  python setup.py install
Processing dependencies for pretrainedmodels==0.7.4
error: torch 0.1.12.post2 is installed but torch==1.2.0 is required by {'torchvision'}

Is that not fairly straightforward? You have an incredibly old version of pytorch installed, version 0.1.12 apparently, but the current version is like 1.3 or 1.4, and pretrainedmodels relies on torchvision, which itself relies on up-to-date pytorch. You need to install the latest version of pytorch


Music does not play (ubuntu)

Please help
./Atraci
Gtk-Message: Failed to load module "pantheon-filechooser-module"
Gtk-Message: Failed to load module "canberra-gtk-module"
[4854:1230/205325:INFO:CONSOLE(1)] ""This module is meant to be used by cli. If you want to use ytdl programmatically, visit https://github.com/fent/node-ytdl-core"", source: /tmp/.org.chromium.Chromium.4uUMos/node_modules/ytdl/index.js (1)
ATTENTION: default value of option force_s3tc_enable overridden by environment.
[4854:1230/205326:INFO:CONSOLE(1)] ""failed to fetch latvia.json"", source: file:///tmp/.org.chromium.Chromium.4uUMos/js/app.js (1)
[4854:1230/205332:INFO:CONSOLE(23)] ""VIDEOJS:" {"message":"Failed to set the 'currentTime' property on 'HTMLMediaElement': The element's readyState is HAVE_NOTHING.","name":"InvalidStateError","code":11,"stack":"Error: Failed to set the 'currentTime' property on 'HTMLMediaElement': The element's readyState is HAVE_NOTHING.\n    at Error (native)\n    at t.Kd (file:///tmp/.org.chromium.Chromium.4uUMos/js/vendor/video-js/video.js:105:92)\n    at V (file:///tmp/.org.chromium.Chromium.4uUMos/js/vendor/video-js/video.js:59:80)\n    at t.currentTime (file:///tmp/.org.chromium.Chromium.4uUMos/js/vendor/video-js/video.js:60:150)\n    at PlayTrack (file:///tmp/.org.chromium.Chromium.4uUMos/js/app.js:1:8526)\n    at HTMLDivElement.\u003Canonymous\u003E (file:///tmp/.org.chromium.Chromium.4uUMos/js/app.js:1:23765)\n    at HTMLDivElement.n.event.dispatch (file:///tmp/.org.chromium.Chromium.4uUMos/js/vendor/jquery-2.1.1.min.js:3:6404)\n    at HTMLDivElement.r.handle (file:///tmp/.org.chromium.Chromium.4uUMos/js/vendor/jquery-2.1.1.min.js:3:3179)"} "Video is not ready. (Video.js)"", source: file:///tmp/.org.chromium.Chromium.4uUMos/js/vendor/video-js/video.js (23)
[4854:1230/205332:INFO:CONSOLE(1)] "Uncaught TypeError: Cannot read property 'entry' of undefined", source: file:///tmp/.org.chromium.Chromium.4uUMos/js/app.js (1)
[4854:1230/205333:INFO:CONSOLE(1)] ""failed to fetch latvia.json"", source: file:///tmp/.org.chromium.Chromium.4uUMos/js/app.js (1)

<bountysource-plugin>
---
Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/29489408-music-does-not-play-ubuntu?utm_campaign=plugin&utm_content=tracker%2F3178491&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F3178491&utm_medium=issues&utm_source=github).
</bountysource-plugin>

@fa7ad Is this why the program crashes on Windows 10? I tried compatibility modes and running the program as administrator, no success.

probably, can't say for sure.
personally i'm using kaku and sometimes mps-youtube. feel free to use anything else but atraci is not coming back afaik


drawGeometry on rotated map

Describe the bug
We draw a Point geometry that is in the correct place on the urotated map. On a rotated map, points are drawn in the wrong location.
Urotated

Rotated

To Reproduce

Create ol.layer.VectorImage
User layer postrender event
Obtain vectorContext with getVectorContext(event)
Create Point geometry -> vectorContext.setStyle(style) ->  vectorContext.drawGeometry(point)

There is an problem with VectorContext for VectorImage layers.  Drawing is also misplaced if the layer imageRatio is not 1.


Fix naming and doc for maybe_snapshot_abort

context: https://github.com/tikv/raft-rs/issues/477
Minimal fix to avoid confusion.

Thanks!


Add cycle stats exporter

Continue building conversions between our format and BatteryArchive's

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

12 of 12 (100.0%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.2%) to 87.913%

Totals

Change from base Build<PHONE_NUMBER>:
0.2%

Covered Lines:
851

Relevant Lines:
968

💛  - Coveralls


feat: Added email verification system

✨ Codu Pull Request 💻
Fixes #1049
Pull Request details

Implemented email verification part if the user want's to change email.

Any Breaking changes

None

Associated Screenshots

@NiallJoeMaher @John-Paul-Larkin Let me know what you think about this.

@NiallJoeMaher Can you check if any more changes require?
Key changes

Changed Migration file name (Removing snapshot and migration file and then created new with proper name)
Removed api/update_email/route.ts and introduced trpc method for updating email.
Introduced few trycatch block
Changed POST to GET for token verification

Key changes

Introduced checkIfEmailExists to check email used by any user already
Now email schema would be unique()
Error was not shown in toast previously (Updated client page of settings to support this)

A few conflicts, if you could delete the generated migration file and the meta files that were generated, pull the changes and re-run with npx drizzle-kit generate --name=email-verification. It should fix any issues that are holding things up with the migration conflicts and the weirdness that was happening.

A few conflicts, if you could delete the generated migration file and the meta files that were generated, pull the changes and re-run with npx drizzle-kit generate --name=email-verification. It should fix any issues that are holding things up with the migration conflicts and the weirdness that was happening.

Yeah sure. Let me do that once.

Your package.lock is different than the main repo, so it should probably be undone, and make sure you are installing with the correct node.js version. And just in case it fails the check after that make sure you run npm run prettier:fix to ensure you don't get stopped at the next hurdle. Once the checks are passing I'll approve and merge .


Unknown call

I have an express-generator application set up
All of the routes are default just the error.hjs and index.hjs (I am using Hogan)
I was watching my server and noticed this come across
GET /img/partBg.png 200 2.114 ms - 263868
GET /robots.txt 404 10.799 ms - 776
GET / 200 13.124 ms - 5883
GET /robots.txt 404 11.282 ms - 776
GET / 200 8.488 ms - 5883
GET http://ip.cn/ 200 10.066 ms - 5883
The last line confused me because with express and the generator set up I do not see what domain is being called.
Now that is not my domain, when I go to my domain I get the standard
GET / 200 44.633 ms - 5883
I am trying to figure out how that GET command with a URL came through.

One note, I have been using Express-generator for the last year and have never seen anything like that come through which is why it concerned me.


style(acme): just use our table tools to shallow copy instead of tablex

Summary
Just a small chore to use our table tools.
Checklist

[ ] ~The Pull Request has tests~
[ ] ~A changelog file has been created under changelog/unreleased/kong or skip-changelog label added on PR if changelog is unnecessary. README.md~
[ ] ~There is a user-facing docs PR against https://github.com/Kong/docs.konghq.com - PUT DOCS PR HERE~

No need to cherry-pick to EE as it is already here:
https://github.com/Kong/kong-ee/pull/10056

Checked manually that this change also exists in kong-ee


Write a Julia program to convert a string to an integer

Description
Write a Julia program to convert a string to an integer
Input  : "123"
Output : 123

How to contribute

Save the solution in program/convert-a-string-to-an-integer.jl file
Add convert-a-string-to-an-integer.jl file in convert-a-string-to-an-integer folder

!assign


fix(controller): re-allow changing executor args

Fixes #12315
Motivation

this was unintentionally removed in #8009 (see my review comment), which was meant to remove deprecated config flags and accidentally removed this as well

it was most certainly on accident as the PR description & issue description don't mention this, and the docs were left as-is for executor args
unfortunately this means that 3.3 was missing this entirely and current versions of 3.4 and 3.5 were too

should be able to backport this to 3.4.x at least and get into a 3.5.x patch release

See my root cause analysis in https://github.com/argoproj/argo-workflows/issues/12315#issuecomment-1913359846
Modifications

add back the functionality to configure args for the Executor

also add a (regression) test for customizing the Executor container

the args as well as resources.limits, since those were previously untested in this file
named the same as TestMainContainerCustomization

also fixes a misnamed test in the same file

Verification

added a new test for some previously untested executor container customizations

Unrelated E2E test failure seems to be due to #12413, c.f. #12596

Hmm this test failure is kinda annoying, do you have any opinions on the review process when there is a flaky test @agilgur5?
I think perhaps urgent PRs can be expedited but others have to wait until the tests pass?

We can't skip tests to merge, they're required CI checks after all. Only repo admins might be able to skip them (which I assume is only Leads, but idk).
In the case of admins, I think it's fine if we have agreement that it's a test flake.
But realistically we really need to fix or skip a flake that's hit this frequently -- i.e. the flake is one of the highest priority since it blocks merging, causes confusion, etc.

We can't skip tests to merge, they're required CI checks after all. Only repo admins might be able to skip them (which I assume is only Leads, but idk). In the case of admins, I think it's fine if we have agreement that it's a test flake.

Ah okay I thought we'd be getting those rights after the membership changes, perhaps not something we need to think about in that case.

But realistically we really need to fix or skip a flake that's hit this frequently -- i.e. the flake is one of the highest priority since it blocks merging, causes confusion, etc.

Yeah I agree on this, actually I have some opinions on e2e testing, I will open an issue about that.

Ah okay I thought we'd be getting those rights after the membership changes, perhaps not something we need to think about in that case.

I believe we'd have at least the "Write" role, not sure about "Maintain" or "Admin" roles

Merged main to fix E2Es as #12596 is now merged


Feature/numbering results

Added numbering to the results.
Added a <hr /> to differentiate the results because after adding the count, the faint grey line disappears (might be a way around it tho').
Note: This is a feature that should be turned off by default & only used when needed.
Closes #198

DO NOT MERGE! A side feature that is not needed at this time. Just something that was mentioned to be good to have when error checking.

This could be an env variable. Only show numbers when and env variable is set.


/api/v1/vulnerabilities contains duplicate field names

The non_normative fields are mentioned in the parent json field already. See image below.

I think this is working as designed. The values of the normative fields (from the Vulnerability) may differ from those of the non-normative fields (from the Advisory). Is that correct @bobmcwhirter?

I see... perhaps it deserves a deeper discussion then. Ideally the API should expose a reasonable abstraction of all the internal data. So what if description != non_normative.description? Shouldn't the REST endpoints abstract those cases and only expose a single description deciding internally which one has precedence e.g. description has higher priority in respect to non_normative.description?

Or I might've been not fully understanding the meaning of non_normative. Perhaps it might be matter of renaming fields to a more meaningful name? i might be wrong, as always :)

We could collapse them into this, maybe:
      "vulnerabilities": [
        {
          "cwe": "string",
          "description": "string",
          "discovered": "2024-07-15T20:41:34.298Z",
          "identifier": "string",
          "modified": "2024-07-15T20:41:34.298Z",
          "normative": true,
          "published": "2024-07-15T20:41:34.298Z",
          "released": "2024-07-15T20:41:34.298Z",
          "title": "string",
          "withdrawn": "2024-07-15T20:41:34.298Z",
          "score": 0,
          "severity": "string"
        }
      ]

So the backend would populate those fields from the Vulnerability if it exists (normative=true) or if it doesn't, the Advisory (normative=false). We could do that easily enough, but I'd want to answer 2 questions beforehand:

Will the user ever care to see the non-normative fields if both entities exist?
Should we account for potentially multiple advisories, i.e. do we need an array of non-normative entities?

This is my personal opinion, not an official one, so I encourage all to disagree :)

Will the user ever care to see the non-normative fields if both entities exist?

A user does not care whether or nor there are non-normative fields, he only cares to see a single description|title that describes the Vulnerability he is looking at. I doubt the user will be interested in looking at descriptions|titles twice (the non_normative one and the parent one). In case there are two different titles|descriptions (the default and non-normative) the user will be interested in read the most accurate one (the one the server thinks is more accurate) or a new title that summarizes the two titles|descriptions in a single one (like a human would do when it comes to merge 2 sentences)

Should we account for potentially multiple advisories, i.e. do we need an array of non-normative entities?

Just like I mentioned in my reply above, I believe a user wants to see only one discovered, modified, published, released, withdrawn, etc fields regardless of the fact that there might be multiple Advisories having an opinion about the vulnerability
The only exception where it might be important to have an array of non-normative entities would be the case of score & severity. E.g. Advisory 1 says it has medium severity but Advisory 2 says it has High severity.

I'd vote dropped non normative info and guide folks to ingesting CVEs.


Update Kani version to 0.39.0

Update dependencies, changelog and crate versions.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 and MIT licenses.

Auto generated release notes:
## What's Changed
* Limit --exclude to workspace packages by @tautschnig in https://github.com/model-checking/kani/pull/2808
* Update Rust toolchain to 2023-10-05 by @tautschnig in https://github.com/model-checking/kani/pull/2802
* Automatic toolchain upgrade to nightly-2023-10-06 by @github-actions in https://github.com/model-checking/kani/pull/2812
* Update Rust toolchain to 2023-10-09 by @tautschnig in https://github.com/model-checking/kani/pull/2814
* Avoid two regression test warnings by @tautschnig in https://github.com/model-checking/kani/pull/2815
* Automatic toolchain upgrade to nightly-2023-10-10 by @github-actions in https://github.com/model-checking/kani/pull/2816
* Fix panic warning and add arbitrary Duration by @celinval in https://github.com/model-checking/kani/pull/2820
* Upgrade toolchain and fix test by @celinval in https://github.com/model-checking/kani/pull/2822
* Update CBMC version to 5.94 by @celinval in https://github.com/model-checking/kani/pull/2821


Make sure we can access the installed python libraries

Describe what this PR does and why we need it:
Sets the permissions on the local python directories so that we can import the needed molecule libraries.

Coverage remained the same at 40.97% when pulling fa9535e252ef6ebe94f37d79884fa79a925cd4a1 on fabianvf:molecule-test-container-perms into ec7ed105f877e13a02c51069fd418f20450a9751 on openshift:master.

/lgtm


VM import/export

please add the required policy and roles for image import
follow this link click here
once the above link is opend then click on prerequisites--> click required service role
please read the documentation and add the required roles and policies.


Switch from Webpack to Vite

Looking over Vite features, looks like the features I need like CSS modules and JSX are built-in and I don't have to add any text telling the reader to update their config file.

Migrated in https://github.com/melange-re/melange-for-react-devs/pull/16


AC working with MHI-AC-Ctrl but not with MHI-AC-Ctrl-ESPHome

Hello,
Two days ago I installed my hardware in the AC unit which is a SRK20ZM-S and I uploaded the MHI-AC-Ctrl-ESPHome software on the ESP8266 which is a D1 Mini. Unfortunately I couldn't get it to work. All my sensors gave unknown values and also I didn't get the current temperature value or couldn't change HVAC modes.
Below is the output of the console when the MHI-AC-Ctrl-ESPHome software is active.
[I][wifi:519]: WiFi Connected!
[C][wifi:363]:   Local MAC: F4:CF:A2:65:FA:CD
[C][wifi:364]:   SSID: ''
[C][wifi:365]:   IP Address: *******
[C][wifi:366]:   BSSID: *******
[C][wifi:368]:   Hostname: 'lr_mhi_ac_ctrl'
[C][wifi:370]:   Signal strength: -76 dB
[C][wifi:374]:   Channel: 6
[C][wifi:375]:   Subnet: <IP_ADDRESS>
[C][wifi:376]:   Gateway: <IP_ADDRESS>
[C][wifi:377]:   DNS1: <IP_ADDRESS>
[C][wifi:378]:   DNS2: <IP_ADDRESS>
[D][wifi:528]: Disabling AP...
[W][mhi_ac_ctrl:139]: mhi_ac_ctrl_core.loop error: -2
[C][ota:093]: Over-The-Air Updates:
[C][ota:094]:   Address: lr_mhi_ac_ctrl.local:8266
[C][api:025]: Setting up Home Assistant API server...
[I][app:062]: setup() finished successfully!
 Temperature: 30.0°C
[C][mhi_ac_ctrl:147]:   Supports HEAT: YES
[C][mhi_ac_ctrl:148]:   Supports COOL: YES
[W][mhi_ac_ctrl:139]: mhi_ac_ctrl_core.loop error: -2
[C][version.text_sensor:021]: Version Text Sensor 'Airco Slaapkamer ESPHome Version'
[C][version.text_sensor:021]:   Icon: 'mdi:new-box'
[W][mhi_ac_ctrl:139]: mhi_ac_ctrl_core.loop error: -2
[W][mhi_ac_ctrl:139]: mhi_ac_ctrl_core.loop error: -2
[C][mdns:108]: mDNS:
[C][mdns:109]:   Hostname: lr_mhi_ac_ctrl
[W][mhi_ac_ctrl:139]: mhi_ac_ctrl_core.loop error: -2
[C][ota:093]: Over-The-Air Updates:
[C][ota:094]:   Address: lr_mhi_ac_ctrl.local:8266
[W][mhi_ac_ctrl:139]: mhi_ac_ctrl_core.loop error: -2
[C][api:138]: API Server:
[C][api:139]:   Address: lr_mhi_ac_ctrl.local:6053
[C][api:143]:   Using noise encryption: NO
[W][mhi_ac_ctrl:139]: mhi_ac_ctrl_core.loop error: -2
[C][wifi_signal.sensor:009]: WiFi Signal 'Airco Slaapkamer WiFi Signal'
[C][wifi_signal.sensor:009]:   Device Class: 'signal_strength'
[C][wifi_signal.sensor:009]:   State Class: 'measurement'
[C][wifi_signal.sensor:009]:   Unit of Measurement: 'dBm'
[C][wifi_signal.sensor:009]:   Accuracy Decimals: 0
[W][mhi_ac_ctrl:139]: mhi_ac_ctrl_core.loop error: -2
[C][wifi_info:009]: WifiInfo IPAddress 'Airco Slaapkamer IP'
[W][mhi_ac_ctrl:139]: mhi_ac_ctrl_core.loop error: -2
[C][wifi_info:011]: WifiInfo SSID 'Airco Slaapkamer SSID'
[W][mhi_ac_ctrl:139]: mhi_ac_ctrl_core.loop error: -2
[C][wifi_info:012]: WifiInfo BSSID 'Airco Slaapkamer BSSID'
[W][mhi_ac_ctrl:139]: mhi_ac_ctrl_core.loop error: -2
[W][mhi_ac_ctrl:139]: mhi_ac_ctrl_core.loop error: -2
[W][mhi_ac_ctrl:139]: mhi_ac_ctrl_core.loop error: -2
[W][mhi_ac_ctrl:139]: mhi_ac_ctrl_core.loop error: -2
And then it just keeps coming up with '[W][mhi_ac_ctrl:139]: mhi_ac_ctrl_core.loop error: -2'
I also got a warning when compiling. But compiling went fine. See the warning below.
In file included from src/esphome/core/controller.h:29,
from src\esphome\components\api\api_server.h:4,
from src\esphome\components\api\api_connection.h:6,
from src\esphome.h:3,
from src\main.cpp:3:
src/esphome/components/climate/climate.h: In constructor 'esphome::climate::Climate::Climate()':
src/esphome/components/climate/climate.h:167:7: warning: 'esphome::climate::Climate::away' is deprecated: away is deprecated, use preset instead [-Wdeprecated-declarations]
167 | class Climate : public EntityBase {
|       ^~~~~~~
src/esphome/components/climate/climate.h:193:8: note: declared here
193 |   bool away{false};
|        ^~~~
src/esphome/components/climate/climate.h:167:7: warning: 'esphome::climate::Climate::away' is deprecated: away is deprecated, use preset instead [-Wdeprecated-declarations]
167 | class Climate : public EntityBase {
|       ^~~~~~~
src/esphome/components/climate/climate.h:193:8: note: declared here
193 |   bool away{false};
|        ^~~~
In file included from src\main.cpp:87:
src\mhi_ac_ctrl.h: In constructor 'MhiAcCtrl::MhiAcCtrl()':
src\mhi_ac_ctrl.h:31:7: note: synthesized method 'esphome::climate::Climate::Climate()' first required here
31 | class MhiAcCtrl : public climate::Climate,
|       ^~~~~~~~~
lr_mhi_ac_ctrl.yaml: In lambda function:
lr_mhi_ac_ctrl.yaml:42:40: note: synthesized method 'MhiAcCtrl::MhiAcCtrl()' first required here
The strange thing is that is seems to work fine with the MHI-AC-Ctrl software. I seem to get data on the sensors and can also set the modes and can turn on and off the AC from MQTT. Below is the output from the console when the MHI-AC-Ctrl software is active.
Starting MHI-AC-Ctrl v2.8
CPU frequency[Hz]=80000000
ESP.getCoreVersion()=3.1.2
ESP.getSdkVersion()=2.2.2-dev(38a443e)
ESP.checkFlashCRC()=1
Measure frequency for SCK, MOSI and MISO pin
SCK frequency=4224Hz (expected: >3000Hz) o.k.
MOSI frequency=746Hz (expected: <SCK frequency) o.k.
MISO frequency=0Hz (expected: ~0Hz) o.k.
OTA Ready
setupWiFi: Start async scanNetworks
WIFI_CONNECT_SCANNING
handleWiFiScanResult(): 9 access points available
1                 Thynet 2G  1 -59dBm FC:EC:DA:81:B2:34 secured 04
2 ShellyPlusI4-08B61FCDC510  1 -62dBm 08:B6:1F:CD:C5:11 open 07
3 ShellyPlusI4-90380C35F428  1 -70dBm 90:38:0C:35:F4:29 open 07
4 ShellyPlusI4-08B61FCDBE28  1 -66dBm 08:B6:1F:CD:BE:29 open 07
5               H369A6A4A4D  1 -87dBm 00:4A:77:6A:4A:4D secured 04
6                     Ziggo  1 -79dBm 6A:02:98:40:9A:29 secured ff
7                 Thynet 5G  1 -58dBm 02:EC:DA:81:B2:34 secured 04
8                 Thynet 2G  6 -74dBm FC:EC:DA:3B:F8:E1 secured 04
9                 Thynet 5G  6 -75dBm 02:EC:DA:3B:F8:E1 secured 04
current BSSID: FF:FF:FF:FF:FF:FF, strongest BSSID: FC:EC:DA:81:B2:34
Connecting from bssid:FF:FF:FF:FF:FF:FF to bssid:FC:EC:DA:81:B2:34, channel:1
WIFI_CONNECT_ONGOING
connected to ******, IP address: ****** (-64dBm)
WIFI_CONNECT_OK
MQTTreconnect(): Attempting MQTT connection (MQTTclient.state=-1), WiFi.status()=3 ...
connected
MQTTclient.connected=1
status=64 topic=connected payload=1
status=64 topic=Version payload=2.8
status=64 topic=RSSI payload=-65
status=64 topic=WIFI_LOST payload=0
status=64 topic=MQTT_LOST payload=0
status=64 topic=WIFI_BSSID payload=FC:EC:DA:81:B2:34
MQTTreconnect(): 9 access points available
status=64 topic=fSCK payload=4224
status=64 topic=fMOSI payload=746
status=64 topic=fMISO payload=0
status=65 topic=Mode payload=auto
power_status: unknown; received status_power: 0
Set fan to Auto to fix fan status after powerdown (230V) AC
status=64 topic=Power payload=OFF
status=66 topic=Fan payload=auto
status=67 topic=Vanes payload=Swing
status=70 topic=Troom payload=18.75
status=71 topic=Tsetpoint payload=21.0
status=72 topic=Errorcode payload=0
status=130 topic=Tsetpoint payload=21.0
status=128 topic=Mode payload=auto
mhi_ac_ctrl_core.loop error: -4
mhi_ac_ctrl_core.loop error: -4
status=131 topic=RETURN-AIR payload=19.00
status=135 topic=THI-R1 payload=16
status=136 topic=THI-R2 payload=56
status=137 topic=THI-R3 payload=16
mhi_ac_ctrl_core.loop error: -4
status=134 topic=IU-FANSPEED payload=0
mhi_ac_ctrl_core.loop error: -2
status=139 topic=TOTAL-IU-RUN payload=1900
mhi_ac_ctrl_core.loop error: -4
status=132 topic=OUTDOOR payload=6.25
mhi_ac_ctrl_core.loop error: -2
mhi_ac_ctrl_core.loop error: -2
status=133 topic=THO-R1 payload=0
mhi_ac_ctrl_core.loop error: -2
status=141 topic=COMP payload=0.00
mhi_ac_ctrl_core.loop error: -2
status=143 topic=TD payload=<=30
mhi_ac_ctrl_core.loop error: -1
status=142 topic=CT payload=0.00
mhi_ac_ctrl_core.loop error: -4
mhi_ac_ctrl_core.loop error: -4
mhi_ac_ctrl_core.loop error: -2
status=144 topic=TDSH payload=0
status=145 topic=PROTECTION-NO payload=0
status=138 topic=OU-FANSPEED payload=0
mhi_ac_ctrl_core.loop error: -2
status=146 topic=DEFROST payload=Off
status=140 topic=TOTAL-COMP-RUN payload=1800
mhi_ac_ctrl_core.loop error: -4
What I have done so far is use different ESPHome versions. The versions I have used so far are 2023.2.0, 2023.4.4 and the latest. I have also used the MHI-AC-Ctrl-core.cpp and MHI-AC-Ctrl-core.h from the MHI-AC-Ctrl which was working for me. But nothing did the trick thus far.
One strange thing I saw from Home Assistant is that after about an hour of being connected some sensor are filled. The current temperature seems to be 19 degrees and does not change over a full night. Also the error code sensor got a value of 1.

I had the same problem. I didn't persist as long as you did (because I had the benefit of your post), however once I flashed the MHI-AC-Ctrl firmware it worked right away. I keep everything up to date so it was the latest version of esphome.
Something I was wondering- could the debug messages that have been added regarding timing be causing timing issues?
I have five units. I will try to get the model numbers. The three most modern units I have had a chance to install the modules on- the other two need to wait a couple of days as it's inconvenient to get to them. Out of the five I have four different models!

I am not sure if that is the problem. Last night however I installed the fork from @arpiecodes and everything seems to run fine. So there must be something significantly changed in one of the commits in this repository I think.

Guys, I think I found a solution to the problem.
take a look   @https://github.com/ginkage/MHI-AC-Ctrl-ESPHome/issues/69

Team,
I can confirm that this is indeed the case. All of my units (I have 5) need
the smaller frame size.
I guess we could be smart and adjust the size of it fails. Best of both
worlds? I might try to add that...
On Wed, 10 Jan 2024, 03:12 RobertJansen1, @.***> wrote:

This is because of the addition of 3dvanes which is not working on older
units (and the bigger framesize is now the default)
if you install
https://github.com/RobertJansen1/MHI-AC-Ctrl-ESPHome/tree/legacy_support
and change the framesize to 20, the older units will continue working.
i patched the files and added an option to configure this setting from the
yaml file. if this can be tested, it would be greatly appreciated and i can
add documentation for it if this works :)
—
Reply to this email directly, view it on GitHub
https://github.com/ginkage/MHI-AC-Ctrl-ESPHome/issues/68#issuecomment-1883345770,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ANALEHJ4DD2WZHXA2SOBSM3YNVT5LAVCNFSM6AAAAAA7F4WXFWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOBTGM2DKNZXGA
.
You are receiving this because you commented.Message ID:
@.***>

@damienmorrissey it would be great if you can, but for now I am happy it's configurable via the esphome yaml.
In #69 I shared my experience regarding old and new units and the frame size and confirmed the legacy fix provided by @RobertJansen1 to be working.
Would you be able to share the model of your indoor units in the other issue mentioned so we het a list of legacy models not supporting the new frame size?
I do think it's good to  consolidate both issues into one ticket as they seem to be duplicates.


Update mitiq bounties 2

We are updating the bountied issues on Mitiq, to avoid any ambiguity that may have arisen in the previous ones.

Hah sorry 🤦♀ merging now

actually @rmlarose this is closed, I cant merge the change from here. maybe make a new one quick?


core-image-pelux.bbclass: add alexa sdks

avs-device-sdk
aac-sdk
portaudio-v19

Signed-off-by: Tariq Ansari<EMAIL_ADDRESS>

Disregard the Taha saying this doesn't build. The build is successful https://pelux.io/jenkins/job/meta-pelux/view/change-requests/job/PR-269/

Typo in the commit message (two 'a' in packages).

Hold on, @TSAnsari! What the heck? You've forced-pushed changes after complitely different change was reviewed?

Hold on, @TSAnsari! What the heck? You've forced-pushed changes after complitely different change was reviewed?

We talked about removing portaudio in this commit. Will add it in a separate commit. So that was removed. Also removed aac-sdk as it is not required for current Alexa sample app.

Hold on, @TSAnsari! What the heck? You've forced-pushed changes after complitely different change was reviewed?

We talked about removing portaudio in this commit.

I do not recall such a conversation.

Hold on, @TSAnsari! What the heck? You've forced-pushed changes after complitely different change was reviewed?

We talked about removing portaudio in this commit.

I do not recall such a conversation.

TSAnsari            May be I should not add portaudio
sashko        No, you shouldn't. Only sample app should depend on it.
TSAnsari    portaudio removed

Hold on, @TSAnsari! What the heck? You've forced-pushed changes after complitely different change was reviewed?

We talked about removing portaudio in this commit.

I do not recall such a conversation.

TSAnsari: May be I should not add portaudio
sashko: No, you shouldn't. Only sample app should depend on it.
TSAnsari: portaudio removed

you've also removed aac-sdk and the entire commit message.

Hold on, @TSAnsari! What the heck? You've forced-pushed changes after complitely different change was reviewed?

We talked about removing portaudio in this commit.

I do not recall such a conversation.

TSAnsari: May be I should not add portaudio
sashko: No, you shouldn't. Only sample app should depend on it.
TSAnsari: portaudio removed

you've also removed aac-sdk and the entire commit message.

Yes the commit message had info about portaudio and aac-sdk. So it must be changed.


docs/readme: Fix typo in README.md

Fix typo in readme

Thanks! :+1:

@homu r+

:pushpin: Commit 79f69a9 has been approved by hobofan

:zap: Test exempted - status


Sync clipboard with host compositor

Same story as #62. Should be pretty easy but may require wlroots changes.

I'd be interested to work on this feature. I use wio for compositing, and this « clipboard sync » is needed for the clipboard to be shared between all cage instances.
If I understand the issue correctly, this would require the compositor to act as a client to the wl_data_control interface of the underlying compositor. Is that correct ?
If so, could you point me in the right direction to get started with it ? Is there already a portion of the code that's used to relay requests to a wayland server ? Also, what is the interface to use for clipboard/selection management ?

Are wlroots changes still needed?
Related Plagman/gamescope/issues/303

wlroots changes should not be necessary.

If someone want to work on this, I have a partial (only selection, aka clipboard, no primary selection or DnD) implementation here : https://github.com/sloonz/cage
But unless I missed something, contra emersion it will need some changes to wlroots, at minimum a public function wlr_wl_backend_get_display to be able to access the remote display. A way to access the registry without having to bind to it a second time to it would be nice too.

But unless I missed something, contra emersion it will need some changes to wlroots, at minimum a public function wlr_wl_backend_get_display to be able to access the remote display.

FYI, there is a wlr_wl_backend_get_remote_display() API in wlr/backend/wayland.h. [1]
[1] https://wayland.emersion.fr/wlroots/wlr/backend/wayland.h.html#func-wlr_wl_backend_get_remote_display

I don’t know how I missed that. Will update my fork shortly.

Updated commit : https://github.com/sloonz/cage/commit/619e8f1a871c3eea76faf4d566eebd2b478bd83e

data-control does not sound like a protocol we should be using for this. The core Wayland protocol should be enough.
Do you plan to open a pull request?

data-control does not sound like a protocol we should be using for this. The core Wayland protocol should be enough.

Yeah, that’s what I realized once I was 99% done. It’s the kind of change that must be made before being made into a proper pull request.

Do you plan to open a pull request?

Not right now, I don’t really have the time. But I probably eventually will if nobody does.


Include instructions for oca_dependencies.txt

These instructions are copied from https://github.com/OCA/maintainer-quality-tools/blob/67d3880b085a99d820e5a65cc7354dae95d1b4b0/sample_files/oca_dependencies.txt. This is a better place to put them.

/ocabot merge nobump

I'm not able to push here. @sbidoul @dreispt can you give me permission or merge?


Support named color properties

It would be great to add support for named color properties for example: "red", "green", "black" etc.

@admdh rgba() is not working too ((

what exactly doesn't work with rgba()?

@talgautb rgba() is fixed.

hi,
can you please share with a working html?


[BUG] <DateField value={undefined} /> is still displaying the date

Describe the bug
Under the hood, <DateField /> components of Refine's UI implementations use dayjs. As an expected behavior of dayjs, when you construct a Dayjs object with an empty/undefined value it will use the current date time. This causes <DateField value={undefined} /> to display current date instead of rendering nothing.
import { useShow } from "@refinedev/core";
import { DateField } from "@refinedev/antd";
import { Typography } from "antd";

export const PostDetails = () => {
  const { query } = useShow();

  return (
    <Typography.Title level={5}>Title</Typography.Title>
    <Typography.Text>{data.data?.title}</Typography.Text>
    <Typography.Title level={5}>Created At</Typography.Title>
    {/* Assume `createdAt` is not present in the response */}
    <DateField value={data.data?.createdAt} />
  );
}

This will render the current date.
import dayjs from "dayjs";

console.log(dayjs().format("DD-MM-YYYY")); // 31-07-2024

console.log(dayjs(Date.now()).format("DD-MM-YYYY")); // 31-07-2024

Steps To Reproduce

Import DateField from any UI implementation of Refine.
Pass undefined or a reference to a non-existing property in an object to the value prop.
Check to see <DateField value={undefined} /> rendering the current date.

Expected behavior
<DateField value={undefined} /> should return null and display nothing.
Implementations should be updated to check for undefined values and return null in that case.
Packages

@refinedev/antd
@refinedev/mui
@refinedev/chakra-ui
@refinedev/mantine

Additional Context
Tests for this fix can be implemented in @refinedev/ui-tests and it will run on all implementations.

i would like to work on this!

Hey @JayBhensdadia, assigning this to you. Let us know if you have any issues. Don't forget to check our Contributing Guide before you start.

Hi @aliemir
I've just fixed this issue.
Can you possibly check following PR?
https://github.com/refinedev/refine/pull/6217

Hey @JayBhensdadia, @webscriptmaster put up a PR with a valid fix for this issue. We're linking this issue with the PR and hoping to include it in our next release.
Maybe you can check our issue list to find yourself one to work on. We'll be happy to see your contribution 🙏

is this issue is still open


AOT illegally removes write-only fields

Consider
class Node {
  ...
  var leftWeak;
  var leftStrong;
  var rightWeak;
  var rightStrong;
  Node get left => leftWeak?.target;
  set left(Node value) {
    leftWeak = value == null ? null : new WeakReference(value);
    leftStrong = value;
  }
  Node get right => rightWeak?.target;
  set right(Node value) {
    rightWeak = value == null ? null : new WeakReference(value);
    rightStrong = value;
  }
}

Whole-program analysis currently observes that leftStrong and rightStrong are written to but never read, and concludes it can eliminate them. This is incorrect because these fields also have an effect on the reachablity of their value. With the fields removed, left and right sometimes return null depending on GC timing.

@rmacnak-google Could you clarify what part of the spec is violated?
My understanding is that when WeakReference was introduced, we were careful enough to not prevent optimizations like tree-shaking of write-only fields. So API specification doesn't actually tell anything about reachability, roots etc.
From the API specification:
https://github.com/dart-lang/sdk/blob/af1536d463b013b527669fcff570d771d36265b9/sdk/lib/core/weak.dart#L68-L70
In the program above, leftStrong and rightStrong are never read so program can access objects stored in those fields only via WeakReferences. So, my understanding that it is correct to clear those WeakReference objects.
At the same time, there's no guarantee that they would be ever cleared, so WeakReferences can always return their targets in JIT mode; or sometimes, depending on the GC timing in AOT mode:
https://github.com/dart-lang/sdk/blob/af1536d463b013b527669fcff570d771d36265b9/sdk/lib/core/weak.dart#L75-L76
It looks like it is working as intended.
@dcharkes @mraleph Please correct me if I'm wrong.

Yes, the intent was to phrase WeakReference API contract in such a way that it makes such optimisation possible. My reading of the comment is the same as @alexmarkov's: there is no execution of the program that could observe this value without derefencing the weak reference itself.
We could clarify the wording if it is not clear. ECMA-262 makes it more explicit and says that the value is considered live only there is a possible execution of the program, which does not dereference weak references and observes this value.

@lrhn Any opinion on making the contract more explicit in the doc-comment? Otherwise I am inclined to close as WAI.

there is no execution of the program that could observe this value without derefencing the weak reference itself.

Plenty of other ways: a different weak reference, an ephemeron, Finalizer, NativeFinalizer, OutOfMemoryError, Dart_NewWeakPersistentHandle, Dart_Invoke, getObject, etc. What WeakReference's doc claims is not relevant to most of these.
I anticipate you will claim these are unimportant and that allowing this class of optimizations is more important. I claim the straightforward semantics are more important. Global fields are reachable. Local fields that are in scope are reachable. The fields of a reachable object are reachable. Activation pruning is an illegal optimization. Closure environment pruning is an illegal optimization. Field pruning is an illegal optimization.

I claim the straightforward semantics are more important.

What we found important in practise is not having premature finalization (which leads to use after free bugs).
We introduced Finalizable for this.
If you want to keep things alive, use Finalizable, this prevents certain optimizations, including tree-shaking its fields.
class Node implements Finalizable {
  ...
  var leftWeak;
  var leftStrong;
  var rightWeak;
  var rightStrong;
  Node get left => leftWeak?.target;
  set left(Node value) {
    leftWeak = value == null ? null : new WeakReference(value);
    leftStrong = value;
  }
  Node get right => rightWeak?.target;
  set right(Node value) {
    rightWeak = value == null ? null : new WeakReference(value);
    rightStrong = value;
  }
}

Specifically for fields, see:

https://github.com/dart-lang/sdk/issues/49643

We do require using Finalizables for NativeFinalizers. So that should prevent premature finalization there.
With Finalizers, the desired semantics (I don't remember by who, we would need to dig through issues) was to allow premature optimization. The thinking here is that if you're still using an object, it will not be GCed. This is not true for native resources, of which the wrapper object can be GCed while the C function is still running.
Of course, that doesn't prevent people from using Finalizable for uses with Finalizer, WeakReference etc.
@rmacnak-google Did you run into a specific use case where this is an issue?

Yes, we should probably clarify docs to say that WeakReference can be cleared when "there is no other way for the program to access the target object except through a target of a WeakReference, Expando or a handle created with Dart_NewWeakPersistentHandle". Otherwise, according to the current wording of the spec it is not correct to clear a WeakReference if there is another WeakReference or Expando pointing to the same object.
How can you reach to an object via an OutOfMemoryError? Also, Finalizer and NativeFinalizer do not provide an access to the original object being finalized.
Dart_Invoke/Dart_GetField can access members only if they are annotated with @pragma('vm:entry-point') which disables tree-shaking of these members, so they should be fine.

I agree that it's working as intended. Mainly because the "intended" is very, very loose.
It's very hard to describe the intended behavior. The shortest I can come up with is:

If dereferencing a weak reference does not return the object it was created with, then there must be no future execution of the program where any expression evaluates to that object.

(That is, observing the weak reference to have been emptied, after previously having held an object o, must mean that there is no way for the program to ever reference o again.)
Finalizers are even trickier, because they act when the object goes away,  not just when you try to observe the weak reference. So, for a finalizer, it must be:

If a finalizer invokes the finalization associated to a specific object, then there must be no future execution of the program where any expression evaluates to that object.

It's prescriptive, not descriptive, but it's hard to be anything but when abstracting over any possible garbage collection techniques.
Users must be ready for finalization whenever they are not absolutely certain that they'll ever look at that object directly again. Or than some other code will.
But even if we take that literally, it still kind-of assumes that we execute every expression in the source program.
Optimizations may change that. Write-only variables is one thing, but you can optimize away reads of variables too.
Take
/*final*/ class Resource {
  final ExternalResource _realResource;
  final Something otherStuff;
  Resource(this._realResource, this.otherStuff);
  void use() {
    staticHelper(_realResource);
  }
}
class Actor {
  final Resource _resource;
  Actor(this._resource);
  void act() {
     _resource.use();
  }
  ...
}

The Actor class doesn't use _resource in any other way. Because the Resource class is final (doesn't have any subclasses, which we can detect to day using global analysis, and might be able to just declare in the future) ... it seems like a safe optimization to inline the use method and unbox the Resource and only store the _realSource value. We don't need that otherStuff anyway.
It's indistinguishable from the outside, because nobody else can access the _resource field, so they can't see that the entire object has been optimized away.
That optimization would wreck havoc if there is a finalizer on the Resource object which disposes the _realResource stored in it.
The source has an expression which evaluates to the resource object, the _resource of act(), but we optimized that expression away, so the actual running program does not have the same "expressions" as the source.
Which makes it under-defined to talk about values of expressions at runtime.
So it's not easy to predict when a value is dead. That's usually not a problem, because if it is, you can't see it.
Finalizers change that. Because finalization has side effects, it needs some kind of predictability.
We can't just say that any optimization is fair game, and finalizers should be ready for their objects to die at any time. Object existence isn't that observable to begin with. If you don't call identical with the object, there are lots of possible optimizations that won't preserve an object with that identity. Being completely unpredictable is not useful.
We may want to make some kind of promise about which optimizations are off the table.
I do think we should say something about how much, or little, you can actually rely on. And again, it might just be "don't assume anything if the class isn't Finalizable".
What is it that Finalizable does?
If a type is Finalizable, we promise to not optimize away any field with that type, its life-time will always be that of the containing object. Any local variable of that type will have a life time that is its entire scope. Any static/top-level variable will stay alive for the duration of the entire isolate.

@rmacnak-google

What WeakReference's doc claims is not relevant to most of these.

The contract in WeakReference documentation is precisely what defines which optimizations we can and can't do. Prior to us adding WeakReference and Finalizer to the dart:core pure Dart programs did not have any way to observe GC behaviour and consequently could not observe reachability properties and how they change at different optimisation levels.

I anticipate you will claim these are unimportant and that allowing this class of optimisations is more important.

I do think that unused field removal is an important optimisation. It allows you to have debug only fields which are stripped in release mode (see e.g. https://github.com/flutter/flutter/issues/22915). Dart does not really provide any language feature to achieve the same thing (i.e. a preprocessor).

I claim the straightforward semantics are more important. Global fields are reachable. Local fields that are in scope are reachable. The fields of a reachable object are reachable. Activation pruning is an illegal optimization. Closure environment pruning is an illegal optimization. Field pruning is an illegal optimization.

I understand where you are coming from, but I think in reality we have to tread a fine line here. For example, currently we base our closure contexts on scopes. It's a very straightforward model. However we constantly see users being puzzled about this - because they expect closure to only close over referenced local variables.
As I see it, there are two forces here pulling in opposite direction: for runtime observability and debuggability you would prefer a very simplistic execution model (similar to what you describe),  but for production deployment you would actually want an optimised execution model which is less straightforward and gives compiler more leeway to optimise things - but within well defined bounds.
e.g. for fields specifically this means that any field that is not read and does not have @pragma('vm:entry-point') can disappear in a deployed binary. I think this is straightforward enough and well-defined enough.
@lrhn

Do we make any promises about weak references not being cleared in the middle of code?

No we did not make such promise.


Custom icon

I can add an SVG-image file via the "custom icon"-button, but it always becomes a black square.

Any news on this?

Hello all,
Can you tell me the purpose of:

Custom Icon
Mask

Please see this

1 and 2 are marks (add and don't press "Apply")
3 is the custom icon

I'm looking for "add a small image into the main image"

I think it must be "Custom icon", but with this feature the small icon isn't showed as expected
"Mask": this works perfectly with out pressing "Apply"

Thank you!
Duong Nguyen

Any news on this?


Made prune more resilient to filesystem errors

Fixed observed problem with prune() where it would have failed due
to exceptions being raised during pruning.
This was observed occurring randomly while running tests with xdist.
Related: #3178

Do we really want to silently handle such situations? Since it is not safe to run multiple molecule commands at once for a single project, errors we want to handle here can only happen when users abuse Molecule.

@tadeboro We are not really silent about it. We ignore only a missing file in first case making the removal idempotent (at the end file is still missing, we do not care if it did vanish or we were the ones removing it).
For the second case, we do emit info message. The reason for this approach is exactly for giving some feedback.

@tadeboro We are not really silent about it. We ignore only a missing file in first case making the removal idempotent (at the end file is still missing, we do not care if it did vanish or we were the ones removing it).

No, we are silent covering up a race condition here because the file was gone while the prune operation was in progress. And there are only two realistic sources of that: the user either ran more than one Molecule instance in the project or the cache folder was removed. And none of those scenarios should be silently ignored.

For the second case, we do emit info message. The reason for this approach is exactly for giving some feedback. If you want we can make them warnings, I do not mind.

The same things hold for this situation.
If we really want to make things safe, we should probably protect the stateful resources with a lock and make sure only only Molecule instance is accessing it at any time.

I plan to address the parallel issue and lock support via ansible-compat by adding support in it for that, especially as it has a method for running any ansible tasks. That should make the implementation quite clean.

I agree with Tadej, this looks like a band-aid. Why not make tests use proper separate tmp dirs and introduce a lock file for preventing race conditions?


Add more args to perVisit docs

Is your feature request related to a problem? Please describe.
I thought I wanted to use perVisit to pass in carbon intensity. But couldn't see this as an option in the documentation. So had to check out the code to see if I could pass it in options
Describe the solution you'd like
Just a few more options on the documentation as per the code
  perVisit(
    bytes,
    carbonIntensity = false,
    segmentResults = false,
    options = {}
  ) {

Since this issue is related to the docs website, I've moved it into that repo (out of the CO2.js repo)

@drydenwilliams we'd like folks who want to use options to change some of the inputs of the function to use the perVisitTrace function. The reason for this is that if a calculation is going to steer off the baseline SWD model, then we believe they should make it clear what changes have been made. In this way there's a transparency to the calculation.
Action: will add this guidance to the docs.
The reason the underlying perVisit function (https://github.com/thegreenwebfoundation/co2.js/blob/9ed607d752bf7fd4eb3b255350aadf302bbb69a8/src/sustainable-web-design.js#L165-L170) takes an object variable was to avoid having to duplicate the code for perVisit and perVisitTrace. This could be fixed up by refactoring the code, which is something that will probably happen alongside the SWD model update later this year.

I've included guidance that the perByteTrace and perVisitTrace functions should be used whenever the variables in the SWD model want to be adjusted.
https://developers.thegreenwebfoundation.org/co2js/methods/


Issue 27

closes #27

Thank you so much for a fastest resolution! Any estimates when version 1.4.3 would be published to npm?


[ogre] Fix include path in usage

Describe the pull request

What does your PR fix?
Fixes #15333
Replace #include "OgreRTShaderSystem.h" as #include "../RTShaderSystem/OgreRTShaderSystem.h" in ../Bites/OgreSGTechniqueResolverListener.h file.

Note: No need to test features.

Depends on #19633


Fix shard ID filter

What changed?
Fix shard ID filter

Why?
shard ID filter does not work

How did you test it?
local test

Potential risks

Coverage decreased (-0.07%) to 66.938% when pulling d56d4c22e71891449214e2e1f8cfc7ca367ec6c0 on fix_shardID_filter into 60c3463a712c0ae3fb384ca654ad1c6c445d6903 on master.


"name" property of OutputChannel has gone

Since updating to 1.33.0 when using createOutputChannel in my extension, the returned objects no longer have a "name" property.

My guess is it "lost" during the rework here: https://github.com/Microsoft/vscode/commit/a4b49166d0768624bf76cfd86ee1a166de844768
/cc @sandy081

I see removing the type assertion is showing the warning but I would still expect to see errors even when I miss something while using type assertion.

Verified with stable build 2f7c3971e1


IBL shows different effect when imported from ktx and png

Describe the bug
We were using png for generate IBL indirectlight. We followed samples/app/IBL.cpp rgb32f and write a script for png format.
But the result are different.
This is from ktx.

This is from png

it seem the
To Reproduce
machine_shop_01_1k.zip
we were using command cmgen -f ktx -x machine_shop machine_shop_01_1k.hdr for ktx
cmgen -f png -x machine_shop machine_shop_01_1k.hdr for png
Expected behavior
the object should be rendered similar both in png IBL and ktx IBL.
Desktop (please complete the following information):

OS: Windows
GPU: GTX 2070

Additional context
The only difference I can find is that ktx store data with the format of rgb32f(R10G11B11), while PNG is of sRGB8. The data precision might differ but I don't expect that influence that much.

The difference is large. sRGB8 cannot encode HDR data. The difference is not surprising. KTX files simply store rgb32f as PNG files. Use the rgb32f export format to generate HDR PNGs.


\left{ and \left[ (and \right counterparts) do not work properly

Using either texlive 2018 on Windows, or texlive 2016 on Mac and pdflatex, without doing funky things with fonts (regardless of whether \usepackage[T1]{fontenc} is used or not, \usepackage[utf8]{inputenc} similarly). They either do not show at all, or show weirdly (\left[ as ( but too low, \right] actually as ] but also too low, by a lot). I also tried both 10pt and 11pt, no difference.
I can provide a full paper that reproduces the issue, but I don't really want to winnow things down to a small reproducible case until it seems to really be for sure due to this template.  Note that I was using another journal's template previously, and it all worked fine, which is why I suspect the template.

Please provide a MWE.

Now that I know someone's paying attention, I will.

Attached is a very small tex file (gzipped to satisfy github)
compo_bug.tex.gz
that reproduces the problems.

The problem seems to be caused by MnSymbol.sty. I believe that this happens because the class file loads lmodern.sty after you've loaded MnSymbol.sty; if they were loaded the other way round, the problem would go away (according to my experiments). The class file loads lmodern.sty after all your usepackage declarations because it is added to the BeginDocument hook, rather than being done at the relevant point in the class file. So I believe that a fix is simply to load lmodern.sty on the spot; see modified compositionalityarticle-jc.cls that does that. However, I don't know why lmodern.sty was postponed to the BeginDocument hook in the first place (maybe it has to be loaded after some other packages?), so I don't know whether making this change would break other things.
compositionalityarticle-jc.cls.gz

Dear Jacques,
Thank you for noticing this problem. As far as I can understand, Jeremy solved this problem in commit e24aa572f60b6acbaad140f12aeb2deafafcfe89, which is now merged. Your minimal working example seems to compile correctly now; I attach an image and the exact code I used. I will close the issue, but please feel free to reopen if you find any other problem with the current version.
Thanks again!

\documentclass[a4paper,onecolumn, superscriptaddress,10pt,accepted=2020-05-01,issue=1, volume=2, shorttitle=papers]{compositionalityarticle}

\pdfoutput=1

\usepackage[english]{babel}
\usepackage[T1]{fontenc}
\usepackage{hyperref}
\usepackage{amsmath,amssymb,amsthm}
\usepackage{tikz}
\usetikzlibrary{matrix,arrows}
\usepackage{wrapfig}
\usepackage{stmaryrd,mathtools,MnSymbol}
\usepackage{url}
\usepackage{xspace}

\pagestyle{headings}

% useful defs
\newcommand{\define}{\triangleq}
\newcommand{\rename}{\mapsto}

\newcommand{\tmop}[1]{\ensuremath{\operatorname{\mathtt{#1}}}\xspace}
\newcommand{\assign}{\coloneq}
\newcommand{\cdummy}{\cdot}

\begin{document}

\title[Theory Presentation Combinators]{Theory Presentation Combinators}

\author{Jacques Carette}
<EMAIL_ADDRESS>\orcid{0000-0001-8993-9804}
\homepage{http://www.cas.mcmaster.ca/~carette}
\affiliation{McMaster University, Dept. of Computing and Software,
    Hamilton, Ontario, Canada}

\maketitle

\begin{abstract}
MRU
\end{abstract}

\section{Motivation}\label{sec:motivation}

\subsection{Renaming}

\[
\tmop{AbelianMonoid} \define\tmop{CommutativeMonoid}
 \left[\ (\cdummy)\rename +,\ e\rename 0 \right]
\]

\begin{align*}
\tmop{MtoCM} \define &
 \left[ \tmop{U}\assign \tmop{U},
      (\cdummy)\assign (\cdummy),
       \tmop{e} \assign \tmop{e},
       \tmop{right\ identity} \assign \tmop{right\ identity}, \right. \\
 & \left.{}\tmop{left\ identity} \assign \tmop{left\ identity},
       \tmop{associative} \assign \tmop{associative}, \right. \\
  & \left.{}\tmop{commutative} \assign \forall x,y:U. x\cdummy y = y\cdummy x
  \right] : \tmop{Monoid} \Rightarrow \tmop{CommutativeMonoid}
\end{align*}
\noindent where we use $\Rightarrow$ to indicate that this is a construction,
and $\assign$ to mean that this is an assignment of terms of
\tmop{Monoid} to names of $\tmop{CommutativeMonoid}$.
\[ \tmop{MtoCM} \define
\left[
       \tmop{commutative} \assign \forall x,y:U. x\cdummy y = y\cdummy x
\right]\\
: \tmop{Monoid} \Rightarrow \tmop{CommutativeMonoid}
\]
\noindent which is easily seen to be isomorphic to the definition we started
with.

\begin{wrapfigure}[11]{l}{0pt}
\begin{tikzpicture}[node distance=3.0cm, auto]
  \node (P) {$\left\{ V : \tmop{Type}\right\}$};
  \node (B) [right of=P] {$\left\{\ ? : \tmop{Type}\right\}$};
  \node (A) [below of=P] {$\left\{ U : \tmop{Type}\right\}$};
  \node (C) [below of=B] {$\left\{ W : \tmop{Type}\right\}$};
  \draw[->] (P) to node {$[V \rename\ ?]$} (B);
  \draw[->] (A) to node {$[U \rename B]$} (P);
  \draw[->] (A) to node [swap] {$[U \rename W]$} (C);
  \draw[->] (C) to node [swap] {$[W \rename\ ?]$} (B);
\end{tikzpicture}
\label{fig:renaming-problem}
\end{wrapfigure}

\end{document}