( Enhancement | Suggestion ) Maybe using gobuilder.me to build packages for various OS's.

I submitted it to gobuilder.me and it finished the build in a few seconds.
The result is packages for nearly every used operating system, ready to go.

Suggestions:

Maybe a webhook, to automatically build it when a new commit occurs
.gobuilder.yml file to customize the build process.

More information on both of them is available here.

I am not affiliated, nor promoting Gobuilder for comercial purposes. :wink:
Congratulations on getting onto the front page of Hacker News :).

Don't really see the point of this. Sorry.

Fair enough.


I link to librt on Linux, I think it's only necessary on Linux. The FreeBSD man page says it's available in libc.
Tested on Linux and OS X.

Out of curiosity, did you encounter this because you saw the problem or were you just looking at the code's use of time functions?

I spotted the problem while randomly reading the sources.

This is only used in the metrics feature (which is for debugging purposes) and it's more code, so I think we don't want this.


UDP with ACKs for SCION infra

Implements a protocol for messages with ACKs on top of a net.PacketConn object.
Also:

A dummy loopback connection object for simplified testing;
An elastic free buffer pool that multiple goroutines can share (when batching is not a performance concern yet).

This change is

Review status: 0 of 6 files reviewed at latest revision, 1 unresolved discussion, some commit checks failed.

