fix(dao): created_at should not change

Summary
fix a bug that the field created_at of entity changesevery time entity are modified with PUT method via admin API, which is not expected.
Checklist

[x] The Pull Request has tests
[x] There's an entry in the CHANGELOG
[ ] There is a user-facing docs PR against https://github.com/Kong/docs.konghq.com - PUT DOCS PR HERE

Full changelog

[Implement ...]

Issue reference
FTI-1690
FTI-5108

PUT is not modification. It is same as POST but over existing entity (think about REPLACE).

The upsert on the other hand feels update OR insert. Perhaps we should have name it replace instead. Not sure.

Thanks @bungle, your explain makes sense to me, I wasn't aware of these slight differences initially.
Additionally, I talked with @raoxiaoyan who created FTI-5108, and waiting for his confirmation.

Hi @bungle , the HTTP spec states that:

9.1.2 Idempotent Methods
Methods can also have the property of "idempotence" in that (aside from error or expiration issues) the side-effects of N > 0 identical requests is the same as for a single request. The methods GET, HEAD, PUT and DELETE share this property.

If every PUT request changes the resource's created_at, it seems non-idempotent to me.

@bungle Thanks for explaining this.
Although RFC 7231 states that request initiators are allowed to change resource identifiers with PUT requests:

A successful PUT of a given representation would suggest that a subsequent GET on that same target resource will result in an equivalent representation being sent in a 200 (OK) response. However, there is no guarantee that such a state change will be observable, since the target resource might be acted upon by other user agents in parallel, or might be subject to dynamic processing by the origin server, before any subsequent GET is received.

In other words, it should allow users to move a record with a new ID. The following should be expected:
GET /record/old_id
Response: { id: "old_id" }

PUT /record/old_id
Request: { id: "new_id" }

GET /record/old_id
Response: 404

GET /record/new_id
Response: { id: "new_id" }

However, we use the collapse function in the DAO strategy implementations (e.g., the PostgreSQL one) to ensure the id field unchanged to prevent users from doing this. It also stops users from "replacing" the record as we only update other fields while keeping the old id. If we treat the ID as proof of a record's existence, then would that be reasonable to keep the created_at field since the ID is not deleted nor created during a PUT request (if the target record already exists)?
If we intend to convey the idea of replacing an entity/record with PUT requests, then should we allow users to replace the id field as well? If so, what if a user's PUT request assigns an existing ID that belongs to others to the record? Should we overwrite it without any warning (since we are replacing it)? Meanwhile, it would also introduce attack vectors since a user can replace a record that they don't have access to by using PUT on a record that they have access to (see example below).
GET /record/1
Response: { id: 1, flag: false }

GET /record/2 (No access but the record is { id: 2, flag: false })
Response: 403 Forbidden

PUT /record/1
Request: { id: 2, flag: true }

GET /record/1
Response: 404

GET /record/2 (No access but the record is changed to { id: 2, flag: true })
Response: 403 Forbidden

Hi @bungle , the HTTP spec states that:

9.1.2 Idempotent Methods
Methods can also have the property of "idempotence" in that (aside from error or expiration issues) the side-effects of N > 0 identical requests is the same as for a single request. The methods GET, HEAD, PUT and DELETE share this property.

If every PUT request changes the resource's created_at, it seems non-idempotent to me.

No, you read idempotency wrong. It means that same request should have same outcome. E.g. if your request is made at time X the created_at should be around that time. If you request is made to same entity at time Y, the created_at should reflect that.

Although RFC 7231 states that request initiators are allowed to change resource identifiers with PUT requests:

We do support that to some extend. That could be improved though.
# create by giving an id:
http put :8001/routes/17884D17-0DA4-4921-936D-35B75B3BAC39 name=doge paths=/doge -f
# change create in place (yes, we keep the id, as otherwise it can be pain as there are foreign keys and references)
http put :8001/routes/doge paths=/doge-new -f
# change the unique name
http put :8001/routes/17884D17-0DA4-4921-936D-35B75B3BAC39 name=doge-again paths=/doge-again -f

So we don't want primary key to be changed as it may cause foreign key check failures or cascades but we allow uniques to be changed. You can also move the unique with patch:
http patch :8001/routes/doge-again name=doge-new-again

A lot oof details in this space is a bit fuzzy and up to interpretation. JSON-API notably doesn't use PUT for anything.

Hi @bungle
Thank you for sharing your point of view. I have carefully considered your arguments and the relevant specifications we mentioned in this PR. Please allow me to share some thoughts
Back to the time the HTTP spec was created, the relationship between URL and the response like the file path and it's content, or parking lot and the car you mentioned. We know there's no substantial restriction between file path and file content, and any car can park at the parking lot. So the topic we discuss may go beyond the HTTP spec itself
After that, people introduce many abstract layers letting HTTP can do more things. The resource is the abstraction introduced by RESTful. Usually, people will associate an ID with a resource, and the ID should be in the URL. You see, after adding this abstraction layer, the URL has a strong restriction with the resource, they at least need to have the same ID.
Let's discuss the created_at now. Assuming the ID is bound to the resource, we may treat the ID need to have the same lifecycle as the resources, the created_at should be the time when the ID was created, not the resource content. This aligns with our intuitive understanding, imagine you have a parking lot with ID 1234-5678, when asking about the creation time of the parking lot 1234-5678, everyone will answer the creation time of the parking lot, but not the creation time of the car parking in it now.

@nekolab,
I hear your point that created_at is the property of url. But in my opinion it isn't. It is property of entity (the content). Urls don't have any properties they are just identifiers for the resource.
Think it this way:
http put :8001/plugins/test name=request-termination
http put :8001/plugins/test name=basic-auth

I feel the created_at of request-termination plugin should not be copied to basic_auth. None of the others properties are copied either (leaving the primary key aside for now).

everyone will answer the creation time of the parking lot, but not the creation time of the car parking in it now

here is another example:
someone writes an article in 1.1.2023 and that article gets url:
http://news.org/hot-news-article-today
now someone writes new article at 2.1.2023 and replaces the original:
http://news.org/hot-news-article-today
Everyone will say that first article was created in 1.1. and second was created in 2.1, even when they share the same url. So the second article didn't inherit creation time of the first.

Also think it this way:

the content is schemaless, e.g. just TEXT or JSON column where everything is but and everything is accepted (same as Redis)
sure there is identifier
but there will be no created at, perhaps some payloads have it and some don't, what would you then be inheriting?

@bungle

someone writes an article in 1.1.2023 and that article gets URL:

Aha! An exciting example that reminds me of the "Ship of Theseus" in philosophy, is that ship still the same ship after each piece of wood been replaced?
In philosophy, they argued the answer for thousands of years. But in practice, the common way is, every ship has its own unique hull number, let's say it is S-1234. In the registry, the S-1234 has its own build date, even we replaced every piece of this ship in the long river of the history, once the hull number is still S-1234, the build date is fixed and will never change. Maybe there will be a very long maintenance record in the appendix to record every piece of change, but the build date will remain still.
The counter-intuitive part of the news example is, hot-news-article-today obviously should not be treated as an identifier, like you never spray "S-WORLD-LATEST-BOAT" on the shipboard as a hull number. It is just a pointer point to the latest article.
And let's give the article a real identifier
http://news.org/hot-news-article-2023-jan or http://news.org/hot-news-article-AAAA-AAAA-AAAA-AAAA
http://news.org/hot-news-article-2023-feb or http://news.org/hot-news-article-BBBB-BBBB-BBBB-BBBB
Do you think we still should write the February news to http://news.org/hot-news-article-2023-jan and mark it created at 2023-02-01?  Even we don't want to keep the original content, we still will want to pick a new identifier because of the semantic conflict.
So what about http://news.org/hot-news-article-AAAA-AAAA-AAAA-AAAA? Yes it's possible to totally rewrite and mark it as created in 2023-02-01. But even there's no semantic conflict, in practice we will still choose another distinct ID to prevent further confustions, I believe the user wants to see rather the 404 page than the unrelated content. Looks familiar? Yes that's how we use the UUID in the URL in real world. And in real world, if you replace the whole article in Wordpress or some other content host, it will remain the create time still be add a "last edit at" mark.

I feel the created_at of request-termination plugin should not be copied to basic_auth. None of the others properties are copied either (leaving the primary key aside for now).

Let's back to our "Ship of Theseus" in the real word, a regular maintenance will ofcourse not change it's hull number, but if you replace 95% part of the whole ship IN ONE TIME, make it from an Oil Tanker to a Cruise ship, it's no doubt that the regulators will ask you to apply a new hull number. If you magically conjuring it from a ship to a plane, you must have a VIN number instead of a hull number.
So Yes! I totally agree the created_at of the request-termination plugin should not be copied from the basic-auth plugin. But I don't agree we use PUT or PATCH to make this change happen. More exaggerated, I don't agree to use PUT or PATCH to change a plugin to a route. Changing the fundamental type (which leading almost all fields been changed) but leave the identifier unmodified is really not a good idea. Like you said, the ID may have many foreigner key relationships or registered to many other components, simply change it's type in complicated system will cause disaster.
In practice, a classic production design will be: If we want provide edit feature to the plugin, we will make the plugin fundamental type readonly, which means you can neither change a plugin entity to a route entity, nor change the basic-auth to request-termination. This design make sure the only way to change the fundamental type is delete the old one and create a new one, and implicitly make sure the construct and deconstruct process of each plugin will be called correctly.
And finally, let's back to the created_at again. Do you think under the restriction I described above, shall we keep the created_at not modified after it's created?

And finally, let's back to the created_at again. Do you think under the restriction I described above, shall we keep the created_at not modified after it's created?

I don't know why we want treat created_at differently than any other property of entity. What is the real-world case for any of this?

This thing goes very far back. Long long time ago when these APIs were implemented Kong had no knowledge whether thing was created or updated. We didn't do read before write back then. So there was practically no way of copying anything.

I agree with @bungle.
Semantically, to PUT is to replace the entity; and the "creation time" should be the time the entity is created. It feels not right to replace an entity but let it be "created at an earlier time".
Idempotent is not relevant here. When we send multiple times of a PUT request, what we want is an entity to be created, and the "creation time" reflects the exact creation time of the entity we got as the result.
I think the PATCH method is what the Deck/Kong Manager actually desired to use when updating the entity.
However, if it costs for us to fix the behavior from Deck/Kong Manager's side, I don't think it's a big deal to have a non-standard semantic of PUT. Just remember to note this in the comment to remind people why we're doing this.

