Cocoon is not respecting the batch schedule logic

All tasks are expected to follow batch schedule of a size of 6. No multiple In Progress (yellow box) tasks are expected for a single target (same column).
Here is the current dashboard snapshot:

Is this related to recent webhook to pub/sub? /cc @CaseyHillers

I have no guesses to why pubsub would cause this. I'm investigating the logs to see if there's anything there.
Interesting, there's both double queued tasks, and tasks not being run. Seems like both edge cases are being violated.

The scheduler always schedules new commit task when an earlier failure happens (within the batch size). It fails to check if any In Progress task exists. We should add a logic to check if any running task before scheduling.


adding %nbdev_default_export

while adding %nbdev_default_export to remove_hidden I realized I should have added "all test flags" with the last PR - hence changes to ReTstFlags.
I'm guessing the changes are small enough to PR together - but let me know if you'd prefer separate PRs

Looks all good to me, thanks a lot!


[BUG] Incorrect type definition for useFeatureEntitlements

const foo = useFeatureEntitlements("bar");
foo is now, according to Typescript, of type Entitlement.
During runtime, however, it is in fact a Ref<Entitlement>.
This causes problems when you're not directly using foo in the component html, but instead using it elsewhere in the script part.
You are then forced to do something like this:
(foo as unknown as Ref<typeof foo>).value.isEntitled
(alternatively unref(foo).isEntitled)
Proof:
  console.log("checking entitlement");
  console.log(foo.isEntitled);
  console.log((foo as unknown as Ref<typeof foo>).value.isEntitled);

Outputs:

In this case, the user is indeed entitled, so true is the correct output.
Similar to https://github.com/frontegg/frontegg-vue/issues/349

@hognevevle Thanks for reporting the issue. We will take a look and update.

Thanks @doregg , but it seems the typings disappeared after this change (now returning any instead). 🤔

npmjs.com confirms the same:

@doregg Can you please reopen this?


Add new TAS EXTENSION

Add this extension please

this extension is completely broken XD

this extension can also easily be recreated with more timers.

this extension can also easily be recreated with more timers.

So what does that have to do with the more timers extension

this extension can also easily be recreated with more timers.

And anyways

this extension is completely broken XD

You could've reviewed a comment like that

Sorry, we cannot accept this extension. This extensions functionality can be easily replicated using More Timers.

Sorry, we cannot accept this extension. This extensions functionality can be easily replicated using More Timers.

Dang, maybe if I didn't forget to set this as draft


Import milli from meilisearch-lib

This PR directly imports the milli dependency used in meilisearch-http from meilisearch-lib. I can't import meilisearch-lib in meiliserach-auth and that meilisearch-auth can't use the milli exported by meilisearch-lib 😞

This is lindera which is not compiling due to Google Drive...
bors merge


Less ambigious return type for colnames/rownames

Follow-up to #796
Instead of returning Robj, we should aim to be more descriptive of the returned result. For colnames/rownames it is a bit obvious that it should be NULL or a character vector.
This uncovered something that our vector types Integers, Doubles etc. are not implemented for From<Robj> for Option<r-vector-type>. That could be a follow-up to this.

[ ] Partial dependence on #802.

@JosiahParry Thanks! @kbvernon & I have adressed all of your comments.


Operations under which block-matrices return block-matrices

I was wondering whether there is interest in someone (me?) implementing operations under which block-matrices are potentially closed (i.e. perhaps return another block-matrix), such as multiplication, inversion, transposition and certain factorisations, at the level of the AbstractBlockMatrix and / or AbstractBlockVector. For example, it would be really nice if in the following
B = BlockArray(Matrix{Float64}, [2, 2], [2, 2])
# fill in the blocks with something.
A = B.'B

both A and B.' were also a block matrices. At the moment these operations appear to return regular dense matrices.
This would be very useful for block matrices who's blocks have special structures where the same structure pops out the other side of such operations (I'm really interested in being able to operate on block-matrices whose blocks are circulant and have sensible things happen).

Yeah, operations that are not specialized will fall back to the AbstractArray versions and will return standard Arrays. One thing that really needs to be done is to implement the broadcasting interface (but that is a bit tricky I think) and the reduction interface (mapreduce & co).

Hmm yeah. It's not even clear to me what should define broadcast-able arrays in this context. Do we view a block-arrays as a special representation of a regular arrays, meaning that you could broadcast a 4 x 1 matrix with a block matrix like
B = BlockArray(Matrix{Float64}, [2, 2], [2, 2])

or is it more appropriate to say that it would be valid to broadcast B with something like
A = BlockArray(Matrix{Float64}, [2, 2], [2])

