x/net/websocket: remedy neglect; merge with gorilla websocket?

It is not well maintained, and essentially everyone uses https://github.com/gorilla/websocket.
This was raised as a concern in #17244: because it is in the x/net repository, people attach greater value to it than it really ought to have.
/cc @dsnet
EDIT 2016-12-02: Copying in my better-phrased problem statement from later in the thread:
The problem I see is that the ownership/maintenance story of x/net/websocket is unclear. It may suit your needs, and that is fine! However, it's not getting the same level of support as the standard library or even gorilla/websocket; it has no established owner AFAIK.
Along the lines of #17244, there is concern that it elevates the status and visibility of the package. I've anecdotally heard of it confusing many new users whose needs were much better filled with gorilla/websocket. I have not heard of someone using gorilla/websocket and then deciding to use x/net/websocket instead.

We can't just delete something and break people who aren't vendoring it.
We can document that it's deprecated perhaps.
Or somebody could maintain it.

Deprecated might be fine, but my experience is that I (and other devs I've talked to) have wasted time trying to use the package only to find out it fails in production and that Gorilla's package works.

I support a strong deprecation message. Would that message endorse the Gorilla implementation?
If we implement golang/lint#238, I think that will help people avoid wasting time developing with deprecated packages or features.

"fails in production" -- what are the open bugs? There's not much to WebSockets. I'm afraid we're going to spend more time discussing things on this bug than we would just fixing any such issues.

Beyond any bugs that could be fixed by maintenance, the deeper problem with x/net/websocket is that it has the wrong API. It puts an io.Reader/Writer interface on top of what is fundamentally a message-based protocol.
I agree it should be documented as deprecated in favor of gorilla/websocket.

It's been long enough since I last tried to use it, but off-hand, you cannot implement a correct websocket reverse proxy with the current API, since it tries to implement io.Reader/io.Writer.  Websocket, for better or for worse, is a frame-oriented protocol, not a stream-oriented protocol.

I agree it has the wrong API. But we could add ReadMessage and WriteMessage to it and deprecate Read and Write.
I am in favor of maintaining less code, though, (not that we ever maintained x/net/websocket much?), and I have no personal or sentimental connection to x/net/websocket, and we actually use gorilla/websocket in Camlistore these days, but it still feels core enough that we should have an official answer for websockets in x/net.
I suppose this all kinda depends on the policy for x/* we figure out in #17244.

I had this problem with a version of my profile package.
My solution was to move the code into a branch and deleting all the code
from the package on master so it could not be imported. The README has told
people not to use the package for years, now in addition jt says if they
still want to do it anyway, they can find the code in the branch.
I considered replacing the paxkage with one that panic'd during init, but
that felt like adding insult to injury.
On Fri, 2 Dec 2016, 08:59 Brad Fitzpatrick<EMAIL_ADDRESS>wrote:

I agree it has the wrong API. But we could add ReadMessage and
WriteMessage to it and deprecate Read and Write.
I am in favor of maintaining less code, though, (not that we ever
maintained x/net/websocket much?), and I have no personal or sentimental
connection to x/net/websocket, and we actually use gorilla/websocket in
Camlistore these days, but it still feels core enough that we should have
an official answer for websockets in x/net.
I suppose this all kinda depends on the policy for x/* we figure out in
#17244 https://github.com/golang/go/issues/17244.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/golang/go/issues/18152#issuecomment-264322154, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAAcA2pJ4SojprgRJRtypivu71yvE_H4ks5rD1FIgaJpZM4LB-47
.

Please do not deprecate it. At work, we are using golang.org/x/net/websocket exclusively and we have never had any problem with it*. Quite the opposite, in our use case it's more robust than what we've ever expected.
*: Of course, that says nothing whatsoever about any trouble anyone else might have with it.

@cznic, "deprecate" does not mean "delete".

Yep. But I guess it means "no more bug fixes for you, ever".

No, not really. Deprecated is not black & white. We continue to fix bugs in other deprecated stuff when there's a good bug report and a clear fix and super minimal risk of breaking existing users. It just means we're not adding features to it, or means that a better way is known to exist.

Great news, honestly. But then again, why to mark it deprecated in the first place? We can cope with it getting no attention from people not loving it, but we do and if we run into a bug we need to resolve, we would be more than happy to contribute the fix.
Status quo anybody?

But then again, why to mark it deprecated in the first place?

To tell users they might be happier elsewhere.

Precisely to @bradfitz's point: Deleting may be too strong, but I want to send a strong signal that there's a much better maintenance story for gorilla/websocket.  Effort spent on x/net/websocket may be better spent on gorilla/websocket.

To tell users they might be happier elsewhere.

I really really really don't want to sound snarky, but by that logic, the Go repository might be marked deprecated as well - just because users might be happier with Rust, C, Java, ...?

Effort spent on x/net/websocket may be better spent on gorilla/websocket.

I have no intention, nor desire to suggest or propose, regardless how impossible and foolish that would be, to delete github.com/gorilla/websocket, just because we don't and probably never would use it.

I really really really don't want to sound snarky,

Yet you did. And it's not very productive. It's actually just noise in this thread.
If you want to be productive, though, step up and maintain golang.org/x/net/websocket. That's one of the options I listed in my first comment (https://github.com/golang/go/issues/18152#issuecomment-264319615)

I apologize, @cznic. The current proposal process biases bug titles to be action-based (do X) versus focused on problem statement, so I should have described the problem instead of a proposed plan of action.  Maybe this is something we should consider improving in the proposal process.
The problem I see is that the ownership/maintenance story of x/net/websocket is unclear.  It may suit your needs, and that is fine!  However, it's not getting the same level of support as the standard library or even gorilla/websocket; it has no established owner AFAIK.
The other issue I see is along the lines of #17244, where there is concern that it elevates the status and visibility of the package.  I've anecdotally heard of it confusing many new users whose needs were much better filled with gorilla/websocket.  I have not heard of someone using gorilla/websocket and then deciding to use x/net/websocket instead.

And to be clear, @cznic, I'm quite serious about you maintaining x/net/websocket. As a user of it, you're better suited to be a maintainer of it than a random contributor looking for work to do. And you maintain enough other stuff that you know what the process entails.

It's actually just noise in this thread.

I respectfully disagree. I see no proof why it's different (wrt people happier with something else). I'm ready to acknowledge you're right if you can actually explain your judgement in some other way than simply claiming my point has no point (just noise in your words).
Nonetheless...

If you want to be productive, though, step up and maintain golang.org/x/net/websocket.

And to be clear, @cznic, I'm quite serious about you maintaining x/net/websocket. As a user of it, you're better suited to be a maintainer of it than a random contributor looking for work to do. And you maintain enough other stuff that you know what the process entails.

Regardless of us (at work) never having a problem with it, how do you expect me to maintain x/net/websocket? Serious question from a person having only R/O access to it.

I apologize, @cznic. ...

@zombiezen Relly appreciated, but there's nothing to apologize for. I don't agree with the proposal, but that's nothing personal. If I made an impression otherwise then it's my duty to apologize for my fault - sorry.

PS: @all Getting the company's approval to use Go and/or code from golang.org/whatever is one thing. The same for code from other domains is not the same.

I respectfully disagree. I see no proof why it's different (wrt people happier with something else).
https://en.wikipedia.org/wiki/Reductio_ad_absurdum

Regardless of us (at work) never having a problem with it, how do you expect me to maintain x/net/websocket? Serious question from a person having only R/O access to it.

If you send us CLs, we'll +2 and you can submit.
If others send you CLs, we'll give you access to +2 their CLs and you can submit.

I respectfully disagree. I see no proof why it's different (wrt people happier with something else). I'm ready to acknowledge you're right if you can actually explain your judgement in some other way than simply claiming my point has no point (just noise in your words).

I find your comparison between recommending a maintained package to recommending a whole alternate language not even remotely equivalent. They're pretty absurdly different. You also found it ridiculous, which is why you prefaced it with "I really really really don't want to sound snarky". You can't just say something outlandish and preface it with "Not to be $X or anything, but ....".
By the time most people are selecting a websocket package, they've already selected their programming language (Go, in this case). On the off chance they haven't yet selected their programming language (and this is a prototype application to decide whether they like the Go ecosystem), that argues even more in favor of @zombiezen's point that we should point them to the solution that's going to be make them happy, rather than the first thing they stumbled into.
Hence https://golang.org/cl/33806

Thank you Brad,
Not to add noise to the issue, but we've recently had to introduce websockets to our app and had this debate do research to find out wether x/net/websocket would work. Luckily I was aware of discussion in https://github.com/golang/go/issues/17244 which mentions websocket vs the gorilla package. The mention will help others save time and avoid using something just because it looks official.

If others send you CLs, we'll give you access to +2 their CLs and you can submit.

Let's roll.

But how about implement it in standard package net/websocket?

@leaxoy, no thanks. Unmaintained code in x/ is bad enough. We don't also want more code in std, especially if it's unmaintained. See https://golang.org/doc/faq#x_in_std

FWIW, the message in this package's godoc is not strong enough, one of my students ended up using it.  You may want to consider a statement to the effect of "do not use this package, we'll murder a puppy if you do", or something.  Please mention clearly what is the recommended replacement.

What about an init function which prints a message when any program links
against it.
On Fri, 2 Dec 2016, 17:51 Juliusz Chroboczek<EMAIL_ADDRESS>wrote:

FWIW, the message in this package's godoc is not strong enough, one of my
students ended up using it. You may want to consider a statement to the
effect of "do not use this package, we'll murder a puppy if you do", or
something. Please mention clearly what is the recommended replacement.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/golang/go/issues/18152#issuecomment-264404055, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAAcAx1mYMIJxHJkUB9zfVkhdNB-RpvOks5rD9wmgaJpZM4LB-47
.

What about an init function which prints a message when any program links
against it.

I think it's excessive.  I think the main point I'm making is that there's
a need for one (and just one) recommended replacement, so that people know
what they should use without the need to evaluate a plethora of libraries.
So please put a clear statement "don't use this package, use X instead",
and people will listen.
-- Juliusz

@jech, your students are allowed to make decisions and explore. They're students, after all.

@jech, your students are allowed to make decisions and explore. They're
students, after all.

Sure.  But I think it's a useful data point.

but it still feels core enough that we should have an official answer for websockets in x/net.

My offer to donate the gorilla/websocket code to the Go project is still open.

@garyburd, what's the CLA story? Have all authors signed the Google CLA?

@garyburd, forgot to say the most interesting part: that's very interesting!

All of the authors had signed the CLA at the time I made the offer. I don't know the status now. We will need to investigate, but let's get a preliminary decision on your end before doing the investigation.

@garyburd, a few of us chatted about it. We're fine to proceed with merging them together if you are and you can verify CLAs. (Let me know if I can help with CLA lookups). I'd like to keep the x/net package's Read and Write methods, to not break people's code, and there's a few things I'd omit or change in gorilla before adding it to x/net. (Or maybe we add it all, but mark some as Deprecated for a few months) So I'd like to do one CL that's an API review before we look at implementation code.
Then maybe we need to write a go fix-ish tool for people.
Thoughts?

Is this the issue where we should discuss this, or should I open a new issue?

@garyburd, let's repurpose this bug.

I'll follow up on email regarding licensing/CLA.
What would you omit from Gorilla package?
The move to a new import path provides an opportunity to improve the Gorilla API. The most important change is to restructure the API to allow for concurrent writers.  I'd also remove the JSON methods from the connection type.
I was expecting that you would take a gorilla/websocket as a new package (x/net/websocket2 ?) or as a new types in x/net/websocket.  Either way, the existing x/net/websocket would be rewritten as a wrapper around the gorilla code.  The wrapper will make a best effort to be compatible given that x/net/websocket API exposes frames in the API while the Gorilla API exposes messages.

What would you omit from Gorilla package?

Could you send a dummy CL (to say, x/net/review/websocket) with just the API surface and all the implementation removed, and I can comment in Gerrit?

there's a few things I'd omit or change in gorilla before adding it to x/net.

Is this the right place to discuss this?  If it is, then I'd like to mention that we're using Websockets for sending frequent tiny updates (on the order of a few octets), and that a cursory reading through the Gorilla implementation doesn't show a way to send a small data frame without consing up a writer.

@jech, that sounds like an implementation detail, but it important to keep in mind since the choice of API does have an impact on performance.

@jech File an issue with Gorilla requesting that WriteMessage allocate zero memory.

@jech  See https://github.com/gorilla/websocket/commit/0868951cdb8e69bc42df4598bdc6164ff2f1a072.  The message writer is no longer allocated on heap for the WriteMessage fast path.

any updates?

There's agreement about moving the package, but I don't have time to do the work.

Google Cloud Platform has a beta websocket API: https://issuetracker.google.com/issues/35886348
Despite lack of maintainers I'd still like to reopen the idea of a standard library package net/websocket for Go 2.

I think I may be encountering this error when using Gorilla's websockets, which apparently isn't present in this implementation: https://github.com/gorilla/websocket/issues/43 .
I have a WebSocket server, with two goroutines per connection: one reading messages and pushing them to a channel, and the other pulling them from the channel, processing them and writing the results to the connection. So far, it looks like at semi-random points I get spurious "unexpected EOF" messages on the Gorilla implementation. I yet need to try Google's.

Looks like Gorilla needs a maintainer.
https://github.com/gorilla/websocket/issues/370

I started working on a new WebSocket library for Go.
The main features being a minimal easy to use API that will work with WebSockets over HTTP/2.
https://github.com/nhooyr/ws#ws
Right now the entire implementation is stubbed out as I wanted to get some feedback on the API.

The main features being a minimal easy to use API that will work with
WebSockets over HTTP/2.

As far as I'm aware, there's no such thing as a WebSockets over HTTP/2
protocol.

@jech https://tools.ietf.org/html/rfc8441

https://tools.ietf.org/html/rfc8441

I stand corrected.

I just tagged v0.1.0, it passes all of the autobahn tests except for compression which I'll add later.
https://github.com/nhooyr/websocket
Let me know what you think.

I opened a PR to add my library to the deprecation message as well. https://github.com/golang/net/pull/51
Should we make the deprecation message stronger as discussed in https://github.com/golang/go/issues/33215?
It seems to actively have issues with pings as described by @fjl at https://github.com/ethereum/go-ethereum/issues/19798#issuecomment-512839103

The issue here isn't that github.com/x/net/websocket doesn't handle ping (it does). We are seeing the reproducer behave this way because SetWriteDeadline interacts badly with the built-in ping frame handler. Whenever the RPC client wants to write something, it sets a write deadline. In the reproducer it only writes once to establish the subscription. When the ping frame arrives 12 seconds after the write, the write deadline that's set has already passed and writing the pong frame fails. The pong write error is returned from Read, causing the client to reconnect.

I looked over the code and confirmed this was a problem. The ping handling code never resets the write deadline and instead relies on the user of the Conn to reset the deadline to zero after reading which is definitely confusing behaviour. I suppose this could be fixed pretty easily but people ought to just use gorilla or mine. Mine also has a net.Conn wrapper to make such a transition easier. I'll add this to the deprecation message.
https://github.com/golang/go/issues/33215 mentions there is also an issue with continuation frames but I didn't notice any problems when I read through the code.

@hadv

try https://github.com/lxzan/gws , provide better performance, easier to use API

这个包满足我的，因为很小，而且是官方维护。唯一不足的地方大多数人没法用它，因为不会Read。
var c *websocket.Conn
var buf bytes.Buffer
b := make([]byte, 1024)

for {
	n, err := c.Read(b)

	if n > 0 {
		buf.Write(b[:n])
	} else if err != nil {
		return
	}

	//处理帧数据，你可能有如下三种判断之一：

	if err == io.EOF { //表示帧结束? 但是你可能永远等不到io.EOF这个值
		//处理帧数据
		buf.Reset()
	}

	//或者
	if buf.Len() == c.Len() { //c.Len()? 这方法返回没有准确表达我需要的条件，不知道有什么作用:frame.Length?
		//处理帧数据
		buf.Reset()
	}

	//或者
	if buf.Len() == int(c.FrameDataLenth()) { //ok,非常棒。但是 websocket.Conn 没有这个方法：FrameDataLenth=frame.header.Length
		//处理帧数据
		buf.Reset()
	}

}

@bradfitz do you think it's possible to continue the conversation about merging gorilla/webosocket into x/net/websocket now that they have new maintainers or that ship has sailed a long time ago?

I am trying to go a:
go get -v golang.org/x/net/websocket
and getting
Fetching https://golang.org/x/net/websocket?go-get=1
Parsing meta tags from https://golang.org/x/net/websocket?go-get=1 (status code 200)
import "golang.org/x/net/websocket": parsing golang.org/x/net/websocket: XML syntax error on line 7: unexpected end element
package golang.org/x/net/websocket: unrecognized import path "golang.org/x/net/websocket"


Improve only post access api

Proposed Changes
The API which only does POST, has been changed so that it does not GET because there was an unnecessary GET access.

Implementation

Target API

dev-invitation
khaos

@hhatto I think it's good.
The role of the local variable shouldFetch can now be replaced by whenDefined. i.g., https://github.com/dev-protocol/stakes.social/blob/204e6d0888fd635ee9e861a78a437c605f4d6273/packages/web/src/fixtures/dev-for-apps/hooks.ts#L193
But I think this PR is mergeable.


approx1 off_grid Error

In the singal.py, for arrayfire.approx1, I found that the off_grid format should be float not double.  Therefore I changed it and it now works as expected.
Sorry if this is not proper procedure for fixing bugs, I am new to reporting bugs using github.

Fixes #118


Send emails upon submission, approval, and denial of resources

Closes #47.

@jamstooks - added tests.  :-)

Hey, Bob. Would you mind updating from master to fix the conflicts and then I'll pull this in...?
I'm about to pull in another PR, so there might be a bit more work to get it up to speed.

@jamstooks - Merged master down into emails branch -- no conflicts with master now.

Awesome. thanks! I've added one comment, but other than that, I think this is probably good to go...


"The application to execute does not exist"

When attempting to create a new project in Visual Studio using a PLCnext template, an error message appears similar to the following:
The application to execute does not exist: 'C:\Users\...\AppData\Local\.net\plcncli\...\plcnli.dll'

or
The application to execute does not exist: 'C:\Users\...\AppData\Local\Temp\.net\EngineeringLibraryBuilder\...\EngineeringLibraryBuilder.dll'.

I am aware of the cause (a caching issue with .NET Core 3.x) and the work-around (delete the plcncli or the EngineeringLibraryBuilder directory in the .NET directory).
This issue is a hint for others who experience a similar problem. The issue can be closed when this problem is resolved.
(internal reference: #208771)

The following symptom is also related to this issue.
When trying to create a new project in Visual Studio, an error like the following may appear:

In all cases the solution is to delete the offending directory from the local .NET cache - for example, delete this directory and its contents:
C:\Users\...\AppData\Local\.net\plcncli

Link to the original issue:
https://github.com/dotnet/runtime/issues/3830
With the next version our CLI will switch to .NET 5.x. In the mean time you could set the DOTNET_BUNDLE_EXTRACT_BASE_DIR to a different, non temporary location as a workaround.

Fixed with Version 2021.6


Document plugin protocol

We should consolidate (and bring up to date) any plugin protocol documentation and put it in this repo.

Perhaps in the wiki as to avoid it getting lost somewhere in some branch.
On Fri, Apr 10, 2015 at 8:41 AM, Michael Bridgen<EMAIL_ADDRESS>wrote:

We should consolidate (and bring up to date) any plugin protocol
documentation and put it in this repo.
—
Reply to this email directly or view it on GitHub
https://github.com/ClusterHQ/docker-plugins/issues/2.

--
Jeff Lindsay
http://progrium.com

https://github.com/ClusterHQ/docker-plugins/wiki/PluginProtocol

It's not fully documented but it's a start


Inconsistency with Url.Content("~")

In previous versions of ASP.NET MVC, Url.Content("~") returns the application's root directory (ie. /foo). On ASP.NET MVC 6, this just returns a verbatim "~", and you need to actually use Url.Content("~/"). It's a subtle difference, but it appears that older versions just check that the first character is "~", whereas newer versions check that the string starts with "~/" (ie. it contains a tilde and a slash)
Old code:
bool isAppRelative = contentPath[0] == '~';

New code:
if (path.StartsWith("~/", StringComparison.Ordinal))

Thanks! :+1:


Low-hanging optimization

If the user didn't add more characters to the query all choices have to
be reconsidered as potential matches. In the opposite scenario, there's
no point in reconsidered all choices again since the ones that didn't
match the previous query will clearly not match the current one due to
the fact that previous query is a left-most substring of the current
one.
Testing would be much appreciated. On large inputs, pick should feel
snappier by now.

gcc (nb2 20150115) 4.8.5 on NetBSD 7.1 shows:
pick.c: In function 'main':
pick.c:554:2: error: 'choices_count' may be used uninitialized in this function [-Werror=maybe-uninitialized]
  for (i = 0; i < nchoices; i++) {
  ^
pick.c:300:11: note: 'choices_count' was declared here
  size_t   choices_count, cursor_position, i, j, length, xscroll;

... no such errors on Debian ...

Thanks for testing @DBOTW. Could your try the latest commit on this
branch?

@mptre: tested & works (GCC 2.95 also complained about this) ...

Thanks, merged.


use mmapped IO

use new IO module
use mmapped IO for reading
use mmapped String for IDs (always)
use mmapped files for SA if memory constrained

moved to seqan/lambda#3 and seqan/lambda#4


updated the x formerly twitter icon and logo

Updated the social icon for X formerly Twitter from the bluebird icon to the X logo
Change the X formerly Twitter URL to have the new URL  https://x.com/rust_foundation

The image explain what the new update look like
The old site

the new update

@MarcoIeni @JoelMarcey

hi, I'm not part of the team that manages the website. However, I noticed you didn't include the X PNGs

hi, I'm not part of the team that manages the website. However, I noticed you didn't include the X PNGs

I just push that thanks for making letting me know lol, it was still in my local 📂

Can you align the two logos in the contact page?

Can you align the two logos in the contact page?

Will work on it later today

@MarcoIeni  done with thanks for bringing my attention to it

Can you align the two logos in the contact page?

done with it thanks for bringing my attention to it i didn't take that notice


Fixed expr meta var after path colons in mbe

Fixes #7207
Added L_DOLLAR in ITEM_RECOVERY_SET , but I don't know whether it is a good idea.
r? @matklad

Urgh, the sad thing is that I don't know it the idea is good neither :(
I think, if we do this, we should do that at Parser::err_recover, but, iirc, that fails as well.
cc https://github.com/rust-analyzer/rust-analyzer/pull/4680#issuecomment-641346748

Urgh, the sad thing is that I don't know it the idea is good neither :(
I think, if we do this, we should do that at Parser::err_recover, but, iirc, that fails as well.
cc https://github.com/rust-analyzer/rust-analyzer/pull/4680#issuecomment-641346748

I managed to move it inside Parser::err_recover, however the design problem you mentioned didn't resolved.

I managed to move it inside Parser::err_recover, however the design problem you mentioned didn't resolved.

Just check , it seem to fix  #6100 too.

Just check , it seem to fix  #6100 too.

Ok, lets merge it. I don't think this is right, but the original code is also wrong, and this reduces the number of observable bugs.
Long term, I'd love to move the parser to a separeate repo, with cleanly defined input-outpuf intertace. That would be the appropriate time to solve this in a principled way.

Ok, lets merge it. I don't think this is right, but the original code is also wrong, and this reduces the number of observable bugs.
Long term, I'd love to move the parser to a separeate repo, with cleanly defined input-outpuf intertace. That would be the appropriate time to solve this in a principled way.

bors r+

bors r+

bors retry

bors retry


Re-order nav links, update download box to include shapefiles,

Purpose
Re-order the navigation links. This PR creates all the placeholder logic to add dropdown navigation links in the future. The TSD, FAQs and download page are also ready to go when we are ready in the future

closes #1425
closes #1533
closes #1532
closes #1436
closes #1324

QA testing
QA link here
QA spec:
Re-order the nav links:

[x] does the map/explore page load by default?
[x] do all the navigation links work?
[x] do all (most) links work as expected on each page?

Engagement calendar button on each page

[x] is there a public engagement button on each page?
[x] does the button work as expected?

Add shapefile download to download box

[ ] does download button work?
[ ] how is the styling of the box?
[ ] how do colors look? Blue public engagement button near the darker blue download box?

Add FAQ link to About page

[x] does the FAQ link work?
[ ] the text has a minimum 92 character requirement. that's why the copy has been updated. Is it ok, or do you have something else that could also meet the 92 character limit?

Modify footer

[x] is the title of the second column in the footer correct?
[x] are all footer links in the second column correct?
[x] are all the footer links in the second column in the correct order?
[x] is the title of the third column in the footer correct?

Questions for QA:

We have 3 different buttons on the site. A blue with white text, white with dark text, and yellow with blue text. I have a feeling that having at most two buttons unless there's some reason to have 3 different types. Wondering if we can discuss the options and see if all 3 button types are needed or if they cause extra cognitive load?

Find answers on the Climate and Economic Justice Screening Tool's Frequently Asked Questions.

updated pic based on @katherinedm-usds's feedback attached


Use lua to define custom commands

I'm hesitant on whether this should be inside the setup method or not.

This would change nothing for images_pull: https://github.com/lspcontainers/lspcontainers.nvim/blob/6d17d45b479d83915bd3b79fb313657fc3b9b40d/lua/lspcontainers/init.lua#L146
This would just make Docker try to remove images it doesn't have for images_remove: https://github.com/lspcontainers/lspcontainers.nvim/blob/6d17d45b479d83915bd3b79fb313657fc3b9b40d/lua/lspcontainers/init.lua#L167

I think for now it's low-impact but if we feel we want to move it later to make the plugin completely unloaded until setup is ran thi seems like a simple fix.


Sender is nil in AwaitFuture

I'm trying to run example code of cluster.
But I got an error below.
runtime error: invalid memory address or nil pointer dereference" stacktrace="github.com/AsynkronIT/protoactor-go/actor.(*PID).ref:11

I think this error occured in https://github.com/AsynkronIT/protoactor-go/blob/9676ac269bc0657e9b1d94ab13f4a0922454b11e/cluster/pid_cache.go#L80, because ctx.Sender() of the context was nil.

Fixed by #112


Issue #59: Display the connector variables

Added a variables section under the prerequisites in the connectors pages to display the connector template variables, their description & their default value if available.
Updated MetricsHub example content producer to add variables configuration example.
Tested on metricshub-doc.

Tests
Default connector variables specified.

Default connector variables not specified (variables are present).

MetricsHub.yaml example

I would simplify the listing of variables like below:
Variables:

matchCommand: Regular expression that command line of the process must match with (default: .*)
matchName: Regular expression that the process name must match with (default: .*)

So the "template" is like:

 VARNAME: VARDESCRIPTION (default: DEFAULTVALUE)

Description and default value should be displayed in the doc only if they are specified, like below:

matchName
matchName: Regular expression that the process name must match with
matchName (default: .*)

Now an interesting question: how do we specify variable values for a connector through the CLI? 😅

There is a plan for this @bertysentry https://github.com/sentrysoftware/metricshub/issues/357


[Enhancement] - Remove empty indices in the permissions yml file.

When using '/pex user  prefix "" ', the users prefix is cleared, but the 'prefix' index in the yml file is not removed. I would like pex to remove the prefix/suffix/options indices when they are empty.

Open the file in Notepad and delete them.  They don't harm anything by being empty sets within the file.

@Stormbow This is not what I asked. I could indeed write something that cleans up the file every once in a while but this request is to implement that into the plugin. Implementing it should not be too hard and it would look better in the file.


Add a readme linking to the blog post

Merged. Thank you very much! :)

No problem! :) I am at work now but I wanted to add a README so I could read your blog post and follow the code later!


[Bug] Component's '@Input set ' is not showed in Playground and is showed in the 'Accessors', not in the 'Properties' of Component's API page

Is this a regression?
Yes
Description
I'm using v15.13.0 of project
Component's ts file looks like:
`import { ChangeDetectionStrategy, Component, HostBinding, Input } from '@angular/core';
export type StatusChipType = 'success' | 'warning' | 'danger' | 'info';

@Component({
  standalone: true,
  selector: 'uck-status-chip',
  template: '{{ text }}',
  styleUrls: ['./status-chips.component.sass'],
  changeDetection: ChangeDetectionStrategy.OnPush,
})
export class StatusChips {
  /**
   * Text for displaying
   */
  @Input() text: string;
  @Input() set type(value: StatusChipType) {
    this.innerType = value;

    this.resetTypeClass();
    this.setTypeClass();
  }

  get type(): StatusChipType {
    return this.innerType;
  }

  private innerType: StatusChipType;

  @HostBinding('class.status_success') private successTypeClass: boolean;
  @HostBinding('class.status_warning') private warningTypeClass: boolean;
  @HostBinding('class.status_danger') private dangerTypeClass: boolean;
  @HostBinding('class.status_info') private infoTypeClass: boolean;

  private resetTypeClass(): void {
    this.successTypeClass = false;
    this.dangerTypeClass = false;
    this.warningTypeClass = false;
    this.infoTypeClass = false;
  }

  private setTypeClass(): void {
    switch (this.innerType) {
      case 'success':
        this.successTypeClass = true;
        break;
      case 'danger':
        this.dangerTypeClass = true;
        break;
      case 'info':
        this.infoTypeClass = true;
        break;
      case 'warning':
        this.warningTypeClass = true;
    }
  }
}`

'ng-doc.dependencies.ts' of the doc page looks like:
`import { NgDocDependencies } from '@ng-doc/core';
import { StatusChips } from '@uk/uc-kit/components';
import { StatusChipsDemoComponent } from './demo/status-chips-demo/status-chips-demo.component';
import { StatusChipsPageModule } from './ng-doc.module';
const StatusChipsPageDependencies: NgDocDependencies = {
  module: StatusChipsPageModule,
  demo: {
    StatusChipsDemoComponent,
  },
  playgrounds: {
    StatusChipsPlayground: {
      target: StatusChips,
      template: `<ng-doc-selector></ng-doc-selector>`,
    },
  },
};