Thanks everyone for the healthy conversation. I agree with Aapo in general - PUT is supposed to reset any non-specified fields on the request, including created_at. Unless this is an emergency, the proper way to fix this would be to Koko to support PATCH. I have read the slack thread which originated one of our tickets and it seems they already had doubts about using PUT everywhere.
In case changing Koko (or others) to use PATCH that is unfeasible, I'd like to ask about a possible workaround: what's our current behavior if a PUT request contains created_at as one of the entity fields? Do we override created_at, or do we respect it?
If we don't, I think respecting created_at field if it was passed  would still be semantic, and it would give other teams the possibility of not having to scramble to support PATCH immediately.
@bungle would you object to changing this PR from "created_at should not change" to "created_at should be respected if it's passed"? In your carparking analogy, I think it would be similar to someone going to the guard and asking "hey, my car has been parked here since only one hour ago, but the meter says yesterday" and the guard entering his card and changing the value.

Thanks everyone for the healthy conversation. I agree with Aapo in general - PUT is supposed to reset any non-specified fields on the request to their defaults, including created_at. Unless this is an emergency, the proper way to fix this would be to Koko to support PATCH. I have read the slack thread which originated one of our tickets and it seems they already had doubts about using PUT everywhere.
In case changing Koko (or others) to use PATCH that is unfeasible, I'd like to ask about a possible workaround: what's our current behavior if a PUT request contains created_at as one of the entity fields? Do we override created_at, or do we respect it?
If we don't, I think respecting created_at field if it was passed would still be semantic, and it would give other teams the possibility of not having to scramble to support PATCH immediately.
@bungle would you object to changing this PR from "created_at should not change" to "created_at should be respected if it's passed"? In your carparking analogy, I think it would be similar to someone going to the guard and asking "hey, my car has been parked here since only one hour ago, but the meter says yesterday" and the guard entering his card and changing the value.

Just in case, do we read/keep track of the creation time when PUT for DecK, KM, and Koko?

As we choose to comply with semantic of PUT and PATCH strictly, this PR should be closed.

@liverpool8056 before closing this PR, could you please confirm wether the gateway respects created_at if it's passed on a PUT request to the admin API?

Hi @kikito , regardless of this PR,  the current logic for created_at is that kong respects created_at if it is not null.

@kikito,
http put :8001/routes/doge paths=/doge created_at=1 -f; http get :8001/routes/doge

HTTP/1.1 200 OK

{
    "created_at": 1,
    ...
}

HTTP/1.1 200 OK

{
    "created_at": 1,
    ...
}

Thank you both, closing this PR.


🌐 Add Spanish translation of Advanced User Guide - Templates

Hi there :handshake: !
This pull request include the Spanish translation of advanced/templates.md
This pull request continues with the Spanish translation of #1218

As this PR had requested changes to be applied but has been inactive for a while, it's now going to be closed. But if there's anyone interested, feel free to create a new PR.


Update for omniauth >= 2.0.0 support

I've released a fork of this gem updated to use omniauth 2.0.0 due to this CVE:
Name: omniauth
Version: 1.9.1
CVE: CVE-2015-9284
Criticality: High
URL: https://github.com/omniauth/omniauth/wiki/Resolving-CVE-2015-9284
Title: CSRF vulnerability in OmniAuth's request phase
Solution: upgrade to >= 2.0.0

https://github.com/andyw8/omniauth-pocket-oauth2
@leppert I know this repo hasn't had updates in a long time, but I can create a PR to add these changes here if you wish.

Hey @andyw8 thanks for making that. I get "Not found. Authentication passthru." when trying to log in despite adding the CSRF gem, do you know what could be causing that? This is my user stuff:
def pocket
    @user = User.from_omniauth(request.env["omniauth.auth"])
    if @user.persisted?
      sign_in_and_redirect @user, event: :authentication # this will throw if @user is not activated
      set_flash_message(:notice, :success, kind: "Pocket") if is_navigational_format?
    else
      session["devise.pocket_data"] = request.env["omniauth.auth"].except(:extra) # Removing extra as it can overflow some session stores
      redirect_to new_user_registration_url
    end

  def failure
    redirect_to root_path
  end


Setting new workspace name restrictions

Preventing workspaces to have empty or existent name
Swapped 'save' and 'clear' buttons
Save workspace on hitting Enter.

Resolves #826

Made described changes with more elegant way using build-in validators.
@ixrock Please re-review.


Presto UI high network usage

Since deploying presto to more users, we saw a decent increase on its load balancer that did not fit with results downloaded or queries ran. Upon further investigation, we found out that the the UI was downloading a ~ 5mb gzipped json payload every second.
The refresh loop on QueryList.jsx https://github.com/prestosql/presto/blob/master/presto-main/src/main/resources/webapp/src/components/QueryList.jsx#L329  hits /v1/query endpoint which returns all queries including its source code.  In our case, the raw payload was 19mb.
This does not seem like a sustainable design choice and I'd like to start a discussion on how to solve this. Some suggestions

Without a big refactor, we could simply add a timestamp filter to this endpoint and request updates only from the highest mark possible.
If a bigger refactor is desired, we could split the endpoint in two and request query status separately from the query metadata. Metadata could be pooled at a lower interval than query status and status could only be requested for non finished queries.