go/lib/infra/messaging/types.go, line 67 at r1 (raw file):

	for {
		old := atomic.LoadUint64((*uint64)(u))
		new := (old + 1) % (1<<56 - 1)

Note to self: drop the -1 here.

Comments from Reviewable

Review status: 0 of 6 files reviewed at latest revision, 2 unresolved discussions, some commit checks failed.

go/lib/infra/messaging/udp.go, line 205 at r1 (raw file):

	case event := <-t.readEvents:
		// Propagate message payload to caller
		return event.buffer.CloneB(), event.address, nil

Note to self: return buffer to free pool here.

Comments from Reviewable

Review status: 0 of 6 files reviewed at latest revision, 3 unresolved discussions, some commit checks failed.

go/lib/infra/messaging/udp.go, line 281 at r1 (raw file):

				// (if requested)
				if flags.isSet(flagNeedACK) {
					t.sendACK(id, address)

Note to self: catch errors here (probably ctx timeout).

Comments from Reviewable

Reviewed 6 of 6 files at r1.
Review status: all files reviewed at latest revision, 10 unresolved discussions, some commit checks failed.

go/lib/infra/messaging/messaging.go, line 33 at r1 (raw file):

	// Send a message without expecting an ACK.
	SendUnreliableMsgTo(context.Context, common.RawBytes, net.Addr) error
	// Send a message, waiting for it to be ACK'd.

The semantics here are clearly written for unreliable protocols, but unclear for reliable protocols.

go/lib/infra/messaging/types.go, line 25 at r1 (raw file):

// ackTable maps packet IDs to channels. Goroutines waiting for an ACK for a
// session ID create a channel, store it in the map at that ID and wait for the

"packet ID" vs "session ID"?

go/lib/infra/messaging/types.go, line 75 at r1 (raw file):

}

func (a uint56) putUint56(b common.RawBytes) {

This is using little-endian encoding... Had to write a test program to confirm:
0x1234567890abcd becomes cdab9078563412.

go/lib/infra/messaging/udp.go, line 106 at r1 (raw file):

// NewRUDP also spawns a background receiving goroutine that continuously reads
// from conn and keeps track of ACKs and messages.
func NewUDPTransport(conn net.PacketConn, logger log.Logger) *RUDP {

Name and comment do not match.

go/lib/infra/messaging/udp.go, line 150 at r1 (raw file):

			return nil
		case <-ctx.Done():
			// Context was canceled and we are out of time, return with failure

s/and/or/

go/lib/infra/messaging/udp.go, line 164 at r1 (raw file):
go vet says:

the cancel function returned by context.WithTimeout should be called, not discarded, to avoid a context leak

From what i can tell, i think the fix is to do:
ctx, cancel := ...
defer cancel()
return t.send(...

go/lib/infra/messaging/udp.go, line 193 at r1 (raw file):

// putHeader returns a new buffer containing the Reliable UDP header and b.
func (t *RUDP) putHeader(id uint56, flags rudpFlag, b common.RawBytes) common.RawBytes {
	packet := make(common.RawBytes, rudpHdrLen)

If you're going to copy the whole packet anyway, you might as well allocate the full length to begin with. make(common.RawBytes, rudpHdrLen, rudpHdrLen + len(b))

go/lib/infra/messaging/udp.go, line 230 at r1 (raw file):

func (t *RUDP) goBackgroundReceiver() {
	go func() {
		liblog.LogPanicAndExit()

Noo, this needs to be defer ..., otherwise it doesn't do anything.

go/lib/infra/messaging/udp.go, line 242 at r1 (raw file):

				if opErr, ok := err.(*snet.OpError); ok && opErr.SCMP() != nil {
					t.log.Warn("Received SCMP message", "msg", opErr.SCMP())
					continue

I think this is missing a freepool.Put

go/lib/infra/messaging/udp.go, line 266 at r1 (raw file):

				ackChannel, loaded := t.ackTable.Load(id)
				if !loaded {
					t.log.Warn("Received ACK, but no one is waiting fot it", "id", id)

*for

Comments from Reviewable

Review status: all files reviewed at latest revision, 10 unresolved discussions, some commit checks failed.

go/lib/infra/messaging/messaging.go, line 33 at r1 (raw file):
Previously, kormat (Stephen Shirley) wrote…
The semantics here are clearly written for unreliable protocols, but unclear for reliable protocols.

I think we still need ACKs, even for reliable protocols. E.g., for TCP, it gives a strong guarantee that the receiving host has received up to a certain sequence number, but that information is difficult to see from the sending app. For a long lived connection, you can keep sending hundreds of messages without any actually getting processed by the remote end, just because the local kernel's buffer has the space so send keeps returning.

go/lib/infra/messaging/types.go, line 25 at r1 (raw file):
Previously, kormat (Stephen Shirley) wrote…
"packet ID" vs "session ID"?

Packet ID, done.

go/lib/infra/messaging/types.go, line 75 at r1 (raw file):
Previously, kormat (Stephen Shirley) wrote…
This is using little-endian encoding... Had to write a test program to confirm:
0x1234567890abcd becomes cdab9078563412.

Whoops, you're right. Now it's always network byte order and added a docstring to say this.

go/lib/infra/messaging/udp.go, line 106 at r1 (raw file):
Previously, kormat (Stephen Shirley) wrote…
Name and comment do not match.

Done.

go/lib/infra/messaging/udp.go, line 150 at r1 (raw file):
Previously, kormat (Stephen Shirley) wrote…
s/and/or/

Done.

go/lib/infra/messaging/udp.go, line 164 at r1 (raw file):
Previously, kormat (Stephen Shirley) wrote…
go vet says:

the cancel function returned by context.WithTimeout should be called, not discarded, to avoid a context leak

From what i can tell, i think the fix is to do:
ctx, cancel := ...
defer cancel()
return t.send(...

Yes, cancel functions were missing everywhere (a lot in the test file). Added them now.

go/lib/infra/messaging/udp.go, line 193 at r1 (raw file):
Previously, kormat (Stephen Shirley) wrote…
If you're going to copy the whole packet anyway, you might as well allocate the full length to begin with. make(common.RawBytes, rudpHdrLen, rudpHdrLen + len(b))

Changed the code to use the free buffer pool.

go/lib/infra/messaging/udp.go, line 230 at r1 (raw file):
Previously, kormat (Stephen Shirley) wrote…
Noo, this needs to be defer ..., otherwise it doesn't do anything.

Ouch, right. Done.

go/lib/infra/messaging/udp.go, line 242 at r1 (raw file):
Previously, kormat (Stephen Shirley) wrote…
I think this is missing a freepool.Put

Done.

go/lib/infra/messaging/udp.go, line 266 at r1 (raw file):
Previously, kormat (Stephen Shirley) wrote…
*for

Done.

Comments from Reviewable

Reviewed 3 of 3 files at r2.
Review status: all files reviewed at latest revision, 2 unresolved discussions.

go/lib/infra/messaging/messaging.go, line 33 at r1 (raw file):
Previously, scrye (Sergiu Costea) wrote…
I think we still need ACKs, even for reliable protocols. E.g., for TCP, it gives a strong guarantee that the receiving host has received up to a certain sequence number, but that information is difficult to see from the sending app. For a long lived connection, you can keep sending hundreds of messages without any actually getting processed by the remote end, just because the local kernel's buffer has the space so send keeps returning.

The real answer, as you mentioned elsewhere, is that we need app-level ACKs. But that's a different layer. This layer is just the transport, so long as it provides retries i think that's all it needs to do, because app-level ACKs are needed regardless.
One thing that makes me a bit uncomfortable is the division of the API here. The choices for the user are:

non-blocking && unreliable
blocking && reliable
There's no way to do non-blocking && reliable (blocking && unreliable probably doesn't make sense :). This is why i had been suggesting that the caller optionally supplies a channel to be used to signal completion, so that it is in control of how this is handled.

go/lib/infra/messaging/udp.go, line 213 at r2 (raw file):

func (t *RUDP) putHeader(id uint56, flags rudpFlag, b common.RawBytes) (*freepool.Buffer, error) {
	buffer := freepool.Get()
	if rudpHdrLen+len(b) > len(buffer.B) {

Buffer should be returned.

Comments from Reviewable

Review status: 4 of 6 files reviewed at latest revision, 2 unresolved discussions.

go/lib/infra/messaging/messaging.go, line 33 at r1 (raw file):
Previously, kormat (Stephen Shirley) wrote…
The real answer, as you mentioned elsewhere, is that we need app-level ACKs. But that's a different layer. This layer is just the transport, so long as it provides retries i think that's all it needs to do, because app-level ACKs are needed regardless.
One thing that makes me a bit uncomfortable is the division of the API here. The choices for the user are:

non-blocking && unreliable
blocking && reliable
There's no way to do non-blocking && reliable (blocking && unreliable probably doesn't make sense :). This is why i had been suggesting that the caller optionally supplies a channel to be used to signal completion, so that it is in control of how this is handled.

I'm not sure we'll need another layer of ACKs on top of this messaging layer, but we'll see when we get there. RUDP provides a different feature compared to TCP, I don't think they're directly comparable.
Go's idiomatic way of doing nonblocking is to spawn a goroutine in the upper layer and have that block (I've seen a few RPC libraries work this way). The app gets full control of its inter-goroutine synchronization without propagating sync primitives down the stack (the context itself suffices for signaling, so everything is cleaner). (For us, this will be supported at the API level of the stack, the app itself doesn't need to see this).

go/lib/infra/messaging/udp.go, line 213 at r2 (raw file):
Previously, kormat (Stephen Shirley) wrote…
Buffer should be returned.

Done.

Comments from Reviewable

Review status: 4 of 6 files reviewed at latest revision, 5 unresolved discussions.

go/lib/infra/messaging/udp.go, line 106 at r2 (raw file):

// NewRUDP also spawns a background receiving goroutine that continuously reads
// from conn and keeps track of ACKs and messages.
func NewRUDP(conn net.PacketConn, logger log.Logger) *RUDP {

This should initialize nextPkdId to a random valid starting value to reduce the risk of unintended associations.

go/lib/infra/messaging/udp.go, line 304 at r3 (raw file):

				}
			default:
				t.log.Warn("Internal queue full, dropped message", "msg_len", n)

Also log the rudp header, so we can correlate packet ids.

go/lib/util/freepool/freepool.go, line 26 at r2 (raw file):

// non-neglibile (e.g., per packet processing in a router), package ringbuf (and
// manual management of free buffers) should be used instead.
package freepool

I would prefer the name bufpool

Comments from Reviewable

Review status: 4 of 6 files reviewed at latest revision, 4 unresolved discussions.

go/lib/util/freepool/freepool.go, line 26 at r2 (raw file):
Previously, shitz wrote…
I would prefer the name bufpool

:+1:

Comments from Reviewable

Reviewed 1 of 2 files at r3.
Review status: 5 of 6 files reviewed at latest revision, 4 unresolved discussions.

Comments from Reviewable

Reviewed 2 of 6 files at r1, 2 of 3 files at r2, 2 of 2 files at r3.
Review status: all files reviewed at latest revision, 4 unresolved discussions.

Comments from Reviewable

Review status: all files reviewed at latest revision, 4 unresolved discussions.

go/lib/infra/messaging/udp.go, line 106 at r2 (raw file):
Previously, shitz wrote…
This should initialize nextPkdId to a random valid starting value to reduce the risk of unintended associations.

Done.

go/lib/infra/messaging/udp.go, line 304 at r3 (raw file):
Previously, shitz wrote…
Also log the rudp header, so we can correlate packet ids.

Done.

go/lib/util/freepool/freepool.go, line 26 at r2 (raw file):
Previously, kormat (Stephen Shirley) wrote…
:+1:

Done.

Comments from Reviewable

Reviewed 1 of 2 files at r3.
Review status: 3 of 6 files reviewed at latest revision, 4 unresolved discussions.

go/lib/infra/messaging/messaging.go, line 33 at r1 (raw file):

I'm not sure we'll need another layer of ACKs on top of this messaging layer, but we'll see when we get there.

It's one of the big things we're currently missing, and it's hurting us. E.g. when you register a path segment, you don't get a response, so you can't tell if it succeeded or not. Same for querying for a path/cert/etc and the server doesn't have an answer, it just drops the query.

RUDP provides a different feature compared to TCP, I don't think they're directly comparable.

Which is why i'm not trying to compare them :P
We currently have two problems that we need to fix:
A. packets can get lost/dropped and they won't be re-sent
B. there's no response to most messages, so we can't tell if they pass the application logic even if they are delivered.
The way i see it is that this Transport interface is to fix A. Reliable protocols intrinsically take care of A in most cases, unreliable protocols don't take care of it at all. By putting ACKs into RUDP, it can then cover A (in slightly more cases than the reliable protocol's basic guarantees, but still not all cases).
Case B still needs to be handled at a higher level. This is where the RPC layer we've been planning comes in. As that is going to happen anyway, i don't see a need to try to make reliable protocols slightly more reliable by adding Transport-level ACKs to them.
[Ah, having read the updated descriptions, it seems you're taking the same approach as i had in mind anyway, so perhaps this was just a miscommunication :)]

Go's idiomatic way of doing nonblocking is to spawn a goroutine in the upper layer and have that block (I've seen a few RPC libraries work this way). The app gets full control of its inter-goroutine synchronization without propagating sync primitives down the stack (the context itself suffices for signaling, so everything is cleaner). (For us, this will be supported at the API level of the stack, the app itself doesn't need to see this).

It doesn't get full control, because non-blocking now requires spawning a goroutine, whereas with the chan method is actually has a choice. But, ok, let's go with it for now at least.

Comments from Reviewable

Reviewed 4 of 4 files at r4.
Review status: all files reviewed at latest revision, 4 unresolved discussions, some commit checks failed.

Comments from Reviewable

Review status: 5 of 6 files reviewed at latest revision, 2 unresolved discussions.

go/lib/infra/messaging/messaging.go, line 33 at r1 (raw file):

It doesn't get full control, because non-blocking now requires spawning a goroutine, whereas with the chan method is actually has a choice. But, ok, let's go with it for now at least.

The API will give it a choice, as it will expose methods for all app requirements (blocking, non-blocking, sync, async, etc.). I think the transport layer can be used to implement all of those, but we'll see later. We can change it if we need to.

Comments from Reviewable

Reviewed 1 of 1 files at r5.
Review status: all files reviewed at latest revision, 2 unresolved discussions.

Comments from Reviewable

Reviewed 3 of 4 files at r4, 1 of 1 files at r5.
Review status: all files reviewed at latest revision, 1 unresolved discussion.

Comments from Reviewable


Added GitHub Action for Pytest

In this commit, I created a GitHub Action to run our pytest scripts for the lambda unit tests.

Right now the action fails because there are no tests to run in this branch. However, when merged with the changes in #75 the action will pass since that version of the repository does include test cases.

Right now the action fails because there are no tests to run in this branch. However, when merged with the changes in #75 the action will pass since that version of the repository does include test cases.

Can you change the base branch of this PR so that it merges into #75 then?
https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/changing-the-base-branch-of-a-pull-request

Closing since these changes have now been folded in #75


[Swagger] Failed to load API definition.

address: http://localhost:8510/openapi/ui
Errors

Fetch error
NetworkError when attempting to fetch resource. http://<IP_ADDRESS>:8510/openapi/docs
Fetch error
Possible cross-origin (CORS) issue? The URL origin (http://<IP_ADDRESS>:8510) does not match the page (http://localhost:8510). Check the server returns the correct 'Access-Control-Allow-*' headers.
Fetch error
NetworkError when attempting to fetch resource. http://<IP_ADDRESS>:8510/openapi/docs
Fetch error
Possible cross-origin (CORS) issue? The URL origin (http://<IP_ADDRESS>:8510) does not match the page (http://localhost:8510). Check the server returns the correct 'Access-Control-Allow-*' headers.

ALL turms HTTP responses have the following headers:

Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: *
Access-Control-Allow-Headers: *

So CORS should not occur if a browser recognizes *.

Were you using any proxy that may remove the HTTP response headers? (You can check whether the browser gets the above HTTP response headers)
Which browser did you use? So I can do some research on it.

@JamesChenX 抱歉回复的晚了. 之前在Win11上跑的， 我切换到 linux之后可以了. 再次感谢兄


multiple arguments of the same flag

I am interested in essentially parse a vector of vector. One way I thought about doing it is to simply send in multiple values of the same flag. For example, something like
<my_binary> -v v0_0 v0_1 v0_2 -v v1_0 v1_1 v1_2
Is this possible using your parser? Thanks.

Hm good question - nope, right now with the current implementation this is not possible iirc. But just thinking about it I guess the implementation effort for this could be okayish.
HTH!


Laboratorio Cloud  📈 v0-0-1

In this update, significant improvements have been made to the codebase, addressing various syntax errors and interface glitches. We've enhanced the overall fluidity, resulting in a smoother user experience. Additionally, exciting new features have been added to the website, enriching interaction possibilities.


Retry logic update

loaded field in the API response will return false when HGS will respond with cache data.
HGS response also provides the retry time after which updated data will be available.

Merging code. Code duplication will remain as of now. This will be addressed during modularization.


Feature Request: Add the ability to choose between English Chords and Italian Chords.

It would be great if it would be possible to choose between chords in English Notation (A, B, C, D) or Italian/Latin Notation (Do, Re, Mi, Fa). It would be very useful for those who are not used to English Notation. Thanks!

Hi there, this is a super interesting idea! I've never heard of playing guitar with Italian style notes, but that might be something I'd consider adding.  I have a few practical questions though:

How do you handle special chords (think minor, suspended, add 7, etc)? For example, how would Am be translated? Or Asus or Am7?

How do you handle sharps and flats in this notation? E.g. A# or Eb.

Hi, thank you for your prompt response!
You can transliterate the following chords in this way:
A -> La
B -> Si
C -> Do
D -> Re
E -> Mi
F -> Fa
G -> Sol
For # and b it's the same as in the English notation. So for example:
A# -> La#
Eb -> Mib
Finally for chords like Am and Am7 here are the rules:
Amaj (commonly A) -> La or La+
Amin (commonly Am) -> La-
A7 (A major 7) -> La7 or La+7
Am7 (A minor 7) ->  La-7
⚠ The Asus notation is untranslatable, cause Romance Notation (also called Latin Notation) is exclusively used in piano chords, which don't usually have suspended notes.
In case of a sus chord you can "translate" it into a simple major chord. For example:
Asus -> La
Asus7 -> La7
Hope this will help you, thanks in advance for your patience and dedication. If you have any other request just ping me!

Hi thanks, that clarifies things.  I think this would be a separate feature than #66 , probably in the app preference menu.  I'll consider adding this next set of updates that I do (but it may be a while since this is a side project for me)

Hi! Thank you for considering adding this feature in the next updates of the app.
I hope to see it as soon as possible but I'm in no hurry. In fact, it'll force me to learn English notation 😉.
Have a nice day! Love from 🇮🇹

Hey by the way, if you'd be willing to help with translations I'm looking to translate the user interface into different languages.  Take a look at #113 if you're interested!

Sure! I'll translate the files as soon as possible 😉. Are the files openable on Android Studio? For me it's easier to translate the strings, cause of the Translation Editor.
Instead, what about opening a crowdin page?

Good suggestion, hadn't heard of that service before.  Here's the translator invite link: https://crowdin.com/project/tabs-lite/invite?h=2cf642473a7398656da8bc4e1b26fff62082308

Hey! I just completed the Italian Translation of the app! You can check it out on Crowdin!
Hope everything is fine... I'll wait for the next update to check that everything is correct.
If you have any suggestion/correction/question just ping me.
Have a nice day!

Related issue: in some parts of Europe, B is usually written as H, as well as some other changes. Maybe there could be a setting to change the display of these chords. A potential issue with this is, that some tabs are already written in this notation, which might cause messed up chords and confusion.
There is a table in this Wikipedia article that shows all the changes. Hope it helps!

@platinorum I created a new issue to track that suggestion: #124

          Related issue: in some parts of Europe, B is usually written as H, as well as some other changes. Maybe there could be a setting to change the display of these chords. A potential issue with this is, that some tabs are already written in this notation, which might cause messed up chords and confusion.

There is a table in this Wikipedia article that shows all the changes. Hope it helps!
Originally posted by @platinorum in https://github.com/More-Than-Solitaire/Tabs-Lite/issues/107#issuecomment-2298470337
I have two worries localizing chord names:

I wouldn't want to localize a chord name when the user didn't want that. I can't localize the tab text, so there will likely be cases where a (French for example) user wants to play a song and might prefer French UI but English chords to go with English lyrics. Also at this moment, I don't have a French localization for the rest of the UI so it would be strange to have French chords with an English UI and lyrics
Currently word wrapping is handled via monospace font and counting characters. Switching how many characters chords take will mess up spacing. This will be hard to correct for in any language that takes significantly more space since previous chords will start to run into the next chords.

The first issue can be handled by adding a manual setting rather than using localization, allowing the user to choose. The second could just be ignored (a few songs just wouldn't work correctly) or could be fixed by a more technically involved solution involving linking chords to a particular point in the next line.
Example format:
I {ch:C}heard there was a {ch:Am}secret chord
That {ch:D}David played and it {ch:Am}pleased the Lord


M4a linux issues 36

Hi @the-m4a , I am trying to run CQUI on Linux (via Proton) and noticed that nothing works - but things seem to work better once this PR is merged in!  I resolved the conflicts by just deleting the delete/conflict.
I have not yet tested all features, but without this PR nothing works.
Can we get this merged in at some point so Linux users can play too? :) Thanks!

Ok, sorry to follow up so quickly, but while this PR fixes minimap and UI elements, upgraded city view (name, production select, etc) is totally missing on the map -- you can't even click your own cities.

Yep - actually fired up my Linux VM (via windows for Linux) again last night in an attempt to get things going.  Once I get to the point where things load without error I will need actual play testers, the WSL Linux barely runs Civ so playing any more than a few turns is brutal

I volunteer to play test on Linux!  I'm very interested in getting this working - I have bare basic Lua skills (from hacking on Factorio mods) but zero Civ modding experience :)

@stevenschlansker I will publish my current working branch on Linux - I got the minimap to load, the changes are similar to what's in here but not completely.  Go over to the tracking thread and we can discuss there
https://github.com/civfanatics/CQUI_Community-Edition/issues/203

I have tested this PR on my NixOS 21.03 box and it works fine. The only issue I found was that R&F city banners don't load, however that is not an issue in Gathering Storm.


Change the SDK on target ESP8266

The reasons for the change are the following:

The communication interfaces (UART, SPI) API documentation is defective.
The usage of the provided API functions are rather complicated. For example a simple method like receiving a character from UART buffer requires  an interrupt handler implementation.
The SDK uses FreeRTOS 7.5.2 which is outdated.

To overcome these difficulties the new SDK should be used for the ESP8266 target.
The new SDK solves the mentioned issues and provides many of benefits like:

Already existing modules like FatFs, SDIO, MbedTLS, SPIFFS can be used while making a new application.
It contains a new-libc which expands the toolchain's libc provided functionalities.
The builtin LwIP module provides POSIX-like interface thereby the jerry-debugger is now available for usage.
The communication interfaces' documentation and the provided API is easy to use and embed to an apllication.
Active developer community.

Besides the SDK change this patch:

Improves the JavaScript source processing.
Adds the possibility to redirect stdout.
Allows the usage of jerry-debugger.
Separates and refactors the already existing external handlers to a modular folder structure.
Extends the usage of JERRY_CONST_DATA macro.
Attempts to follow the JerryScript coding style as where as possible

JerryScript-DCO-1.0-Signed-off-by: Robert Fancsik<EMAIL_ADDRESS>

The ESP8266 jobs fails on Travis, I'm going to fix it ASAP.

Thanks for the review. According to your comments I can agree that this PR should be splitted, especially for the consts handling. The SDK change and and the modularization quite depends on each other so I would keep them together.
So, I will close this PR and separate it based on your thoughts.

@rerobika Well, you could leave (could have left) this PR open to track the development of the SDK change and only open a new PR for the jerry-core const changes. (Reopening the PR is still possible.)


[NO-QA]: Add Card reconciliation account setting

Details
Add card reconciliation account setting
Fixed Issues
$ https://github.com/Expensify/App/issues/44315
PROPOSAL:
Tests

Enable accounting for workspace
Sync for any of products (xero, quick online, etc)
Verify that new menu item - Card reconciliation appears
Click on menu item
Verify that new empty page will be opened in the right stack

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

Offline tests

Enable accounting for workspace
Sync for any of products (xero, quick online, etc)
Verify that new menu item - Card reconciliation appears
Click on menu item
Verify that new empty page will be opened in the right stack

QA Steps

Enable accounting for workspace
Sync for any of products (xero, quick online, etc)
Verify that new menu item - Card reconciliation appears
Click on menu item
Verify that new empty page will be opened in the right stack

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

PR Author Checklist

[x] I linked the correct issue in the ### Fixed Issues section above
[x] I wrote clear testing steps that cover the changes made in this PR

[x] I added steps for local testing in the Tests section
[x] I added steps for the expected offline behavior in the Offline steps section
[x] I added steps for Staging and/or Production testing in the QA steps section
[x] I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[x] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
[x] I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).

[x] I included screenshots or videos for tests on all platforms
[x] I ran the tests on all platforms & verified they passed on:

[x] Android: Native
[x] Android: mWeb Chrome
[x] iOS: Native
[x] iOS: mWeb Safari
[x] MacOS: Chrome / Safari
[x] MacOS: Desktop

[x] I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
[x] I followed proper code patterns (see Reviewing the code)

[x] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick)
[x] I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
[x] I verified that comments were added to code that is not self explanatory
[x] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[x] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method

[x] If any non-english text was added/modified, I verified the translation was requested/reviewed in #expensify-open-source and it was approved by an internal Expensify engineer. Link to Slack message:

[x] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[x] I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is either coming verbatim from figma or has been approved by marketing (in order to get marketing approval, ask the Bug Zero team member to add the Waiting for copy label to the issue)
[x] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[x] I verified the JSDocs style guidelines (in STYLE.md) were followed

[x] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[x] I followed the guidelines as stated in the Review Guidelines
[x] I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
[x] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[x] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[x] I verified that if a function's arguments changed that all usages have also been updated correctly
[x] If any new file was added I verified that:

[x] The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory

[x] If a new CSS style is added I verified that:

[x] A similar style doesn't already exist
[x] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG))

[x] If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
[x] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[x] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[x] If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
[x] If the PR modifies the UI (e.g. new buttons, new UI components, changing the padding/spacing/sizing, moving components, etc) or modifies the form input styles:

[x] I verified that all the inputs inside a form are aligned with each other.
[x] I added Design label and/or tagged @Expensify/design so the design team can review the changes.

[x] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[x] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.

Screenshots/Videos

Android: Native

Android: mWeb Chrome

iOS: Native

iOS: mWeb Safari

MacOS: Chrome / Safari

MacOS: Desktop

Conflicts resolved. This PR also includes changes from this issue https://github.com/Expensify/App/issues/44314

I will take over this PR

@narefyev91 The Reconciliation Account Settings page is created in this PR https://github.com/Expensify/App/pull/45047 . Please merge the latest main

@narefyev91 The linked issue https://github.com/Expensify/App/issues/44315 is creating Card Reconciliation page not Card reconciliation account setting. Card reconciliation account setting is created in another PR

@DylanDylann - @narefyev91 is ooo, I'm taking over this PR

@narefyev91 The linked issue #44315 is creating Card Reconciliation page not Card reconciliation account setting. Card reconciliation account setting is created in another PR

yes, and this PR adds a correct page. There is some misunderstading with the routes - https://github.com/Expensify/App/pull/45047 this PR should actually lead to /settings/workspaces/YOUR_POLICY_ID/accounting/CONNECTION/card-reconciliation/account not to /settings/workspaces/YOUR_POLICY_ID/accounting/CONNECTION/card-reconciliation. I need to add another route (/settings/workspaces/YOUR_POLICY_ID/accounting/CONNECTION/card-reconciliation/account) and change the pages

@narefyev91 The Reconciliation Account Settings page is created in this PR #45047 . Please merge the latest main

already merged with these changes

@mountiny @DylanDylann looks like this PR should be linked to https://github.com/Expensify/App/issues/44314. The code here misses the switch and logic for this page. I just fixed the problem with routes. Maybe we can merge this one the way it is, I will take care of the Card Reconciliation Page in another PR, when I'm back (tomorrow, I'm ooo and I need to skedaddle now)

I am working on this PR. Trying to complete the checklist today

Reviewer Checklist

[ ] I have verified the author checklist is complete (all boxes are checked off).
[ ] I verified the correct issue is linked in the ### Fixed Issues section above
[ ] I verified testing steps are clear and they cover the changes made in this PR

[ ] I verified the steps for local testing are in the Tests section
[ ] I verified the steps for Staging and/or Production testing are in the QA steps section
[ ] I verified the steps cover any possible failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[ ] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)

[ ] I checked that screenshots or videos are included for tests on all platforms
[ ] I included screenshots or videos for tests on all platforms
[ ] I verified tests pass on all platforms & I tested again on:

[ ] Android: Native
[ ] Android: mWeb Chrome
[ ] iOS: Native
[ ] iOS: mWeb Safari
[ ] MacOS: Chrome / Safari
[ ] MacOS: Desktop

[ ] If there are any errors in the console that are unrelated to this PR, I either fixed them (preferred) or linked to where I reported them in Slack
[ ] I verified proper code patterns were followed (see Reviewing the code)

[ ] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick).
[ ] I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
[ ] I verified that comments were added to code that is not self explanatory
[ ] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[ ] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method
[ ] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[ ] I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is either coming verbatim from figma or has been approved by marketing (in order to get marketing approval, ask the Bug Zero team member to add the Waiting for copy label to the issue)
[ ] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[ ] I verified the JSDocs style guidelines (in STYLE.md) were followed

[ ] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[ ] I verified that this PR follows the guidelines as stated in the Review Guidelines
[ ] I verified other components that can be impacted by these changes have been tested, and I retested again (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar have been tested & I retested again)
[ ] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[ ] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[ ] If a new component is created I verified that:

[ ] A similar component doesn't exist in the codebase
[ ] All props are defined accurately and each prop has a /** comment above it */
[ ] The file is named correctly
[ ] The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
[ ] The only data being stored in the state is data necessary for rendering and nothing else
[ ] For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
[ ] Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
[ ] All JSX used for rendering exists in the render method
[ ] The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions

[ ] If any new file was added I verified that:

[ ] The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory

[ ] If a new CSS style is added I verified that:

[ ] A similar style doesn't already exist
[ ] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG)

[ ] If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
[ ] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[ ] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[ ] If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
[ ] If the PR modifies the UI (e.g. new buttons, new UI components, changing the padding/spacing/sizing, moving components, etc) or modifies the form input styles:

[ ] I verified that all the inputs inside a form are aligned with each other.
[ ] I added Design label and/or tagged @Expensify/design so the design team can review the changes.

[ ] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[ ] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.
[ ] I have checked off every checkbox in the PR reviewer checklist, including those that don't apply to this PR.

Screenshots/Videos

Android: Native

Android: mWeb Chrome

iOS: Native

iOS: mWeb Safari

MacOS: Chrome / Safari

MacOS: Desktop

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

🚀 Deployed to staging by https://github.com/mountiny in version: 9.0.7-3 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅

🚀 Cherry-picked to staging by https://github.com/thienlnam in version: 9.0.7-4 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
failure ❌

🕸 web 🕸
success ✅

@Expensify/applauseleads please QA this PR and check it off on the deploy checklist if it passes.

🚀 Deployed to production by https://github.com/thienlnam in version: 9.0.7-8 🚀

platform
result

🤖 android 🤖
failure ❌

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
failure ❌

🕸 web 🕸
success ✅

The code here misses the switch and logic for this page

@mountiny @DylanDylann the UI is done in https://github.com/Expensify/App/pull/45452

🚀 Deployed to production by https://github.com/mountiny in version: 9.0.8-6 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅


Add more content related to GJK and hpp-fcl

@jslee02 I did a mistake in the previous PR #10. Sorry for the noise

@jslee02 If you have time to review this PR, it would be greatly appreciated ;).
Thanks in advance.

This is not a noise at all! Thank you for your contribution!


DO NOT MERGE: Create Generic Launcher and add launcher for rancher-compose-executor

@ibuildthecloud @cjellick @alena1108

Now that we are going to launch multiple externalhandlers (go-machine-service, and rancher-compose-executor), I have moved the common code for launching externalhandlers into an abstract class.
I have also added a launcher for launching rancher-compose-executor in the same PR.

Please do not merge this PR yet. This can be merged after this https://github.com/rancher/cattle/pull/808 is merged

The test failure is random/unrelated


Additional HTTP clients.

Closes #51.

@alexeyOnGitHub in general case I would agree with you. But library provide out of box support for popular http clients. That's very good and of course they require maintenance. Providing large amount of implementations is flexible for users, because if they using Spring-Web then they don't need dependencies at all, same applies for Android, the Retrofit is very popular.
IMO maintenance definitely worth this flexibility.
Why do we need the AsyncTrelloHttpClient2 and AsyncTrelloHttpClient? What is difference between them?

What do you think to pull postFileForObject to the TrelloHttpClient like this:
    default <T> T postFileForObject(String url, File file, Class<T> responseType, String params) {
        throw new UnsupportedOperationException("POSTing files not supported!");
    }

and override it when necessary. The TrelloHttpClient does need the file download method as well.

@alexeyOnGitHub in general case I would agree with you. But library provide out of box support for popular http clients. That's very good and of course they require maintenance. Providing large amount of implementations is flexible for users, because if they using Spring-Web then they don't need dependencies at all, same applies for Android, the Retrofit is very popular.
IMO maintenance definitely worth this flexibility.
Why do we need the AsyncTrelloHttpClient2 and AsyncTrelloHttpClient? What is difference between them?

I don't use either of these classes, but someone wanted to contribute the "2" version which states -
"TrelloHttpClient based on the org.asynchttpclient HTTP client, the successor to the ning async http client.". speaking of clients proliferation...


[Feature request] run several instances of Windows Sandbox simultaneously on Windows

Thanks for your suggestion! We’ll review it as we prioritize future updates.

Hello, this issue is not closed at all. Can you please re-opened this ticket because this will stay a feature request and not a suggestion as long as this feature has not been fully  implemented. Thank you.

I would really appreciate this feature, to me it's quite important to be able to run programs side by side in real-time and in clean environments, Windows Sandbox is almost perfect for this. Could you please share what the technical limitations are to this feature @kavyamsft ?


Starforged Custom Oracles FoundryVTT

Project name: Starforged Custom Oracles for FoundryVTT
Project URL: https://foundryvtt.com/packages/starforged-custom-oracles

Why it's awesome
A FoundryVTT compendium of fan-created oracles for the Ironsworn: Starforged system.

Added in ea945944ed7f97ac75aeae1602c882c3a6c3efb6


Support deleting / publishing draft changes

When looking at draft changes (by using the "Status: Drafts" filter) and right-clicking on any of the drafts, the context menu shows "Abandon". However, draft changes can only be deleted, not abandoned, and trying to do so yields this error message:
Failed to abandon Gerrit change.
com.urswolfer.gerrit.client.rest.http.HttpStatusException: Request not
successful. Message: Conflict. Status-Code: 409. Content: draft changes cannot
be abandoned.

So for draft changes, please change the context menu to say "Delete" instead of "Abandon", and use the Delete Draft Change endpoint instead.

On a related note, also instead of "Submit" we should have "Publish" for draft changes.

Thanks! Looking forward to trying it out in a new release :-)

@sschuberth: I have released a release-candidate which contains these features. See #34.

@uwolfer Publishing / deleting drafts seems to work fine. The only thing I noticed is that doing so does not automatically refresh the list view to reflect the new status. Is this by intention?

@sschuberth: Right, it does not refresh after any action yet. I have created #216.


Mono docs improvements

Rename "Related Pages" heading
Remove versions.txt files

Sample docs: https://djurekdocs.z5.web.core.windows.net/mono/index.html

Did you get a chance to look into the bash commands and it's formatting (you had suggested that some tab changes might fix it)? Given it is the guidance on how to use the SDK, I think we should try to fix the getting started. It also looks like the sdk link is broken.

In the fields page (Data structures > Data Fields), we are seeing internal fields show up like az_span size:
https://djurekdocs.z5.web.core.windows.net/mono/functions.html

https://github.com/Azure/azure-sdk-for-c/blob/6932409372f234cd2a3423d85e9921fc2e7eca8e/sdk/core/core/inc/az_span.h#L32-L39
https://github.com/Azure/azure-sdk-for-c/blob/6932409372f234cd2a3423d85e9921fc2e7eca8e/sdk/core/core/inc/az_credentials.h#L86-L97

https://djurekdocs.z5.web.core.windows.net/mono/pages.html
@danewalton, @CIPop - I think these titles are starting to get a bit confusing (and repetitive)

How about changing them to these:
Azure IoT Client MQTT State Machine
Azure IoT Hub Client
Auzre IoT Device Provisioning Client
Azure IoT Clients (maybe?)

The typedef list seems incomplete. Where is az_span, az_context, json builder, etc.?
https://djurekdocs.z5.web.core.windows.net/mono/globals_type.html

https://djurekdocs.z5.web.core.windows.net/mono/md_samples__r_e_a_d_m_e.html
Looks like certain markdown things don't render well in doxygen, like bold:

Compared to https://github.com/Azure/azure-sdk-for-c/tree/master/samples

Latest docs generated from this: https://djurekdocs.z5.web.core.windows.net/mono/index.html

Filed issues:
https://github.com/Azure/azure-sdk-for-c/issues/746
https://github.com/Azure/azure-sdk-for-c/issues/748
https://github.com/Azure/azure-sdk-for-c/issues/749

Latest docs generated from this:

It doesn't look like these docs have your tab changes that fixed the ````bash` issue.


Mandatory contact - Validation

We had defined the Contact Email to be the only mandatory Contact field.  But some of the data only has a link to the code/project's Issue tracker.  When adding YAML validation in #119 we had to make the Contact Email not mandatory or the build would be failing.
The goal is to have a way to contact the project.  The issue tracker does that, if someone is there to answer.  So that seem OK.  It also mean that we could add projects even if we can't find an email contact right away.  But I would still like to encourage emails as a more direct point of contact.
Can Yamle handle mandatory Email or URL?

in my opinion I encourage you to use an email as a direct point of contact and as a mandatory field

Yeah agreed. Conditionally validating fields could get out of hand too. Between this and #121, it makes me wonder if we should have a policy about removing old projects?

in the file administrations / federal.yaml we can add the email of each organization or ministry, and use them as contact email in yaml files

Agreed!  Let's set the build validation for mandatory contact email.  The build will fail, I will look at fixing it by finding email or removing projects.
@imadeDev peux-tu faire les changements?

Agreed! Let's set the build validation for mandatory contact email. The build will fail, I will look at fixing it by finding email or removing projects.
@imadeDev peux-tu faire les changements?

ok je vais faire les changements


feat: Cypress makes screenshots, then we use argos CI to do comparison

Previously, we'd use Cypress to make screenshots and compare them to a screenshot saved in the repository.
This tactic is cumbersome since we have to remember to update the screenshots when we make a change
and it is cumbersome to see the screenshots since we have to download the artifacts from the github workflow
to see the problem.
Here, Cypress takes the screenshots and saves them to the cypress/screenshots folder. This folder is then uploaded to argos platform where they will be compared to the screenshots coming from the main branch.
Then if Argos founds an error, it will be reported on the PR as a Github check. The interesting part is that we  can then go to the failing check, see directly the screenshots in a web interface, and accept the changes if they correspond to something that we really want. This makes the workflow smoother.
See the build here for this branch: https://www.argos-ci.com/visualize-admin/visualization-tool/builds/4
I do not know why right know we have no comparison screenshots, I guess that when we merge it should be OK 🤔

Yep and there should be a check on Github.

Then you can click on details and see something like this : https://www.argos-ci.com/cozy/cozy-ui/builds/259 where the 3 images are side by side (original from main/master, your branch, and the diff).


fix(packaging): fixes packaging issue

:tada: This PR is included in version 1.37.1 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Empty-Commit

Purpose

How does the solution address the problem

Changes made

/deploy

/deploy

Failed to deploy prnet


Weird values for t_done/t_page and nt_domcomp

I'm seeing really weird values reported back to the beacon. About 90% looks just about right. But then 10% have t_done and t_page values ranging from a couple of minutes up to 10 hours. It doesn't seem to be limited to any specific browser or version. In most, but not all, such cases the nt plugin also reports high values for nt_domcomp.
 For instance, for one page view made with Mobile Safari 8 we got:
t_resp: null
t_page: 69160352
t_done: 69160352
domComplete_minus_domContentLoadedEventEnd: 9263870 (calculated value base on navigation timings reported)
t_syncPage: 685 (custom timer started in head and completed just before )
Any thoughts about what could be going on?
I should add that the site is not a single page app but does load quit a lot of things on the client, including:

ads
content fetch asynchronously, typically after onLoad
images fetch asynchronously, typically after onLoad
Often, but not always, Facebook likes count etc

When I compare with another RUM tool, Pingdom, our average numbers using Boomerang is waaaaay higher and median numbers are about 20%. However, if I exclude the 95% percentile and calculate median on the rest I get pretty much the same numbers.

Been digging into what seems to be the same issue as mentioned here and possibly also in issue
https://github.com/lognormal/boomerang/issues/35
and in issue
https://github.com/lognormal/boomerang/issues/43
Not being too familiar with the code, I hesitate to submit a patch, but I think I've located the problem.
First, my symptoms...
When a page loads, 2 beacons are fired. The first beacon has timing for the time in between (+/_) the last page load and clicking a link. So often this is several seconds or minutes, depending on how long the user waited between clicks. The first beacon also has the rt.quit flag set.
This first beacon is being fired by the unload event. But according to the notes, it should only be fired only if the user aborts the page load in some way before the page_ready fires. This beacon, however, is being fired most every time in my tests. This causes extra beacons, extra data, and large t_done times.
The line of code in question was introduced in 239bbd0a3f1c9b8b77028942c24870907ef57f8c from April 2014. Not sure if this fits everyone's timeline, or if some additional trigger in a later commit actually exposed the issue. The commit message says:
       Call done() on unload as well just in case the user left the page before …
                 the onload event fired.

       We will only send a beacon if unload fired before onload, and will include
                 a rt.abrt flag on the beacon.

But the code looks like this: (line 553 of rt.js from the most recent commit)
	if(!this.unloadfired) {
		// run done on abort or on page_unload to measure session length
		BOOMR.plugins.RT.done(edata, "unload");
	}

According to the comments, we should be checking for "this.onloadfired", rather than this.unloadfired. Switch that little "u" to an "o" and the double beacons and false timings go away in my tests.
We saw the problem in actual production code as we were testing implementation of boomerang, but the problem can easily be duplicated by simply adding an appropriate beacon URL to any of the "howto" docs pages and then refreshing it, or add it to multiple of them and click between them. Your webserver accepting the beacon, or the console logs will show the extra beacon.
Again, I'd consider submitting a patch, but it is 1 letter, and I'm not extremely comfortable with all that is going on in the code here.

Thanks, I know about the extra beacon on unload, and I have a fix for this which I'll push out soon.

Glad I asked about it first. Any idea how soon it will be pushed? Or do you have a commit number from another fork I could look at?

Just pushed it here.  In future you can have a look at my fork at bluesmoon/boomerang which is sometimes about 2 weeks ahead of this one.


Test common workflows across different instance types, cluster sizes

If a workflow is struggling, there are often a number of plausible fixes, including:

Changing chunk/partition sizes
Increasing cluster size
Choosing a bigger instance type.

We don't always have strong guidance for users about what to choose in this case. It would be good to include some tests parameterized across these dimensions to better inform coiled users. I know the @gjoseph92 has some work-in-progress towards that end, and @ntabris has expressed interest.

From my perspective, I'd love for the platform to be able to tell people how to save money running their workloads, and this data would potentially enable some of that (e.g., we can tell you taht your workload would finish faster if you used fewer, larger instances).


Rendering Issue After Using ComboBox or Tab

When using the ComboBox or Tab the UI will render like below:

I use Chrome as the browser.

I see, thanks!

All fixed.


Azure Active Directory authentication doc miss WorkloadIdentityCredential

Azure Active Directory authentication doc miss WorkloadIdentityCredential in docs/connect/ado-net/sql/azure-active-directory-authentication.md which is part of DefaultAzureCredential

You are correct that WorkloadIdentityCredential was indirectly added to the DefaultAzureCredential chain in Microsoft.Data.SqlClient 5.1.4 with the Azure.Identity dependency version bump from 1.7 to 1.10. I'll update the doc page.
Thanks,
David

I've pushed updates to this article adding WorkloadIdentityCredential (and AzureDeveloperCliCredential - another missing one) to the list. They should appear later today.
Thanks,
David
#please-close


[WIP] Fixes #3154 Filter events

First draft of enabling filtering of event callbacks to fix #3154
My goal it to provide configurable way of filtering events before they were sent. On big clusters events becomes a problem (especially deployments events with size 10MB). This leads to errors and increase events delay.
My idea is to allow user use jsonpath or some other way to get field and compare it with accepted values. Accepted values contains specific field event will be delivered if no then it will be skipped.
Pleas give me some clues if this is good idea. Maybe we should stick to event_type and do not allow more filtering but it was request in #4637 by @tobilg

here might be use cases where it would make sense to filter on field values as well, so as if an application wants to only listen to a specific applications events, such as status updates of a certain appId.

Related to: allegro/marathon-consul#139

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Thanks @janisz, just a quick question: Does the PR support both event callbacks and the event stream, or is it callbacks only?

Callbacks only. I don't believe it will be merged in nearest soon. It's quite big change involving zk migration and API change. I'll prepare another patch for SEE because it there is no persistence involved so it's easier to change.

I see, thanks for the fast feedback! I started to build an "event proxy" in Node to be able to have this filter functionality available quickly. It solely relies on SSEs, and acts as proxy between Marathon and the client applications.
The better solution would be to have this directly in Marathon I guess...

Is Ike to consider deprecating the non-sse event style. Thanks for taking this on, I'll try to review this weekend.
We've been using phabricator lately for our own reviews, feel free to give it a shot, see http://phabricator.mesosphere.com/D48 for the updated contributing docs.

This is only a draft to take thoughts and comments on way to implement it.
+1 to to deprecate http callbacks, maybe there is no point to review this

I do think we should deprecate non-SSE and only fix this in SSE style. I'll file a separate issue to deprecate non-SSE

@jasongilanfarr Closing due to https://github.com/mesosphere/marathon/issues/4675


Fix: Liqoctl Install EKS

Description
This pr fixes the installation of Liqo on EKS when using non-user credentials (e.g. when using OAuth credentials)
How Has This Been Tested?

[x] On EKS cluster with standard IAM authentication
[x] On EKS cluster with OAuth user authentication (for the liqoctl user)

/rebase test=true


az rest cmd with json body calling

Describe the bug
Describe the bug
When using a mix of PowerShell, AZ CLI, VS code with .azcli file, the az rest cmd returns the
In trying to work with Azure Cost Management's Scheduled Actions: https://learn.microsoft.com/en-us/rest/api/cost-management/scheduled-actions/create-or-update-by-scope?view=rest-cost-management-2022-10-01&tabs=HTTP
The goal was to subscribe to cost details of the Accumulated Costs View via emails but I wanted to create they programmatically vs the Azure Portal.
To reduce the number of tools and util's required, I used the "az rest" cmd to build up the payload, request and response. All the code and json object is the same but when called the Az Rest cmd it fails. PowerShell's Invoke-RestMethod is able to handle this. Details to follow.
Related command
az rest
Errors
Error:
cli.azure.cli.core.azclierror: Traceback (most recent call last):
File "D:\a_work\1\s\build_scripts\windows\artifacts\cli\Lib\site-packages\knack/cli.py", line 233, in invoke
File "D:\a_work\1\s\build_scripts\windows\artifacts\cli\Lib\site-packages\azure/cli/core/commands/init.py", line 666, in execute
File "D:\a_work\1\s\build_scripts\windows\artifacts\cli\Lib\site-packages\azure/cli/core/commands/init.py", line 733, in _run_jobs_serially
File "D:\a_work\1\s\build_scripts\windows\artifacts\cli\Lib\site-packages\azure/cli/core/commands/init.py", line 703, in _run_job
File "D:\a_work\1\s\build_scripts\windows\artifacts\cli\Lib\site-packages\azure/cli/core/commands/init.py", line 336, in call
File "D:\a_work\1\s\build_scripts\windows\artifacts\cli\Lib\site-packages\azure/cli/core/commands/command_operation.py", line 121, in handler
File "D:\a_work\1\s\build_scripts\windows\artifacts\cli\Lib\site-packages\azure/cli/command_modules/util/custom.py", line 24, in rest_call
File "D:\a_work\1\s\build_scripts\windows\artifacts\cli\Lib\site-packages\azure/cli/core/util.py", line 1010, in send_raw_request
azure.cli.core.azclierror.HTTPError: Bad Request({"error":{"code":"BadRequest","message":"Invalid property in the request. PropertyName: ","details":null}})
cli.azure.cli.core.azclierror: Bad Request({"error":{"code":"BadRequest","message":"Invalid property in the request. PropertyName: ","details":null}})
az_command_data_logger: Bad Request({"error":{"code":"BadRequest","message":"Invalid property in the request. PropertyName: ","details":null}})
cli.knack.cli: Event: Cli.PostExecute [<function AzCliLogging.deinit_cmd_metadata_logging at 0x00000284CC311EE0>]
az_command_data_logger: exit code: 1
cli.main: Command ran in 3.696 seconds (init: 0.330, invoke: 3.367)
cli.azure.cli.core.decorators: Suppress exception:
Traceback (most recent call last):
File "D:\a_work\1\s\build_scripts\windows\artifacts\cli\Lib\site-packages\azure/cli/main.py", line 53, in
File "D:\a_work\1\s\build_scripts\windows\artifacts\cli\Lib\site-packages\azure/cli/main.py", line 46, in
SystemExit: 1
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "D:\a_work\1\s\build_scripts\windows\artifacts\cli\Lib\site-packages\azure/cli/core/decorators.py", line 79, in wrapped_func
File "D:\a_work\1\s\build_scripts\windows\artifacts\cli\Lib\site-packages\azure/cli/core/telemetry.py", line 129, in generate_payload
File "json_init.py", line 238, in dumps
File "json\encoder.py", line 200, in encode
File "json\encoder.py", line 258, in iterencode
File "json\encoder.py", line 180, in default
TypeError: Object of type HTTPError is not JSON serializable
telemetry.main: Split cli events and extra events failure: the JSON object must be str, bytes or bytearray, not NoneType
Issue script & Debug output
To Reproduce:
Steps to reproduce the behavior. Note that argument values have been redacted, as they may contain sensitive information.

Install Az cli latest
Install PowerShell 7+
Install VS Code
Login to Azure with Az Login, connect to your tenant and subscription
Create a file Testfile.azcli and use the PowerShell code below, update for your scenario and specifics:

Create or update a scheduled action at Subscription level
$subscriptionName = "<subscription_name>"
$apiVersion = "2022-10-01" #Matches the version in Azure Portal calls but not the latest
$subscriptionId = (az account list --query "[?name=='$subscriptionName'].id" -o tsv)
$startDate = (Get-Date).ToString("yyyy-MM-ddT13:00:00.000Z")
$endDate = (Get-Date).AddDays(365).ToString("yyyy-MM-ddT05:00:00.000Z")
$notificationEmail = "<notify_email>"
#$toEmail = "<to_email>"
$message = "This is the weekly accumulated cost report for: $subscriptionName"
$displayName = "$subscriptionName Accumulated Costs - Weekly Report"
$subject = "$subscriptionName Accumulated Costs - Weekly Report"
$scope = "/subscriptions/$subscriptionId"
#$scheduledActionName = $displayName -replace ' ', '' -replace '[A-Z]', { $_.Value.ToLower() } #Name field
$scheduledActionName = "<testnameforscheduledAction>"
$baseUrlCreateScheduledAction = "https://management.azure.com/${scope}/providers/Microsoft.CostManagement/scheduledActions/${scheduledActionName}"
#$baseUrlCreateScheduledAction = "https://management.azure.com/providers/Microsoft.CostManagement/scheduledActions/${scheduledActionName}"
$viewId = "/subscriptions/$subscriptionId/providers/Microsoft.CostManagement/views/ms:AccumulatedCosts"
$status = "Enabled"
# Create the JSON object, PowerShell Hash
    $jsonObject = @{
        kind = "Email"
        properties = @{
            displayName = $displayName
            notification = @{
                message = $message
                subject = $subject
                to = @($toEmail)
            }
            notificationEmail = $notificationEmail
            schedule = @{
                daysOfWeek = @("Monday")
                endDate = $endDate
                frequency = "Weekly"
                startDate = $startDate
                hourOfDay = 13
            }
            fileDestination = @{
                fileFormats = @()
            }
            scope = $scope
            status = $status
            viewId = $viewId
        }
    }
    # Test the JSON object
    $jsonString = $jsonObject | ConvertTo-Json -Depth 10
    Write-Output $jsonString

**# Not Working
az rest --debug --subscription $subscriptionId --method put --url "${baseUrlCreateScheduledAction}?api-version=${apiVersion}" --headers "Content-Type=application/json" --body $jsonString**

# Make the API call using PowerShell Invoke-RestMethod with debugging - Works
    # Get the auth token using az cli
    $authToken = (az account get-access-token --query accessToken -o tsv)

    try {
        $response = Invoke-RestMethod -Uri "${baseUrlCreateScheduledAction}?api-version=${apiVersion}" -Method Put -Headers @{
            "Authorization" = "Bearer $authToken"
            "Content-Type" = "application/json"
            "Subscription" = $subscriptionId
        } -Body $jsonString -Debug -Verbose

        # Output the response as a JSON string on one line
        Write-Output "Response: $(ConvertTo-Json $response -Depth 10)"
    } catch {
        Write-Error "Error making API call: $_"
    }

Expected behavior
Az Rest would work or provide more details on why it didn't work for this scenario
Environment Summary
Windows-10-10.0.19045-SP0
Python 3.12.7
Installer: MSI
azure-cli 2.67.0
Extensions:
application-insights 1.2.2
appservice-kube 0.1.10
azure-devops 1.0.1
datafactory 1.0.2
logic 1.1.0
resource-graph 2.1.0
Dependencies:
msal 1.31.0
azure-mgmt-resource 23.1.1
Additional context

Thank you for opening this issue, we will look into it.

You are hitting the quoting issue of PowerShell where double quotes are stripped from the JSON body. Please see https://github.com/Azure/azure-cli/blob/dev/doc/quoting-issues-with-powershell.md.
I recommend using the @<file> convention to bypass PowerShell and CMD's interpretation.


Remove use of multiprocessing from the OAuth client

Why are the changes needed?
Multiprocessing in Python is a bit fraught with issues, as it requires that every dependency in the transitive dependency tree of your project supports multiprocessing. We've noticed issues with the way that this code interacts with concurrent task registration that results in trying to open multiple instances of the server, which fails due to listening on the same port.
What changes were proposed in this pull request?
The multiprocessing usage here didn't actually bring any real benefit, as the intended use was to simply block the requestor's control flow anyways with the use of a queue. This retains the same behavior without the use of any multiprocessing.
How was this patch tested?

[ ] I updated the documentation accordingly.
[ ] All new and existing tests passed.
[x] All commits are signed-off.

@rdeaton-freenome There is a linting issue: https://github.com/flyteorg/flytekit/actions/runs/10185219976/job/28174935429?pr=2626

Sorry about that linting issue, fixed in the last commit. Thanks for the quick review!

I'll just quickly note I expect we'll have a second PR in adjacent areas shortly. We're finding that there's still concurrency issues with registration with auth enabled, but we're certain multiprocessing was both exacerbating the issues and are aware of a long history of multiprocessing issues with grpcio.


Add a sequence map

Sequence map pattern for use in multi-step forms

step
Subcomponent for use in SequenceMap


[6.0] MoveOnlyAddressChecker: More robust checking for consume-during-borrow.

Explanation: Fixes a compiler crash and properly diagnoses attempts to consume the value of a variable while it's being borrowed, such as if a consume occurs in the case of a borrowing switch on the consumed variable.
Scope: Bug fix.
Issue: rdar://124360175.
Original PR: https://github.com/swiftlang/swift/pull/74707
Risk: Low. Replaces a crash-on-invalid situation with proper diagnostics.
Testing: Swift CI, test cases from bug report(s)
Reviewer: TBD

@swift-ci Please test


[Question] Multiple sites in different branches.

Can it be done? Or what would be a recommended approach for multiple sites that share the same theme, plugins, except the DB (or content.

The recommended approach would be to use a single local installation of FDK for development, and then create a Movefile with multiple environments' upload credentials, then using wordmove with the -e flag to specify the environment for each operation. In this way push theme, plugins, etc to several different independent installations.
See https://github.com/welaika/wordmove/wiki/Usage-and-flags-explained


Remove CRs only in headers

This PR does the following:

Fixes a regression where we stripped too many carriage returns.
Adds a test that verifies both this and that Wagi can run WAT files

Signed-off-by: Matt Butcher<EMAIL_ADDRESS>

In addition to the unit test, I have manually tested by:

Testing against Bartholomew's main
Testing against Bartholomew's feat/brotli
Running against the Fermyon.com website


Project page broken

https://datamart.github.io/Komito/ looks borked.

Hello @Razoxane,
Thank you very much for your comment.  This issue has been temporary fixed with da8c8cd commit.
Sincerely,
Alex K.

The new page has a mixed content error, and appears to keep attempting to reload, but never succeeds.

It seems that you are using a cached version. Please clear cache and refresh page.


[JAV-490]Fix the rest address binding logic.

If user specified the rest address as <IP_ADDRESS>, NetUtils will choose an available address as the registry rest address.

Coverage decreased (-0.007%) to 86.438% when pulling f4df279676efaf9fd4c9186a2f374a30c6b6c29b on yhs0092:restAddressRegistryFix into 871a076031e723a367ec6a907c100aa026c18171 on ServiceComb:master.


New property handlerSchema in handlerDefinition not in provider.definition.schema.v1.json

Recent updates to some CloudFormation resource schemas

AWS::NetworkManager::TransitGatewayRegistration
AWS::NimbleStudio::LaunchProfile
AWS::NimbleStudio::StreamingImage
AWS::NimbleStudio::StudioComponent

have added a new property, handlerSchema , to certain handlers, e.g.
    "list": {
      "handlerSchema": {
        "properties": {
          "GlobalNetworkId": {
            "$ref": "resource-schema.json#/properties/GlobalNetworkId"
          }
        },
        "required": ["GlobalNetworkId"]
      },
      "permissions": [
        "networkmanager:GetTransitGatewayRegistrations"
      ]
    },

This property has not been added to https://github.com/aws-cloudformation/cloudformation-resource-schema/blob/master/src/main/resources/schema/provider.definition.schema.v1.json, so validation of these resource schemas against the meta-schema are failing.

https://github.com/aws-cloudformation/cloudformation-resource-schema/pull/147


Updating picture and index.html for Hacktoberfest

Adding profile picture to img folder and including corresponding code to index.html.

@geekquad Was the "main" branch supposed to be merged here? I thought it was supposed to be the other way around, with this branch being merged into "main".

@geekquad Was the "main" branch supposed to be merged here? I thought it was supposed to be the other way around, with this branch being merged into "main".

Hey @SevilleCode, there were some conflicts that were being resolved. Those were from our end.

@geekquad Thank you! Is there anything else I need to do on my end?


Contentlayer with Notion failed on Windows

I'm using contentlayer with notion integration, and it failed on Windows with the following error:
╥
╠══╦══╗
║  ║  ║
║  ║  ╠─An interrupt was produced by #39.
║  ║  ║
║  ║  ▼
║  ║
║  ╠─An unchecked error was produced.
║  ║
║  ║ TypeError: Cannot read properties of undefined (reading 'tracer')
║  ║     at file:///C:/Users/user/g/org/project/node_modules/.pnpm/@effect-ts+system@0.57.5/node_modules/@effect-ts/system/_mjs/Effect/derive.mjs:26:60
║  ║     at IRead.f (file:///C:/Users/user/g/org/project/node_modules/.pnpm/@effect-ts+system@0.57.5/node_modules/@effect-ts/system/_mjs/Effect/has.mjs:44:44)
║  ║     at FiberContext.evaluateNow (file:///C:/Users/user/g/org/project/node_modules/.pnpm/@effect-ts+system@0.57.5/node_modules/@effect-ts/system/_mjs/Fiber/context.mjs:948:41)
║  ║     at file:///C:/Users/user/g/org/project/node_modules/.pnpm/@effect-ts+system@0.57.5/node_modules/@effect-ts/system/_mjs/Fiber/context.mjs:504:33
║  ║     at file:///C:/Users/user/g/org/project/node_modules/.pnpm/@effect-ts+system@0.57.5/node_modules/@effect-ts/system/_mjs/Support/Scheduler/index.mjs:11:22
║  ║
║  ║ Fiber: #41 (started at: 2023-06-16T08:15:53.406Z) was supposed to continue to: <empty trace>
║  ║
║  ║ Fiber: #41 (started at: 2023-06-16T08:15:53.406Z) Execution trace: <empty trace>
║  ║
║  ║ Fiber: #41 (started at: 2023-06-16T08:15:53.406Z) was spawned by:
║  ║
║  ║ Fiber: #39 (started at: 2023-06-16T08:15:53.405Z) was supposed to continue to: <empty trace>
║  ║
║  ║ Fiber: #39 (started at: 2023-06-16T08:15:53.405Z) Execution trace: <empty trace>
║  ║
║  ║ Fiber: #39 (started at: 2023-06-16T08:15:53.405Z) was spawned by:
║  ║
║  ║ Fiber: #37 (started at: 2023-06-16T08:15:53.401Z) was supposed to continue to: <empty trace>
║  ║
║  ║ Fiber: #37 (started at: 2023-06-16T08:15:53.401Z) Execution trace: <empty trace>
║  ║
║  ║ Fiber: #37 (started at: 2023-06-16T08:15:53.401Z) was spawned by:
║  ║
║  ║ Fiber: #26 (started at: 2023-06-16T08:15:53.373Z) was supposed to continue to: <empty trace>
║  ║
║  ║ Fiber: #26 (started at: 2023-06-16T08:15:53.373Z) Execution trace: <empty trace>
║  ║
║  ║ Fiber: #26 (started at: 2023-06-16T08:15:53.373Z) was spawned by:
║  ║
║  ║ Fiber: #5 (started at: 2023-06-16T08:15:49.582Z) was supposed to continue to: <empty trace>
║  ║
║  ║ Fiber: #5 (started at: 2023-06-16T08:15:49.582Z) Execution trace: <empty trace>
║  ║
║  ║ Fiber: #5 (started at: 2023-06-16T08:15:49.582Z) was spawned by:
║  ║
║  ║ Fiber: #0 (started at: 2023-06-16T08:15:49.561Z) was supposed to continue to: <empty trace>
║  ║
║  ║ Fiber: #0 (started at: 2023-06-16T08:15:49.561Z) Execution trace: <empty trace>
║  ║
║  ║ Fiber: #0 (started at: 2023-06-16T08:15:49.561Z) was spawned by: <empty trace>
║  ▼
▼

OS: win32 10.0.22621 (arch: x64)
Process: C:\Program Files\nodejs\node.exe C:\Users\user\g\org\project\node_modules\.pnpm\next@13.4.2_@opentelemetry+api@1.4.1_react-dom<EMAIL_ADDRESS>Node version: v18.16.0
Contentlayer version: 0.3.3

Here's my package.json
{
...
  "@notionhq/client": "^2.2.5",
  "contentlayer": "^0.3.3",
  "contentlayer-source-notion": "0.0.1-alpha.26",
  "date-fns": "^2.30.0",
  "next-contentlayer": "^0.3.3",
...
}

Here's contentlayer.config.ts
import { defineDatabase, makeSource } from "contentlayer-source-notion";
import { Client } from "@notionhq/client";
import { env } from "./src/env.mjs";

const notionClient = new Client({
  auth: env.NOTION_INTERNAL_INTEGRATION_SECRET,
});

export const Article = defineDatabase(() => ({
  name: "Article",
  databaseId: env.NOTION_DATABASE_ID,
  query: {
    filter: {
      property: "Status",
      status: {
        equals: "Published",
      },
    },
  },
  properties: {
    date: {
      name: "Updated On",
    },
  },
  computedFields: {
    url: {
      type: "string",
      resolve: (aritcle) => `/articles/${aritcle._id}`,
    },
  },
}));

export default makeSource({
  client: notionClient,
  databaseTypes: [Article],
});

next.config.mjs
/**
 * Run `build` or `dev` with `SKIP_ENV_VALIDATION` to skip env validation. This is especially useful
 * for Docker builds.
 */
await import("./src/env.mjs");

const { withContentlayer } = await import("next-contentlayer");

/** @type {import("next").NextConfig} */
const config = {
  reactStrictMode: true,

  /**
   * If you have `experimental: { appDir: true }` set, then you must comment the below `i18n` config
   * out.
   *
   * @see https://github.com/vercel/next.js/issues/41980
   */
  i18n: {
    locales: ["en"],
    defaultLocale: "en",
  },
};

export default withContentlayer(config);

I'm still facing this issue on Linux with next-contentlayer 0.3.4; Using "next-contentlayer": "0.3.2" seems to resolve it.


Install error on windows

When I try to compile and install Imath I get the following error message:
5>EXEC : CMake error : failed to create symbolic link 'Imath.dll': operation not permitted
5>-- Creating symlink in D:/Imath-debug/install/bin Imath.dll -> Imath-3_0.dll

Visual Studio 2017 under Windows 10 is used.
For symbolic links admin rights are obviously required. It would be better to include the symbolic links as an option.

See https://github.com/AcademySoftwareFoundation/openexr/issues/741

Closing, since #741 is resolved.

Closing, since #741 is resolved.


Fixes reading CSV files with BOM characters

Fixes https://github.com/Kotlin/dataframe/issues/687
The solution is based on https://stackoverflow.com/questions/46296827/java-spring-returning-csv-file-encoded-in-utf-8-with-bom
Passing csv reader through BOMInputStream to catch BOM characters if they exist in the file.

Code is different than that in the SO answers, is this ok?

Code is different than that in the SO answers, is this ok?

Yeah, if I had it like there, it didn't like the .reset() command. But the BOMInputStream changed in the meantime; the old constructor was deprecated, so I assume it now works like this. The test worked in any case :)


background image

Hello Zerthox!
I really like your theme Clear Vision Sapphire.
But please delete from the background is the name: Stellar Collision Kuldar Leement.
It is mixed with the button closing the Discord window
Looks like this : http://radikal.ru/fp/8zjgp6vv6imu5
Thank you in advance

add this into your custom css
[class*="titleBar-"]{     background-image: linear-gradient(#202225, #202225) !Important;     margin-top: 0px !Important;     padding-top: 4px !Important; }

Thank you for a temporary solution

Sorry, but I won't delete that. It's part of the image and if the creator decided he wanted to leave it there, I won't take an effort and photoshop it away.

Thanks for the help, I will have to use other themes.
На 24.11.2017 21:13:48, Zerthox<EMAIL_ADDRESS>писал:
Sorry, but I won't delete that. It's part of the image and if the creator decided he wanted to leave it there, I won't take an effort and photoshop it away.
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub [https://github.com/Zerthox/ClearVision/issues/57#issuecomment-346878492], or mute the thread [https://github.com/notifications/unsubscribe-auth/AfMmUnQIHent9JzZsDJMxZgo3MllaUGWks5s5wbogaJpZM4QJ6Pu].


Automatic propagation of RequestContext

One of the most complaints from the users is that they are struggling to propagate a RequestContext. Check out this snippet:
@Override
public HttpResponse serve(ServiceRequestContext ctx, HttpRequest req) throws Exception {
    backend1.execute(req).aggregate().handle((aggregatedRes, cause) -> {
        // ctx is not in the thread-local. You should use ctx.makeContextAware() or contextAwareExecutor
        backend2.execute(req)...
    });
    ...
    return res;
}

If we return a RequestContextAwareCompletebleFuture from aggregate() call, most of the situations are solved because RequestContextAwareCompletebleFuture keeps spwaning the future itself when adding callbacks.
Of course, we cannot propagate the ReqeustContext all of the cases. For example, if a user creates a new CompletableFuture instance and completes it with a value, the RequestContextAwareCompletebleFuture will stop spawning.
So he/she has to understand how the propagation works to use Armeria properly.
However, I think Automatic propagation will still reduce the burden of users who are not familiar with the asynchronous server and can lower the entry point.

@anuraaga I wanted to listen to your opinion before I go ahead because I feel you are reluctant Armeria to have this feature. 😄

However, I think Automatic propagation will still reduce the burden of users who are not familiar with the asynchronous server and can lower the entry point.

I think you know my opinion ;)
If relying on context and writing an asynchronous server, knowing how context works is a requirement - I find bandaids to be worse since the context bug will inevitably appear, but later in the lifecycle of the codebase and has an even higher chance of affecting production vs development servers. Being confused in the beginning is better than later IMO.
Also, IMO writing asynchronous code effectively basically requires a framework on top of Armeria for a reasonable sized app. I personally know Dagger makes it trivial to solve the context problem completely where it would be harder for a user to make a mistake than do the right thing. I have heard of rxjava users forgetting to subscribe correctly - perhaps enforcing use of something like ArmeriaFlux that automatically subscribes would be harder to forget. I was a little interested in seeing what approaches could help with RxJava but currently have no plans of using it so not sure if I could come up with anything but it seems like a better layer to deal with asynchronous issues than our custom CompletableFuture implementation.
Also just for reference, golang and gRPC both have context and take the approach of no automation at all (note, the Armeria context is a combination of gRPC concepts of Call and Context, only Call is automatic in gRPC). Creating and propagating context is all up to the user. This creates some tedium, and I do think automatically creating context like Armeria does is better, but I do like how it forces users to understand context before using it.
These are my opinions and some reference point, I wouldn't say no if everyone still felt automatic propagation makes sense :)

Thanks for your opinion. I do agree with most of the problems you pointed out. 😄
Let me figure it out how we handle (or don't handle) this whole context propagation things so that users can use Armeria in a better way. 😃

I prefer automatic context propagation. It will be bad if there's an inevitable pitfall that lets a user get a completely wrong context, but I guess we have fair amount of protection for that in @minwoox's recent work. :clap:
As @anuraaga pointed out, an unpropagated context can be a problem with automatic propagation because a user may have hard time finding out where the propagation stopped, but I think the convenience outweighs this problem and the tedium of explicit propagation.
Learning how a context propagates is an important matter when building a complex asynchronous application, and I agree that an automatic propagation may mislead some users to believe things will just work magically and eventually shoot themselves on their feet. However, wouldn't it still happen anyway even with explicit propagation as long as they cargo-cult makeContextAware() and not test enough? :sweat_smile:

@imasahiro @kojilin @taicki @julnamoo @hktechno @renaudb What do you think? Which would you prefer, automatic or manual context propagation?

@imasahiro @kojilin @taicki @julnamoo @techno @renaudb What do you think? Which would you prefer, automatic or manual context propagation?

and @tobias- as well.

the tedium of explicit propagation.

My point doesn't seem to have gone across - no one should explicitly propagate context. But for complex async apps, they should use something's like Kotlin, RxJava, or Dagger which have good tools for automatic propagation of context even for non-Armeria code. So understanding context is mostly just to the extent if using it properly with these tools. I think it's better for the Armeria team to focus on teaching these practices rather than creating a bandaid that pops off as soon as a user uses MySQL or Redis (most do, right? ;) )

I see where you're coming from now :smile:
But does automatic context propagation interfere with those technologies? It's still useful for simpler applications, so I think it'll be nice to have something easy to use in our sleeves for those who starts to play with Armeria.

I don't feel strongly one way or another. We've been burned by it in the past when using static CompletableFuture methods such as allOf or anyOf which won't be automated with this proposal, so we're already more careful about it.

Learning how a context propagates is an important matter when building a complex asynchronous application, and I agree that an automatic propagation may mislead some users to believe things will just work magically and eventually shoot themselves on their feet.

Thinking it is the point is understanding the context propagating rather than introducing the automatic propagation ☔

But does automatic context propagation interfere with those technologies? It's still useful for simpler applications, so I think it'll be nice to have something easy to use in our sleeves for those who starts to play with Armeria.

I worry what happens when the user starts to play, then adds in their DB call and get hurt. I'm also worried about a codebase that only uses context-awareness for non-Armeria, and the reduced reasonability of the code.
I found in #2363 that even for a very simple server, automatic propagation wouldn't work mainly due to @renaudb's good point of the static future methods not being intercepted.
Also, while probably not direct interference, I think automatic propagation would have an unecessary performance cost. I always recommend asynchronous logic to use ServiceRequestContext.contextAwareExecutor for all callbacks since not only does it keep context mounted but runs all logic on the same thread which tends to be better for performance / concurrency. And for non-Armeria callbacks, But if we automatically mounted ClientRequestContext in a client callback, then for these users they will end up remounting ServiceRequestContext on top of that, which is pretty significant performance. Even if we decided to mount ClientRequestContext.root in a client callback (not sure if this makes semantic sense when scoped to just a client), there'd still be the thread-local check + no-op.
So I think we'd need a ClientOption to control the automatic propagation if going with it, ideally opt-in. But I'm not sure I would ever recommend using the option...

Due to the limit that we cannot do it automatically in all cases, it seems like the cons heavily outweigh the pros. So let me close this and thanks all for the valuable opinions!
For the consistent APIs, let me revert the RpcResponse back to DefaultRpcResponse.

Thanks a lot for valuable feed back, folks. :bowing_man:

Sorry I didn't chip in before. I took an extended vacation during christmas/new years. For the record, my vote is with @anuraaga in that I prefer explicit propagation. The only problem with that is afaik grpc server methods, because they have a fixed signature, which afaik does not include access to any armeria-specific context. Since I write in Kotlin, I use coroutines(fibres?) extensively, but I've yet to encounter any case where I need access to that context beyond the authentication methods and access logger.
I come from the jaxrs-world, so I'm used to the magical @Context/@Inject Proxys, but haven't seen or used anything that would help propagate that context to other threads, thus more or less forcing everything related to the actual http request to be in the top-most layer or in special servlet filter-like classes that are more or less forced to be single-threaded.
@minwoox  Thanks for the ServiceRequestContext.contextAwareExecutor reference. Although magical and I don't see a use for it yet, it will fit nicely with coroutines.

@minwoox Thanks for the ServiceRequestContext.contextAwareExecutor reference.

It's not me. Thanks to @anuraaga. 😆


Login/Signup Page content not visible in dark mode

The text written on Sign Up page "Already have an account?" is not visible after the dark mode is turned on. Same issue is with Login page for the text "Don't have an account yet?".

Steps To Reproduce

Go to html file of login/signup page
Click on the paragraph tag of both the text.
Add class="font-color" to these tags.
Now Go to css file of these pages add their this code snippet -
p.font-color{
color: black;
}

The color of the texts got changed to black as i wanted and hence the text is now visible in dark mode too.

I expected the same thing to happen as i observed its current behavior.

@subhadipbhowmik sir please assign me this issue.

Hello @subhadipbhowmik,
This is Srisanth. Can I contribute to this issue? I have fixed the problem. I have made the changes you asked for.
Here is the screenshot of the updated page:

Changes Made:

Added a CSS class .dark-text in /css/custom.css.
Applied the .dark-text class to the <p> tag in the HTML file.


Display all volumes to root admin

Description
Currently only volume of User vm's are displayed in api.
Display all volumes to root admins so that its easy to see
rather than doing some sql queries
Types of changes

[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] New feature (non-breaking change which adds functionality)
[ ] Bug fix (non-breaking change which fixes an issue)
[x] Enhancement (improves an existing feature and functionality)
[ ] Cleanup (Code refactoring and cleanup, that may add test cases)

Feature/Enhancement Scale or Bug Severity
Feature/Enhancement Scale

[ ] Major
[ ] Minor

Bug Severity

[ ] BLOCKER
[ ] Critical
[ ] Major
[ ] Minor
[ ] Trivial

@blueorangutan package

@harikrishna-patnala a Jenkins job has been kicked to build packages. It will be bundled with  KVM, XenServer and VMware SystemVM templates. I'll keep you posted as I make progress.

Packaging result: :heavy_multiplication_x: el7 :heavy_multiplication_x: el8 :heavy_multiplication_x: debian :heavy_multiplication_x: suse15. SL-JID 4655

@CharlesQueiroz  this feature is already available through the parameter listSystemVms of the the listVolumes API. With the parameter set to true it will list the system VMs' volumes of the VMs created by the caller account. If the account is a Root Admin, then, it can use the parameter listAll to list all volumes, including those created by the system account.