export default StatusChipsPageDependencies;`

Please provide the exception or error you saw
No response
OS
Unix (Linux, macOS, etc.)
Browser
None
Node version
16.20.2
Anything else?
No response

This bug was present before and was fixed in #116. Unfortunately, I cannot maintain and release multiple major versions at once. Even the Angular team does not provide such support for Angular. I am the sole developer working on the project and I do this only in my personal time. Such support would greatly slow down the library support because I am still working on the main features.
I would recommend updating to a newer version where this issue is resolved or use regular inputs and data- attributes to style your component, for example like here.


[Hub Generated] Review request for Microsoft.AzureStackHCI to add version stable/2023-06-01

This is a PR generated at OpenAPI Hub. You can view your work branch via this link.
ARM (Control Plane) API Specification Update Pull Request
PR review workflow diagram
Please understand this diagram before proceeding. It explains how to get your PR approved & merged.

Purpose of this PR
What's the purpose of this PR? Check all that apply. This is mandatory!

[x] New API version. (Such PR should have been generated with OpenAPI Hub, per this wiki doc.)
[ ] Update existing version for a new feature. (This is applicable only when you are revising a private preview API version.)
[ ] Update existing version to fix swagger quality issues in S360.
[ ] Other, please clarify:

edit this with your clarification

Due diligence checklist
To merge this PR, you must go through the following checklist and confirm you understood
and followed the instructions by checking all the boxes:

[x] I have reviewed the general guidance on the spec PR review process: https://aka.ms/specprreview.
[x] I confirm this PR is modifying Azure Resource Manager (ARM) related specifications, and not data-plane related specifications.
[x] I commit to follow the Breaking Change Policy.
[x] I have reviewed following Resource Provider guidelines, including
ARM resource provider contract and
REST guidelines (estimated time: 4 hours).
I understand this is required before I can request review from an ARM API Review board.

ARM API changes review

If you want for the ARM team to review this PR, you must add the ARMReview label.
The automation may automatically add the ARMReview label, if appropriate.
If this happens, proceed according to guidance given in GitHub comments also added by the automation.

Breaking change review
If you have any breaking changes as defined in the Breaking Change Policy,
follow the process outlined in the High-level Breaking Change Process doc.
Getting help

For guidance on fixing this PR CI check failures, see the hyperlinks provided in given failure
and https://aka.ms/ci-fix.
For additional help, see https://aka.ms/azsdk/support/spectools.

@Reviewers Same changes have been reviewed and merged in private swagger repo - https://github.com/Azure/azure-rest-api-specs-pr/pull/13421

/azp run unifiedPipeline

Hi @rkmanda, thank you. Regarding the errors in Swagger LintDiff, these changes have not been introduced in this swagger PR. They are already present in previous stable version 2023-03-01 as well.
These issues were not reported in the last iteration when openapi-validator version 2.1.3 was being used. Looks like these are new validations introduced in version 2.1.4.


Documentation change

Documented that if the last argument given is an exception it will
be printed in the log. As this is not documented its unclear how
to use arguments and include an exception.

Instead of repeating the same text multiple times, I rather the statement "Note that logging statements can be parameterized in presence of an exception/throwable" be emphasized or expanded upon.

I agree that the JavaDoc should be more verbose here.  It is unclear from the JavaDoc that the last parameter in the array is special.  This is hidden functionality IMO.  JavaDoc on the interface should explicitly state that if the last element of the array extends Throwable, it will not be used to template the string, and will be "the exception (throwable) to log".
Documenting this expected functionality in docs outside of the JavaDoc is fine, but it should explicitly be stated in the interface contract.

Please create a Jira issue linking to this PR.

@ceki I am not able to reach https://jira.qos.ch/ It looks to be down. Could you please have a look at it?

@aglassman where is this documented? I only found this by thinking that it should be there and reading the source code.

@bjornblomqvist I was only able to find a reference to this functionality on the slf4j FAQ page.

Created: https://jira.qos.ch/browse/SLF4J-446

+1
I was about to open a jira but I found the jira related to this PR.
@ceki Any chance it can make it into master?
Right now it's really not adhering to the principle of least astonishment.
The thing is that there are some methods which do take a Throwable, and others which don't.
So I will expect the methods not taking a Throwable to not support it, unless stated otherwise in the javadoc.
I see that there's a line in the javadoc at the class level mentioning the thing, but personally I had completely missed that.
https://github.com/qos-ch/slf4j/blob/e2c29c81df6fb405a3c5a6dfd1cf28ba26a7c1d6/slf4j-api/src/main/java/org/slf4j/Logger.java#L73
I wouldn't have missed it if it were at the method level, as this PR is proposing


Incorrect handling of multiple return values with v128, causing segmentation fault

Subject of the issue
iwasm fails to handle multiple return values when one of them is a v128, causing a segmentation fault.
Test c
program.wasm.txt
(module
  (type (func (param i32 i32) (result i64 v128)))
  (func $func1 (type 0) (param i32 i32) (result i64 v128)
    i64.const 0x1234567890
    (v128.const i32x4 0x00000004 0x34567890 0x66666666 0x77777777)
  )

  (func $main (result i64 v128)
    i32.const 0x12341234
    i32.const 0x1234
    call $func1
  )

  (export "main" (func $main))
)

Your environment

OS: Ubuntu 20.04
CPU: amd64
WAMR version: iwasm 1.2.3
Command:  iwasm --llvm-jit ./program_call_indirect.wasm

Steps to reproduce
Run the WebAssembly module, and get the output:
$  iwasm --llvm-jit  -f main ./program.wasm
fast jit compilation failed: Error: unsupported opcode
failed to compile fast jit function 0
fast jit compilation failed: unknown error
failed to compile fast jit function 1
Segmentation fault (core dumped)

Expected behavior
The module should correctly handle multiple return values including v128. A valid output should look like:
0x1234567890:i64,<0x3456789000000004 0x7777777766666666>:v128

fail to reproduce the result Segmentation fault (core dumped)
Could you please provide more details?
Which build of iwasm are you using? If it's built from source, which branch and commit are you on and your compilation combination?
What toolchain are you using to convert .wat files to .wasm?
Here are my steps:
Using main branch, commit https://github.com/bytecodealliance/wasm-micro-runtime/commit/04f1071f1c08b47d734acf0e74511bfeef7c5568
cmake -S . -B build
/opt/wabt-1.0.36/bin/wat2wasm --no-check  ./test.wat -o test.wasm
$ /workspaces/wasm-micro-runtime/product-mini/platforms/linux/build/iwasm -f main ./test.wasm -> 0x1234567890:i64,<0x3456789000000004 0x7777777766666666>:v128


ModelBinding - Fails to bind if was called in Before hook or more than once in the Module

using Nancy 1.4.3 - Owin Self Host
Let's say I have a module FakeIdModule that inherits from an abstract module and uses its constructor to define a base route /fake/{idUri:long}, then I provide a ValidateIdUri function in the Before hook to verify the idUri for all routes.
It is all working great up to this point, but when the requests enters the route 'POST /fake/{idUri:long}/property-one' the call to Bind<...>() fails because returns an empty object.
If the call to ValidateIdUri is commented everything works as expected
    //inside module
    internal class FromUri
    {
        public long idUri {get;set;}
    }
    internal class FakeRequest
    {
        public string Name {get;set;}
        public int Year {get;set;}
    }

    public FakeIdModule(IService _service): base("/fake/{idUri:long}")
    {
        service = _service;
        this.Before.AddItemToStartOfPipeline(ValidateIdUri);
        Post["/property-one"] = PostPropertyOne;
    }
    private Task<Response> ValidateIdUri(NancyContext context, CancellationToken cancel)
    {
        var id = this.Bind<FromUri>().idUri;  ///used first time - IT WORKS, if I comment this line and its dependencies it will work on next method
        if (!id)
            return Task<Response>.Factory.StartNew(() => {
                    return HttpStatusCode.NotFound;
                });
        var obj = service.GetById(id);
        if (!obj)
            return Task<Response>.Factory.StartNew(() => {
                    return HttpStatusCode.NotFound;
                });
        return Task<Response>.Factory.StartNew(() => {
                    return null;
                });
    }

    //route POST: /fake/1234/property-one
    public dynamic PostPropertyOne(dynamic arg)
    {
        var fakeObject = this.Bind<FakeRequest>();  //DOES NOT WORK! Only if the previous bind is commented
        /// ...
    }

Binding should work like that but what are you sending in the request, how
can it bind to two separate objects unless you are sending in iduri, name
and year in your POST
On 6 October 2016 at 19:37, Leoni Br<EMAIL_ADDRESS>wrote:

using Nancy 1.4.3 - Owin Self Host
Let's say I have a module FakeIdModule that inherits from an abstract
module and uses its constructor to define a base route /fake/{idUri:long},
then I provide a ValidateIdUri function in the Before hook to verify the
idUri for all routes.
It is all working great up to this point, but when the requests enters the
route 'POST /fake/{idUri:long}/property-one' the call to Bind<...>()
fails because returns an empty object.
//inside module
internal class FromUri
{
    public long idUri {get;set;}
}
internal class FakeRequest
{
    public string Name {get;set;}
    public int Year {get;set;}
}

public FakeIdModule(IService _service): base("/fake/{idUri:long}")
{
    service = _service;
    this.Before.AddItemToStartOfPipeline(ValidateIdUri);
    Post["/property-one"] = PostPropertyOne;
}
private Task<Response> ValidateIdUri(NancyContext context, CancellationToken cancel)
{
    var id = this.Bind<FromUri>().idUri;  ///used first time - IT WORKS, if I comment this line and its dependencies it will work on next method
    if (!id)
        return Task<Response>.Factory.StartNew(() => {
                return HttpStatusCode.NotFound;
            });
    var obj = service.GetById(id);
    if (!obj)
        return Task<Response>.Factory.StartNew(() => {
                return HttpStatusCode.NotFound;
            });
    return Task<Response>.Factory.StartNew(() => {
                return null;
            });
}

//route POST: /fake/1234/property-one
public dynamic PostPropertyOne(dynamic arg)
{
    var fakeObject = this.Bind<FakeRequest>();  //DOES NOT WORK! Only if the previous bind is commented
    /// ...
}

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/NancyFx/Nancy/issues/2583, or mute the thread
https://github.com/notifications/unsubscribe-auth/AAGapqBtpwyRsD2jGCvNYvjc6jRbLtDmks5qxT_XgaJpZM4KQRh3
.

I didnt want to repeat the logic of verify idUri in every route, something like (using angularjs):
$http.post('/fake/1234/property-one', {name: 'Fake name', year: 2016 })
$http.post('/fake/1234/another-property', {comment: 'this is another comment' , year : 2016 })
For every route I must verify if 1234 is valid, and then get the data sent.

Long shot but thought it had been fixed. After first Bind do Body.Position
= 0
On Thursday, 6 October 2016, Leoni Br<EMAIL_ADDRESS>wrote:

I didnt want to repeat the logic of verify idUri in every route, something
like (using angularjs):
$http.post('/fake/1234/property-one', {name: 'Fake name', year: 2016 })
$http.post('/fake/1234/another-property', {comment: 'this is another
comment' , year : 2016 })
For every route I must verify if 1234 is valid, and then get the data sent.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/NancyFx/Nancy/issues/2583#issuecomment-252058181, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAGapp68__7YKfxBy5HYFsE-ctH03gMLks5qxUX9gaJpZM4KQRh3
.

That is it!!!
Thank you


Build 6825626 failed

Details

Project URL: https://github.com/Alignak-monitoring-contrib/alignak-app
Build URL (if applicable): https://readthedocs.org/projects/alignak-app/builds/6825626/
Read the Docs username (if applicable): Algorys

Expected Result
Build success on develop branch.
Actual Result
This build was terminated due to inactivity. If you continue to encounter this error, file a support request with and reference this build id (6825626).

Probably related to https://github.com/rtfd/readthedocs.org/issues/3707#issuecomment-369636647
And see https://github.com/rtfd/readthedocs.org/issues/3215#issuecomment-369661968

Thanks @stsewd, I will follow theses issues.
Strange thing is I've no submodule in my repository.

I had this issue around the same time, resetting the build environment fixed it (although I am now getting a different error).

Seems solved by resetting environment.


"Faked finally" - will this potentially cause any issues?

Hi!
I found an easy solution to "fake" a finally callback with axios, without installing any shims or polyfills.
https://codepen.io/lnfnunes/pen/ygzEvY
console.clear();

axios.all([
  axios.get('https://httpbin.org/get'),
  axios.get('https://httpbin.org/404')
])
.catch(error => console.log('Catch:', error))
.then(() => console.log('Finally!'))

is this considered bad practice, or will this cause any potential issues? I've only seen the order
.then() // resolved
.catch() // rejected
.finally() // always execute me..

so far, but never actually thought about changing it..
thanks!

Wondering the same thing!

It's ok, but you should make sure that your catch will never throw exception otherwise finally won't be called


Fixes #1194 (fix return macros)

Description

Related Issue

Motivation and Context

How Has This Been Tested?

Types of changes

[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[x] Breaking change (fix or feature that would cause existing functionality to change)
[ ] Trivial change (affects only documentation or cleanup)

Checklist:

[ ] I have tested this change with a run of GEOSgcm (if non-trivial)
[ ] I have added one of the required labels (0 diff, 0 diff trivial, 0 diff structural, non 0-diff)
[x] I have updated the CHANGELOG.md accordingly following the style of Keep a Changelog

The intent was precisely so that one could not use _RETURN inside a main program.    Instead one should use _FAIL is the examples you sited.   Even better if we can come up with a good error message.
Without this change, my expectation is that all of these would have called MPI_Abort().  If that was not the case, we need to study the macros again to see why that did not happen.

Hmm.   I suppose an even better fix would be to have _RETURN generate the string "Do not use _RETURN in main programs."   which will generate a nice syntax error that the user might be able to understand.
We'll discuss when you are back online tomorrow.

Close in favor of #1760


Get rid of the Facades and make ComputationContext the entrypoint for the library.

The puzzle 122-fa2d9963 from #122 has to be resolved:
https://github.com/nergal-perm/java-decita/blob/11ad72f83260cdd11ad2a9a6aec7b1b99d268434/src/main/java/ru/ewc/decisions/api/ComputationContext.java#L40-L40
The puzzle was created by Евгений Терехов on 29-May-24.
role: DEV.
If you have any technical questions, don't ask me, submit new tickets instead. The task will be "done" when the problem is fixed and the text of the puzzle is removed from the source code. Here is more about PDD and about me.

The puzzle 122-fa2d9963 has disappeared from the source code, that's why I closed this issue.


Vampire Drain: Do not display periods during which the vehicle has been preheated

I have my Tesla now for over a month. After the first month of pure fun, I start looking a little deeper into the physics and Technology.
Using your tool made me realise, that there could be some improvement for less Vampire drain during night and office times.
Now as the nights get colder, we start to heat the car in the morning.
But then we realised that teslamate does not realise the heating. So the Vampire Drains went sky high.
Is there any chance to exclude them from vampire losses or maybe split it into the 3 phases
try to sleep
sleeping
conditioning/heating
Shaun

I was just about to enter a new issue with this same thing cause I noticed that the Vampire Drain numbers seemed to be way overstated based on my own observations outside of TeslaMate. I suspected that they were including the pre-heat periods as those were the times that the numbers seemed to be WAY WAY higher than I noticed myself.

I do not know if this is a real remedy, but you may consider using the REST API approach to resume logging and set the car online when starting the pre-heat. Will it then be included in the vampire drain?
I'm using this method and pre-heat every morning, but my installation is very new. Will report back if I experience this. If not we may have a work-around.

Any further decisions on this?

Sorry, the @github-actions bot should have ignored this issue. The status has not changed - it is still on the To-Do list.

Would it be possible to modify this request to include all temp/climate states? I don't think pre-cooling the car should be considered vampire drain either. Maybe add AC/heating as states? I was camping in the car last night and had camping mode on all night, but this only shows up as vampire drain.


Drinking Water Extension

Is your extension request related to a problem? Please describe.
This small extension will help in reminding of drinking at regular intervals of time.As we all know that we got busier with our laptops than we forget to take care of our health . Staying hydrated is an essential part of maintaining good health.
Describe the solution you'd like.
This simple extension will help to remind drink water periodically.
Describe alternatives you've considered.
This extension have the option to set a time interval to show the notification.has
Add any other context or screenshots about the extension here.
https://drive.google.com/file/d/1-8Mh0ygrfjkeQWN0dmoXfnYLc4gYBV0Y/view?usp=sharing

@khushbooshakya there is already an extension present you can enhance its features or if your idea is different from this then explain it briefly

@khushbooshakya update? If you are thinking of any enhancement?


Warn of duplicates in arrays

Re-using the same key in an array should result in a warning.

Currently a duplicate will result in a backtrace like https://app.netlify.com/sites/coast/deploys/5be7f24c9a063f0e1f62c4e5
As duplicates do not alter the output, the duplicate should be eliminated and only a descriptive warning given .  The exit status could still be non-zero to indicate there was a significant problem with the input data.


Replaced artist and gene sitemaps with Spark-generated ones.

You can see these:
https://s3.amazonaws.com/artsy-sitemaps/sitemap-genes.xml
https://s3.amazonaws.com/artsy-sitemaps/sitemap-artists.xml
https://s3.amazonaws.com/artsy-sitemaps/sitemap-artists-2017.xml

          1 Warning

:warning:
Please include a PR summary

  Generated by :no_entry_sign: Danger

Looks pretty straight forward. Merging!


iOS targets fail on Linux

Our workaround with iosDisabled is not yet implemented in this project.

updating gradle in the parent project to 8.5 removes the need for this workaround


incorrect PQ tracking for .hdr images in "no effect" mode

I did some tests using HDR + WCG viewer using one of our NVIDIA GSYNC HDR10 monitor prototypes. Our debug tools can observe the exact HDR PQ12 codes coming in from the PC to the monitor. And it looks like brightness of a .hdr image displayed by HDR + WCG is about 8.5x too high at default brightness and when selecting Render Effect = No Effect (all other settings have special transformations we don’t want for our tests).
Consider the attached 4k ‘simultaneous contrast’ style test image we use. It has a 1400 nits bright bar at top. At bottom it has a greyscale with 14 steps, starting with 0.02 nits and increasing by 1.5x for every step to the right. We verified that the .hdr brightness is as we want it with 'tev' (see table).
When we display this with an in-house viewer, we get PQ12 values that translate to the correct nits (within RGBE quantization accuracy). Table below shows PQ12 values/nits values we get with HDR+WCG viewer.
We’d be very interested to see a fix, so we can recommend use of this viewer for our partners/monitor makers.

ContrastTest_0p02_1p5_3840_2160.zip
PS: we did these experiments with Win10 21H2 (19044.1706), and a 27” 4k 144 Hz 1000 nits GSYNC Ultimate monitor (max 1107 nits).

Thanks for your patience and for reporting this!
Tentative findings from my initial investigation:
From the RGBE file format spec, there is an EXPOSURE header variable:

EXPOSURE
A single floating point number indicating a multiplier that has
been applied to all the pixels in the file. EXPOSURE values are
cumulative, so the original pixel values (i.e., radiances in
watts/steradian/m^2) must be derived by taking the values in the
file and dividing by all the EXPOSURE settings multiplied
together. No EXPOSURE setting implies that no exposure
changes have taken place.

In this file, that value is:
EXPOSURE=0.11713
which corresponds to a multiplier of about 8.5, the discrepancy between the two apps.
This isn't my area of expertise, but from my reading of the spec, a decoder does need to divide color values by the EXPOSURE, i.e. the 8.5x higher values produced by the HDR image viewer are indeed correct. I am relying on directxtex for RGBE radiance decoding, and it looks like it is applying this divider.
However, I'm not an expert on the RGBE format. It's entirely possible that the EXPOSURE directive isn't widely used so it practically should be ignored; however I need to do further research on how to achieve this while using DirectXTex.

Attaching a quick and dirty hex-edited version of the repro image with
EXPOSURE=1.00000
ContrastTest_0p02_1p5_3840_2160-exposure1.zip
When loading this image, my MaxCLL histogram calculation gives 1517 nits, which is within the expected 10% margin of error to 1400 nits design point.

Thanks, Simon. Let me consult with someone inside NVIDIA that's an RGBE expert who gave me the encoding library.
From: Simon Tao @.>
Sent: Tuesday, December 27, 2022 8:08 AM
To: 13thsymphony/HDRImageViewer @.>
Cc: Gerrit Slavenburg @.>; Author @.>
Subject: Re: [13thsymphony/HDRImageViewer] incorrect PQ tracking for .hdr images in "no effect" mode (Issue #51)
Thanks for your patience and for reporting this!
Tentative findings from my initial investigation:
From the RGBE file format spechttps://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffloyd.lbl.gov%2Fradiance%2Frefer%2Ffilefmts.pdf&data=05|01|gslavenburg%40nvidia.com|d89b0653df374bc221b708dae82477af|43083d15727340c1b7db39efd9ccc17a|0|0|638077542138067982|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|3000|||&sdata=9chZ4DOtGjI187VZgwVTVGRXokdtlqfrUhg2tKXP42k%3D&reserved=0, there is an EXPOSURE header variable:
EXPOSURE
A single floating point number indicating a multiplier that has
been applied to all the pixels in the file. EXPOSURE values are
cumulative, so the original pixel values (i.e., radiances in
watts/steradian/m^2) must be derived by taking the values in the
file and dividing by all the EXPOSURE settings multiplied
together. No EXPOSURE setting implies that no exposure
changes have taken place.
In this file, that value is:
EXPOSURE=0.11713
which corresponds to a multiplier of about 8.5, the discrepancy between the two apps.
This isn't my area of expertise, but from my reading of the spec, a decoder does need to divide color values by the EXPOSURE, i.e. the 8.5x higher values produced by the HDR image viewer are indeed correct. I am relying on directxtexhttps://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmicrosoft%2FDirectXTex&data=05|01|gslavenburg%40nvidia.com|d89b0653df374bc221b708dae82477af|43083d15727340c1b7db39efd9ccc17a|0|0|638077542138067982|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|3000|||&sdata=PntAc1uYaJL%2Bmka0okpPg8uHIz%2Ffigq5niXORJETeiQ%3D&reserved=0 for RGBE radiance decoding, and it looks like it is applying this dividerhttps://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmicrosoft%2FDirectXTex%2Fblob%2F23b7fd1f385d33f40093a0786ca5b54147f2f24a%2FDirectXTex%2FDirectXTexHDR.cpp%23L878&data=05|01|gslavenburg%40nvidia.com|d89b0653df374bc221b708dae82477af|43083d15727340c1b7db39efd9ccc17a|0|0|638077542138067982|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|3000|||&sdata=x2Mf5uWZjDhEKTHGn%2BK2cE2U%2Fb8qiv0%2FAfeIcro78bU%3D&reserved=0.
However, I'm not an expert on the RGBE format. It's entirely possible that the EXPOSURE directive isn't widely used so it practically should be ignored; however I need to do further research on how to achieve this while using DirectXTex.

Reply to this email directly, view it on GitHubhttps://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2F13thsymphony%2FHDRImageViewer%2Fissues%2F51%23issuecomment-1366014242&data=05|01|gslavenburg%40nvidia.com|d89b0653df374bc221b708dae82477af|43083d15727340c1b7db39efd9ccc17a|0|0|638077542138223762|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|3000|||&sdata=FAsDK86ailY2j4eEe0aPMzHVtN50179qY9e5SYZ7oPA%3D&reserved=0, or unsubscribehttps://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAZJVWE5HP2ATNCEXMYOPWUDWPMH4NANCNFSM5WXS4HZQ&data=05|01|gslavenburg%40nvidia.com|d89b0653df374bc221b708dae82477af|43083d15727340c1b7db39efd9ccc17a|0|0|638077542138223762|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|3000|||&sdata=OBaALWspm%2Ft9azVWaxozRJQkjwlswO1KKgB4AnLcBrs%3D&reserved=0.
You are receiving this because you authored the thread.Message ID<EMAIL_ADDRESS>

Hi Simon,
I just tested your 'hacked' version of the Contrast Test image that edited the header to have EXPOSURE 1.0 (whereas my test image had exposure 0.11713)

NVIDIA's in-house viewer, HDRshow.exe appears to ignore the header exposure, the PQ codes I get are same for both versions !
'tev' also ignores the header exposure value, it reports "17.5" (*80 = 1400 nits) for the bright bar in both images !

I think the easiest solution is for me to change my .hdr image generation program to always use exposure 1.0. Then it should give identical results on all viewers. (to be confirmed)
Gerrit, NVIDIA
From: Gerrit Slavenburg @.>
Sent: Tuesday, December 27, 2022 8:34 AM
To: 13thsymphony/HDRImageViewer @.>; 13thsymphony/HDRImageViewer @.>
Cc: Author @.>
Subject: RE: [13thsymphony/HDRImageViewer] incorrect PQ tracking for .hdr images in "no effect" mode (Issue #51)
Thanks, Simon. Let me consult with someone inside NVIDIA that's an RGBE expert who gave me the encoding library.
From: Simon Tao @.>
Sent: Tuesday, December 27, 2022 8:08 AM
To: 13thsymphony/HDRImageViewer @.>
Cc: Gerrit Slavenburg @.>; Author @.>
Subject: Re: [13thsymphony/HDRImageViewer] incorrect PQ tracking for .hdr images in "no effect" mode (Issue #51)
Thanks for your patience and for reporting this!
Tentative findings from my initial investigation:
From the RGBE file format spechttps://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffloyd.lbl.gov%2Fradiance%2Frefer%2Ffilefmts.pdf&data=05|01|gslavenburg%40nvidia.com|d89b0653df374bc221b708dae82477af|43083d15727340c1b7db39efd9ccc17a|0|0|638077542138067982|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|3000|||&sdata=9chZ4DOtGjI187VZgwVTVGRXokdtlqfrUhg2tKXP42k%3D&reserved=0, there is an EXPOSURE header variable:
EXPOSURE
A single floating point number indicating a multiplier that has
been applied to all the pixels in the file. EXPOSURE values are
cumulative, so the original pixel values (i.e., radiances in
watts/steradian/m^2) must be derived by taking the values in the
file and dividing by all the EXPOSURE settings multiplied
together. No EXPOSURE setting implies that no exposure
changes have taken place.
In this file, that value is:
EXPOSURE=0.11713
which corresponds to a multiplier of about 8.5, the discrepancy between the two apps.
This isn't my area of expertise, but from my reading of the spec, a decoder does need to divide color values by the EXPOSURE, i.e. the 8.5x higher values produced by the HDR image viewer are indeed correct. I am relying on directxtexhttps://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmicrosoft%2FDirectXTex&data=05|01|gslavenburg%40nvidia.com|d89b0653df374bc221b708dae82477af|43083d15727340c1b7db39efd9ccc17a|0|0|638077542138067982|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|3000|||&sdata=PntAc1uYaJL%2Bmka0okpPg8uHIz%2Ffigq5niXORJETeiQ%3D&reserved=0 for RGBE radiance decoding, and it looks like it is applying this dividerhttps://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmicrosoft%2FDirectXTex%2Fblob%2F23b7fd1f385d33f40093a0786ca5b54147f2f24a%2FDirectXTex%2FDirectXTexHDR.cpp%23L878&data=05|01|gslavenburg%40nvidia.com|d89b0653df374bc221b708dae82477af|43083d15727340c1b7db39efd9ccc17a|0|0|638077542138067982|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|3000|||&sdata=x2Mf5uWZjDhEKTHGn%2BK2cE2U%2Fb8qiv0%2FAfeIcro78bU%3D&reserved=0.
However, I'm not an expert on the RGBE format. It's entirely possible that the EXPOSURE directive isn't widely used so it practically should be ignored; however I need to do further research on how to achieve this while using DirectXTex.

Reply to this email directly, view it on GitHubhttps://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2F13thsymphony%2FHDRImageViewer%2Fissues%2F51%23issuecomment-1366014242&data=05|01|gslavenburg%40nvidia.com|d89b0653df374bc221b708dae82477af|43083d15727340c1b7db39efd9ccc17a|0|0|638077542138223762|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|3000|||&sdata=FAsDK86ailY2j4eEe0aPMzHVtN50179qY9e5SYZ7oPA%3D&reserved=0, or unsubscribehttps://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAZJVWE5HP2ATNCEXMYOPWUDWPMH4NANCNFSM5WXS4HZQ&data=05|01|gslavenburg%40nvidia.com|d89b0653df374bc221b708dae82477af|43083d15727340c1b7db39efd9ccc17a|0|0|638077542138223762|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|3000|||&sdata=OBaALWspm%2Ft9azVWaxozRJQkjwlswO1KKgB4AnLcBrs%3D&reserved=0.
You are receiving this because you authored the thread.Message ID<EMAIL_ADDRESS>

That's great to hear, let me know how it turns out!


Toaster stops working on storybook

🐛 Bug Report
After navigating to toaster info/warning/error, the toaster stops working. The only way to fix it is to cold refresh (F5) the whole storybook.
Expected behavior
The toaster must work in any case.
Paste the results here:

It is working again thanks to rebuild and redeploy.


signature: return access key when V4SignVerify is successful

That way we will be able to extend renterd to still reject an authentication attempt if the key used wasn't part of a given set of allowed keys.

@ChrisSchinnerl sorry about that :/ I was looking at the board and was curious and then found out it was assigned to me


An actorless load generator

At the moment Rally uses a process per client model (see https://github.com/elastic/rally/issues/9#issuecomment-179312337, https://github.com/elastic/rally/issues/58 and https://github.com/elastic/rally/commit/fe5dba3205c7c09a1491f349c6d4db19d89d2f9d for more details) and implements this with an actor system that allows clients (actors) to communicate with each other. The basic structure is that there is a controller actor (called Driver) for all clients and each client (actor) is responsible to execute scheduled tasks. However, this has several drawbacks that we've seen in practice:

Complexity added by the actor framework: we need to spin up a separate process to communicate across nodes. Having the ability to communicate across nodes was mostly needed to spin up a cluster from the coordinator machine (where the benchmark has been started) but is less important for the load generator (although we also use it to distribute it across several machines). This was convenient in the early days but nowadays we let other tools handle remote connections during setup (e.g. Ansible) and use Rally only to setup the individual nodes. Thus we don't need an actor system as much as we did before.
Terminal output issues (the actor system performs a double-fork and thus we cannot write to the terminal)
Issues to even startup the system on Windows that are hard to debug.
Limit on the upper bound of supported clients (the whole system is just hanging if there are too many actors).
Logging issues: logs are sent to a central component which then writes to the log file. If one actor issues too many logs, the actor system just becomes unresponsive (which is quite hard to debug because there are no logs to begin with).
Debugging actor issues is quite tricky and we don't have much influence over what is logged.

Note that these limitations are due to the specific actor system implementation, and not necessarily conceptual issues. There are, however, also shortcomings that can be related to the process per client model:

There is no built-in mechanism for clients to share state (this is not technically impossible, it's just a bit harder than with a single process model). Sharing state can be sometimes convenient e.g. if in an initial step, data is retrieved from Elasticsearch and then we can use this information in later steps. This is done for example by the eventdata track that retrieves the minimum and maximum date of log entries in Elasticsearch and uses it to choose appropriate date range parameters for simulating dashboard queries in later steps.
Starting a process for each client is quite heavy-weight and thus it's not feasible to simulate thousands of clients with Rally.

We should explore a few options based on these shortcomings:

Using the Python Elasticsearch async client.
Using asyncio directly
Keeping the process per client model but instead use multiprocessing

There are maybe other options as well but these are the choices that first come to mind. We should also refine this ticket as we proceed with our analysis.
IMHO it is ok to support only one load generator machine in the first step but we should aim to support the Rally tracks that we currently maintain.

Reopening as our current multi-core implementation in https://github.com/elastic/rally/pull/944  still uses the actor system.

Closing as we have no intention of changing this in the foreseeable future (this may change in the far future though).


Unable to run HTTP trigger based Azure Function locally using VS Code (Value cannot be null. (Parameter 'provider'))

I’ve followed the following link to create a sample HTTP trigger based Azure function
https://docs.microsoft.com/en-us/azure/azure-functions/create-first-function-vs-code-java
When I am trying to run it using Ctrl+F5 in VS Code, I am getting the following error.

Exception StackTrace :
Azure Functions Core Tools
Core Tools Version:       3.0.3477 Commit hash: 5fbb9a76fc00e4168f2cc90d6ff0afe5373afc6d  (64-bit)
Function Runtime Version: 3.0.15584.0
[2021-06-23T19:16:29.003Z] File 'C:\Program Files\dotnet\dotnet.exe' is not found, 'dotnet' invocation will rely on the PATH environment variable.
System.ArgumentNullException: Value cannot be null. (Parameter 'provider')
at Microsoft.Extensions.DependencyInjection.ServiceProviderServiceExtensions.GetRequiredService[T](IServiceProvider provider)
at Azure.Functions.Cli.Actions.HostActions.StartHostAction.RunAsync() in D:\a\1\s\src\Azure.Functions.Cli\Actions\HostActions\StartHostAction.cs:line 344
at Azure.Functions.Cli.ConsoleApp.RunAsync[T](String[] args, IContainer container) in D:\a\1\s\src\Azure.Functions.Cli\ConsoleApp.cs:line 66
[2021-06-23T19:17:29.037Z] Starting worker process failed
[2021-06-23T19:17:29.041Z] System.TimeoutException: The operation has timed out.
[2021-06-23T19:17:29.043Z] Failed to start language worker process for runtime: (null). workerId:fe772472-d708-4e23-b636-6835656f8760
The terminal process "C:\WINDOWS\System32\WindowsPowerShell\v1.0\powershell.exe -Command func host start" terminated with exit code: 1.

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

ID: 16d5655a-1676-d3de-1a3d-15613b75675c
Version Independent ID: d5e7bbdd-e581-7fa2-8b24-8c18e2003e51
Content: Create a Java function using Visual Studio Code - Azure Functions
Content Source: articles/azure-functions/create-first-function-vs-code-java.md
Service: azure-functions
GitHub Login: @ggailey777
Microsoft Alias: glenga

@tarun-gupta-ps  Thank you for the question. We will review and get back to you.

@ggailey777 Could you please review this and see if we need any modification?

Looks to me like your Core Tools installation may be messed-up. Try reinstalling Core Tools manually? #please-close


New Collections protocol breaks xarray objects

The recent merge of the new Collections protocol (#8674) broke Xarray's tests (https://github.com/pydata/xarray/issues/6578)
Xarray objects return None from __dask_graph__ if there no dask arrays being wrapped.
It seems like the current version of is_dask_collection only checks for the presence of __dask_graph__. Xarray objects are a case where this check is not sufficient (they look like dask collections in general, you can call dask.visualize and dask.compute on xarray objects).
It isn't clear to me that there is a good solution other than explicitly checking the return value in is_dask_collection but if there is something we could do on the Xarray side, please let us know!

Thanks for reporting @dcherian (and hooray for upstream CI testing 🎉 ). I've not had a chance to dig into this yet, but plan to do so tomorrow. cc'ing @douglasdavis @ian-r-rose in the meantime

Thanks for flagging this @dcherian! We had some discussion about exactly this change here, and were not aware of any downstream usages of returning None. At the time it seemed relatively safe since there are many places in dask's codebase that don't check for None and happily assume the result is a graph. But evidently not.
It's simple enough fix to roll back that change, though after we do it it might be nice if we could continue discussing how to tighten the protocol a bit.

I agree with @ian-r-rose. I just created a PR (#9062) to revert the change to is_dask_collection.


Doesn't work with OBDLink MX

No data is received with OBDLink MX bluetooth devices.
The issue is because the OBDLink MX device does not seem to have new lines enabled by default.

I believe this issue is now fixed in the dev branch. Need to verify.

Still broken in 0.2.
OBDLink doesn't send 'OK' after a reset request, which breaks my response verification code. This should be fixed for 0.3.


[.NET] Remove action type from style

Fixes https://github.com/microsoft/AdaptiveCards/issues/2891
Changes the style name to be used for style from Adaptive.Action.

Changes the style name to be used for style from Adaptive.Action.


Error while running pcicrawler utility

While running the pcicrawler utility from within a virtual-environment - Following ModuleNotFound error is observed -
(venv) gabhijit@gabhijit-GL553VD:~/backup/personal-code/pcicrawler$ pcicrawler
Traceback (most recent call last):
  File "/home/gabhijit/backup/personal-code/pcicrawler/venv/bin/pcicrawler", line 11, in <module>
    load_entry_point('pcicrawler==0.1.0', 'console_scripts', 'pcicrawler')()
  File "/home/gabhijit/backup/personal-code/pcicrawler/venv/lib/python3.7/site-packages/pkg_resources/__init__.py", line 490, in load_entry_point
    return get_distribution(dist).load_entry_point(group, name)
  File "/home/gabhijit/backup/personal-code/pcicrawler/venv/lib/python3.7/site-packages/pkg_resources/__init__.py", line 2859, in load_entry_point
    return ep.load()
  File "/home/gabhijit/backup/personal-code/pcicrawler/venv/lib/python3.7/site-packages/pkg_resources/__init__.py", line 2450, in load
    return self.resolve()
  File "/home/gabhijit/backup/personal-code/pcicrawler/venv/lib/python3.7/site-packages/pkg_resources/__init__.py", line 2456, in resolve
    module = __import__(self.module_name, fromlist=['__name__'], level=0)
  File "/home/gabhijit/backup/personal-code/pcicrawler/venv/lib/python3.7/site-packages/pcicrawler-0.1.0-py3.7.egg/pcicrawler/cli.py", line 12, in <module>
ModuleNotFoundError: No module named 'pcicrawler.lib'

Indeed there is no module named lib inside pcicrawler.
This error is observed while running from the checked out repo after doing a setup.py install in virtualenv.

Likely the entire lib directory is missed to be checked in?

Thanks for raising the issue. Currently working on removing the reference to pcicrawler.lib.

Okay! created a pull request with the fix.

@martinezmarcos  I see that you have removed the reference to pcicrawler.lib so the 'master' branch now works. Closing this issue, however having this hard coded return value of 16 is a really bad idea and totally avoidable!
I also, see there is only one place where there is explicit sys.exit with an error code. Also using 1 or -1 makes more sense for this particular case because semantically it is correct.
$ errno -l | grep EPERM
EPERM 1 Operation not permitted

@gabhijit Thanks for your helpful insight. We will definitely consider the suggestions offered when working on this. For now, removing the reference was the intention. Hope you find the tool helpful and we encourage further contribution!


molecule destroy --all

Issue Type

Feature request

Molecule and Ansible details
ansible --version
ansible <IP_ADDRESS>
  config file = /home/markus/projects/mgit/ansible/ansible.cfg
  configured module search path = Default w/o overrides
  python version = 2.7.12 (default, Nov 19 2016, 06:48:10) [GCC 5.4.0 20160609]

molecule --version
molecule, version <IP_ADDRESS>rc11

Molecule installation method: pip
Ansible installation method: OS package

Desired Behaviour
After running molecule destroy --all, no instance should be running and all instances from all scenarios should be destroyed.
I'd like to add this to my CI scripts after running molecule test, since I might end up with some still running instances if a test run fails. Nice for local debugging, not so nice on a CI server. molecule destroy currently is just a shorthand for molecule destroy --scenario-name default, while molecule test already will run all possible scenarios one at a time.

I'm actually going to change Molecule's test api slightly.  I would prefer to keep things consistent.  I'm going to implement a --all flag on both destroy and test so that they remain consistent.  This also means test will become consistent with the existing sub commands.


Bug with ScopeProvider  falsely capturing an immer atom

When you define an immer atom and the create a ScopeProvider that should not capture the immer atom, it still ends up capturing the immer atom inside the ScopeProvider.
Here is an example where we have 3 atoms:

a scoped regular atom
an unscoped regular atom
a scoped regular atom

We start out with the mounted ScopeProvider. Try incrementing all 3 atoms and then press the button to unmount the ScopeProvider. You would expect to see results:

Counter scoped: 0
Counter immer: 101
Counter unscoped: 1001

but instead you see:

Counter scoped: 0
Counter immer: 100
Counter unscoped: 1001

For some reason, the immer atom ends up scoped within the ScopeProvider.
Here is the code example:
"use client";

import React from "react";
import { useAtom, atom } from "jotai";
import { atomWithImmer } from "jotai-immer";
import { ScopeProvider } from "jotai-scope";

const regAtom = atom({counter: 1000})
const scopedAtom = atom({ counter: 0 });
const immerAtom = atomWithImmer({ counter: 100 });

export default function JotaiBug() {
  const [innerMounted, setInnerMounted] = React.useState(true);

  return (

Are we mounted? {innerMounted}

      {innerMounted ? (
        <ScopeProvider atoms={[scopedAtom]}>

            <Inner />

              <button onClick={() => setInnerMounted(false)}>
                unmount scoped provider
              </button>

        </ScopeProvider>
      ) : (
        <CounterDisplay />
      )}

  );
}

function Inner() {
  return <CounterDisplay />;
}

function CounterDisplay() {
  const [counterScoped, setState] = useAtom(scopedAtom);
  const [counterImmer, setState2] = useAtom(immerAtom);
  const [counterReg, setState3] = useAtom(regAtom);

  const incScoped = () => {
    setState((prev) => {
      return { counter: prev.counter + 1 };
    });
  };
  const incImmer = () => {
    setState2((prev) => {
      prev.counter++;
    });
  };
  const incReg = () => {
    setState3((prev) => {
      return { counter: prev.counter + 1 };
    });
  }

  return (

        Counter scoped: {counterScoped.counter}
        <button style={{ marginLeft: 20 }} onClick={incScoped}>
          increment
        </button>

        Counter immer: {counterImmer.counter}
        <button style={{ marginLeft: 20 }} onClick={incImmer}>
          increment
        </button>

        Counter unscoped: {counterReg.counter}
        <button style={{ marginLeft: 20 }} onClick={incReg}>
          increment
        </button>

  );
}

Thanks for reporting!
I wonder if someone can dig into it.
(But, someone only I know is @yf-yang )
@dbmikus One thing I want you to try is if you can reproduce the same bug with atomWithReducer.

@dbmikus One thing I want you to try is if you can reproduce the same bug with atomWithReducer.

Unfortunately, I can't put time into trying to reproduce or fix right now. I just stopped scoping the atom for now. If I have time free up to investigate/attempt a fix, I will post here.

@dai-shi Check this out: codesandbox
I've added two lines:
// App.js
const immerAtom = atomWithImmer({ counter: 100 });
immerAtom.debugLabel = "immerAtom";
immerAtom.temp = 1;

// patched-jotai-scope.js, in the patched store, when the new atom is created
if (scopedAtom.debugLabel === "immerAtom") {
  scopedAtom.temp = 1000;
}

Open the log console, click "increment" right next to "Counter Immer", and you'll get the point.
However, I am not so clear of how jotai calls atom.read, and my intuition is the point is how the "thisArg" is bind. Another intuition is, current solution does not work for all the atom, but the "pure" atom bypass the flaw in some way, so both reducer and immer do not work.
Do you have any ideas?

Hmmm, I have some clues. Take jotai-immer for example (I think reducer is similar)
https://github.com/jotaijs/jotai-immer/blob/2748abcf203daa96ac07cf6ae609a815fcb6eaca/src/atomWithImmer.ts#L13
export function atomWithImmer<Value>(
  initialValue: Value
): WritableAtom<Value, [Value | ((draft: Draft<Value>) => void)], void> {
  const anAtom: any = atom(
    initialValue,
    (get, set, fn: Value | ((draft: Draft<Value>) => void)) =>
      set(
        anAtom,
        produce(
          get(anAtom),
          typeof fn === 'function'
            ? (fn as (draft: Draft<Value>) => void)
            : () => fn
        )
      )
  )
  return anAtom
}

Here, the first argument of the anAtom.write will always be anAtom itself (Actually those wrappers move the anAtom from its external scope into its current scope). Therefore, when we call store.set, which in jotai-scope calls
https://github.com/jotaijs/jotai-scope/blob/ab16ee3760d6906883647f3b6da2c52f32b15bdd/src/ScopeProvider.tsx#L53-L61
We expect the a at line 57 be the copied atom (scopedAtom), but due to the implementation above, it is the original atom. Therefore,
https://github.com/jotaijs/jotai-scope/blob/ab16ee3760d6906883647f3b6da2c52f32b15bdd/src/ScopeProvider.tsx#L32-L41 will return the scopedAtom instead of the correct default atom. Then, in the internal atomStateMap, the scopedAtom's value is incremented, while the original atom's value is unchanged at all. When we remove the ScopeProvider, the original atom is exposed again, so it rewinds back to the untouched original atom's (initial) value.

ah, nice catch... that explains the #16 issue.

Maybe refactor getAtom can fix the issue (check if mappings has the atom), but frankly speaking I am not so clear what target, thisArg, orig, delegate mean in different scenarios.

Yeah, it's confusing to me too. I'll draft a PR later.

After thinking about this, this is the issue of atomWithImmer and atomWithReducer implementation. Let me draft PRs there.

https://github.com/jotaijs/jotai-scope/issues/16#issuecomment-1900330973
Well, now, I don't know how to fix it...

I'll leave my comment here. I am subject to https://github.com/pmndrs/jotai/pull/2351 fix, because that is quite a common technique. I use this trick/recipe a lot, too. It is hard to tell people why we need to do so, and jotai-scope is relative not so broadly used.
Let me think about the implementation.

@dai-shi I find an intuitive solution (for this specific case), haven't have it tested with other scenarios and fully consider its validity yet. See if that can give you some inspirations.
Besides, I quickly drafted a doc for getAtom, writing it hastily without careful consideration, and its wording still needs to be improved.
/**
 * When an scoped atom call get(anotherAtom) or set(anotherAtom, value), we ensure `anotherAtom` be
 * scoped by calling this function.
 * @param thisArg The scoped atom.
 * @param orig The unscoped original atom of this scoped atom.
 * @param target The `anotherAtom` that this atom is accessing.
 * @returns The scoped target if needed.
 *
 * Check the example below, when calling useAtomValue, jotai-scope first finds the anonymous
 * scoped atom of `anAtom` (we call it `anAtomScoped`). Then, `anAtomScoped.read(dependencyAtom)`
 * becomes `getAtom(anAtomScoped, anAtom, dependencyAtom)`
 * @example
 * const anAtom = atom(get => get(dependencyAtom))
 * const Component = () => {
 *  useAtomValue(anAtom);
 * }
 * const App = () => {
 *   return (
 *    <ScopeProvider atoms={[anAtom]}>
 *      <Component />
 *    </ScopeProvider>
 *   );
 * }
 */
const getAtom = (thisArg, orig, target) => {
  if (thisArg.debugLabel === "immerAtom") {
    console.log(
      `GETATOM thisArg.temp=${thisArg.temp} target.temp=${target.temp} delegate=${delegate}`
    );
  }
  if (target === thisArg) {
    return delegate ? getParentScopedAtom(orig) : target;
  }
  return getAtom(thisArg, orig, getScopedAtom(target));
};

I also suggest we change those internal parameter names (delegate, thisArg, orig, target), use clearer terms.

OK, that doesn't fix #16, needs more investigation.

I also suggest we change those internal parameter names (delegate, thisArg, orig, target), use clearer terms.

Totally agree. If you understand how it's working, can you suggest the terms?

Fixed in 0.5.0


docs: add cyberconnect to showcase

Pre-flight checklist

[x] I have read the Contributing Guidelines on pull requests.
[ ] If this is a code change: I have written unit tests and/or added dogfooding pages to fully verify the new behavior.
[ ] If this is a new API or substantial change: the PR has an accompanying issue (closes #0000) and the maintainers have approved on my working plan.

Motivation

Test Plan

Test links

Deploy preview: https://deploy-preview-_____--docusaurus-2.netlify.app/
Related issues/PRs

@snowdot Please don't open duplicate PRs. You can keep this one and the CLA status will be updated.


Support for request logging in kafka emitter.

This is continuation of #5782. Due to Apache Incubating process and packages renames it was easier to create new PR than resolve conflicts, sorry for inconvenience.
@jihoonson According to your comment the Jackson mixin annotation has been moved into kafka-emitter module.

By the way, apologies for the delay in picking review back up on this PR>

Hey @mkuthan  - hope the review was helpful, let us know if you have any questions about further implementation!

This is sad that this pr never was merged. It would be awesome if someone would pick this up. I can contribute with lots of emojis if that happens!

this looks like very close indeed, @mkuthan there is at least  one more person ( @Raboo ) needing this , if you wanna revive this PR  , I can help review and get in.


Add support for monitorType external in GSLB_Monitor

Is your feature request related to a problem? Please describe.
To enable HTTPS SNI-enabled healthchecks for AS3 GSLB pools I want to use the "external" monitor type for GSLB monitors but this option does not exist.
Describe the solution you'd like
Add monitorType external for GSLB_Monitor, similar to how the LTM "Monitor" has a more specific "Monitor_External".

Closing as duplicate of #160.

Actually, keeping this open. I misunderstood the request. This is actually to create an external GSLB monitor with AS3 instead of just referencing one, right?

Exactly!

Thank you for your feedback. I have added this to our internal product backlog as AUTOTOOL-1571.

This issue has been resolved with the 3.30.0 release of AS3.


Diagram link in documentation broken

On
https://sys-bio.github.io/libOmexMeta/docs-build/diagrams/diagrams_index.html
the digram image is not displayed, i.e. the follogin link is not working on the documentation page
https://sys-bio.github.io/libOmexMeta/docs-build/_images/TeusinkDiagram.png

Hi Matthias, Thanks for pointing this out. I'll have it fixed in the next release (this week probably),

For reference of anybody following this thread, I had problems with locating the png on the githib.io server and didn't get this resolved, but for now its not a priority

For reference of anybody following this thread, I had problems with locating the png on the githib.io server and didn't get this resolved, but for now its not a priority


BACKEND

Create the routes using nodejs

@toure5013 We are working only on the front end for now. And secondly, are you participant for HackInCodes Contributor's Hack?


Create a new guide for session management

We should create a new documentation guide on how to work with sessions (SessionPool).
Inspiration: https://crawlee.dev/docs/guides/session-management

Hi, I would like to work on this issue

@RaghavMangla We don't assign issues for hacktoberfest. If you want to work on this, open a PR. First mergeable one gets merged.


bundix: 2.3.1 -> 2.4.0

Motivation for this change
path support
Things done

[ ] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
Built on platform(s)

[ ] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Assured whether relevant documentation is up to date
[ ] Fits CONTRIBUTING.md.

Success on x86_64-linux (full log)
Attempted: bundix
Partial log (click to expand)
  Bin dir: /nix/store/jbalpf8nri72b24xspnhpzz4yrr8ai5c-bundix-2.4.0/lib/ruby/gems/2.5.0/bin
  Gem home: /nix/store/jbalpf8nri72b24xspnhpzz4yrr8ai5c-bundix-2.4.0/lib/ruby/gems/2.5.0
Successfully installed bundix-2.4.0
1 gem installed
post-installation fixup
shrinking RPATHs of ELF executables and libraries in /nix/store/jbalpf8nri72b24xspnhpzz4yrr8ai5c-bundix-2.4.0
patching script interpreter paths in /nix/store/jbalpf8nri72b24xspnhpzz4yrr8ai5c-bundix-2.4.0
/nix/store/jbalpf8nri72b24xspnhpzz4yrr8ai5c-bundix-2.4.0/lib/ruby/gems/2.5.0/gems/bundix-2.4.0/bin/bundix: interpreter directive changed from "/usr/bin/env ruby" to "/nix/store/ika1q830fhx778vdrnpbpsz2a4386yl6-ruby-2.5.3/bin/ruby"
checking for references to /build in /nix/store/jbalpf8nri72b24xspnhpzz4yrr8ai5c-bundix-2.4.0...
/nix/store/jbalpf8nri72b24xspnhpzz4yrr8ai5c-bundix-2.4.0

Success on aarch64-linux (full log)
Attempted: bundix
Partial log (click to expand)
  Bin dir: /nix/store/zwwnnp7rhy30wn8bqrl0w7fsrbccgqg1-bundix-2.4.0/lib/ruby/gems/2.5.0/bin
  Gem home: /nix/store/zwwnnp7rhy30wn8bqrl0w7fsrbccgqg1-bundix-2.4.0/lib/ruby/gems/2.5.0
Successfully installed bundix-2.4.0
1 gem installed
post-installation fixup
shrinking RPATHs of ELF executables and libraries in /nix/store/zwwnnp7rhy30wn8bqrl0w7fsrbccgqg1-bundix-2.4.0
patching script interpreter paths in /nix/store/zwwnnp7rhy30wn8bqrl0w7fsrbccgqg1-bundix-2.4.0
/nix/store/zwwnnp7rhy30wn8bqrl0w7fsrbccgqg1-bundix-2.4.0/lib/ruby/gems/2.5.0/gems/bundix-2.4.0/bin/bundix: interpreter directive changed from "/usr/bin/env ruby" to "/nix/store/caf5a0v9s94j17z3f8db6jjhysdpa0j8-ruby-2.5.3/bin/ruby"
checking for references to /build in /nix/store/zwwnnp7rhy30wn8bqrl0w7fsrbccgqg1-bundix-2.4.0...
/nix/store/zwwnnp7rhy30wn8bqrl0w7fsrbccgqg1-bundix-2.4.0

Success on x86_64-darwin (full log)
Attempted: bundix
Partial log (click to expand)
WARNING:  You build with buildroot.
  Build root: /
  Bin dir: /nix/store/0jx4wxfw6b87gzjz9jcvim1skgkxg0rb-bundix-2.4.0/lib/ruby/gems/2.5.0/bin
  Gem home: /nix/store/0jx4wxfw6b87gzjz9jcvim1skgkxg0rb-bundix-2.4.0/lib/ruby/gems/2.5.0
Successfully installed bundix-2.4.0
1 gem installed
post-installation fixup
patching script interpreter paths in /nix/store/0jx4wxfw6b87gzjz9jcvim1skgkxg0rb-bundix-2.4.0
/nix/store/0jx4wxfw6b87gzjz9jcvim1skgkxg0rb-bundix-2.4.0/lib/ruby/gems/2.5.0/gems/bundix-2.4.0/bin/bundix: interpreter directive changed from "/usr/bin/env ruby" to "/nix/store/l977nffsm9vikszj4znjlnhgg57gzdc1-ruby-2.5.3/bin/ruby"
/nix/store/0jx4wxfw6b87gzjz9jcvim1skgkxg0rb-bundix-2.4.0


Prove termination of inductive type including other inductive types

Hello,
I find F* can not prove the termination of one kind of inductive type elegantly:
type tlist =
  | Base: nat -> tlist
  | Llist: list tlist -> tlist

val size_tlist_fail: tl:tlist -> Tot nat (decreases %[tl])
let rec size_tlist_fail tl =
  match tl with
  | Base _ -> 1
  | Llist l ->
    match l with
    | [] -> 0
    | hd:: tl -> size_tlist_fail hd  + size_tlist_fail (Llist tl)

where size_tlist_fail (Llist tl) satisfies Llist tl << old (tl) of size_tlist_fail tl.
However, F* says: Could not prove termination of this recursive call; The SMT ....
Currently, I only find one solution:
...
type tlists = list tlist

val size_tlist_ok: tl:tlist -> Tot nat (decreases %[tl])
let rec size_tlist_ok tl =
  match tl with
  | Base _ -> 1
  | Llist l -> size_tlists l
and size_tlists (l:tlists) : Tot nat (decreases %[l]) =
  match l with
  | [] -> 0
  | hd :: tl -> let tn = size_tlist_ok hd in
    tn + size_tlists tl

So my question is: Can F* support some notations like decreases %[tl; tl?Llist] or type tlist (decreases %[Llist]) = in order to make the recursion function like size_tlist_fail can be accepted by z3?  Or maybe F* already supports some features to solve it?

However, the only solution (mutually inductive types) bears the known bug #2193 . That is,
if A.fst defines a mutually inductive type, and if you declare open A in B.fst, then you get the same bug #2193
I am trying the solution https://github.com/FStarLang/FStar/pull/2200/files?file-filters[]=.fs&file-filters[]=.fst&file-filters[]=No+extension#

However, the only solution (mutually inductive types) bears the known bug #2193 . That is,
if A.fst defines a mutually inductive type, and if you declare open A in B.fst, then you get the same bug #2193
I am trying the solution https://github.com/FStarLang/FStar/pull/2200/files?file-filters[]=.fs&file-filters[]=.fst&file-filters[]=No+extension#

Hi,

Or maybe F* already supports some features to solve it?

You can provide your function size_tlist_fail a custom measure for your type tlist (that is, a total function from tlist to, for instance, nat), so that F* is able to reason about decreasing tlists. For example:
type tlist =
  | Base: nat -> tlist
  | Llist: list tlist -> tlist

let rec lex (tlst: tlist): nat =
  match tlst with
  | Base n -> 0
  | Llist l -> 1 + lex_helper l
and lex_helper (l: list tlist): nat
  = match l with
  | [] -> 0
  | hd::tl -> 1 + lex hd + lex_helper tl

val size_tlist_fail: tl:tlist -> Tot nat (decreases (lex tl))
let rec size_tlist_fail tl =
  match tl with
  | Base _ -> 1
  | Llist l ->
    match l with
    | [] -> 0
    | hd:: tl -> size_tlist_fail hd  + size_tlist_fail (Llist tl)

Hi,

Or maybe F* already supports some features to solve it?

You can provide your function size_tlist_fail a custom measure for your type tlist (that is, a total function from tlist to, for instance, nat), so that F* is able to reason about decreasing tlists. For example:
type tlist =
  | Base: nat -> tlist
  | Llist: list tlist -> tlist

let rec lex (tlst: tlist): nat =
  match tlst with
  | Base n -> 0
  | Llist l -> 1 + lex_helper l
and lex_helper (l: list tlist): nat
  = match l with
  | [] -> 0
  | hd::tl -> 1 + lex hd + lex_helper tl

val size_tlist_fail: tl:tlist -> Tot nat (decreases (lex tl))
let rec size_tlist_fail tl =
  match tl with
  | Base _ -> 1
  | Llist l ->
    match l with
    | [] -> 0
    | hd:: tl -> size_tlist_fail hd  + size_tlist_fail (Llist tl)

Thanks, my colleague :-) @W95Psp
So, now we need an auxiliary function (e.g. aux) with the mutually inductive type to tell FStar how to do descreases aux. (because FStar is not so smart)
But if we use the mutually inductive type within the target function, like size_tlist_ok, the bug #2193 will appear.

Thanks, my colleague :-) @W95Psp
So, now we need an auxiliary function (e.g. aux) with the mutually inductive type to tell FStar how to do descreases aux. (because FStar is not so smart)
But if we use the mutually inductive type within the target function, like size_tlist_ok, the bug #2193 will appear.

I don't see any other way to do this. There are essentially two inductions involved, one on tlist and one on list. And since F* does not automatically set up the induction, you have to specify both. Now whether you do it "inline" as @nuaaysh did or as a separate function as @W95Psp did, is a matter of choice and whether the induction principle needs to be applied multiple times.
I am closing the issue (#2193 is already being tracked separately), please reopen if needed. Thanks!

I don't see any other way to do this. There are essentially two inductions involved, one on tlist and one on list. And since F* does not automatically set up the induction, you have to specify both. Now whether you do it "inline" as @nuaaysh did or as a separate function as @W95Psp did, is a matter of choice and whether the induction principle needs to be applied multiple times.
I am closing the issue (#2193 is already being tracked separately), please reopen if needed. Thanks!