Theses seem like reasonable ideas.  If possible, can you join Slack (https://prestosql.io/community.html) and start a design discussion there?

Sure.

I believe this was resolved by fixing a leak in the query history.   Is this fixed for you?

@dain Yes. The root cause was the query history leak. The payload is still kinda big for a polling endpoint, but it's not harming us any more. Thanks for the quick fix.

@dain  which PR has the fix?

@tooptoop4 there were several fixes in 314, but there may be others I forgot about.  I would just upgrade.


Refactor workspace Redux state in preparation for multiple editor tabs

Description
Refactor the state of the workspace in the Redux store as such:
export type EditorTabState = {
  readonly value: string;
  readonly prependValue: string;
  readonly postpendValue: string;
  readonly highlightedLines: HighlightedLines[];
  readonly newCursorPosition?: Position;
};

export type WorkspaceState = {
  // ...
  readonly activeEditorTabIndex: number | null;
  readonly editorTabs: EditorTabState[];
  // ...
}

All state which should be tied to an editor tab instead of the workspace have been moved into EditorTabState. The WorkspaceState keeps track of an array of EditorTabStates, as well as the active editor tab index.
Note that the following properties were renamed to better fit the new EditorTabState:

editorValue -> value
editorPrepend -> prependValue
editorPostpend -> postpendValue

Strictly speaking, "postpend" should be "append", but I decided to keep the current naming to avoid adding more complexity to this PR.

All other properties in WorkspaceState should be tied to the workspace and not any individual editor tab, except for breakpoints, which will be dealt with in a follow-up PR because it is apparently unused. The removal of breakpoints will be dealt with in a separate PR so that the change will be more visible in the Git history.
Note that some instances of Partial were updated to DeepPartial. This is because Partial only makes the top-level properties of any object optional, meaning that nested properties are still required. DeepPartial from the redux library solves this issue by recursively making all nested properties optional.
Even though the shape of the workspace state has been updated, there should be no change in functionality. Currently, instances in which the first editor tab is hardcoded is marked with the following TODO:
// TODO: Hardcoded to make use of the first editor tab. Rewrite after editor tabs are added.

All instances of such TODOs will be incrementally addressed before the feature branch is merged into master.
Part of the refactoring for https://github.com/source-academy/frontend/issues/2176.
Type of change

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update
[x] Code quality improvements

How to test
There should not be any change in behaviour.

Looks like CI is failing: https://github.com/source-academy/frontend/actions/runs/3640005248/jobs/6144106133
Is this still "in progress"?

Looks like CI is failing: https://github.com/source-academy/frontend/actions/runs/3640005248/jobs/6144106133 Is this still "in progress"?

It seems that the Git pre-push hook does not type check tests vs the CI pipeline which type checks all TypeScript files:
https://github.com/source-academy/frontend/blob/91aaaffce1fd34fd10d4b5cefd0b1b7794f79a00/scripts/test.sh#L10-L18

It seems that the Git pre-push hook does not type check tests vs the CI pipeline which type checks all TypeScript files

@martin-henz Created #2266; shouldn't be too difficult a change.

Great. Thanks for looking into this.

LGTM, just pointing out some places that I think needs TODOs so as to make things easier down the line.

Thanks for catching these instances!


operator project-quay (3.12.0-nightly.20240622)

Add 3.12.0-nightly.20240622 to community operators

/merge possible

/merge possible


cmd/go: linker issue when using clang with cgo on linux

Hello,
1. What go version do I use?
go version go1.4.2 linux/amd64.
2. What operating system do I use?
alpine linux as official docker image build steps can be taken from this Dockerfile.
3. What did I do?
I want to compile a go project which uses cgo to do some work in opencv.
You can see the file which imports C.
4. What did I expect to happen?
That cgo works platform independent across unix* and between gcc and clang.
5. What happened instead?
/usr/bin/ld: -r and -shared may not be used together
clang-3.6: error: linker command failed with exit code 1 (use -v to see invocation)

6. What did I do as workaround?
I prefixed the go command with CC="" CXX="" so that go uses gcc instead of clang.
Possible related issues:

https://github.com/golang/go/issues/7800

Best Bodo

What is the output of "pkg-config opencv"?
I assume you are getting this error when you run "go build".  Can you add the output of "go build -x"?
Go is probably passing the -r option (as -Wl,-r), but I doubt it is passing the -shared option.  Go 1.4 never passes a -shared option.  We need to find out where -shared is coming from, and why.
I have no idea why GCC and clang would be behaving differently here.  The error message is from the linker, and normally on GNU/Linux both GCC and clang use the same linker.

pkg-config opencv returns nothing but

pkg-config --cflags opencv: -I/usr/local/include/opencv -I/usr/local/include
pkg-config --libs opencv: -L/usr/local/lib -lopencv_shape -lopencv_stitching -lopencv_objdetect -lopencv_superres -lopencv_videostab -lopencv_calib3d -lopencv_features2d -lopencv_highgui -lopencv_videoio -lopencv_imgcodecs -lopencv_video -lopencv_photo -lopencv_ml -lopencv_imgproc -lopencv_flann -lopencv_core -lopencv_hal

The output of go get -x github.com/bodokaiser/retina can be found here.
I don't think this relates but here was some flag difference between OS X and linux mentioned.
Also interesting a pastebin from someone else who had the same problem.

There is nothing in the way that the Go tool is invoking clang++ that should cause it to pass -shared to the linker.
Run go build -work.  That will print out a value for WORK and leave files in that directory.  Set the environment variable WORK to the value it prints out and run the failing command:
/usr/bin/clang++ -I . -fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -o $WORK/github.com/bodokaiser/retina/image/_obj/_all.o $WORK/github.com/bodokaiser/retina/image/_obj/_cgo_export.o $WORK/github.com/bodokaiser/retina/image/_obj/image.cgo2.o $WORK/github.com/bodokaiser/retina/image/_obj/image.cc.o -g -O2 -L/usr/local/lib -Wl,-r -nostdlib /usr/bin/../lib/gcc/x86_64-alpine-linux-musl/4.9.2/libgcc.a -Wl,--build-id=none
and add a -v option as well.  It should fail the same way, but should show how clang++ invoked the linker.  Show us the complete compiler output.

go build -x -v -work ./...
WORK=/tmp/go-build288906313
github.com/bodokaiser/retina/image
mkdir -p $WORK/github.com/bodokaiser/retina/image/_obj/
mkdir -p $WORK/github.com/bodokaiser/retina/
cd /srv/src/github.com/bodokaiser/retina/image
pkg-config --cflags opencv
pkg-config --libs opencv
CGO_LDFLAGS="-g" "-O2" "-L/usr/local/lib" "-lopencv_shape" "-lopencv_stitching" "-lopencv_objdetect" "-lopencv_superres" "-lopencv_videostab" "-lopencv_calib3d" "-lopencv_features2d" "-lopencv_highgui" "-lopencv_videoio" "-lopencv_imgcodecs" "-lopencv_video" "-lopencv_photo" "-lopencv_ml" "-lopencv_imgproc" "-lopencv_flann" "-lopencv_core" "-lopencv_hal" /usr/lib/go/pkg/tool/linux_amd64/cgo -objdir $WORK/github.com/bodokaiser/retina/image/_obj/ -- -I/usr/local/include/opencv -I/usr/local/include -I $WORK/github.com/bodokaiser/retina/image/_obj/ image.go
/usr/lib/go/pkg/tool/linux_amd64/6c -F -V -w -trimpath $WORK -I $WORK/github.com/bodokaiser/retina/image/_obj/ -I /usr/lib/go/pkg/linux_amd64 -o $WORK/github.com/bodokaiser/retina/image/_obj/_cgo_defun.6 -D GOOS_linux -D GOARCH_amd64 $WORK/github.com/bodokaiser/retina/image/_obj/_cgo_defun.c
/usr/bin/clang -I . -fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -print-libgcc-file-name
/usr/bin/clang -I . -fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -I/usr/local/include/opencv -I/usr/local/include -I $WORK/github.com/bodokaiser/retina/image/_obj/ -g -O2 -o $WORK/github.com/bodokaiser/retina/image/_obj/_cgo_main.o -c $WORK/github.com/bodokaiser/retina/image/_obj/_cgo_main.c
/usr/bin/clang -I . -fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -I/usr/local/include/opencv -I/usr/local/include -I $WORK/github.com/bodokaiser/retina/image/_obj/ -g -O2 -o $WORK/github.com/bodokaiser/retina/image/_obj/_cgo_export.o -c $WORK/github.com/bodokaiser/retina/image/_obj/_cgo_export.c
/usr/bin/clang -I . -fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -I/usr/local/include/opencv -I/usr/local/include -I $WORK/github.com/bodokaiser/retina/image/_obj/ -g -O2 -o $WORK/github.com/bodokaiser/retina/image/_obj/image.cgo2.o -c $WORK/github.com/bodokaiser/retina/image/_obj/image.cgo2.c
/usr/bin/clang++ -I . -fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -I/usr/local/include/opencv -I/usr/local/include -I $WORK/github.com/bodokaiser/retina/image/_obj/ -g -O2 -std=c++11 -o $WORK/github.com/bodokaiser/retina/image/_obj/image.cc.o -c ./image.cc
/usr/bin/clang++ -I . -fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -o $WORK/github.com/bodokaiser/retina/image/_obj/_cgo_.o $WORK/github.com/bodokaiser/retina/image/_obj/_cgo_main.o $WORK/github.com/bodokaiser/retina/image/_obj/_cgo_export.o $WORK/github.com/bodokaiser/retina/image/_obj/image.cgo2.o $WORK/github.com/bodokaiser/retina/image/_obj/image.cc.o -g -O2 -L/usr/local/lib -lopencv_shape -lopencv_stitching -lopencv_objdetect -lopencv_superres -lopencv_videostab -lopencv_calib3d -lopencv_features2d -lopencv_highgui -lopencv_videoio -lopencv_imgcodecs -lopencv_video -lopencv_photo -lopencv_ml -lopencv_imgproc -lopencv_flann -lopencv_core -lopencv_hal
/usr/lib/go/pkg/tool/linux_amd64/cgo -objdir $WORK/github.com/bodokaiser/retina/image/_obj/ -dynimport $WORK/github.com/bodokaiser/retina/image/_obj/_cgo_.o -dynout $WORK/github.com/bodokaiser/retina/image/_obj/_cgo_import.c
/usr/lib/go/pkg/tool/linux_amd64/6c -F -V -w -trimpath $WORK -I $WORK/github.com/bodokaiser/retina/image/_obj/ -I /usr/lib/go/pkg/linux_amd64 -o $WORK/github.com/bodokaiser/retina/image/_obj/_cgo_import.6 -D GOOS_linux -D GOARCH_amd64 $WORK/github.com/bodokaiser/retina/image/_obj/_cgo_import.c
/usr/bin/clang++ -I . -fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -o $WORK/github.com/bodokaiser/retina/image/_obj/_all.o $WORK/github.com/bodokaiser/retina/image/_obj/_cgo_export.o $WORK/github.com/bodokaiser/retina/image/_obj/image.cgo2.o $WORK/github.com/bodokaiser/retina/image/_obj/image.cc.o -g -O2 -L/usr/local/lib -Wl,-r -nostdlib /usr/bin/../lib/gcc/x86_64-alpine-linux-musl/4.9.2/libgcc.a -Wl,--build-id=none
# github.com/bodokaiser/retina/image
/usr/bin/ld: -r and -shared may not be used together
clang-3.6: error: linker command failed with exit code 1 (use -v to see invocation)

Still no -shared or -Bshareable there do you think this is a cgo issue or more a ld, clang one?

Thanks for that output, but what I need to see is the output of the final /usr/bin/clang++ line when you add the -v option to that line.  That is, please do exactly what I asked for above.  I don't need -v added to go build.  I need it added to clang++.  Thanks.

clang version 3.6.1 (tags/RELEASE_361/final)
Target: x86_64-alpine-linux-musl
Thread model: posix
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-alpine-linux-musl/4.9.2
Found candidate GCC installation: /usr/lib/gcc/x86_64-alpine-linux-musl/4.9.2
Selected GCC installation: /usr/bin/../lib/gcc/x86_64-alpine-linux-musl/4.9.2
Candidate multilib: .;@m64
Selected multilib: .;@m64
clang-3.6: error: no such file or directory: '/tmp/go-build30000/github.com/bodokaiser/retina/image/_obj/_cgo_export.o'
clang-3.6: error: no such file or directory: '/tmp/go-build30000/github.com/bodokaiser/retina/image/_obj/image.cgo2.o'

Ah, right.  Sorry.  The Go linker will create a temporary file, but it won't save it.  Bother.
OK, try creating a foo.o file from C, and run
/usr/bin/clang++ -v -I . -fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -o foo foo.o  -g -O2 -L/usr/local/lib -Wl,-r -nostdlib /usr/bin/../lib/gcc/x86_64-alpine-linux-musl/4.9.2/libgcc.a -Wl,--build-id=none

Another way to do the same is:
go build -x -ldflags "-extldflags -v" ./...

foo.c (if it matters)
#include <stdlib.h>

int main() {
	return 0;
}

/usr/bin/clang++ -v -I . -fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -o foo foo.o
-g -O2 -L/usr/local/lib -Wl,-r -nostdlib /usr/bin/../lib/gcc/x86_64-alpine-linux-musl/4.9.2/libgcc.a -Wl,--build-id=none
clang version 3.6.1 (tags/RELEASE_361/final)
Target: x86_64-alpine-linux-musl
Thread model: posix
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-alpine-linux-musl/4.9.2
Found candidate GCC installation: /usr/lib/gcc/x86_64-alpine-linux-musl/4.9.2
Selected GCC installation: /usr/bin/../lib/gcc/x86_64-alpine-linux-musl/4.9.2
Candidate multilib: .;@m64
Selected multilib: .;@m64
 "/usr/bin/ld" -pie -z relro --hash-style=gnu --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib/ld-musl-x86_64.so.1 -o foo -L/usr/local/lib -L/usr/bin/../lib/gcc/x86_64-alpine-linux-musl/4.9.2 -L/usr/bin/../lib/gcc/x86_64-alpine-linux-musl/4.9.2/../../../../x86_64-alpine-linux-musl/lib -L/usr/bin/../lib/gcc/x86_64-alpine-linux-musl/4.9.2/../../.. -L/usr/bin/../lib -L/lib -L/usr/lib foo.o -r /usr/bin/../lib/gcc/x86_64-alpine-linux-musl/4.9.2/libgcc.a --build-id=none
/usr/bin/ld: -r and -shared may not be used together
clang-3.6: error: linker command failed with exit code 1 (use -v to see invocation)

Thanks.  It's a very misleading message from the GNU linker.  The actual problem is the -pie option.  The GNU linker rejects using -pie -r.
Unfortunately the GNU linker has no way to turn off a -pie option.  So we need to arrange for clang++ to not pass -pie to the linker.  That means we need to find out why it is doing it and how to disable it.
The version of clang++ installed on my system (3.4) does not pass a -pie option.  I can't find any evidence that LLVM likes to pass -pie on systems other than Android.
Does your system have a file /usr/lib/gcc/x86_64-alpine-linux-musl/4.9.2/specs ?  If so, please add it here.
Otherwise I think we need to pass this to the LLVM developers.  Why it LLVM passing -pie?  How can we get it to stop?

vanila.spec
%include <hardenednossp.specs>
%include <hardenednopie.specs>
*esp_link_now:

*esp_link_relro:

*esp_cc1_strict_overflow:

hardenednopie.spec
*esp_cc1_pie:

*esp_options_pie:

*esp_link_pie_check:

*esp_link_pie:

hardenednopiessp.specs
%include <hardenednossp.specs>
%include <hardenednopie.specs>

hardenednossp.specs
*esp_cc1_ssp:

*esp_options_ssp:

Seems you are right that one of the specs are setting the pie option.
Am I right that the distributor of the gcc package adds the *.spec files?

I can't see the actual contents of the spec files--I think that github markdown syntax is hiding them.  Is there some way to disable markdown?
Yes, in this case, it is the distributor of GCC who is added the spec files.  GCC does not distribute spec files like this.

This is strange? Are you answering per email?
However thank you for your support! I will show this the distributor maybe this will save a good portion of time for further docker deploys :D
vanila.spec
%include <hardenednossp.specs>
%include <hardenednopie.specs>
*esp_link_now:
*esp_link_relro:
*esp_cc1_strict_overflow:
hardenednopie.spec
*esp_cc1_pie:
*esp_options_pie:
*esp_link_pie_check:
*esp_link_pie:
hardenednopiessp.specs
%include <hardenednossp.specs>
%include <hardenednopie.specs>
hardenednossp.specs
*esp_cc1_ssp:
*esp_options_ssp:

I'm not answering by e-mail, I'm looking at http://golang.org/issue/11002 and failing to see the contents of the spec files.  I just see lines like "*esp_cc1_ssp:" but nothing else.  Is that what the spec files look like?

Yes, they are just some lines of code. In the worst case you could still look it up on github

I would find it helpful to see those lines.  Where would I look on github to find them?  Thanks.

You do not use GitHub very often?
https://github.com/golang/go/issues/11002#issuecomment-107677368

I am not at all an expert user of github.  When I go to that link, which is exactly what I have been doing, I see just '*' lines and %include lines.  I do not see anything else.  I would expect to see more text, along the lines of %{!-r:-pie} or something.

If you do not see more you are expecting too much. Each of the files only had about one to five lines.
One contains some option where "pie" is a part of so I guess this is the "bad one".

Am 01.06.2015 um 22:11 schrieb Ian Lance Taylor<EMAIL_ADDRESS>I am not at all an expert user of github. When I go to that link, which is exactly what I have been doing, I see just '*' lines and %include lines. I do not see anything else. I would expect to see more text, along the lines of %{!-r:-pie} or something.
—
Reply to this email directly or view it on GitHub.

Ah, in that case, these files are not the problem.
I still don't know where the -pie option is coming from.  I agree that it must be some distro-specific patch, though.


Transition to WebP Format and Replace PNG Images with Icons #18

Pull Request: Transition to WebP Format and Replace PNG Images with Icons
Description
This pull request addresses issue #18 to enhance the project's performance and streamline image management. The key modifications include transitioning from using PNG, JPG, JPEG images to the more efficient WebP format for image assets and replacing .png images with vector icons where feasible.
Changes Made

Image Format Transition: Replaced existing .png .jpg .jpeg images with WebP images, leveraging the modern and efficient WebP format to significantly reduce file sizes and improve loading times.

Icon Integration: Where possible, .png images have been replaced with vector icons. Vector icons are highly scalable, reducing the reliance on multiple image files and contributing to efficient asset management.

Attachments:
Before:
https://github.com/Virtual4087/Tree2Hope/assets/107195487/4f2bffc3-80fb-41c1-b7c4-402367e2f645
After:
https://github.com/Virtual4087/Tree2Hope/assets/107195487/a9699889-edfc-4259-b131-f2418cf37469
Additional Notes

These changes align with the goal of optimizing the project's performance and image management.
If any further adjustments, refinements, or specific guidelines are needed, please provide your feedback. We are committed to delivering these enhancements effectively.

Closes #18

Additionally, I have added a favicon to the website as well in 898e2a176e488812c9b5e4d82e7d611e11e54d19 commit.

Additionally, for better and faster website performance on commit 280aa8db815e349462a3c601b0ade5471f2f73c3, I have optimized the code and improved file storage.


Remove unneeded blueprints folder

This project uses semver, please check the scope of this pr:

[ ] #none# - documentation fixes and/or test additions
[x] #patch# - backwards-compatible bug fix
[ ] #minor# - adding functionality in a backwards-compatible manner
[ ] #major# - incompatible API change

CHANGELOG

Remove unneeded blueprints folder that should have been removed in #522

👍


Integrate newrelic apm

Integrated Newrelic APM
Have added Newrelic license key in staging and prod env with key name INTEGRATIONS_NEWRELIC_LICENSEKEY

Merging the PR myself to deploy to staging, to verify the frequency of API calls on staging.


Integrate Recycleview into kivy

It preserves the previous garden commits. My new commits are at the end.
I did not write it up so the docs are not fully formed and following is a choppy explanation of what it does. But the code is fully functional.
I cleaned up the API with proper base and inherited classes. Also cleaned up the MVC pattern so the relationships between model/view/controller is clearly defined and things are kept separate.
The key things is that it adds a RecycleLayout class with which integrating any of the kivy layouts to be usable from rv is trivial. I already added full GridLayout and BoxLayout support and it can be used like any normal GridLayout/BoxLayout .
It also allows sizes to be computed dynamically using size_hint None and the rv will respect and update itself to use this height, even if not specified by the data originally (see the 4th rv in the example below, all the sizes are dynamically computed from texture, that's why it's a bit choppy as the layout needs to be re-computed, but it's done quite efficiently).
Still need to add:

Docs

Code Example:
from kivy.lang import Builder
from kivy.app import runTouchApp

runTouchApp(Builder.load_string('''
#:import Factory kivy.factory.Factory

<MyLabel@Label>
    size_hint: None, None
    size: self.texture_size
    padding: '25dp', '25dp'
    canvas.before:
        Color:
            rgba: .8, 0, .1, .3
        Rectangle:
            size: self.size
            pos: self.pos

<MyScrollView@ScrollView>:
    label: ''
    on_label: [g.add_widget(getattr(Factory, self.label)(text=str(i), size_hint=(None, None))) for i in range(1000)]
    GridLayout:
        id: g
        size_hint: None, None
        size: self.minimum_size
        cols: 10
        spacing: '15dp'
        padding: '55dp'

<MyRecycleView@RecycleView>:
    on_viewclass: self.data = [{'text': str(i)} for i in range(1000)]
    default_size: (100, 100)
    RecycleGridLayout:
        default_size: root.default_size
        initial_size: (50, 50)
        size_hint: None, None
        size: self.minimum_size
        cols: 10
        spacing: '15dp'
        padding: '55dp'

GridLayout:
    cols: 2
    MyScrollView:
        label: 'Label'
    MyRecycleView:
        viewclass: 'Label'
    MyScrollView:
        label: 'MyLabel'
    MyRecycleView:
        default_size: (None, None)
        viewclass: 'MyLabel'
'''))

The only thing i've changed is the factory register we discussed, kivy runs that way, but not always. :P
from kivy.config import Config
Config.set('modules', 'inspector', '')

from kivy.app import App
from kivy.uix.boxlayout import BoxLayout

class Test(BoxLayout):
    pass

class TestApp(App):
    def build(self):
        return Test()

if __name__ == '__main__':
    TestApp().run()

[ERROR             ] [Modules     ] unable to import <inspector>
Traceback (most recent call last):
  File "E:\dev\prs\kivy\kivy\modules\__init__.py", line 147, in import_module
    module = __import__(name=modname)
  File "E:\dev\prs\kivy\kivy\modules\inspector.py", line 69, in <module>
    from kivy.uix.textinput import TextInput
  File "E:\dev\prs\kivy\kivy\uix\textinput.py", line 171, in <module>
    from kivy.uix.bubble import Bubble
  File "E:\dev\prs\kivy\kivy\uix\bubble.py", line 65, in <module>
    from kivy.uix.gridlayout import GridLayout
  File "E:\dev\prs\kivy\kivy\uix\gridlayout.py", line 93, in <module>
    from kivy.uix.layout import Layout, RecycleLayout
ImportError: cannot import name 'Layout'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "E:\dev\prs\kivy\kivy\modules\__init__.py", line 151, in import_module
    module = __import__(name=name)
  File "E:\dev\prs\kivy\kivy\modules\inspector.py", line 69, in <module>
    from kivy.uix.textinput import TextInput
  File "E:\dev\prs\kivy\kivy\uix\textinput.py", line 171, in <module>
    from kivy.uix.bubble import Bubble
  File "E:\dev\prs\kivy\kivy\uix\bubble.py", line 65, in <module>
    from kivy.uix.gridlayout import GridLayout
  File "E:\dev\prs\kivy\kivy\uix\gridlayout.py", line 93, in <module>
    from kivy.uix.layout import Layout, RecycleLayout
ImportError: cannot import name 'Layout'
 Traceback (most recent call last):
   File "E:\dev\prs\kivy\kivy\modules\__init__.py", line 222, in update
     self.activate_module(name, win)
   File "E:\dev\prs\kivy\kivy\modules\__init__.py", line 179, in activate_module
     pymod = mod['module']
 KeyError: 'module'
[CRITICAL          ] [Window      ] Unable to find any valuable Window provider at all!
sdl2 - KeyError: 'module'
  File "E:\dev\prs\kivy\kivy\core\__init__.py", line 67, in core_select_lib
    cls = cls()
  File "E:\dev\prs\kivy\kivy\core\window\window_sdl2.py", line 138, in __init__
    super(WindowSDL, self).__init__()
  File "E:\dev\prs\kivy\kivy\core\window\__init__.py", line 730, in __init__
    Modules.register_window(self)
  File "E:\dev\prs\kivy\kivy\modules\__init__.py", line 205, in register_window
    self.update()
  File "E:\dev\prs\kivy\kivy\modules\__init__.py", line 222, in update
    self.activate_module(name, win)
  File "E:\dev\prs\kivy\kivy\modules\__init__.py", line 179, in activate_module
    pymod = mod['module']

 Traceback (most recent call last):
   File "E:\dev\prs\main\test2.py", line 17, in <module>
     TestApp().run()
   File "E:\dev\prs\kivy\kivy\app.py", line 810, in run
     Window.add_widget(self.root)
 AttributeError: 'NoneType' object has no attribute 'add_widget'

@dessant Probably due to https://github.com/kivy/kivy/issues/2163.

Let's test.

Updated selection. Here's a selection example:
from kivy.lang import Builder
from kivy.app import runTouchApp
from kivy.uix.recycleview.views import RecycleDataViewBehavior
from kivy.uix.recycleview.layout import LayoutSelectionBehavior
from kivy.uix.gridlayout import RecycleGridLayout
from kivy.uix.behaviors.focus import FocusBehavior
from kivy.uix.label import Label
from kivy.properties import BooleanProperty

class SelectableLabel(RecycleDataViewBehavior, Label):

    index = None  # stores our index
    selected = BooleanProperty(False)
    selectable = BooleanProperty(False)

    def refresh_view_attrs(self, rv, index, data):
        self.index = index
        return super(SelectableLabel, self).refresh_view_attrs(rv, index, data)

    def on_touch_down(self, touch):
        if super(SelectableLabel, self).on_touch_down(touch):
            return True
        if self.collide_point(*touch.pos) and self.selectable:
            return self.parent.select_with_touch(self.index, touch)

    def apply_selection(self, rv, index, is_selected):
        self.selected = is_selected

class MyRecycleGridLayout(FocusBehavior, LayoutSelectionBehavior,
                          RecycleGridLayout):

    def keyboard_on_key_down(self, *largs, **kwargs):
        if super(MyRecycleGridLayout, self).keyboard_on_key_down(*largs):
            return True
        return self.select_with_key_down(*largs)

    def keyboard_on_key_up(self, *largs, **kwargs):
        if super(MyRecycleGridLayout, self).keyboard_on_key_up(*largs):
            return True
        return self.select_with_key_up(*largs)

runTouchApp(Builder.load_string('''
#:import Factory kivy.factory.Factory

<SelectableLabel>:
    canvas.before:
        Color:
            rgba: (.8, 0, .1, .3) if self.selected else (0, 0, 0, 1)
        Rectangle:
            size: self.size
            pos: self.pos

RecycleView:
    data: [{'text': str(i), 'selectable': not i % 2} for i in range(1000)]
    viewclass: 'SelectableLabel'
    MyRecycleGridLayout:
        multiselect: True
        key_selection: 'selectable'
        size_hint: None, None
        size: self.minimum_size
        cols: 10
        spacing: '15dp'
        padding: '55dp'
'''))

RecycleBoxLayout added.
Example:
from kivy.lang import Builder
from kivy.app import runTouchApp

runTouchApp(Builder.load_string('''
#:import Factory kivy.factory.Factory

<MyLabel@Label>
    size_hint_x: None
    width: self.texture_size[0]
    padding: '25dp', '25dp'
    canvas.before:
        Color:
            rgba: .8, 0, .1, .3
        Rectangle:
            size: self.size
            pos: self.pos

<MyRecycleView@RecycleView>:
    data: [{'text': str(i)} for i in range(1000)]
    viewclass: 'MyLabel'
    RecycleBoxLayout:
        default_size: (50, 100)
        default_size_hint: (None, 1)
        initial_size: (50, 100)
        size_hint_x: None
        width: self.minimum_size[0]
        spacing: '15dp'
        padding: '55dp'

MyRecycleView
'''))

I know this might be minor, but can you yield "flat" result?
Like not doing yield len_children - i - 1, (cx, cy), (w, h) but yield len_children - i - 1, cx, cy, w, h ? It will prevent creating inner tuple for no real uses cases :)

Is there a reason to have recyclelayout-aware layout in the same file as the original layout? IMO, it might be better (for optim or packaging) to make them separated, like `from kivy.uix.recycleboxlayout import RecycleBoxLayout).

Add BoxLayout and maybe StackLayout.

-> I see boxlayout already, but this can be done in the later, better to focus and ensure the current PR is ok, with doc coming along ^^
Yeah, I added boxlayout. I will leave stack layout for now to be implemented later.
Investigate how pos_hint would be used because now it's not used within RV.

-> pos_hint in children, or the widget itself? If it's pos_hint in children, i guess it's up to the layout to deal with it?
Yeah, I had ignored it before. But now, with BoxLayouyt, I had to pay attention to pos_hint of its children so it's fully integrated.
Add Warning that it's still experimental.

+1
Not sure if the current structure of putting the corresponding rv layout version next to the normal layout version is good or if it should all be in the rv folder.

It might be better (for optim or packaging) to make them separated, like `from kivy.uix.recycleboxlayout import RecycleBoxLayout).
Yeah,. that's a good idea. It didn't occur to me.
I''l fix those things and update the first comment after.