since in some sense it's a 2 x 1 block-matrix. Or is it reasonable for both to be valid?
I guess there are similar questions to be asked about the reduction interface: for example, does a reduction over a block matrix whose blocks are all of size 2 x 2 return a 2 x 2 block? Or does it return a scalar? Or, again, is it sensible to somehow support both?
I think certain unary linear algebra operations are quite simple to do e.g. the transpose of a block matrix is always a block matrix, so it seems pretty clear-cut what should happen there. Similarly with matrix multiplication; the result will be a block matrix if each of the blocks that you have to multiply are conformal, but otherwise the result should probably be dense (if you start with dense matrices, I'm not sure about sparse).

WIth broadcast I meant stuff like sin.(B) using the dot notation.https://julialang.org/blog/2017/01/moredots
Linear Algebra would be nice to have.

Oh okay, so you're just interested in the unary case for now? I was referring the more general case, so things like A .+ sin.(B) if A and B are different sizes?
If you have no objections, I'll put together a PR for transposition to start with.

Sounds good!

I'd add matrix algebra to this: for example:
julia> A = BlockArray(rand(4,4), [2,2], [2,2])
2×2-blocked 4×4 BlockArrays.BlockArray{Float64,2,Array{Float64,2}}:
 0.302873  0.193358    │  0.411812   0.830986
 0.658837  0.932453    │  0.0245708  0.415494
 ──────────────────────┼─────────────────────
 0.973492  0.00193905  │  0.731272   0.953296
 0.292634  0.343203    │  0.105658   0.417385

julia> B = BlockArray(rand(3,4), [1,1,1], [2,2])
3×2-blocked 3×4 BlockArrays.BlockArray{Float64,2,Array{Float64,2}}:
 0.506225  0.752294  │  0.534993  0.347013
 ────────────────────┼────────────────────
 0.398445  0.591069  │  0.699823  0.783644
 ────────────────────┼────────────────────
 0.189798  0.712026  │  0.485311  0.626346

julia> B*A # expected BlockArray(..., [1,1,1], [2,2])
3×4 Array{Float64,2}:
 1.27132  0.919495  0.654844  1.38808
 1.42069  0.898492  0.773167  1.57091
 1.18233  0.916535  0.516729  1.17764

I'm not sure what to do if the block sizes are not compatible. Maybe make them compatible by taking the "union" of the block sizes? That is, add blocks to get the "least common divisor"-analogue of the block sizes?

Here's another one:
A[Block.(1:3)]
should probably also return a BlockArray.

What is the status of this work? Especially I am interested in efficient BlockMatrix*BlockMatrix multiplication.
I need it in my work, so I will write the code nevertheless. Thus, if you are not in middle of implementing it now, I think I can contribute.

BlockBandedMatrices.jl has a nice template for how to implement this. It would be good to have it here.

Do you require 5-argument variants? (E.g., analogues to BLAS.gemv!?) Do you need Adjoints of block banded matrices as well? This is all implemented in BlockBandedMatrices.jl, but requires LazyArrays.jl, and we should hesitate before that dependency is added here.
The alternative is to overload mul!(::BlockMatrix, ::BlockMatrix, ::BlockMatrix), but the catch is that you ended up with hundreds of overloads for Adjoint for full functionality.

I need to have 5-arguments. Judging from your previous comment I thought that you want LazyArrays.jl to be used. I started reading this package but it is still not really clear for me, so if it is ok with you I will prefer using mul! .
I cannot see what is the problem with adjoint.

The reason we would want LazyArrays.jl is that it is much more flexible. For example, the high performance implementation of mul! would automatically work for things like views of block ranges:
A = BlockMatrix(...)
B = BlockMatrix(...)
V = view(A, Block.(1:3), Block.(3:4)) # take a subrange of blocks, then transpose them
C .= α.*Mul(V, B) .+ β.*C # alternative to mul!(C, V, B, α, β), automatically calls fast block multiply (BLAS) routines
C .= Mul(V',B) # alternative to mul!(C, V', B), automatically calls fast block multiply (BLAS) routines

Accomplishing this with standard mul! is virtually impossible as the number of combinations of view, Adjoint, etc. are combinatorially large.  Note with LazyArrays.jl, there would still be support for the standard syntax mul!(y, A::BlockBandedMatrix, x::BlockBandedMatrix), so this is an implementation detail hidden from users.
LazyArrays.jl is a bit complicated if you are not familiar with Broadcasted style of code. But it would only take me an hour or so to implement, which I'm happy to do. The bigger issue is that LazyArrays.jl has not "stabilised" yet, so it may be premature.
If you only need mul!(::BlockMatrix, ::BlockMatrix, ::BlockMatrix) (that is, you don't need to work with subviews or adjoints), then I'm happy to accept a PR that adds that, which can be replaced with the more general LazyArrays.jl version down the line.

"amortize" block size analysis

I don't quite see what you want to analyse.

I was referring to "least common divisor"-analogue you mentioned in https://github.com/JuliaArrays/BlockArrays.jl/issues/31#issuecomment-352499336

This should be negligible compared to multiplication

That would depend on the ratio of number of blocks and average block size, right?  Especially when it's block diagonal (which is actually what I have in mind).  I know we shouldn't be worrying about performance before any benchmarks, but I just thought it is worth mentioning that there is an optimization opportunity.

whether MulAdd(α, A, B, β, C) should actually by MulAdd(C, A, B, α, β).

It seems MulAdd is not exported so I guess you don't need to worry about API compatibility?
If you want to expose an API, how about a macro (say) @lair to build "LazyArray Intermediate Representation" so that user don't need to explicitly construct MulAdd?  What I mean is that @lair α .* A * B .+ β * C is evaluated to MulAdd(α, A, B, β, C).  The same macro can also build a BroadcastArray.

block diagonal

BlockDiagonal could also live in BlockBandedMatrices.jl.

It seems MulAdd is not exported so I guess you don't need to worry about API compatibility?

It still means to change it you have to put upper bounds in METADATA on dependent packages, but it's not that big of a deal.

how about a macro

There already is the shorthand α .* Mul(A,B) .+ β .* C that lowers to MulAdd, so a macro doesn't add much. A unicode version of Mul(A,B) is preferable to me.

There already is the shorthand α .* Mul(A,B) .+ β .* C that lowers to MulAdd

But isn't it impossible to evaluate such an expression without calling materialize or materialize!?  I thought you were talking about MulAdd API for exposing the way to construct the lazy representation object that can be materialized later.

I just added support for broadcasting. Let's get that merged before moving on to Mul/mul!.


 We could skim through manually, or maybe try some off-the-shelf text classification / clustering, to get a sense of what categories of stuff people mapped, and to spot possible gaps in a schema

Big :+1: to this.


curtail: init at 1.3.0

Description of changes
Added Curtail, a simple GTK image compression utility, as curtail

Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[x] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
22.05 Release Notes (or backporting 21.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

Welcome!
I've cleaned up your derivation a little bit. You can apply my patch from here: https://pastebin.com/Pn6xLn1j
I'm not entirely sure about the strictDeps thing, and some python packages seem to use propagatedBuildInputs for everything that otherwise went into buildInputs, but maybe someone else knows more about that and can fix it for us.
Unfortunately I couldn't test the diff that I wrote (I don't have a gui nix machine), but I'm sure it should work since it's mostly stylistic changes.

Oh yeah, I totally forgot the meta part! Thanks.
As for the strictDeps thing, I tested it, it is 100% necessary. gobject-introspection is also responsible for blocking cross-building.
Why did you remove the duplicate dependencies? I was told dependencies that fit in both categories should go in both.
I can’t apply the patch, both git apply and piping the patch to patch fail.

I have re-opened this pull request due to force pushes as PR #173520. It now works!


[macOS] OS::GetCurrentMonotonicTicks should probably use CLOCK_UPTIME_RAW.

This would corresponds to other macOS API such as CACurrentMediaTime(). Otherwise we have a problem where DisplayLink callback gives target timestamp in based on CLOCK_UPTIME_RAW, but fml::TimePoint expects CLOCK_MONOTONIC_RAW.
Also the documentation for mach_absolute_time suggests clock_gettime_nsec_np(CLOCK_UPTIME_RAW) as suitable replacement and clock_gettime_nsec_np(CLOCK_UPTIME_RAW) is not mentioned in the prohibited boot time API list.
@rmacnak-google

@rmacnak-google
For reference, the related patch that switched from mach_absolute_time to clock_gettime_nsec_No problem! which caused the issue:
https://dart-review.googlesource.com/c/sdk/+/348044

mach_absolute_time and clock_gettime_nsec_np(CLOCK_UPTIME_RAW) access the same clock and so have the same fingerprinting privacy implications.
Dart_TimelineGetTicks/Micros and Timeline.now do not promise any particular clock, only that it is suitable for measuring duration and for use with Dart_RecordTimelineEvent. If an application needs some particular clock, it should access that clock itself instead of assuming Dart timeline APIs use the same clock.

So does CACurrentMediaTime() and yet it's not mentioned in the document. I would assume there is a reason why apple singled out mach_absolute_time in the document and not mentioned either clock_gettime_nsec_np(CLOCK_UPTIME_RAW) or CACurrentMediaTime().
The issue here is that Dart_TimelineGetTicks is used in fml::TimePoint in Flutter, which right now leaks through the embedder API. I opened this issue because I think that maybe the original PR was overly cautious, but if that's not the case we'll need to handle this in the embedder.

I gave this another though - I think the correct solution is to not assume anything about the embedder API clock and always rebase the time, i.e. CACurrentMediaTime() -> FlutterEngineGetCurrentTime().
I still think that maybe CLOCK_MONOTONIC_RAW is bit too defensive since we're using CACurrentMediaTime() anyway in other places of engine and can't really get rid of it, but the engine API doesn't make any guarantees about the clock and embedder should handle that properly.

@knopp is there anything actionable on the Dart side for this ?

I don't think so. I'll close the issue.


[WIP] [TEST] Analyze test case failure of #3614

Why is this PR needed?
What changes were proposed in this PR?
Does this PR introduce any user interface change?

No
Yes. (please explain the change and update document)

Is any new testcase added?

No
Yes

Build Success with Spark 2.4.4, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbon_PR_Builder_2.4.4/550/

Build Failed  with Spark 2.3.4, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.3/2250/

Build Success with Spark 2.4.4, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbon_PR_Builder_2.4.4/551/

Build Failed  with Spark 2.3.4, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.3/2251/

Build Success with Spark 2.4.4, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbon_PR_Builder_2.4.4/554/

Build Failed  with Spark 2.3.4, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.3/2254/

Build Success with Spark 2.4.4, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbon_PR_Builder_2.4.4/564/

Build Failed  with Spark 2.3.4, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.3/2268/

Build Success with Spark 2.4.4, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbon_PR_Builder_2.4.4/566/

Build Failed  with Spark 2.3.4, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.3/2270/


Add link to Grafana dashboard for Sidekiq monitoring

The Grafana dashboard doesn't show as much information as Sidekiq::Web, but it is handy for quickly viewing multiple queues and it allows you to view historical queue lengths.
Also clean up trailing whitespace in a separate commit.

TIL! Can you bump the review date?

Done! 👍
And thanks to @cbaines, who I think created the dashboard. 🙂


Report max memory used and max pause time

Report more information when benchmarks run.

since these stats are in the process of being added to Julia, should we condition this by Julia version?


Machines still work in unpowered dimension

Not sure if this is a bug, feature, or can't be changed / fixed.
I have a resident ender ocean world requiring 90K/T to run, i went in, set up an ender pump, ender tank, tessaract and a chunk loader and left.
I removed the realized dimension tab out of the builder, and let it drain. It's currently at 0 power. The drums in the Overworld are still filling up. I know it's not what is left  over as they are bedrockium drums and have put in over 8K buckets since it ran out of power.

I would love to turn off chunkloaders and similar in unpowered dimensions but I don't know how to do that currently.

Probably fixed in upcoming release (but still disabled by default)


Refs #24622 -- Documented the change of behavior when using alternative template engines with the test client

See https://code.djangoproject.com/ticket/24622. This just documents the change in behavior and recommends alternative attributes that could be used instead.

merged in 2b9eed41fa26537d1af4f818c6e4296ce3305b01, thanks!


Pretranslate already written text

The SF user often is wanting to pretranslate text they have already written to compare against as a review tool.  Serval does not have a good workflow for this, especially if the user wants USFM in the target USFM structure.  Here is a possible way to do it:

Add a flag when building under each pretranslation entry of pretranslateExistingText which will instruct Serval to pretranslate text even if there is already text in the target for that verse. Default to false (preserve current behavior).
Add a flag for USFM called textOrigin which can be preferExisting, preferPretranslated, onlyPretranslated and onlyExisting. Default to preferExisting (preserve current behavior).

Also, we need to confirm that we will use the fresh Paratext zip file when generating this USFM combo file.
This was requested by SF users (Bethany, etc.) and designed with @pmachapman.  @ddaspit, do you have any comments?

It doesn't make sense to pretranslate verses that are in the training corpus. The model will just spit out the target text in the training corpus. SF can already control what is included in the training corpus and what is pretranslated using trainOn and pretranslate when starting a build. Would that be sufficient?

These controls were requested by Peter/Bethany assuming that through SF, they would remove the desired book from training through the book/chapter filters, i.e., they want to review Luke so they would remove it from the training set.
The options for different presentations of the USFM is to enable different presentations of the data (all in the target USFM structure) to enable use cases such as:

Blue/black text from existing/new (need both AI onlyExisting and preferExisting)
Review already written chapters against an AI draft (need onlyPretranslated)

These have become particularly relevant as SF is now relying upon Serval to merge the USFM, instead of doing it internally.  They are therefore losing some functionality in the change and want to recover it.

I think I understand a bit better what is being requested.
For the pretranslateExistingText parameter, I think we should consider changing the current behavior, so that Serval always pretranslates verses that aren't in the training corpus even if there is already text in the target. This would make the pretranslateExistingText option unnecessary. I don't know if anyone would want the current behavior. If changing the behavior would break SF, then we should add the parameter and preserve the current behavior.
I can understand the purpose of the textOrigin parameter.


Proxy Implementation can be out of date on the database

The implementation field in deployed_contract_metadata can be out of date. Perhaps the best way is to load implementation field from Updated events from the proxy contract

(Partially) addressed with on-chain lookup with get_storage_at for eip1967-style proxy.


[Fix #199] Fix the homepage URI

Fixes #199.
This PR fixes the homepage URI.

Before submitting the PR make sure the following are checked:

[x] Wrote good commit messages.
[x] Commit message starts with [Fix #issue-number] (if the related issue exists).
[x] Feature branch is up-to-date with master (if not - rebase it).
[x] Squashed related commits together.
[ ] Added tests.
[ ] Added an entry to the Changelog if the new code introduces user-observable changes. See changelog entry format.
[x] The PR relates to only one subject with a clear title
and description in grammatically correct, complete sentences.
[x] Run bundle exec rake default. It executes all tests and RuboCop for itself, and generates the documentation.

Perhaps also worth adding to the README?

That is a good idea! It will help users if added like the RuboCop core.
https://github.com/rubocop-hq/rubocop#documentation

Nice catch! It's pretty weird this doesn't work without the trailing slash. Oh, well... One more argument to abandon ReadTheDocs at some point.

Sure. ReadTheDocs may have changed. I have no opinion as there is no knowledge of a services that provide documentation.

@koic I've migrated a while ago one of my other major projects to Antora (AsciiDoc) and I've been pretty happy with the results (see https://docs.cider.mx). Notice is the menu how you can easily switch between the docs for related projects and how much better doc search is. That's also why I moved the style guides from Markdown to AsciiDoc (btw, these days the canonical AsciiDoc implementation is written in Ruby, which is pretty cool). The only real problem is that converting between the two formats is a lot of work, as the auto-conversion is not precise and we'd have to update the cop docs generation logic as well.


Mods Request

Is there a way to trigger mods prior to the execution ?
the though process here is to pop a toast notification for some applications prior to install to allow the user to delay the install.

Hello @temeyers!
The custom (mods) feature is somewhat my responsibility/idea so I'm writing this first reply.
The foremost use of it is via https://github.com/Romanitho/Winget-Install and it can be used to run your own powershell scripts placed in the mods folder (AppId + "-install-once", "-install" or "-uninstall")
It doesn't integrate in the installation/uninstallation at all but waits until the installation/upgrade have been marked successful.
The reason it is integrated in WAU is because some standard upgrades overwrites the modifications done (reg/file) for an application.
This proposal of yours could be an integration of some sort of delay/cancel of the installations in the WAU toast notification itself, and that's another thing (if your showing the notifications for the users)!

The custom (mods) feature could be expanded to include "-pre" and "-post" scripts too but one problem is that when the upgrade loop in WAU runs you cant pause the script (running in System context) and show something for the user to respond to.
And a delay in that place would stop the loop from continuing the foreach looping through all the applications in need of an update...


Automate updates to InstaScale test result images

https://github.com/project-codeflare/codeflare-operator/pull/120 introduced the ability to update the CodeFlare being used for a test case. The issue however is that when you update the Default value for the deployment, the test cases are outdated.
https://github.com/project-codeflare/codeflare-operator/pull/127/commits/8c7803e22ae8c93b1865b7886ad544a54d73de15 is an example commit fixing the test failures.
We should determine a fix for this. One of the options is to update https://github.com/project-codeflare/codeflare-operator/blob/main/Makefile#L104 to also edit the test results.

Another option is for tests to fetch the proper image directly from https://github.com/project-codeflare/codeflare-operator/blob/main/controllers/defaults.go and replace a placeholder in test resource.

This has become obsolete with #279.


chore(main): release 2.6.4

:robot: I have created a release beep boop
2.6.4 (2024-07-05)
Bug Fixes

Load charts eagerly (598ad5f)

This PR was generated with Release Please. See documentation.

:robot: Release is at https://github.com/philipcristiano/et/releases/tag/v2.6.4 :sunflower:


del dublicate protect icon

subject to issue #7454

@gary-kim is this ok? -> https://github.com/go-gitea/gitea/pull/7520 @lunny: "duplicated protect button."

working on better solution

working on better solution


Separate "core" and "extras" tests.

Tests are pretty comprehensive, and almost all the examples are tested in https://github.com/NeuralEnsemble/libNeuroML/blob/development/neuroml/examples/run_all.py, and run every time on Travis-CI.
If someone wants to test a subset, they can run the individual examples...


Understanding Design Choices -- Graph vs Dot Classes

As far as I can understand, Dot being an extension of Graph, is the recommended way to create a Graph, since it gives additional capabilities for writing. But, in that case, what is the use of having separate classes?
When would one require a class without the added methods of Dot?
Additionally, if I already have a  Graph instance, is there an easy/recommended way of converting it into a Dot instance?
Ideally, there should be a from_graph method or a simple issue of casting like pydot.Dot(g).
Currently print(pydot.Dot(pydot.Graph())) would give an
digraph digraph G {
}
 {
}

(Probably not particularly useful information, 2.5 years later, but for the benefit of anyone seeing this in the future...)
@hrishikeshrt Fair questions.
the pydot.Graph class exists because it's the type used for subgraphs, which don't need all of the file-I/O methods provided by pydot.Dot. But you're correct that pydot.Dot is a subclass of pydot.Graph, making it somewhat ambiguous which one to instantiate.
Typically you'd want to work with a pydot.Dot() instance as your root graph, which can contain any number of pydot.Graph() instances added with .add_subgraph(), pydot.Node() instances added with .add_node(), and pydot.Edge() instances added with .add_edge().
If you don't need the file I/O functionality, though — maybe you only want to use .to_string() on your graph — you can have a leaner root instance by creating it as a pydot.Graph() instead.
As far as casting, the best-supported method is probably this:
graph = pydot.Graph(...)
dot = pydot.Dot(obj_dict=graph.obj_dict)

dot should be created identical to graph including all subgraphs, nodes, and edges (if not it's a bug), but will provide the additional create_* and write_* output methods.

If you don't need the file I/O functionality, though — maybe you only want to use .to_string() on your graph — you can have a leaner root instance by creating it as a pydot.Graph() instead.

(Actually... I say that, but graph.__sizeof__() and dot.__sizeof__() are probably going to be equal for any given graph, since they have all of the same instance data. So really, it may not matter one bit.)

Thank you!


Predicate simplification loop limit

Sorry I didn't extract a simpler example, but I'm working from my Mac and my current setup is somewhat broken, so I can't do that in a reasonable way (e.g. kprint does not work, but that's not the only issue). I'll try to do that in a future comment.
FWIW, I'm currently working on this proof, so it's not supposed to pass.
Bug report: predicate-loop.tar.gz
The warning I receive:
Kore version <IP_ADDRESS>
Git:
  revision:     03694d9ae4d99c76de42d49266484939b18ef6d4 (dirty)
  branch:       master
  last commit:  Tue Oct 19 09:10:32 2021 -0500
kore-exec: [3114243] Warning (WarnUnsimplifiedPredicate):
    (InfoReachability) while simplifying the claim:
    (DebugAttemptEquation) while applying equation at /private/var/tmp/_bazel_virgil/7ebb50144cfccb48519cef812dffd979/sandbox/darwin-sandbox/86/execroot/__main__/protocol-correctness/symbolic-map/typed-map.k:61:10-65:10:
    Predicate not simplified after 4 rounds.
    Original predicate:
        /* Spa */
        \not{_}(
            /* Sfa */
            \not{_}(
                /* Spa */
                \exists{_}(
                    EquationVar'Unds'6:SortCastable{},
                    /* Spa */
                    \exists{_}(
                        EquationVar'Unds'7:SortTypedMapEntryCellMap{},
                        /* Spa */
                        \and{_}(
                            /* Spa */
                            \ceil{SortCastable{}, _}(
                                /* Fl Fn D Sfa */ ConfigVarKey:SortCastable{}
                            ),
                            /* Spa */
                            \and{_}(
                                /* Spa */
                                \equals{SortTypedMapEntryCellMap{}, _}(
                                    /* Fn Spa */
                                    /* InternalMap: */ Lbl'Unds'TypedMapEntryCellMap'Unds'{}(
                                        /* element: */ LblTypedMapEntryCellMapItem{}(
                                            /* Fl Fn D Spa */
                                            Lbl'-LT-'typed-map-key'-GT-'{}(
                                                /* Fl Fn D Sfa */
                                                ConfigVarKey:SortCastable{}
                                            ),
                                            /* Fl Fn D Spa */
                                            Lbl'-LT-'typed-map-entry'-GT-'{}(
                                                /* Fl Fn D Spa */
                                                Lbl'-LT-'typed-map-key'-GT-'{}(
                                                    /* Fl Fn D Sfa */
                                                    ConfigVarKey:SortCastable{}
                                                ),
                                                /* Fl Fn D Sfa */
                                                Lbl'-LT-'typed-map-value'-GT-'{}(
                                                    /* Fl Fn D Sfa */
                                                    EquationVar'Unds'6:SortCastable{}
                                                )
                                            )
                                        ),
                                        /* opaque child: */ /* Fl Fn D Sfa */
                                        EquationVar'Unds'7:SortTypedMapEntryCellMap{}
                                    ),
                                    /* Fn Sfa */
                                    /* InternalMap: */ Lbl'Unds'TypedMapEntryCellMap'Unds'{}(
                                        /* element: */ LblTypedMapEntryCellMapItem{}(
                                            /* Fl Fn D Sfa */
                                            Lbl'-LT-'typed-map-key'-GT-'{}(
                                                /* Fl Fn D Sfa */
                                                ConfigVarKey:SortCastable{}
                                            ),
                                            /* Fl Fn D Sfa */
                                            Lbl'-LT-'typed-map-entry'-GT-'{}(
                                                /* Fl Fn D Sfa */
                                                Lbl'-LT-'typed-map-key'-GT-'{}(
                                                    /* Fl Fn D Sfa */
                                                    ConfigVarKey:SortCastable{}
                                                ),
                                                /* Fl Fn D Sfa */
                                                Lbl'-LT-'typed-map-value'-GT-'{}(
                                                    /* Fl Fn D Sfa */
                                                    ConfigVarValue:SortCastable{}
                                                )
                                            )
                                        ),
                                        /* opaque child: */ /* Fl Fn D Sfa */
                                        ConfigVar'Unds'DotVar2:SortTypedMapEntryCellMap{}
                                    )
                                ),
                                /* Spa */
                                \and{_}(
                                    /* Spa */
                                    \equals{SortCastable{}, _}(
                                        /* Fl Fn D Sfa */
                                        ConfigVarKey:SortCastable{},
                                        /* Fl Fn D Sfa */
                                        ConfigVarKey:SortCastable{}
                                    ),
                                    /* Spa */
                                    \not{_}(
                                        /* Spa */
                                        \exists{_}(
                                            Rulex:SortTypedMapEntryCell{},
                                            /* Spa */
                                            \not{_}(
                                                /* Spa */
                                                \ceil{SortTypedMapEntryCellMap{}, _}(
                                                    /* Fn Spa */
                                                    /* InternalMap: */ Lbl'Unds'TypedMapEntryCellMap'Unds'{}(
                                                        /* element: */ LblTypedMapEntryCellMapItem{}(
                                                            /* Fl Fn D Spa */
                                                            Lbl'-LT-'typed-map-key'-GT-'{}(
                                                                /* Fl Fn D Sfa */
                                                                ConfigVarKey:SortCastable{}
                                                            ),
                                                            /* Fl Fn D Sfa */
                                                            Rulex:SortTypedMapEntryCell{}
                                                        ),
                                                        /* opaque child: */ /* Fl Fn D Sfa */
                                                        EquationVar'Unds'7:SortTypedMapEntryCellMap{}
                                                    )
                                                )
                                            )
                                        )
                                    )
                                )
                            )
                        )
                    )
                )
            )
        )
    Output after 4 rounds:
        /* Sfa */
        \not{_}(
            /* Spa */
            \exists{_}(
                Rulex:SortTypedMapEntryCell{},
                /* Sfa */
                \not{_}(
                    /* Sfa */
                    \ceil{SortTypedMapEntryCellMap{}, _}(
                        /* Fn Spa */
                        /* InternalMap: */ Lbl'Unds'TypedMapEntryCellMap'Unds'{}(
                            /* element: */ LblTypedMapEntryCellMapItem{}(
                                /* Fl Fn D Sfa */
                                Lbl'-LT-'typed-map-key'-GT-'{}(
                                    /* Fl Fn D Sfa */
                                    ConfigVarKey:SortCastable{}
                                ),
                                /* Fl Fn D Sfa */ Rulex:SortTypedMapEntryCell{}
                            ),
                            /* opaque child: */ /* Fl Fn D Sfa */
                            ConfigVar'Unds'DotVar2:SortTypedMapEntryCellMap{}
                        )
                    )
                )
            )
        )

Thanks Virgil, this is interesting. We'll need to see if removing the limit induces looping behavior, maybe it's just the case that it eventually gets fully simplified after more iterations. If it's looping, then we can study this example to get a better idea of what exactly is looping inside the simplifier.

@dopamane tried to reproduce this but failed, @andreiburdusa could you take a look as well?

I also failed reproducing the error. All I get is some WarnFunctionWithoutEvaluators warnings

I'm going to close this since we can't reproduce it.


Sentence field must be of type str

In nmea_topic_serial_reader, sentence field is a bytes object and should be a str object.
Fixes: https://github.com/ros-drivers/nmea_navsat_driver/issues/172

Thank you for finding this and contributing a fix.


cover:close

Using the cover: close function from HA  outputs a warning message:
"WARNING (MainThread) [homeassistant.components.mqtt.cover] Payload is not supported (e.g. open, closed, opening, closing, stopped): close"
I think it is related to the state payload from MQTT . Looking at the mqtt_convention_api i think the following should be changed:
        msg.payload_open = "open"
        msg.payload_close = "close"
        msg.payload_stop = "stop"

        msg.state_open = "open"
        msg.state_closed = "close" -- it is "closed" in the QA now
        msg.state_opening = "opening"
        msg.state_closing = "closing"
        msg.state_stopped = "stop" -- missing in the QA now

Happy New Year !!!!!

Sure, I can look at it once I'm done with a massive refactoring of the QuickApp this week

"massive refactoring of the QuickApp" sounds interesting.

Speaking about refactoring, and just to make sure you saw the message from another thread => the QuickApp is now simplified and uses less variables for configuration => no need to pass HC3 user/pass, as the QuickApp passes authorization automatically now

yuo saw it :) thank you !

@MomosX
It should be fine use use "closed" (or even "my_favourite_string") for the state_closed parameter, according to Home Assistant MQTT spec.
I believe the fix would be to avoid use of position_topic and state_topic at the same time. I plan to release the QuickApp using position_topic only today. It works for me and then you can test if it works for you too.

Hi @MomosX, please let test if the issue is fixed, or persist?

The latest QuickApp version addresses multiple changes for Fibaro cover devices.
Closing this issue as outdated / no more inputs received.


[BUG] Streaming Pipeline Log Fetching issues

Mage version
0.9.69
Describe the bug
For last 30days logs of trigger level is not working and custom date also not working.

The filter is for the last 30days.
To reproduce
No response
Expected behavior
We should be able to extract the current running logs rather than selecting the pipeline execution start date.
Screenshots
No response
Operating system
No response
Additional context
No response

@wangxiaoyou1993 Any planned dates for this

working on this ticket now

@wangxiaoyou1993 any plan for this in our roadmap?

hi @sujiplr
you can workaround this problems seting start_timestamp=0 on url: "&_limit=20&_offset=0&start_timestamp=0"
like https://your_mage_url/pipelines/streamingPipe1/logs?pipeline_schedule_id[]=01**&_limit=20&_offset=0&start_timestamp=0**
@wangxiaoyou1993 When I choose, a time option on frontend the timestamp not roollsback to 0 and this is the "bug"


extending SFA to wind power analysis

I'm frequently asked what we'd need to do to support wind power forecast analyses in the Arbiter. Technically it works now if you ignore the solar specific items and hack your way around the solar plant metadata. So for this issue I'll interpret the question to mean: what do we need to do to support wind power as robustly as we support solar power?
I'll update the list below with potential new requirements as they're discussed in this issue or elsewhere.

[ ] replace documentation and report text references to "solar" with "solar and wind" or "wind" where appropriate
[ ] create a datamodel.WindModelingParameters similar to datamodel.PVModelingParameters
[ ] create a datamodel.WindPowerPlant similar to datamodel.SolarPowerPlant. The SolarPowerPlant doesn't have anything particular to solar aside from the modeling parameters type hint, so it could easily be generalized to PowerPlant. A WindPowerPlant might need richer metadata for specifying individual turbine locations and specs. There are probably enough forecasters interested in turbine by turbine forecasts vs. plant forecasts that we need to think hard about these metadata issues as well as aggregation.
[ ] create new wind variables like wind_80m through wind_120m or maybe just wind_hub_height. maybe users would want us to track direction or shear too.
[ ] might need to track other weather variables for things like icing
[ ] data validation toolkit needs new limit checks, maybe other more sophisticated checks. icing and high speed cutouts come to mind.
[ ] reference wind power data
[ ] reference wind speed data at hub height
[ ] implement a reference forecast based on NWP data using simple turbine metadata

You could also consider adding load forecasts (e.g., building electric load, distribution feeder load, or ISO/RTO etc. balancing area load) and/or net load forecasts (e.g., net after solar). We recently completed a building-level load forecasting trial with EPRI. EPRI also created a reference forecast model which might be easy to implement.

@williamhobbs thanks, it's definitely a good idea to keep those applications in mind as we think about refactoring to support wind.
We put a little bit of thought into load forecasts earlier this year when SETO announced their FY20 funding that included a subtopic on AI/ML for net load forecasts. That subtopic actually specified that awardees are supposed to use Solar Forecast Arbiter to assess their forecasts. SETO has not yet announced the winner(s) of those awards, but I expect we'll need to rethink the "sites", "observations", and "aggregates" model for really robust support of their forecasts. A datamodel that allows for building --> feeder --> substation --> load pocket --> BA/ISO could also allow for more granularity in wind and solar. I'd also like to see a broader stakeholder engagement effort to better understand the requirements.
For the record, we do already support basic analyses of "net load" in that you're allowed to specify that as the variable type for an observation or forecast. Also the reference data set includes observations and reference forecasts for the US ISOs. For example, here's a link to the CAISO "site": https://dashboard.solarforecastarbiter.org/sites/c52b4b26-bfd7-11ea-adc8-0a580a800344/ The reference forecasts are just based on persistence, so there's a lot of room for a more sophisticated (but still understandable and transparent) reference forecast.


Docs and more tests

:warning: Please install the  to ensure uploads and comments are reliably processed by Codecov.
Codecov Report
Attention: Patch coverage is 75.55556% with 22 lines in your changes missing coverage. Please review.

Project coverage is 91.48%. Comparing base (c25505b) to head (ba399bf).

Files with missing lines
Patch %
Lines

packages/dartcv/lib/src/dnn/dnn.dart
27.77%
13 Missing :warning:

packages/dartcv/lib/src/core/rect.dart
80.43%
9 Missing :warning:

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@            Coverage Diff             @@
##             main     #270      +/-   ##
==========================================
+ Coverage   90.55%   91.48%   +0.93%
==========================================
  Files          49       49
  Lines        9049     9125      +76
==========================================
+ Hits         8194     8348     +154
+ Misses        855      777      -78

Flag
Coverage Δ

unittests
91.48% <75.55%> (+0.93%)
:arrow_up:

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

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


SelectorIcon missing from v2

The SelectorIcon appears to be missing from v2.
It's used for example in the Select Menus in TailwindUI.
I thought maybe it had been renamed but I can't seem to find it.
Unless this is an intentional removal?

It's not in the Figma file.  Will be interesting to see what's up with it.

Is there a migration guide?

As I could find it, I ended up using the ArrowsUpDownIcon for now.

The refresh icon seems to be missing as well. I used this one quite often.

@nik736 does the ArrowLeftRight not help you for the refresh?  I don't have a good alternative for the SelectorIcon though which I also miss...

@denjaland Well, it's not the same. The old version also had both, refresh and ArrowLeftRight :)

@nik736 have you checked the ArrowPathIcon?

arrow path is very different. this is the closest so far

@steveoh I know the topic has been hijacked a bit by @nik736, but I meant as a replacement for his refresh icon.
The ChevronUpDown icon has been added recently - you probably need to update your react library ;-)

Just added this icon to the set as chevron-up-down 👍🏻

@steveoh I know the topic has been hijacked a bit by @nik736, but I meant as a replacement for his refresh icon. The ChevronUpDown icon has been added recently - you probably need to update your react library ;-)

Thanks. It's ChevronUpDownIcon


Adding global tree to database

Global tree added to database (run load_all_datasets.sh)
Global tree currently displayed with phylogenies (will need to be moved, as it isn't a phylogeny)
Cleaned up some of the tree code

#97 #99


Input file generations

Hi!
Could you clarify what the input files need to contain in the bed and anchor files? For instance, do I need to map my contigs my scaffolds and specify the coordinates of contigs? It would be great if you could provide a bit more detailed workflow for each of these files.
Thank you!
head *.bed
==> qry.bed <==
Chr01   41145   41785   qry_00001       0       +
Chr01   59154   71715   qry_00002       0       -
Chr01   103208  111702  qry_00003       0       -
Chr01   149421  150851  qry_00004       0       -
Chr01   191873  224679  qry_00005       0       +
Chr01   250203  251891  qry_00006       0       +
Chr01   254140  255065  qry_00007       0       -
Chr01   266012  268537  qry_00008       0       +
Chr01   278218  283309  qry_00009       0       +
Chr01   284138  310323  qry_00010       0       -

==> ref.bed <==
Chr01   55738   61737   ref_00001       0       -
Chr01   106533  107844  ref_00002       0       -
Chr01   168873  170182  ref_00003       0       -
Chr01   202454  203895  ref_00004       0       -
Chr01   235032  236624  ref_00005       0       -
Chr01   273437  277531  ref_00006       0       +
Chr01   316293  318461  ref_00007       0       +
Chr01   332249  332956  ref_00008       0       -
Chr01   375185  385620  ref_00009       0       +
Chr01   388537  389590  ref_00010       0       -

head qry.ref.anchors
###
qry_00271       ref_02777       3600
qry_00272       ref_02778       1610
qry_00273       ref_02779       2250
qry_00275       ref_02771       319
qry_00277       ref_02769       969
qry_00278       ref_02768       2490
qry_00288       ref_02762       490
qry_00290       ref_02756       1160
qry_00291       ref_02755       2470

This tools is designed for adjusting the assembly result of ALLHiC (or other scaffolding tools which can output agp file) by modifying blocks of contigs on chromosomes based on the collinearity between assembly genome and reference genome, both of genomes should be chromosome level assembly.
The files required with this tool are two bed files, one anchors file and one agp file, details of them are:

The JCVI package is required to generate ref.bed and qry.bed file from gff3 files with command below,

python -m jcvi.formats.gff bed --type=mRNA --key=Name ref.gff3.gz -o ref.bed

Both gff files should be chromosome or pesudo-chromosome level, and if the annotation of the new assembly (query one) is missing, a simple way to use this tool is using gmap to mapping reference CDS to the query genome (chromosome level).
The anchors file is also required JCVI package, with 4 files that qry.bed, qry.cds, ref.bed and ref.cds, then run command below,

python -m jcvi.compara.catalog ortholog qry ref

More details of JCVI could be found in JCVI.
3. AGP file is a text file which recorded the contig positions and orients on chromosomes. More details could be found in AGP file format

Thank you for the instruction!


ETHUSD: Long and short liquidation price are swapped

In addition to https://github.com/itchysats/itchysats/issues/2754 we should check how we compute the liquidation prices. Right now they are swapped:
Long position shows short liquidation price and vice versa:

https://github.com/itchysats/itchysats/issues/2774 should be resolved with https://github.com/itchysats/itchysats/pull/2790
The flipped liquidation price is yet to be investigated!

Note: Further assertions in the actor tests - https://github.com/itchysats/itchysats/pull/2799 - currently point to this problem coming from the UI.
Once https://github.com/itchysats/itchysats/pull/2799 is finished (see https://github.com/itchysats/itchysats/issues/2802) I will have another look at this.

So, the problem is again pointing us to fix #2786
The issue is that we create an offer from the perspective with liquidation price of the maker.
In the frontend, we think we just flip it around but this is wrong because the liquidation price for the maker != the liquidation price for the taker.
In values expressed (other values omitted):
These are the offers as received in the frontend:
[
  {
    "contract_symbol": "EthUsd",
    "position": {
      "key": "Long"
    },
    "price": "9850.00",
    "leverage_details": [
      {
        "leverage": 2,
        "liquidation_price": "4925",
      },
      {
        "leverage": 1,
        "liquidation_price": "1",
      },
      {
        "leverage": 3,
        "liquidation_price": "6567",
      }
    ],
  },
  {
    "contract_symbol": "EthUsd",
    "position": {
      "key": "Short"
    },
    "price": "11165.00",
    "leverage_details": [
      {
        "leverage": 2,
        "liquidation_price": "16747",
      },
      {
        "leverage": 1,
        "liquidation_price": "22330",
      },
      {
        "leverage": 3,
        "liquidation_price": "14886",
      }
    ],
  }]

It says:

maker long:
price: 9850
liquidation price 4925, ..
maker short:
price: 11165
liquidation price 16747, ...

From the maker perspective this is correct.
Now if we want to turn this around, we will need to flip the liquidation prices.

Note: one problem is that we need to have both offers available which we can't be guaranteed because they come through 2 different event sources. Again, pointing to https://github.com/itchysats/itchysats/issues/2786 ;)

An alternative solution would be to compute the liquidation price in the frontend then we would not need to swap things around.

Concerning the specific problem:
To my knowledge in 0.5.5 the liquidation price is still displayed correctly in the taker UI and not flipped.
The liquidation price sent out in LeverageDetails is supposed to be according to the own position and leverage. I think the problem is, that somehow we use the maker's position now, but we should convert it into the own_position - as we did until 0.5.5:
https://github.com/itchysats/itchysats/blob/59a7b9b8f455f767845ef0c2162a8a3b0efd2b98/daemon/src/projection.rs#L1347-L1350
I think we can just fix that for now.

Concerning making the model better:
I totally agree that the projection model is not designed well and should be cleaned up. This concerns both the projection::CfdOffer and projection::Cfd.
We have argued in the past, that the projection should always model what the consumer needs, i.e. the taker UI should receive the values from the taker's perspective; the maker UI / other consumers might need even more fields because they may require taker and maker specific values, we had that problem in the past that suddenly we only say maker related data and that was not sufficient.
In the past we have discussed to split the model between maker and taker, so that the API can cater for the needs of the consumers better. I think this would be a good way forward, but will require some more work.
Note: We can change the internal model (i.e. model::Cfd, model::Offer) as well, but they are independent of changing the API (i.e. the projection).

@bonomat I think what you proposed in https://github.com/itchysats/itchysats/pull/2764 - i.e. remove the flip from the UI - would be a good step forward, but we would then have to start refactoring the projection::CfdOffer model.
For now we could opt to just adapt it so it works for the taker-UI and ignore the maker-UI 😬

The liquidation price sent out in LeverageDetails is supposed to be according to the own position and leverage, see:

well that is blody confusing 😅


No ACCEPT option for refund after REVEAL of bid for CURRENCIES.ETH

Dear Sir/Madame,
On June 20 and June 21, I attempted to bid a total of 0.77, 0.76, 0.75 and 0.72 to secure name CURRENCIES.ETH; unfortunately, all of these attempts were 'Rejected' or 'Failed'. I either did not receive confirmation of this bid or if I did, my MetaMask does not show an approved transaction for CURRENCIES.ETH. Auction site https://registrar.ens.domains/#currencies however, indicates that 'You are willing to pay at most: 0.74 ether; 0.01 ether will refunded when you reveal your bid.' When I click on the REVEAL button to obtain these funds back (which were somehow withdrawn from my MetaMask Ethereum Main Net network without confirmation), MetaMask notification indicates that there is 'Insufficient balance for transaction' and I am unable to ACCEPT reveal to obtain these funds back.
Please review this transaction for CURRENCIES.ETH and refund 0.74 + 0.01 ETH back to my account before auction ends early 06/24. Please also inform<EMAIL_ADDRESS>if there is any further information you need from me in order to resolve issue. Thank you for your time as I look forward to a speedy resolution.

When I click on the REVEAL button to obtain these funds back (which were somehow withdrawn from my MetaMask Ethereum Main Net network without confirmation), MetaMask notification indicates that there is 'Insufficient balance for transaction' and I am unable to ACCEPT reveal to obtain these funds back.

You need to place enough funds in your account to be able to send the reveal transaction, or you will not be able to send it and recover your ether.

Please review this transaction for CURRENCIES.ETH and refund 0.74 + 0.01 ETH back to my account before auction ends early 06/24.

ENS is a distributed system. We have no access to your funds, and it's up to you to follow the rules of the contract when interacting with the system.

Regarding https://github.com/ethereum/ens/issues/218:
Thank you Arachnid for your quick reply. Per your suggestion, I placed additional funds in my MetaMask account to be able to send the reveal transaction. After I did this, I received https://registrar.ens.domains/#currencies confirmation that "...since someone else was willing to pay more, your full deposit was returned, minus a bidding fee of 0.0037 ether which was burned." However, according to MetaMask's Ethereum Main Net network, I did not receive my 0.74 ether deposit as confirmed on registrar.ens.domains for CURRENCIES.ETH.

Would someone from your end be able to review this transaction for me?
Or should I contact MetaMask regarding refund that was not received?

Thank you for your time as I look forward to hearing from you soon.
Kind regards,
Zee Wilson
<EMAIL_ADDRESS>Cell:<PHONE_NUMBER>

Regarding https://github.com/ethereum/ens/issues/218:
Thank you for your quick reply. Per your suggestion, I placed additional
funds in my MetaMask account to be able to send the reveal transaction.
After I did this, I received https://registrar.ens.domains/#currencies
confirmation
that "...since someone else was willing to pay more, your full deposit was
returned, minus a bidding fee of 0.0037 ether which was burned." However,
according to MetaMask's Ethereum Main Net network, I did not receive my
0.74 ether deposit as confirmed on registrar.ens.domains for CURRENCIES.ETH.

Would someone from your end be able to review this transaction for me?
Or should I contact MetaMask regarding refund that was not received?

Thank you for your time as I look forward to hearing from you soon.
Kind regards,
Zee Wilson
<EMAIL_ADDRESS>Cell:<PHONE_NUMBER>
On Fri, Jun 23, 2017 at 4:39 AM, Nick Johnson<EMAIL_ADDRESS>wrote:

When I click on the REVEAL button to obtain these funds back (which were
somehow withdrawn from my MetaMask Ethereum Main Net network without
confirmation), MetaMask notification indicates that there is 'Insufficient
balance for transaction' and I am unable to ACCEPT reveal to obtain these
funds back.
You need to place enough funds in your account to be able to send the
reveal transaction, or you will not be able to send it and recover your
ether.
Please review this transaction for CURRENCIES.ETH and refund 0.74 + 0.01
ETH back to my account before auction ends early 06/24.
ENS is a distributed system. We have no access to your funds, and it's up
to you to follow the rules of the contract when interacting with the system.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/ethereum/ens/issues/218#issuecomment-310607742, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AcGTtaENPrpOS_sFjQSIEAgFOHfOu5_1ks5sG3nGgaJpZM4ODBpj
.

Your ether was returned; you can see it in the 'internal transactions' tab on etherscan.

Thank you for informing where I may see this ether return. I do see in
etherscan's "internal transactions" that 0.7363 Ether has been sent back to
my account 0xc5894ecb9951453... However, this $265.13 amount still has not
been deposited back into my Ethereum Main Network in MetaMask, where I
received these funds from.

Would you be able to manually refund 0.7363 ether back to my MetaMask
Ethereum Main Network account?
Or is there another place where I may access and withdraw these funds
(perhaps within Etherscan)?

Thank you for your time as I look forward to hearing from you soon.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/ethereum/ens/issues/218#issuecomment-310921162, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AcGTtfX0sNiqPQFXvOCYzqpioEDEGyZKks5sHq4IgaJpZM4ODBpj
.


Device abstraction

Users will not like lugging the GPUResourceManager around.
Each tensor should store a reference to the underlying Device.

Completed


feat(layout): fix sidebar & toolbar position in viewport

This PR adds the participants stat to the home page.

#117

1440px

768px

375px

I think the last-child css selector is not robust: what will happen if there is not only the toolbar and the main page, but also other elements? the last child will not necessarily select the right element... don't you think @fredericvilcot ?

Yes, would be better to target the className IMHO

Yes you are correct. I've added a wrapper class name to avoid potential issues. I've also reworked the layout padding to be able to position the scrollbar more to the right, please see updated images


Changes for using official Vue packages.

@denisbednov,
Thanks for your contribution.
To ensure that the project team has proper rights to use your work, please complete the Contribution License Agreement at https://cla.microsoft.com.
It will cover your contributions to all Microsoft-managed open source projects.
Thanks,
Microsoft Pull Request Bot


Fix overflowing header error for issue #1100

This PR fixing issue #1100

Codecov Report

Merging #1142 into master will decrease coverage by 0.02%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master    #1142      +/-   ##
==========================================
- Coverage   55.56%   55.53%   -0.03%
==========================================
  Files          41       41
  Lines       10124    10127       +3
==========================================
- Hits         5625     5624       -1
- Misses       3476     3479       +3
- Partials     1023     1024       +1

Impacted Files
Coverage Δ

msg.go
76.64% <100.00%> (-0.57%)
:arrow_down:

msg_helpers.go
68.01% <100.00%> (ø)

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 34cecfe...b22fdcb. Read the comment docs.

i disagree this needs fixing

I prepared this PR because you suggested but if you change your mind, I can close this.


The document of 'プログラミング言語SML#解説' has invalid link

The Japanese document has links to https://www.pllab.riec.tohoku.ac.jp/smlsharp/docs/3.6.0/ja/ in top of Part N pages.
For example, in this page.
But now, this link will lead to 403 forbidden error page.
Because this link does not redirect to https://www.pllab.riec.tohoku.ac.jp/smlsharp/docs/3.6.0/ja/index.xhtml.
Link

Fixed. Thanks!


[v1.3] Refactor room package and fix UI bugs in v1.2

Main

Changed all Room classes except UniqueRoomList, and Expenses to be immutable. Expenses will be done by @teowz46
Refactored tests, like CheckoutCommandTest and RoomTest
Refactored test utils, like TypicalRooms, TypicalBookings
Fixed style in user guide
UI not updating appropriately upon command in v1.2 was due to mutable changes to Room object not being detected by ObservableList, which is expected behavior of ObservableList. After refactoring Room (and the associated classes) to immutable, this bug has been fixed.
Fixed commands_log in .git_ignore

I have no idea why Travis is failing here. This branch passes on my local, using the same checks that Travis uses.

Pull Request Test Coverage Report for Build 269

126 of 146 (86.3%)  changed or added relevant lines in 16 files are covered.
25 unchanged lines in 7 files lost coverage.
Overall coverage increased (+0.5%) to 85.672%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

src/main/java/seedu/address/logic/commands/CheckinCommand.java
0
1
0.0%

src/main/java/seedu/address/model/room/Room.java
21
22
95.45%

src/main/java/seedu/address/model/room/UniqueRoomList.java
9
10
90.0%

src/main/java/seedu/address/model/room/booking/Booking.java
14
16
87.5%

src/main/java/seedu/address/model/room/booking/Bookings.java
31
33
93.94%

src/main/java/seedu/address/model/AddressBook.java
25
28
89.29%

src/main/java/seedu/address/storage/XmlAdaptedRoom.java
12
16
75.0%

src/main/java/seedu/address/model/util/SampleDataUtil.java
0
6
0.0%

Files with Coverage Reduction
New Missed Lines
%

src/main/java/seedu/address/model/util/SampleDataUtil.java
1
70.97%

src/main/java/seedu/address/model/room/booking/BookingPeriod.java
1
80.56%

src/main/java/seedu/address/model/room/booking/Bookings.java
1
87.5%

src/main/java/seedu/address/model/AddressBook.java
1
90.91%

src/main/java/seedu/address/model/room/Room.java
2
94.29%

src/main/java/seedu/address/model/expenses/Expenses.java
3
57.69%

src/main/java/seedu/address/logic/CommandArchive.java
16
0.0%

Totals

Change from base Build 236:
0.5%

Covered Lines:
2021

Relevant Lines:
2359

💛  - Coveralls


Petfinder might be dead, or at least the link is dead

The link provided in the readme for petfinder now leads to a redirect site instead of the api.

See #911

Both the old doc and new doc links are 404ing with Travis, not sure what the issue is - see https://github.com/toddmotto/public-apis/pull/926


tools/ symlink still required when using a .bazelrc in repository

My project checks in a .bazelrc file the repository to provide standard options to all developers. This means that the tweak described in http://bazel.io/blog/2015/04/06/Simplified-Workspace-Creation.html doesn't work, since the system-wide .bazelrc file isn't read if there is a local .bazelrc file, so I still have to symlink tools/ manually.
Maybe Bazel could read non-conflicting options from the home directory .bazelrc instead of ignoring it completely?

Where do you put your bazelrc file?
Master bazelrc's:
/etc/bazel.bazelrc
%workspace%/tools/rc.bazel
user bazelrc's:
--bazelrc=path
$HOME/.bazelrc
%workspace%/.bazelrc
It works that way: master bazelrc file are read first except if --nomaster_blazerc option is specified, then the first user bazelrc found is read (meaning that if you specify --bazelrc option then neither $HOME/.bazelrc nor %workspace%/.bazelrc is read).
Note also that if you specify the --package_path in all files, then the user bazelrc's option will replace the master bazelrc ones.

I have my bazelrc in %workspace%/.bazelrc, right next to the WORKSPACE file. It looks to me like that rc file is taking priority over the one in $HOME/.bazelrc, so the package_path flags in home (which are set up during installation) have no effect.
Is it intended for home to take priority over workspace? That also feels wrong to me.

The code looking for the bazelrc is there.
So masterc:

depot: tools/bazel.rc
alongside blazerc: path/to/bazel.bazelrc
system-wide: /etc/bazel.bazelrc

Then the user bazelrc:
a. command line provided rcfile
b. workspace rcfile
c. user's rcfile
The order of reading the files are 1, then 2, then 3 then first one found in a.b.c. The option are then concatenated to the bazel command line so the last package_path is the one used.
That's indeed as you said the workspace file take precedence of the user rcfile. I think that's because we do not check in dotted file in the workspace root so they are user specified and depending on your workspace you might want to have different user specified-one.
For your usage your should use the master bazelrc in tools/bazel.rc. With that, if a user has a ~/.bazelrc, option specified in it will take precedence over those in the workspace rcfile.

Interesting - so if I understand correctly, you'e suggesting that I not check in %workspace%/.bazelrc, but do check in the same file in %workspace%/tools/bazel.rc. In that case the tools repository in my workspace would have only that one file, which I guess is fine as long as bazel still checks the other tools directory in the package path.  Seems to work okay if I try it out - am I understanding correctly?

Yes. As long as you don't have build file in that directory
Le ven. 19 juin 2015 à 09:23, Erik Kuefler<EMAIL_ADDRESS>a
écrit :

Interesting - so if I understand correctly, you'e suggesting that I not
check in %workspace%/.bazelrc, but do check in the same file in
%workspace%/tools/bazel.rc. In that case the tools repository in my
workspace would have only that one file, which I guess is fine as long as
bazel still checks the other tools directory in the package path. Seems to
work okay if I try it out - am I understanding correctly?
—
Reply to this email directly or view it on GitHub
https://github.com/google/bazel/issues/254#issuecomment-113405866.

--
Damien

OK, moving the file to tools/ seems to be working fine for me. Not sure if you want to keep this open or not - still seems a bit surprising that adding a .bazelrc file to the workspace basically breaks the installation, but the workaround is easy and I'm not sure what an alternative solution would be.

It is documented that way. The documentation needs a bit update on that so I will mark it as a documentation issue until the documentation is fixed.

Forgot to mark this bug as fixed:

documentation was fixed in bf6dcb7
A blog post to clarify in 00e5df7


Qnamaker and Luis sample: answer with prompts breaks business logic

The idea of this sample is to first try and understand the intent of a user (Luis) and if bot succesfull find an answer in a connected knowledgebase.
As soon as the answer from qnamaker containts prompts, Luis seems not to be consulted for the next user input.
How to reproduce:
Create a qna answerpair with prompts
Create a qna answerpair with 'help' in it.
Start Bot
type help -> the intent in Luis is used
type question with answer in QnAKB -> answer is shown with prompts
type help -> the QnAKB is consulted and answer in QnaQB is shown (with help in it)

@HesselWellema If I understand correctly, you want luis to be recognized but not the QnA answerpair even if the 'help' includes in the QnA answerpaire.
We do plan to support this scenario in upcoming release in composer.

Exactly. First Luis needs to be recognized. If that fails, QnaMaker needs to be recognized.

@HesselWellema when you have multi-turn prompt in QnA maker, then subsequent user replies to multi-turn prompt are only handled by QnA maker. We are working on a more deeper integration with QnA maker and until that is available in composer there isn't a way to do consultation across LUIS and QnA maker.
This capability however does exist in the SDK. You could consider switching your bot to be SDK based and use the cross-trained recognizer. See this sample.
@pchoudhari @cwhitten

thanks @vishwacsena. This is exactly what I need. I use JS for bot development and know adaptive daialogs are in preview. Do you  expect this recognizer to become available (in preview) soon in JS?

@HesselWellema sure, JS is available in 'preview'. See sample here

Ok, tnx for your support


Environment variables are required to run this application

Dear open source author, I am unable to run this project. Could you provide me with the environment variables that you used to run it? These include LISTING_ID, ITEM_MARKET_NAME, LISTING_FILTER_PARAM, LISTING_START_PARAM, RATE_LIMIT, and others.

Hi! App works next way: request page with listing from steammarket with currencies from CURRENCIES_TO_FETCH. This action requires some "stable" listing on market, which will be active all the time.  To find this listing app need some data: LISTING_ID  of this listing of course, ITEM_MARKET_NAME like "USP-S | Cortex (Field-Tested)", LISTING_FILTER_PARAM to search trough listings (it may be sticker name on item, smth else), LISTING_START_PARAM if item is not on the results first page (e.g. 10 - for second page, 20 -  for third). RATE_LIMIT - how many requests be in one app invoke time. STEAM_GAME_ID - app id of steam game, like 730 - CSGO, 570 - DOTA2.


(WSL2) Mapped drives fail with "The parameter is incorrect"

Your Windows build number:  Microsoft Windows [Version 10.0.18922.1000]

Mount a network drive to \\wsl$\Ubuntu. This works fine. After a while, and always after hibernating, the drive becomes unaccessible and a dialog with U:\ is not accessible. The parameter is incorrect. shows up.
Going directly to \\wsl$\Ubuntu works as expected, and detaching and reattaching the drive works for a little while.
IntelliJ does not support having projects at UAC paths, hence Network drive is necessary, but it's only workable for a few minutes before failing.
Might be related to #4143

Hello,
You have a small typo in the command. Should be:
net use U: \\wsl$\Ubuntu


Added Polish (Programmers) Layout for JIS keyboards

Thanks for your work! You saved me a lot of time.
Added Polish (programmers) keyboard layout that works with JIS (japanese 106/109) keyboards.
Feel free to merge this PR if you feel like it.

Thank you @quirell, I will merge it. Such unexpected combinations as Polish + Japanese is the reason why this kind of project can only be cooperative.


Fix seeking skip when you join a room midway through a track

---
Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/23372484-fix-seeking-skip-when-you-join-a-room-midway-through-a-track?utm_campaign=plugin&utm_content=tracker%2F9578624&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F9578624&utm_medium=issues&utm_source=github).

It starts at beginning of tune, then seeks after a delay, but you hear the beginning of tune so sounds a bit crap...

Also affecting preview


Add scan improvements

This PR:

adds these options to the scan action:

suppress_xcode_output that defaults to false and prevents printing the build's output when set to true
app_identifier and reinstall_app that defaults to false and reinstalls the app with the specified, auto-detected or typed app_identifier when set to true

opens the report (if the open_report option is active) when tests fail too

@joshdholtz, Bump 😃

Bump


CI / GSG : make Kafka service headless

The current Kafka yaml in GSG and K8ts test have the Kafka service as a ClusterIP service. When we enforce an allow-all policy, and try to consume, the Kafka broker sends out a service discovery request for the other brokers. Ideally it should resolve to itself (with a single broker configuration), but there is currently a bug in data path which does not resolve the reverse NAT for loopback address correctly. By making this service headless, we can avoid the request from leaving the node altogether.
This also fixes the "first consume delay" which we see due to drops in data path for the Kafka broker service discovery requests.
Fixes: #3319
CI / GSG : make Kafka service headless

test-me-please

@joestringer This is not only due to the data path issue. With multiple brokers, the correct way is to have headless services for each of the broker, else multiple brokers will not communicate with each other.  I will be raising the GitHub issue soon Thanks!


adshnk.com isn't bypassed

Domain
https://adshnk.com/
Link
http://adshnk.com/Bj3jBO
Version
0.0.0
What browsers are you seeing the problem on?
Firefox, Chrome
What OS are you seeing the problem on?
No response
(Optional) Anything else?
No response
Code of Conduct

[X] I agree to follow this project's Code of Conduct

it "redirects"  to the same website, just uses captcha...


Forever initializing after 1.8

Hi
After upgrade to 1.8 my theatre keeps initializing forever. Attached screenshot and log file with debug enabled. The log file does not give me any clue to what is causing the problem. I've tried to delete the theatre device and added it again. Can someone point me to a direction where I can see the rootcause to the init problem.
Kind regards
Frank
Attached files:

home-assistant_2024-01-26T17-16-21.144Z.log
The hiccup:
2024-01-26 18:05:00.471 ERROR (MainThread) [homeassistant.config_entries] Error setting up entry Beosound Theatre-35857485 for bangolufsen
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/config_entries.py", line 406, in async_setup
result = await component.async_setup_entry(hass, self)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/config/custom_components/bangolufsen/init.py", line 93, in async_setup_entry
if not await client.check_websocket_connection():
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/mozart_api/mozart_client.py", line 200, in check_websocket_connection
async with session.ws_connect(f"ws://{self.host}:9339/") as websocket:
File "/usr/local/lib/python3.11/site-packages/aiohttp/client.py", line 1187, in aenter
self._resp = await self._coro
^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/aiohttp/client.py", line 825, in _ws_connect
resp = await self.request(
^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/aiohttp/client.py", line 601, in _request
await resp.start(conn)
File "/usr/local/lib/python3.11/site-packages/aiohttp/client_reqrep.py", line 960, in start
with self._timer:
File "/usr/local/lib/python3.11/site-packages/aiohttp/helpers.py", line 735, in exit
raise asyncio.TimeoutError from None
TimeoutError
2024-01-26 18:05:00.521 ERROR (MainThread) [homeassistant] Error doing job: Unclosed client session

Sorry to hear that you're having problems.
I'm not able to replicate this behavior on a Balance,  Emerge, Level or a Theatre.
What version of Mozart is the Theatre running? And I'm guessing it was working in 1.6.2? Was the Theatre added to Home Assistant using Discovery or by manually entering the IP address?
It looks like Home Assistant can't establish a WebSocket connection to the Theatre.
A difference between 1.6.2 and 1.8.0, is that 1.8.0 checks if a WebSocket connection can be made before starting the integration, which is where your setup is failing. The code to check connection and actually establish connection is not very different, so I wouldn't expect there to be any problems.
Kind regards

My Theatre is running software version <IP_ADDRESS>. I tried to delete all entities, deleted the HACS integration, restartet my Synology (which runs HA in docker), added the 1.8.1 and the problem is the same - regardless of adding it in discovery mode or manually by the static IP. My beolab 28 and Level is added ok in a few secs.
Something definitely changed in 1.8.x. When I downgrade to 1.6.2 it adds my Theatre in a few secs. By the way - I am a programmer (java). If I can help troubleshoot I would be happy to help (the reward would be that I am not stuck on 1.6.x 🤗 )
Here's my Docker HA stack + versions:

Kind Regards
Frank

So, the API actually got a big change from 1.6 to 1.8. Instead of using Threads for the WebSocket listeners, we are now using Asyncio Tasks and also a new way of handling notifications. But your setup is failing before this is even relevant.
Can I get you to comment out line 93-96:
if not await client.check_websocket_connection():
    raise ConfigEntryNotReady(
        f"Unable to connect to {entry.title} WebSocket notification channel"
    )

in __init__.py in version 1.8, reboot Home Assistant and see if the Theatre works as expected.
Kind regards

Yeah Markus. That worked.
By the way. Last night all speakers where updated to <IP_ADDRESS>. At first I just installed 1.8.1, without the code change, just to see if it worked. For some crazy reason the Theatre was added ok, but then it was my Beolab which got stuck in initializing. I commented out the code in init_py and all of my use cases now works on 1.8.1:

Press on a FUGA light switch turns on Live TV and lights in my living room
Press on favourite buttons on my Level groups other speakers in the house
Press on light control on my Beoremote One controls the lights in my living room
Volume control on all speakers from my HA app or FUGA switch

Kind Regards
Frank

Good to hear!
Looks like we've found the culprit (WebSocket connection can't be established outside of a Task/Thread sometimes?).
I've reworked the way API and WebSocket connection is checked. Could I get you to test this?
In __init__.py:
Replace async_setup_entry
With this:
async def async_setup_entry(hass: HomeAssistant, entry: ConfigEntry) -> bool:
    """Set up from a config entry."""
    # Remove casts to str
    assert entry.unique_id

    # Create device now as BangOlufsenWebsocket needs a device for debug logging, firing events etc.
    # And in order to ensure entity platforms (button, binary_sensor) have device name before the primary (media_player) is initialized
    device_registry = dr.async_get(hass)
    device_registry.async_get_or_create(
        config_entry_id=entry.entry_id,
        identifiers={(DOMAIN, entry.unique_id)},
        name=entry.title,
        model=entry.data[CONF_MODEL],
    )
    client = MozartClient(host=entry.data[CONF_HOST], websocket_reconnect=True)

    # Check API and WebSocket connection
    if not await client.check_device_connection():
        await client.close_api_client()
        raise ConfigEntryNotReady(f"Unable to connect to {entry.title}")

    # Initialize coordinator
    coordinator = BangOlufsenCoordinator(hass, entry, client)
    await coordinator.async_config_entry_first_refresh()

    # Add the websocket and API client
    hass.data.setdefault(DOMAIN, {})[entry.entry_id] = BangOlufsenData(
        coordinator, client
    )

    await hass.config_entries.async_forward_entry_setups(entry, PLATFORMS)

    # Start WebSocket connection when all entities have been initialized
    entry.async_create_background_task(
        hass,
        _start_websocket_listener(hass, entry, hass.data[DOMAIN][entry.entry_id]),
        f"{DOMAIN}-{entry.unique_id}-websocket_starter",
    )

    return True

In manifest.json:
Replace the "requirements" key's value with "mozart_api-<IP_ADDRESS>.7.tar.gz".
"requirements": ["mozart_api-<IP_ADDRESS>.7.tar.gz"],

In config/:
Place the mozart_api-<IP_ADDRESS>.7.tar.gz file in the config folder.
Like so:

I've tested that. Attached edited files + logfile with debug.
/frank
manifest.json
init.py.txt
home-assistant.log

Thank you for your patience. It looks like it may be the WebSocket library that I am using.
I've replaced the WebSocket library. Can I get you to do the following?
In __init__.py
Replace _start_websocket_listener and async_setup_entry with:
async def _start_websocket_listener(
    hass: HomeAssistant, entry: ConfigEntry, data: BangOlufsenData
) -> None:
    """Start WebSocket listener when all entities have been initialized."""
    entity_registry = er.async_get(hass)

    while True:
        # Get all entries for entities and filter all disabled entities
        entries = er.async_entries_for_config_entry(entity_registry, entry.entry_id)
        expected_entities = len(
            [entry for entry in entries if not entry.disabled or not entry.disabled_by]
        )

        # Check if all entities and platforms have been initialized and start WebSocket listener
        if (
            expected_entities == data.entities_initialized
            and len(PLATFORMS) == data.platforms_initialized
        ):
            await data.client.connect_notifications(remote_control=True, reconnect=True)
            return

        await asyncio.sleep(0)

async def async_setup_entry(hass: HomeAssistant, entry: ConfigEntry) -> bool:
    """Set up from a config entry."""
    # Remove casts to str
    assert entry.unique_id

    # Create device now as BangOlufsenWebsocket needs a device for debug logging, firing events etc.
    # And in order to ensure entity platforms (button, binary_sensor) have device name before the primary (media_player) is initialized
    device_registry = dr.async_get(hass)
    device_registry.async_get_or_create(
        config_entry_id=entry.entry_id,
        identifiers={(DOMAIN, entry.unique_id)},
        name=entry.title,
        model=entry.data[CONF_MODEL],
    )

    client = MozartClient(host=entry.data[CONF_HOST])

    # Check API and WebSocket connection
    if not await client.check_device_connection():
        await client.close_api_client()
        raise ConfigEntryNotReady(f"Unable to connect to {entry.title}")

    # Initialize coordinator
    coordinator = BangOlufsenCoordinator(hass, entry, client)
    await coordinator.async_config_entry_first_refresh()

    # Add the coordinator and API client
    hass.data.setdefault(DOMAIN, {})[entry.entry_id] = BangOlufsenData(
        coordinator, client
    )

    await hass.config_entries.async_forward_entry_setups(entry, PLATFORMS)

    # Start WebSocket connection when all entities have been initialized
    entry.async_create_background_task(
        hass,
        _start_websocket_listener(hass, entry, hass.data[DOMAIN][entry.entry_id]),
        f"{DOMAIN}-{entry.unique_id}-websocket_starter",
    )

    return True

And in manifest.json
"requirements": ["mozart_api-<IP_ADDRESS>.8.tar.gz"],

And place mozart_api-<IP_ADDRESS>.8.tar.gz in the config/ folder

Good evening 🤗
After editing the files + restart HA the first thing I noticed is that HA only discover my Beolab (1) and icon in (2) has gone. It does not discover the Level and Theatre any longer:

I added Level+Theatre manually by their static IP. When I entered the Beolab 28 IP it finds it in a few secs. But before I got to place in in LivingRoom (i.e Stue) it failed in the background while initializing. You can see it here;

There is no mention of Beolab in the log?
home-assistant.log
By the way. I'm thinking about adding a Beoremote Halo in my setup. Will I be able to listen to events from it in HA - just like I do on my Beoremote One (lys, styring)
More debugging? Just write again. I'm happy to help.

Have you updated to the latest Home Assistant Core beta?
The missing icon is expected as a simplified version of this integration has been merged into the official release, but it has been renamed to bang_olufsen, making the icons for the current name "bangolufsen" disappear. This will be fixed in a 2.0.0 release soon.
The Beoremote Halo is currently not directly supported, but can be made to work see video. There is some help to find in the Beotalk discord channel.
I'l try to find a pair of Beolab 28 to test on.

I'll have to get an overview of your setup. I'm guessing you have a pair of Beolab 28 that are stereo paired. Do you have your Beolab 28 connected to the Beosound Theatre with Power Link? And is it wireless or wired?

My Beolab 28's are stereo paired and connected to my Theatre with wireless powerlink 🤗

Just to follow up. Status right now, on 2.0.0, is that everything works except my Beolab 28's which I cannot add. I tried to trace it locally. Replaced the striped down version in Home Assistant Core 2024.2 with 2.0.0 and it is obvious that the hiccup is a failing websocket connection. My trace hangs here:

And Postman confirms that the ws connection is not possible:

It is over my paygrade to figure out what is wrong 🤗 I have no idea if it is the wireless powerlink that causes this. I reckon that a setup without powerlink would be more straight forward.

At this point it looks like it is a setup issue. I've Tried to replicate the Theatre and wireless powerlink setup with the stereo paired Beolab 28s and it was working as expected. Beolink with a Level also worked with this setup.
What I would recommed is a factory reset of both of the Beolab 28 and if that doesn't fix the problem, then also the Theatre.

I restored all products back to the official releases (and made a opt-out of the beta program). That fixed the problem. Now all products are added to HA (and I can see that it can now make a websocket connection to my beolab). I learned a lot during debugging. Thanks a lot for your support 🤗


Protecting against CSRF ?

How can we implement the sending / creation of the token on client side so our serverside is protected against CSRF ?

For now you'll need to solve this in whatever way you would for other SPA apps (e.g., React, Angular, etc.).
Eventually we will probably include built-in helpers for this but I'm afraid it will be a while before we get to it.

@RemiBou If you want, I've a sample Chatle.Blazor where you can see how I send anty CSRF headers and cookies.
I used a specific HttpMessageHandler
And in Program class, I set the HttpMessageHandler the DI and the fetch options to include credentials.


API: Add .model_selection.split, deprecate .iterate

To be compat with sklearn 0.18, rename model_selection.iterate to .split.

Coverage increased (+0.01%) to 94.781% when pulling 030b63d9e62fed9c44612d71a1c8d326f5fdae83 on sinhrks:crv_split into a0f0e03c8ca1d2728f99eff8e3c229633b199921 on pandas-ml:master.


HDDS-6664. Implements getUri in TrashOzoneFileSystem

What changes were proposed in this pull request?
Fix the following exception being thrown during FileSystem.close()
Exception in thread "Trash Emptier" java.lang.UnsupportedOperationException: fs.getUri() not implemented in TrashOzoneFileSystem
What is the link to the Apache JIRA
https://issues.apache.org/jira/browse/HDDS-6664
How was this patch tested?
Ran relevant checks scripts locally and build-branch was successful with  this change. https://github.com/pratapchandu/ozone/actions/runs/3172304615

Please fill out the last part of the pull request template on how this change was tested. (And also write unit tests for this, if possible)

Thanks @pratapchandu for the contribution and @nandakumar131 for the review. Merged the change.


Ember UI | v1 Monitoring | Memory Data does not appear on the cluster page when switching between clusters

Setup

Rancher version: v2.5-edf83d5f6d2041217f9e543743d69246fe18afa7-head  (confirmed on 2.5.11 to be present)
Browser type & version: Chrome

Describe the bug

When switching between clusters with monitoring v1 installed the Memory Data does not show up on the cluster page
To Reproduce

you will need at least 2 cluster with v1 monitoring enabled

Create HA Rancher cluster with enough resources to install monitoring
Install v1 monitoring into your rancher local cluster
Provision a node downstream cluster with enough resources to install monitoring
Install v1 monitoring into your downstream cluster
Wait for monitoring to work
Start switching between clusters
Global > select the cluster with monitoring > select another cluster

Result
you will see the Memory monitoring data is not showing up even though it's returned by  POST v3/clustermonitorgraphs
workaround: refresh the page
Expected Result

All monitoring data appear when a user navigates to a cluster
Screenshots

@sgapanovich is this happening in Vue and 2.6.x? I don't think we'll be fixing anything else in outside of security updates after 2.5.12, so if things are all right in the newer UI, that's where we'd only look going forward.

2.5.x is now EOL so closing as won't fix: https://www.suse.com/support/kb/doc/?id=000020631


extra spacing is showing below bar code

I have used below code to generate bar code . But some extra white space is  showing below bar code
jsBarcode('#crmMCIDBarcode', masterCRMID, {
text: ' ',
fontOptions: "bold",
width: 0.55,
height: 90,
background: "#ffffff"
});

Use displayValue: false to disable the printing of the text, which is causing the extra whitespace.


[Doc] Need an alteration in page "Logging in to Salesforce with Integrated Windows Authentication"

In signup page, we have the older salesforce UI. please update with following.

Likewise, please update all the older UI screeenshots in this page.
[1] https://docs.wso2.com/display/IS540/Logging+in+to+Salesforce+with+Integrated+Windows+Authentication

Thank you for your contribution!
We are closing this issue since it has not been prioritized for a long time. Chances are that it has already been solved in more recent versions. If not, we will be re-evaluating this when it becomes a priority.


Use of placement new in expected_operations_base.

Hello TL :)
This might be a non-issue, it's likely I've overlooked something, but it would appear that the usage of placement new here:
template <class... Args> void construct(Args &&... args) noexcept {
    new (std::addressof(this->m_val)) T(std::forward<Args>(args)...);
    this->m_has_val = true;
  }

  template <class Rhs> void construct_with(Rhs &&rhs) noexcept {
    new (std::addressof(this->m_val)) T(std::forward<Rhs>(rhs).get());
    this->m_has_val = true;
  }

begins to misbehave in some cases when constructing an expected<T const> from an expected<T>. std::addressof returns a pointer of type T const * which seems to confuse the overload resolution of operator new. E.g.
#include "expected.hpp"
#include <iostream>

class A
{
public:
    A() = default;;
    A(A const &) = default;
    A(A&&) = default;
    ~A() {}

    A& operator=(A const &) = default;
    A& operator=(A &&) = default;

    int i = 5u;
};

template< typename T>
using Expected = tl::expected<T, int>;

Expected<A> getSomeExpected()
{
    return Expected<A>(A{});
}

int main()
{
    Expected<A const> a (getSomeExpected());
}

Gives the following:
1> error C2665: 'operator new': none of the 4 overloads could convert all the argument types
...
1> expectedtest\expected.hpp(665):  note: while trying to match the argument list '(unsigned __int64, _Ty *)'
1>        with
1>        [
1>            _Ty=const A
1>        ]

Casting the address type passed to placement new works, although I suspect that's probably UB.
Compiled with:
MSVC++ 14.16, _MSC_VER == 1916 (Visual Studio 2017 version 15.9)
/std:c++17

I think the solution might be to use something similar to std::construct_at from C++20?
https://en.cppreference.com/w/cpp/memory/construct_at
equivalent to
return ::new (const_cast<void*>(static_cast<const volatile void*>(p)))
    T(std::forward<Args>(args)...);

Hey just bumping this because I ran into a similar issue, this time with using expected to store types with a deleted placement new operator. In my case this works fine in MSVC with C++23 std::expected, and I see that they indeed use std::construct_at for all their member construction.


Make links in tag descriptions clickable

Make links in tag descriptions clickable (MIT tag in the License categorie):

Thank you for reporting this issue. We think, that is already fixed in our development version.


Switch direct eval to indirect eval to fix esbuild warnings

Fixes https://github.com/TotalTechGeek/json-logic-engine/issues/16

Hm, this should run in all common JavaScript Engines >2020, so I'm going to merge this in, I think there are some improvements that could be made (switching to strict mode) and a few other things to better restrict the scope,
but I think this is improvement enough over previous functionality to release.
Thanks!


Client-side number field min/max validation shows raw translation key

Describe the Bug
When validating a number field with a min/max value constraint, there’s an inconsistency between the server-side and client-side error messages. The client-side message is incorrect.
Current Behaviour
Server-side validation shows a descriptive message:

E.g.: 1234 is greater than the max allowed Value of 100.

Client-side validation shows a translation key as the message instead:

validation:greaterThanMax

Expected Behaviour
Both server and client validation should show the same error message.

Problem 2:
1234 is greater than the max allowed Value of 100
The error message shows “Value” instead of using the field’s label. E.g., a collection config with label: 'SomeNumb' should say:
1234 is greater than the max allowed SomeNumb of 100
Problem 3:
Feature request: When an invalid number, such as arbitrary text, is entered into a (non-required) number field, the value gets ignored just as if you hadn’t written anything. I would prefer if the raw text went through with the validation function and told the user that their number was invalid. Incorrectly entered data shouldn’t be discarded silently.
Link to the code that reproduces this issue
https://github.com/Pyprohly/payload-number-field-validation
Reproduction Steps
Steps to Reproduce

Create a new blank PayloadCMS application.
Create a new collection with number field:

import type { CollectionConfig } from 'payload'

export const Thing: CollectionConfig = {
  slug: 'thing',
  fields: [
    {
      name: 'name',
      type: 'text',
      required: true,
    },
    {
      name: 'count',
      type: 'number',
      label: 'SomeNumb',
      max: 100,
    },
  ],
}

export default Thing

Add collection to payload.config.ts.
Navigate to create new item form.
Enter a value greater than 100 in the number field.
Click ‘Save’ to observe server message.
Change the field value to observe client-side message.

Which area(s) are affected? (Select all that apply)
Not sure
Environment Info
Payload: 3.5.0
Node.js: 23.3.0
Next.js: 15.0.4

Thanks for the report @Pyprohly — this is now fixed!