I know this might be minor, but can you yield "flat" result?
Like not doing yield len_children - i - 1, (cx, cy), (w, h) but yield len_children - i - 1, cx, cy, w, h ? It will prevent creating inner tuple for no real uses cases :)

Yeah, I can change that to make it flat. I guess I just did it like that for visual/organizing purposes.

@tito I did those changes and split the layouts into their own files.

@matham, thank you for your work, it's a truly phantamajestic contribution. :crown:
We'll merge, notes will be added about its experimental nature and docs will be completed at a later date.

On the matham sample posted the 21 Mar, line 5
from kivy.uix.gridlayout import RecycleGridLayout
should be
from kivy.uix.recyclegridlayout import RecycleGridLayout.
Instead there is an import error.


feat: replace detox with maestro

Deleted detox from the project
Added Maestro
Added some Maestro flows like creating wallet, renaming wallet and restoring wallet
Added E2E CI that runs on every dev commit
Write docs for it: https://github.com/leather-io/mono/blob/feat/replace-detox-with-maestro/docs/e2e-tests.md

@pete-watters it's usually a better practice to use test ids instead of strings s.t.

changes to localization strings don't cause e2e test failures
tests in another locale (e.g. in Spanish) don't cause e2e test failures

I am a fan of the React Testing Library style and Kent Dodds view on testing
I think that sometimes we should use test IDs but not all the time. If there are localisation changes then using the correct ID should not cause failures?
I don't think we should have E2E tests across different locales

Hmm yea good points 🤔 I still have concerns like "what if i want to select "Save" on screen, but we might have another Save text somewhere on the screen". I'm fine with using strings for E2E tests, i just want to make sure we would need to tweak tests as little as possible

I think what you've done is excellent. I'm just throwing out some ideas as its so new we can go whatever direction that works best for us.
The YAML is so readable, it may help the tests be more like feature specs is we have some text lookups.


180 Update several bundles into monai 1.0.1

Fixes #180 and #186
Description
This PR follows #179 and #182 to update some of the remanent bundles into monai 1.0.1 version:
endoscopic_inbody_classification and endoscopic_tool_segmentation are verified by @binliunls ,
spleen_deepedit_annotation, pancreas_ct_dints_segmentation are verified by myself.
lung_nodule_ct_detection is updated without detailed check due to the size of the dataset.
For pathology_tumor_detection, as mentioned in: https://github.com/Project-MONAI/MONAI/issues/5485 in order to match monai 1.0.1, this bundle is adjusted to not support torchscript.
Status
Ready
Please ensure all the checkboxes:

[x] Codeformat tests passed locally by running ./runtests.sh --codeformat.
[ ] In-line docstrings updated.
[ ] Update version and changelog in metadata.json if changing an existing bundle.
[ ] Please ensure the naming rules in config files meet our requirements (please refer to: CONTRIBUTING.md).
[ ] Ensure versions of packages such as monai, pytorch and numpy are correct in metadata.json.
[ ] Descriptions should be consistent with the content, such as eval_metrics of the provided weights and TorchScript modules.
[ ] Files larger than 25MB are excluded and replaced by providing download links in large_file.yml.
[ ] Avoid using path that contains personal information within config files (such as use /home/your_name/ for "bundle_root").

/build

/build


Dev 16 - Added content to the Projects session

Please make sure these boxes are checked before submitting your PR, thank you!

[x] Make sure all the tests are still passing.
[x] Make sure the test coverage is still 100%.
[x] Make sure your source branch is correct.
[x] Make sure your destination branch is devel.
[x] Make sure the name of the PR has a correct DEV-# identification prefix.
[ ] Make sure you reviewed all your changes and they look correct.
[x] Make sure all the commits have a correct format.
[x] Make sure you refer related issues for you PR.
[x] Make sure you add KovDimaY as a reviewer and assignee of your PR.

Take a look at the Issue #21

Coverage remained the same at 100.0% when pulling 163f270a4fbe3a014ebac0d61f976dde4f9406ab on DEV-16 into ae2a7b201d55e1817e99a0e390c1f03a19e8f61c on devel.


LightOverlay not showing up on vanilla server

Hi,
The light overlay is not showing up on a vanilla server. Since the mod is client-side, I am under the impression that it should work okay. I am running the latest JRE. The little status thing that says "light overlay" appears in the top left corner (as I think it probably should), and I can toggle it with F7, but nothing shows up. It works as expected in singleplayer.

Update architectury, plus, your room is well lit so there aren't any crosses.

Update architectury, plus, your room is well lit so there aren't any crosses.

Apologies- I apparently misunderstood how the mod worked. I walked in here just to take the screenshot, though. It looks to be working as expected.
Thank you, sorry for the misfire.

Apologies- I apparently misunderstood how the mod worked. I walked in here just to take the screenshot, though. It looks to be working as expected.
Thank you, sorry for the misfire.

No worries, enjoy the mod!

No worries, enjoy the mod!


Make sure normalizeCSSVarsValue runs for more cases

const color = createVar('color');

const x = style({
   background: `rgba(${color}, 0.15)`,
});

Will produce this css:
.a1 {
   background: rgba(--color, 0.15);
}

Instead of this:
.a1 {
   background: rgba(var(--color), 0.15);
}

Source:
https://github.com/eagerpatch/navita/blob/main/packages/engine/src/helpers/normalizeCSSVarsValue.ts#L3
At first glance, it looks like the regex is still valid, but we need to expand the test cases, and modify or remove the if-statement that decides if we should normalize CSS var values.

@Zn4rK Although I'm just a beginner. I would like to work on this but I don't have rust on my system do I need to install it? also how do i run this on my local machine if there are any contributing guidelines do let me know :)

Hello @vinayakhegde1! Nice! You should for sure try!
To build the whole project, you'll need to have rust installed. But the @navita/engine does not require the rust package.
Right now, to not have to install the rust package, while still maintaining the correct relationship between the packages, would be to potentially use a .pnpmfile.cjs:
module.exports = {
  hooks: {
    readPackage(packageJson) {
      if (packageJson.name === '@navita/swc') {
        packageJson.version = 'latest';
      }
      return packageJson;
    },
  },
};

(This will affect the lock file incorrectly though, so dependencies would need to be re-installed before publishing, but you should be able to run it locally without having to install rust)
I'll try to compose some contributing guidelines later this week, and also think about ways to contribute without having to install rust.


Not work parameter mouse="" in /etc/vim/vimrc

Changes to /etc/vim/vimrc don't work. If I change the parameter in /usr/share/vim/vim82/defaults.vim then it is removed after vim update. The only solution is to add parameters to ~ /.vimrc for each user. It blows my mind.
:scriptnames
  1: /usr/share/vim/vimrc
  2: /usr/share/vim/vim82/syntax/syntax.vim
  3: /usr/share/vim/vim82/syntax/synload.vim
  4: /usr/share/vim/vim82/syntax/syncolor.vim
  5: /usr/share/vim/vim82/filetype.vim
  6: /usr/share/vim/vim82/colors/desert.vim
  7: /etc/vim/vimrc.local
  8: /usr/share/vim/vim82/syntax/nosyntax.vim
  9: /usr/share/vim/vim82/defaults.vim
 10: /usr/share/vim/vim82/ftplugin.vim
 11: /usr/share/vim/vim82/indent.vim
 12: /usr/share/vim/vim82/plugin/getscriptPlugin.vim
 13: /usr/share/vim/vim82/plugin/gzip.vim
 14: /usr/share/vim/vim82/plugin/logiPat.vim
 15: /usr/share/vim/vim82/plugin/manpager.vim
 16: /usr/share/vim/vim82/plugin/matchparen.vim
 17: /usr/share/vim/vim82/plugin/netrwPlugin.vim
 18: /usr/share/vim/vim82/plugin/rrhelper.vim
 19: /usr/share/vim/vim82/plugin/spellfile.vim
 20: /usr/share/vim/vim82/plugin/tarPlugin.vim
 21: /usr/share/vim/vim82/plugin/tohtml.vim
 22: /usr/share/vim/vim82/plugin/vimballPlugin.vim
 23: /usr/share/vim/vim82/plugin/zipPlugin.vim

what problem are you trying to solve? And why can't you use ~/.vimrc? Depending on your distribution, it might be possible. Debian e.g. uses /etc/vim/vimrc.local.
Also possible duplicate of #2042 #2841 #1188 and #1326

Changes to /etc/vim/vimrc don't work. If I change the parameter in /usr/share/vim/vim82/defaults.vim then it is removed after vim update. The only solution is to add parameters to ~ /.vimrc for each user. It blows my mind.

It's not a Vim bug.  There is nothing at :help initialization which suggests that /etc/vim/vimrc should be read.  Google tells me that this file can be used by package maintainers:

/etc/vim/vimrc is a system-wide default Vim configuration added by the corresponding package maintainers (e.g. the Debian folks for the vim-common APT package). It represents the opinion of the distribution's maintainers about good (and secure) defaults.

The devs have no control over how Vim is packaged on each OS (thank you for providing this information BTW).
The closest file I can think of is the one documented at :help system-vimrc.  On your system, it could be /usr/share/vim/vimrc; that's the 1st line in the output of :scriptnames that you posted.  Or maybe try /etc/vim/vimrc.local; that's the 7th line.

On your system, it could be /usr/share/vim/vimrc;

This is a symlink to /etc/vim/vimrc, since /usr/share files aren't supposed to be edited.
The problem is the unintuitive behavior of defautls.vim, as described in the issues Christian already mentioned.
The system-vimrc is where sysadmins expect to put things that apply to all users.  However, defaults.vim is loaded after that (only if the user doesn't have a ~/.vimrc) and overrides their choices.
The solution, @stm32repo, which is suggested in /etc/vim/vimrc if you're on a Debian-based system, is to source defaults.vim in the system vimrc (or vimrc.local) and then override the settings you dislike from defaults.vim.

Generally, sys admins should not force their own opinion upon their users.  Just give them the Vim defaults and don't confuse them with undocumented defaults.
If you are stubborn and want to do it anyway, the solution from James McCoy works.  So nothing to change in Vim.


Define code style standards

We should analyze if we could do something similar that we did with code conventions, but for code style standards.
That is basically taking a well known standard like Google's, and analyze the possibility of extending it (if we consider it necessary) and provide instructions for configuring the IDEs that we use in order to do the setup quickly and without problems.

We have been using Google Code Style for a while, with no extensions. Let's call that 1.0.0.


[MIRROR/DNM] Map view

Mirror of #6561, to run full CI with the map_view feature enabled.

[x] yes

@rerun-bot full-check

@rerun-bot full-check

All green but some unrelated links 🎉


Not loading with discord

Just updated to discord 0.0.14 and noticed better discord wasn't launching with discord as it launched.
I typed:
betterdiscordctl install
betterdiscordctl upgrade
betterdiscordctl update
And it still doesn't launch with the new version of discord.
I am also sad that there is no "repair" option with this.
Any help is greatly appreciated!
(I'd also like to have my plugins and stuff still exist)
System notes:
OS: Manjaro Linux (The better Arch)

Also on Manjaro, betterdiscord installed makes discord think it's running on a browser instead of the app, no betterdiscord items show up in settings either

I have this same problem on a fresh Manjaro installation.

Same issue here as well. betterdiscordctl status -s /usr/share gives the following output after being updated, yet BetterDiscord doesn't kicks in once Discord loads.
$ betterdiscordctl status -s /usr/share
Discord: /usr/share/discord
Modules: /home/herrcrazi/.config/discord/0.0.14/modules
Index modified: yes
Linked injector directory: /home/herrcrazi/.local/share/betterdiscordctl/bd/0
Linked injector repository: https://github.com/rauenzi/BetterDiscordApp

Having this same issue on Manjaro, with the same weird browser bug @huantianad is describing.

Didn't redirect to the original issue that this is a duplicate of and or help with the issue at all.
Noted*
very helpful

You didn't redirect to the original issue that this is a duplicate of and or help with the issue at all.
@ObserverOfTime
Going off of the BBD Issue label you have provided in the given labels...(next to the Duplicate label)
I don't use canary and I don't use Kali linux. I use stable.
(If that is supposed to be a redirect to the "original".  At-least give me/us a link to go to..

The cause of this and every other new issue is the same as the pinned one.

https://github.com/rauenzi/BetterDiscordApp/issues/598#issuecomment-806067616
This part seemed to work for me, in case you still havent found a solution :)

Hey Look!
Someone finally posted a link, to something that may fix my issue.
I am no longer sat here waiting for ANY kind of answer to look into.
It's almost as if they know how to answer someone properly that has an issue.
I'll look into it and thank you @QuantumABI

So far, nothing there has worked @QuantumABI
Still looking!

@QuantumABI
I found a patch and it's working now.
https://github.com/rauenzi/BetterDiscordApp/issues/598#issuecomment-807118794
This worked for me.


UI - Source link provided in knowledge tool response takes us to a new chat window.

Electron builds from commit id -  e7bb77ab
Steps to reproduce the problem:

Run the following assistant with knowledge tool and chat with it to get some response.

Name: sangeeknowledge
Type: Tool
Tools: github.com/gptscript-ai/knowledge, github.com/gptscript-ai/context/workspace
Context: dynamic-instructions
Chat: true

You are a helpful assistant that can retrieve information and answer questions using your tools. When you start just introduce yourself as Oracle and wait for the user to prompt you.
You must use the knowledge tool to look up answers to your questions. Do NOT use the read tool. You may only answer questions with information you retrieve from the knowledge tool.
Even if you've seen the question before and have the answer in your context, don't reuse the answer - go back to the knowledge tool because it's possible the information it gave you previously is out of date.
When you give answers, always give a proper citation to the best of your abilities.

Notice that there is a  source link provided in knowledge tool response.

Clicking on this link takes us to a new chat window for this assistant.

Expected Behavior:
It should open the file when source link is clicked.

I think this is the same bug as #280. Closing. If it's not a dupe, reopen


Add natural sort library

Natural sort was originally introduced in #72, but became broken at some point.
This PR fixes #551 and #486.

LGTM. Thank you @tingvold for bringing it back 😬


x1189 core—As TS (Katy), I want to upload/deal with the xenium metrics summary to Stan to pull the information into a view for reporting

"in the xenium lab menu, new operation called Xenium Metrics
Select SGP number
Scan in labware
pulls up the Region of interest already to the linked labware in STAN (as Defined in the Xenium analyser oepration), and then select the Region of interest for file upload
upload file(s)
Do not need to view metric in STAN just pulled onto the view
data to be inputed/stored in a view called Xenium Metrics
Metric summary sheet from Xenium Analyser is here
"Read CSV file, store columns and single-data-row as key/values.
Write view assuming that the rows are consistent.
The view shows all the data as if a concatenation of the data rows from each file."

metrics_summary.csv

schema change
view definition


Update options.timeout implementation

Would the project be open to a change in how the timeout logic is implemented?
Specifically, there seem to be many cases where the node-fetch timeout callback executes after a socket is assigned, but before a connection is fully established, leading to the request being aborted prior to any connection / transfer.
We think it is a reasonable interpretation of the description for this option:

req/res timeout in ms

to expect that the timer would start once a request has been sent, and end upon any of the following:

a response having been received
an application / transport layer error having occurred
the timer having expired

Aside from exposing a reference to the underlying ClientRequest instance, we believe that replacing:
https://github.com/bitinn/node-fetch/blob/745a27c38953129ce81f162b23c3d24f4a4d18f3/src/index.js#L55-L62
with a change along the lines of the following:
if (request.timeout) {
  req.once('timeout', () => {
    reject(new FetchError(`network timeout at: ${request.url}`, 'request-timeout'));
    finalize();
  });
}

would more closely align with the description of the timeout option and better serve most non-browser use cases.
We'd be happy to send a patch if the project is open to the change.
Thanks!

I would rather want AbortController to be implemented. then you can abort the request anytime you want

I don't disagree.. is support for that in progress? fwiw, here is the set of changes we'd propose if the project was open to it
https://github.com/bitinn/node-fetch/compare/master...montmanu:issues/536

#478 #437
if you like to help you can test or review those PR

Hi @montmanu, can you elaborate on this?

Specifically, there seem to be many cases where the node-fetch timeout callback executes after a socket is assigned, but before a connection is fully established, leading to the request being aborted prior to any connection / transfer.

Like a slow DNS resolution that delay the request? I consider it a part of timeout, but I can see why you might see differently.
We are closed to getting AbortSignal support done, see #539, even though it doesn't expose underlying client request, but you might find it more flexible.

hi @bitinn thanks. yeah, we're in the process of instrumenting what we can to determine where the bottleneck is, but slow DNS resolution would be my best guess. Could also be slow TLS negotiation.. really could be any point along the chain prior to the request headers being flushed. We'll follow #539 .
Thanks again!


Column widths are reset on update

When user manually resizes the column, we should stick to that setting as much as possible.
Right now, whenever the pivot table updates, the column headers are re-rendered, and any manual resizing information is forgotten.
For example: user makes query, user changes column width, user adds and applies filter, and column width is reset.
Or filter is expanded, boom, column widths get reset.
What would make sense is to reset column widths only when the columns axis itself is changed (ie. items are added / deleted)

If we would have a handler to tells us when the user manually tweaked the column width, we could store it in the column tuple.
Then on rendering we could use the width stored in the tuple.
This would allow the user to keep using their column widths until the column axis has a structural change (ie query items added or removed from the column axis)


Add support for 'near' parameter for Catalog and Health query

There is also a small fix for compilation error on Health::state call without headers.

ppconsul/health.h:127:35: error: ‘state’ cannot be used as a function
127 |             return std::move(state(withHeaders, state, params...).data());

Thank you for your contribution!


The given key was not present in the dictionary

What are you experiencing an issue with?

[ x] Aurora
[ ] Aurora supported game, (Fill in the game)
[ ] Aurora Wrapper
[ ] Aurora Profile
[ ] Aurora supported device, (Fill in problematic devices)
[ ] Aurora Scripts
[ ] Aurora Updater
[ ] Aurora Lighting issue
[ ] Other, (Fill in another issue here)

What kind of an issue is it?

[ x] Crash
[ ] Performance problems
[ ] Visual bug
[ ] Localization issue
[ ] Enhancement suggestion
[ ] Device issue
[ ] Other, (Fill in another type of issue here)

Expected behavior:
Explain here what should happen.
It should start normally
Actual behavior:
Explain here what happened instead.
It crashed when it tries to start the program
How often does this problem occur?

This problem occurs... (Fill in here)
Every time
Please describe the steps to reproduce this issue:
The issue can be reproduced by doing following steps:

Uninstall Aurora
Reinstall Aurora
Open Aurora

What is the version of Aurora you are experiencing this issue with?

My version is... (Latest verion that the latest web downloader uses as of 24.6.17)
Does the previous version of Aurora have this issue?
The previous version, (0.6.0.b), did not have this issue.
Please include any logs, screenshots, or files that are related to this issue:

https://pastebin.com/aX50DUJy
http://imgur.com/a/p7e5H
For logs, you can use: http://pastebin.com/
For screenshots, you can use: http://imgur.com/
For files, you can use: http://www.tinyupload.com/ , https://www.dropbox.com/ , or attach them to the issue.

This issue has been brought up many times. It's been fixed in the latest pre-release and you can deal with it without updating by deleting %appdata%/Aurora


In getting-started-guides, in front matter, change approvers to revie…

Partially addresses #7432.

This change is

/assign @chenopis

/lgtm


Custom provider not copied to new resources

If you set a provider on an S3 resource, it's not copied to the child S3 resources
resource "aws_s3_bucket" "bucket" {
  provider = aws.ohio
  bucket   = "mybucket"
  acl      = "private"
}

After migration:
resource "aws_s3_bucket" "bucket" {
  provider = aws.ohio
  bucket   = "mybucket"
}

resource "aws_s3_bucket_acl" "bucket" {
  bucket = aws_s3_bucket.bucket.id
  acl    = "private"
}

This will cause an error when you try and import:
│ Error: error getting S3 bucket ACL (bucket,private): AuthorizationHeaderMalformed: The authorization header is malformed; the region 'us-east-1' is wrong; expecting 'us-east-2'

@danielcompton Thank you for reporting this! Fixed in #51.


Fix tax details are empty when categorizing tracked expense

Details

Fixed Issues

$ https://github.com/Expensify/App/issues/42114
PROPOSAL: #1 here https://github.com/Expensify/App/issues/42114#issuecomment-2109928682
Tests

Same as QA

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

Offline tests

Same as QA
QA Steps

Precondition:

Workspace has enabled taxes.

Go to FAB > Track expense.
Track a manual expense.
In 1:1 DM, click Categorize from the whisper.
Select a policy with tax enabled
Select a category.
On confirmation page, click Show more and ensure default tax rate and tax amount are populated
Submit the expense
Reload and ensure tax rate and tax amount are populated
Now disabled Taxes for workspace
And repeat steps 1-5 and ensure no tax field is displayed, submit the expense and ensure user is able to submit tracked expense

[ ] 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

Start reviewing

Nice, thanks!! Let me know if you have any questions.
Alternatively, we can also discuss effectively here https://expensify.slack.com/archives/C01GTK53T8Q/p1715689873074619

@MonilBhavsar Should we close this PR in favor of https://github.com/Expensify/App/pull/42126?

Yes, let's do it 👍


Refresh token

Very nice, but it's missing the ability to refresh the token, or am I missing something?

@edewit Hi can you provide your code for refreshing token here?


Is this project later considered to support linux?

@wordhui: There's a plan about this by refactoring it with .NET 5 on Linux, please see: https://github.com/NickeManarin/ScreenToGif/issues/579

Perhaps with .NET MAUI once it's released and Linux support is added.

Perhaps with .NET MAUI once it's released and linux support is added.


expand DE yes no alternatives

Have to sleep over it, maybe rearrange (esp. bc those double negatives) and add some Tests

Have to sleep over it, maybe rearrange (esp. bc those double negatives) and add some Tests

please add tests for the use cases this is covering, being your native language you are the authority, we can only review tests and trust you on the language side

generally hard to compute sarcasm/irony.
additionally we usually prefix like "not impossible" (ie. un-*)
The question should be clear cut on the skill side

Mabe we should allow a dict to be passed and merged with the default, so we can assure better contextual accuracy.
We could use the  data  that is already part of the signature


openstack-ardana-gerrit: enable Cloud 9 builds

Make the repository name configurable, so that the
openstack-ardana-gerrit job can be used to test
patches against the cloud 9 media.

Rebased

Tested with: https://ci.suse.de/job/openstack-ardana-snica/15


Add a Windows Explorer Preview Handler for associated file types

Currently you can't preview vs-code associated file types in Windows Explorer's Preview pane, it just says no preview available.
https://docs.microsoft.com/en-us/windows/desktop/shell/preview-handlers

@deepak1556 does electron support this?

@sbatten its not supported at the moment, but seems like something we could add via a node native module.

Having a simple text preview like notepad would already help a lot. It just needs to properly handle encoding and line endings. I won't even ask for syntax highlighting, etc.
Although I think that formatted Markdown preview would be a nice thing to have.

Any ideas one how it can be optimized for performance? The vscode instance it launches for the preview should be lightweight as possible while supporting particular extensions, such as syntax highlighting for additional languages. Perhaps all extensions should be disabled in preview mode by default, with a setting allowing the user to specify extensions to be enabled in preview mode?

Any ideas on how it can be optimized for performance?

Well, complete syntax highlighting would be overkill for me, so if it's done, it should be limited to lexicon (token-only) highlighting (typically doable with just regex). As long as it's done properly, of course. I've seen some sites do this poorly, with things like highlighting keywords inside strings or comment blocks.

Perhaps all extensions should be disabled in preview mode by default, with a setting allowing the user to specify extensions to be enabled in preview mode?

I like this idea.
Also, there should be a way to disable the feature for specific file types, to use the external preview.

If you go for the full, ideal implementation, previews should let you switch between views as applicable:

Text view, with at least:

encoding auto-detected
line wrapping
ability to copy text
tab size selection (by default the user setting)
line numbers
lexicon highlighting?
search feature?
use theme?

Structure view, mostly for types like JSON, XML, HTML, YAML - essentially the outline (tree) view.
Rendered view, for types like SVG, Markdown, HTML.

This presumably could enable VS Code as a previewer within Outlook as well?
Seemingly most recent updated previewer for any code is one from 2006/2010, that has long since been abandoned since CodePlex days:
https://archive.codeplex.com/?p=previewhandlers

If this ever gets picked up, would be nice to have following option:

Format/Beautify (and button to revert back to original)

Selectable language if not enough context.

Use case in particular when receiving JSON/XML file in email, would love to be able to preview them within Outlook.


Provide option for cleaning up files that PipReport produces

It appears that the pip install command that runs during PipReport will produce some artifacts that are not cleaned up at the end of the run. Some examples of these:

.egg-info/ directories https://setuptools.pypa.io/en/latest/deprecated/python_eggs.html#eggs-and-their-formats
.egg files
__pycache__/ directories https://pip.pypa.io/en/stable/topics/caching/

It would be valuable for some customers to have the option to remove all files that are produced, leaving the source as it was found.

fixed with https://github.com/microsoft/component-detection/pull/1259


feat: change cloudformation file to support arm architecture

Description
I updated the cloudformation file to support ARM architectures as well.
I updated the Ubuntu images from 20.04 to 22.04 LTS.
I had to change the python easy_install to pip3 because the easy_install version is not working on the newer Ubuntu version.
Type of Change
[ ] Bug Fix
[x] New Feature
[ ] Breaking Change
[ ] Refactor
[ ] Documentation
[ ] Other (please describe)
Checklist

[x] I have read the contributing guidelines
[x] Existing issues have been referenced (where applicable)
[x] I have verified this change is not present in other open pull requests
[x] Functionality is documented
[x] All code style checks pass
[x] New code contribution is covered by automated tests
[x] All new and existing tests pass

Hey @adamtagscherer would you mind splitting the ubuntu base image bump out of this change, I think that'll be a worthwhile thing to review and merge by itself

Hey @adamtagscherer would you mind splitting the ubuntu base image bump out of this change, I think that'll be a worthwhile thing to review and merge by itself

@sambetts-cisco We have to update the Ubuntu 22.04 LTS as easy_install is not available on 20.04 LTS for arm and pip also has bugs preventing us easy install the cfn tools.

Hey @adamtagscherer would you mind splitting the ubuntu base image bump out of this change, I think that'll be a worthwhile thing to review and merge by itself

@sambetts-cisco We have to update the Ubuntu 22.04 LTS as easy_install is not available on 20.04 LTS for arm and pip also has bugs preventing us easy install the cfn tools.

Right I read the description, I was suggesting moving the 22.04 and cfn tool install out into a separate PR which can be merged first without the addition of the ARM ami's and bumping all the dependent components to keep the scope of the change to specifically adding the ARM architecture.

This PR has also prompted my memory that we need to move the VMClarity DB into a volume, because if the AMI for the VMClarity Server changes, the VM is replaced and today all the data will go with it.

@sambetts-cisco I removed the ARM64 AMI images and the other control plane element version bumps.
Only the Ubuntu 22.04LTS upgrade and the AMD64 AMI images remained in this PR.

@sambetts-cisco I removed the ARM64 AMI images and the other control plane element version bumps. Only the Ubuntu 22.04LTS upgrade and the AMD64 AMI images remained in this PR.

Looks great, thats @adamtagscherer, please update PR header and description to reflect to clean up, and then please open a new PR with the ARM additions.

I updated the header and description.
I will open the ARM PR after this gets merged.


How would you declare a 'mixin' using glamor?

Say I have a project with a lot of different (Sass) mixins. Each mixin serves one or more of these purposes:

limit the options for certain css values
use mappings to turn a 'simple parameter' into a set of css properties that belong together
standardize a certain look and feel across components

Some of these mixins might look something like this:
@mixin mixinWithParameter ($size) {
  font-size: $size;
  line-height: $size * 2;
}
@mixin mixinWithoutParameter () {
  font-family: sans-serif;
}
some-element {
  @include mixinWithParameter(16px);
  @include mixinWithoutParameter();
  color: blue;
}

How would you use style() and/or merge() to declare and use these mixins as inline styles?
How would you ensure the least amount of duplicate rules are generated?

haven't tested, but this should work.
let mixinWithParameter = size => ({ fontSize: size, lineHeight: size*2 })
let mixinWithoutParameter = { fontFamily: sans-serif } // don't need function here!

let rule = merge(mixinWithParameter(16), mixinWithoutParameter, { color: blue })
// merge accepts regular objects, so we can avoid allocating intermediate css rules. win!

the above should result in just one rule being added to the styleSheet.

Thanks for reacting so quickly. :)
Yeah that implementation seems very similar to what I've been experimenting with. But the problem arises when I would like to reuse those mixins between different components.
If I create a 'rule' like in your example for every component that uses those 'mixins', Glamor will add a separate rule to the styleSheet for each invocation, resulting in a lot of duplicate styles.
Especially for mixins like the 'mixinWithoutParameter', it would be very nice to have those properties 'cached' somehow to prevent duplicating them.
And for mixins with parameters, some sort of input memoization could also create a set of 'cached' rules minimizing duplicate styles as well. But that's probably trickier to implement and would require a 'mixin' method from Glamor so it can do the input memoization.
Or am I thinking in the wrong direction here?
I was kind of hoping something like this would prevent duplicated styles:
const mixinWithoutParameter = style({ fontFamily: sans-serif });

let ruleForComponentA = merge(mixinWithoutParameter, { color: blue });
let ruleForComponentB = merge(mixinWithoutParameter, { color: red });

Perhaps merge could return an array of classes / data properties, reusing existing classes when passed as arguments.
My assumption herein is that 'mixinWithoutParameter' above is a class name / data property [the return value of style()], which could be detected by merge() and reused instead of regenerating a new class which duplicates all of the css properties from the merged sources.

Glamor consciously avoids this! I'd argue that trying to do that introduces way too much complexity and bugginess, by way of precedence order etc.
And before you ask, this turns or to be fine for performance. I test with 10s 1000s of rules, but do point out if you see any problems. It gzips well, and gets better when combined with our SSR helpers.

Thanks for clarifying your/glamor's stance on the subject. I think you're probably right about the complexity and potential bugginess of making that work. I'm glad to hear you've done exhaustive performance testing.
And I agree this kind of repetition gzips well so the 'extra file size' shouldn't be a problem either.
I'll continue working on my project (a proprietary UI library in React for products my company makes) using the strategy of my last example.

Let me know how it goes, and I'm always open to feedback/requests!


pushing or popping routes during build should assert

indeed, during any part of a frame, probably.
probably also manipulating overlays during a frame should assert.

Closing as per comment above.


adds course resource, adds punctuation consistency

Hi! I created an item for britco and also updated a few other items so that there's a consistent style for the Summary section (some items had periods at the end of the description, and some didn't. most did, so i added for the few that didn't!)

Thank you!


Handle new 'dont know download speed' question

What? and Why?
https://trello.com/c/mh0fa5HS/764-e-commerce-changes
Needed to handle new playback page for 'Are you sure you don't know your download speed'.
This also moved some of the radio qcodes around.  r2 was changed to this new download question, and what was previously r2 is now r3
Checklist

[ ] CHANGELOG.md updated? (if required)

Wait for survey-runner PR to go in before merging if there's testing in preprod atm.

Just got told that we don't need 029 in the pck after all.  Just removed it from the transform and tests.
I also forgot to add it to the image so I've done that too


When loading my wallet I get "Error: Failed to connect to a federation"

Restoring the seed on a clean machine results in the same problem. What can I do in the situation?

Submit logs

There are a hundreds if these in Chrome console logs:
Connection to 'wss://bravo.mainnet-25-madeira.dev.fedibtc.com/' failed:
(anonymous) @ mutiny_wasm.js:5397
Show 1 more frame
Show lessUnderstand this error
mutiny_wasm.js:5404 WebSocket is already in CLOSING or CLOSED state.
(anonymous) @ mutiny_wasm.js:5404
Show 1 more frame
Show lessUnderstand this error
mutiny_wasm.js:5397 WebSocket connection to 'wss://alpha.mainnet-25-madeira.dev.fedibtc.com/' failed:
(anonymous) @ mutiny_wasm.js:5397
Show 1 more frame
Show lessUnderstand this error
mutiny_wasm.js:5397 WebSocket connection to 'wss://charlie.mainnet-25-madeira.dev.fedibtc.com/' failed:
(anonymous) @ mutiny_wasm.js:5397
Show 1 more frame
Show lessUnderstand this error
mutiny_wasm.js:5404 WebSocket is already in CLOSING or CLOSED state.
(anonymous) @ mutiny_wasm.js:5404
Show 1 more frame
Show lessUnderstand this error
mutiny_wasm.js:5404 WebSocket is already in CLOSING or CLOSED state.
(anonymous) @ mutiny_wasm.js:5404
Show 1 more frame
Show lessUnderstand this error
mutiny_wasm.js:5397 WebSocket connection to 'wss://delta.mainnet-25-madeira.dev.fedibtc.com/' failed:
(anonymous) @ mutiny_wasm.js:5397
Show 1 more frame
But in the debug logs, it doesn't look too bad, ending with
2024-09-04 17:34:33.836 7528 DEBUG [mutiny_core::node:923] Persisting monitor for output: OutPoint { txid: 0xd..., index: 0 }
2024-09-04 17:34:34.013 7528 INFO  [mutiny_core::nodemanager:1241] We are synced!
2024-09-04 17:34:34.013 7528 TRACE [mutiny_core::nodemanager:1247] finished calling sync
2024-09-04 17:34:34.320 7528 DEBUG [mutiny_core::node:944] notified channel monitor updated: OutPoint { txid: 0x..., index: 0 }
In the beginning of the debug log, there is
2024-08-15 22:16:50.268 9dba ERROR [mutiny_core::federation:293] Could not open federation client: Federation rpc error {general => Received errors from 2 peers: peer-0: Rpc error: The background task closed WebSocket connection failed; restart required, peer-1: Rpc error: The background task closed WebSocket connection failed; restart required), 0 => Rpc error: The background task closed WebSocket connection failed; restart required)1 => Rpc error: The background task closed WebSocket connection failed; restart required), }
Do you want the entire debug log file? I'm a bit cautious on posting it here.

It's trying to connect the Madeira federation. Is that one offline?

Yes, I think so. I don't remember connecting to it though, I think I have connected to some other federation. Is this a hack?

Is there a resolution? I don't have any funds in the federation, but I did have lightning channel open.

Can't do anything about a federation not working.


Dev v3.5.1

Type your response on top of this email to respond to this case. Learn Email Commands Here - https://support.desk.com/customer/portal/articles/1191712-reply-via-email-commands
Case Assignment Notification - Case #39313 ( https://affirm.desk.com/web/agent/case/39313 )
Affirm | Dec 05, 2017 11:43PM UTC

Case #39313
Customer: Affirm/Magento_Affirm
Subject: [Affirm/Magento_Affirm] Dev v3.5.1 (#34)
Case Information (39313):
Subject: [Affirm/Magento_Affirm] Dev v3.5.1 (#34)
Description:
Status: Open
Priority: 4
Assigned Group: MTS

Case History
goatmad  at DEC 05, 2017 | 03:43PM PST:
You can view, comment on, or merge this pull request online at:
https://github.com/Affirm/Magento_Affirm/pull/34
-- Commit Summary --

Remove Affirm promo key from admin
Enabling website scope for Affirm promos and mfp
Admin functions (Capture, Refunds, Voids) issue  due to incorrect store scope for multiple store magento

-- File Changes --
M extension/app/code/community/Affirm/Affirm/Helper/Promo/Data.php (16)
M extension/app/code/community/Affirm/Affirm/Model/Payment.php (52)
M extension/app/code/community/Affirm/Affirm/etc/config.xml (1)
M extension/app/code/community/Affirm/Affirm/etc/system.xml (419)

-- Patch Links --
https://github.com/Affirm/Magento_Affirm/pull/34.patch
https://github.com/Affirm/Magento_Affirm/pull/34.diff
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/Affirm/Magento_Affirm/pull/34

This message was sent to<EMAIL_ADDRESS>in reference to Case #39313


Feature:  Custom OS image for Claudie nodepools

Motivation

Currently, Claudie uses Ubuntu 22.04 images for all node pools it creates. It serves us well, however, I think we can do better.
During Claudie's workflow, a lot of time is invested in installing dependencies for the cluster. Tools like wireguard, kubeadm, kubelet has to be installed which takes a lot of time. If Claudie would use a custom OS image with all prerequisites already present, we could save ourselves a few minutes during node creation. This can benefit autoscaled node pools as well as ordinary ones. What's more, we could "harden" the image to keep it secure and minimal. It can still be based on Ubuntu or any other image we could choose (Talos, CoreOS, ...).
Description

Claudie can use custom image to improve the time it takes to create and join a new node, as well as keep it more secure.
Exit criteria

[ ] Custom OS image for Claudie is created
[ ] Image is available in every cloud provider supported

Flatcar is a coreOS spinoff: https://www.flatcar.org/; it could be considered as well.
Not sure about the wireguard support in there.

This sounds like a pretty good idea, however, I am wondering about the following:

Will this be possible in smaller clouds like Hetzner?
Is it possible for us to upload an OS image to a Cloud provider, and then make that OS image usable to other users without any authentication?
Does this mean we are going to take away the possibility for the user to select their OS?
Can we easily do this in a manner that's compatible with both ARM64 and AMD64 ?

There will be implications from this decision towards the hybrid-cloud bootstrapping mode. That makes me think that the sequence of actions should be 1) hybrid-cloud POC, 2) then this task.
Because a decision taken within this issue might render good hybrid-cloud bootstrapping options invalid.

Let's optimize the playbooks before we consider again the custom Ubuntu images.

I'll just add 2 more projects, similar to Flatcar OS, for an eventual future consideration:
https://github.com/bottlerocket-os/bottlerocket
https://github.com/kairos-io/kairos

I have used https://github.com/choria-io for managing lage fleets of servers. it might be a nice backplane for claudie, independent of k8.
It allow soyu to keep 1,000 of servers in sync and upgrade them. its golang.


fix(patch): extend original server.moduleGraph

Fixes #4.

Thank you!

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Add support for glTF extension EXT_lights_ies

Please make sure to label your PR with "bug", "new feature" or "breaking change" label(s).
To prevent this PR from going to the changelog marked it with the "skip changelog" label.

Snapshot stored with reference name:
refs/pull/15970/merge
Test environment:
https://snapshots-cvgtc2eugrd3cgfd.z01.azurefd.net/refs/pull/15970/merge/index.html
To test a playground add it to the URL, for example:
https://snapshots-cvgtc2eugrd3cgfd.z01.azurefd.net/refs/pull/15970/merge/index.html#WGZLGJ#4600
Links to test babylon tools with this snapshot:
https://playground.babylonjs.com/?snapshot=refs/pull/15970/merge
https://sandbox.babylonjs.com/?snapshot=refs/pull/15970/merge
https://gui.babylonjs.com/?snapshot=refs/pull/15970/merge
https://nme.babylonjs.com/?snapshot=refs/pull/15970/merge
To test the snapshot in the playground with a playground ID add it after the snapshot query string:
https://playground.babylonjs.com/?snapshot=refs/pull/15970/merge#BCU1XR#0

WebGL2 visualization test reporter:
https://snapshots-cvgtc2eugrd3cgfd.z01.azurefd.net/refs/pull/15970/merge/testResults/webgl2playwright/index.html

Visualization tests for WebGPU (Experimental)
https://snapshots-cvgtc2eugrd3cgfd.z01.azurefd.net/refs/pull/15970/merge/testResults/webgpuplaywright/index.html


Well logs duplicate with the exact same data

Duplication of exact same well data observed for well logs containing the same well log number. Sometimes multiple logs will occur for a well; however, the data is usually different (like for different drill depths, for example). For an example, load charlott.dat and view well log W-2229.

Added WellLog object to tree node, which is retrieved and displayed when node is selected.