runtime/race: running with -race misses races (mismatch with memory model)

What version of Go are you using (go version)?

$ go version
go version go1.13.7 darwin/amd64

Does this issue reproduce with the latest release?
Yes.
What operating system and processor architecture are you using (go env)?
go env Output
$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/danielsf/Library/Caches/go-build"
GOENV="/Users/danielsf/Library/Application Support/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/danielsf/Dropbox/edu/uio.no/favasynthesis/src/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/sb/5mzmh37n6bl7pt2yzf0sy3s80000gq/T/go-build206592919=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do
This issue was found from inspecting the code in chan.go as opposed to observing behavior during execution.  I did created a program to illustrate the issue.  I believe the program (shown below) is racy, but the race detector does not flag the race (no output in stdout/stderr).
(I believe the culprit are four lines of code in chan.go, as detailed in "What did you expect", with a patch suggested at the end.)

$ go build -race test_chan.go
$ ./test_chan

The program is as follows:
$ cat test_chan.go
package main
import(
"sync"
"time"
)
var wg sync.WaitGroup
var z = 0
func t1(c chan bool){
defer wg.Done()
c <- true
}
func t2(c chan bool){
defer wg.Done()
z = 42
<- c
}
func t3(c chan bool){
defer wg.Done()
time.Sleep(1)
c <- true
}
func t4(c chan bool){
defer wg.Done()
time.Sleep(1)
<- c
z = 13
}
func main() {
c := make (chan bool, 1)
wg.Add(4)
go t1(c)
go t2(c)
go t3(c)
go t4(c)
wg.Wait()
}

What did you observe
I observed no output.  The program does not print to stdout or stderr and, when running the program with the race checker enabled, the race checker also does not produce any output.
What did you expect instead
I expected the race checker to flag a race between the write in t1 and the write in t4.
The program can (and often does) produce the following trace:

sd(1,c)   # t1 sends on c
wr(2,z)   # t2 writes to shared variable z
rv(2,c)   # t2 receives on c
sd(3,c)   # t3 sends on c
rv(4,c)   # t4 receives from c
wr(4,z)   # t4 writes to shared variable z

The question is: are the two writes, wr(2,z) and wr(4,z), in a race?
According to the memory model:

rv(2,c) happens-before the completion of sd(3,c),
sd(3,c) happens-before the completion of rv(4,c),
however, rv(2,c) is not in happens-before with respect to rv(4,c).  They are not in happens-before relation because sd(3,c) and the completion of sd(3,c) are not the same.  Thus we cannot use transitivity of happens-before to derive a relation between rv(2,c) and rv(4,c).

This race is not flagged by the race detector.  I believe the race detector interpret the events as follows:

rv(2,c) happens-before sd(3,c)
sd(3,c) happens-before rv(4,c)
therefore, rv(2,c) is in happens-before with respect to rv(4,c), thus the write by thread 2 is in the past of the write by thread 4.

Instead of not getting any output when running the program with race check enabled, I expected to see output like this:

$ /Users/danielsf/Dropbox/go/go/bin/go build -race test_chan.go
$ ./test_chan
==================
WARNING: DATA RACE
Write at 0x00000117cc18 by goroutine 9:
  main.t4()
      /Users/danielsf/Dropbox/edu/uio.no/favasynthesis/src/go/src/test_chan.go:36 +0x94

Previous write at 0x00000117cc18 by goroutine 7:
  main.t2()
      /Users/danielsf/Dropbox/edu/uio.no/favasynthesis/src/go/src/test_chan.go:20 +0x70

Goroutine 9 (running) created at:
  main.main()
      /Users/danielsf/Dropbox/edu/uio.no/favasynthesis/src/go/src/test_chan.go:45 +0xf2

Goroutine 7 (finished) created at:
  main.main()
      /Users/danielsf/Dropbox/edu/uio.no/favasynthesis/src/go/src/test_chan.go:43 +0xae
==================
Found 1 data race(s)

The output above is from the following patch:
Consider the following piece of code present in both chansend() and chanrecv() functions of runtime/chan.go:

    if raceenabled {
      raceacquire(qp)
      racerelease(qp)
    }

If in chansend(), the raceacquire() comes before racerelease(), then a thread gains happens-before information (via the raceacquire) before the completion of the send operation, as opposed to at the point of completion as specified by the memory model.  Similar for the order of raceacquire() and racereceive() in chanrevc().
In practice, having raceacquire() before racerelease() can prevent the race detector from flagging certain race conditions, such as the race condition illustrated with the example program and trace above.
The fix is simple:  just swap the order of raceacquire() and racerelease() in both chansend() and chanrecv() functions of runtime/chan.go:

    if raceenabled {
      racerelease(qp)
      raceacquire(qp)
    }

The patch passes the tests in all.bash.
In more detail...
Another way to look at the trace above is by transforming the sends and receives into sequences of acquire and releases. If the sends and receives are interpreted as raceacquire(); racerelease() as it is currently the case in chan.go, then the trace would be as shown below, and a race detector will not flag the trace as racy:

acq(1,c)  # this sequence of acq
rel(1,c)  # followed by rel stands in place of the send sd(1,c)
wr(2,z)   # thread 2 writes to shared variable z
acq(2,c)  # this sequence of acq
rel(2,c)  # followed by rel stands in place of the receive rv(2,c)
acq(3,c)  # this sequence of acq
rel(3,c)  # followed by rel stands in place of the send sd(3,c)
acq(4,c)  # this sequence of acq
rel(4,c)  # followed by rel stands in place of the receive rv(4,c)
wr(4,z)   # thread 4 writes to shared variable z

The absence of a race in the trace above comes from the fact that we can find a happens-before chain from wr(2,z) to wr(4,z):

wr(2,z) is in happens-before with rel(2,c) by program order
rel(2,c) is in happens-before with acq(3,c) and rel(3,c) by lock semantics and program order
rel(3,c) is in happens-before with acq(4,c) by lock semantics
acq(4,c) is in happens-before with wr(4,z) by program order

If, however, we swap the order of the raceacquire() and racerelease() in the interpretation of sends and receives, then a race detector will then report the trace as racy.  The race exists because, given the trace below, it is not possible to derive that the write from thread 2 is in happens-before with respect to the write from thread 4.

rel(1,c)  # this sequence of rel
acq(1,c)  # followed by acq stands in place of the send sd(1,c)
wr(2,z)
rel(2,c)  # this sequence of rel
acq(2,c)  # followed by acq stands in place of the receive rv(2,c)
rel(3,c)  # this sequence of rel
acq(3,c)  # followed by acq stands in place of the send sd(3,c)
rel(4,c)  # this sequence of rel
acq(4,c)  # followed by acq stands in place of the receive rv(4,c)
wr(4,z)

cc @dvyukov

Tsan changes are in, but the Go side isn't done yet.

Reopening because CL 220419 is being reverted; see #42598.

Fix to #42598 in df68e01

This CL was not reverted given the fix to #42598 in df68e01.
I think it is safe to close it.


Increased async for gitlab package install

Tested the async value of 300 on AWS and it fails consistently, manual install of the gitlab-ce package tells me that 600 should be a good value, no failures when testing, consistently succeedes now.
Note, it's a huge package and it does a lot of post stuff.

How about making this value configurable instead of hardcoding it to a specific value?

I also noticed that #161 increases the async value from 300 to 3000.


Validate contact form

We created the JavaScript necessary to validate the email input in the contact form.

🚫⚠🛑 INVALID SUBMISSION 🚫⚠🛑
Hi <STUDENT_MENTION>,
While you made a great effort in this project, unfortunately, I cannot proceed to review your code.
Invalid Code Review Request
You have submitted a project, that submitted a merged pull request link
Your Code Review Request will be marked as invalid in your Dashboard, so please submit a new one once you are ready 🙏
Cheers and Happy coding!👏👏👏
Feel free to leave any questions or comments in the PR thread if something is not 100% clear.
Please, do not open a new Pull Request for re-reviews. You should use the same Pull Request submitted for the first review, either valid or invalid unless it is requested otherwise.

Invalid Code Review Request does not count into the code reviews limit.

🚫⚠🛑 INVALID SUBMISSION 🚫⚠🛑
Hi @vechicin ,
While you made a great effort in this project, unfortunately, I cannot proceed to review your code.
Invalid Code Review Request
You have submitted a project, that submitted a merged pull request link
Your Code Review Request will be marked as invalid in your Dashboard, so please submit a new one once you are ready 🙏
Cheers and Happy coding!👏👏👏
Feel free to leave any questions or comments in the PR thread if something is not 100% clear.
Please, do not open a new Pull Request for re-reviews. You should use the same Pull Request submitted for the first review, either valid or invalid unless it is requested otherwise.
Invalid Code Review Request does not count into the code reviews limit.

Dear @carlos-ssh
This is a coding-partner activity. The code was checked and approved by the first reviewer. This is the reason why the PR was merged.


Uncaught ReferenceError: process is not defined

I got this error when running the plugin initialized with -react template

Likewise, can't get a react UI build running

https://www.figma.com/plugin-docs/api/api-overview/
figma.createRectangle()
figma.closePlugin()

◆☆ Roman Nurik : Stars ☆◆
rsms/figplug
Figma plugin builder
★ 109  ● TypeScript

What exact steps can be taken to reproduce this issue?

@rsms I got this error out of the box when scaffolding a plugin with the React UI. E.g.:

run the command: figplug init -react my-plugin
build and watch: figplug build -w my-plugin
the above error prevents the plugin from running

Screenshot of what I get when I init, build, and run a -react plugin from scratch:

Aaah! I see. This is an error in the resulting app, not necessarily in figplug (the program.) Thanks @brianlovin — this narrows down the test cases.

It seems the culprit is that the latest react library tries to unconditionally access process.env.NODE_ENV which is of course not set in a web browser. A fix should land soon.

New release has been published to npm with the fixes included.
https://www.npmjs.com/package/figplug
To upgrade:
npm install -g figplug

You may also want to run init in your projects to update figma and figplug type definitions:
cd my-project
figplug -v init  # -v flag enables verbose logging

@rsms I think this is still an issue. While

figplug -v init

works, doing it with the -react flag results in the same problem.


Fix API Server log configuration

The current API Server when deployed into ECS cluster is generating overwhelmingly large (and useless) volume of logs. It seems that logs as recorded by ECS (which are directly fetched from container console) ignore the RUST_LOG=INFO - the CloudWatch logs are littered with tons of TRACE and DEBUG records.

Could we solve this in refactoring? The amount of logs shall be decreased significantly

...but right now the volume is killing us and makes troubleshooting really painful.


Speedup build process

Parallelise frontend and backend build.
Missing: assets.go build and porcelain -> depends on #555

replcaed by #555


docs: add GAR

Adds a reference to GAR support.
Closes #157

cc @jonjohnsonjr - does this look good for merge?

Content LGTM, but do you mind waiting a until tomorrow to merge? My fix still hasn't rolled out to a couple regions, so I don't want to claim support quite yet.
Thanks Hideto!

do you mind waiting a until tomorrow to merge?

This should be good to go now.


Setup download functionality (png) for chart.js charts using quickchart service

This is available for all charts now except the Tree Chart, as this uses a custom chart plugin.

@bgsandan Please can you review and either close if completed or comment if more required?

This looks great 👍 .  Closing this issue.  Any future bugs or tweaks can have their own issues


Convert exdata tests to new test framework

Checklist

[x] tests are added or updated
Removed asserts and replaced with TEST_* checks.

Merged.  eb16fc8fb6087ae1aeb22634e2c4b5c913d1836e


Add new category

Added MoAIJobs to the jobs category

Sorry have to reject this. The site theme is about building AI.
Think there are already plenty of other sites suitable for job related links.

Hello Anthony,
TO rephrase from the description - "Community-driven platform dedicated to sharing resources, tools, and knowledge for AI enthusiasts and developers" so I think, devs and enthusiasts can also benefit from AI job listings, makes the platform goto source for any devs in AI.


I have tried to written the implementation for the phi2 model. However, I am experiencing some problems:

I have tried to written the implementation for the phi2 model. However, I am experiencing some problems:

doing a test on the model with and without tova, it turns out that tova consumes more VRAM

i don't understand where the error is in my implementation in custom_phi.py or what i am not considering or doing wrong.
can you help me
Originally posted by @GiacomoLeoneMaria in https://github.com/schwartz-lab-NLP/TOVA/pull/3

Hi,
Thanks for reaching out!
It seems that your implementation is missing a call to the "reduce()" function. As an example, you can refer to the implementation for llama in:
https://github.com/schwartz-lab-NLP/TOVA/blob/59be3d17a5f3327b99c67c3b9f78bae96f9563b8/src/convert_models/llama_custom.py#L112
Can you try again with an updated implementation?
Hope it helps :)


Fix for Issue 967: Create matching small molecule versions of all standard peptide reports in Document Grid

Our change to remove peptide-only features in small molecule mode resulted in the loss of some useful reports. There is currently no equivalent to:
"Peptide RT Results", which has headers
Peptide,Protein,Replicate,Predicted Retention Time,Peptide Retention Time,Peptide Peak Found Ratio and
"Transition Results", which has headers
Peptide,Protein,Replicate,Precursor Mz,Precursor Charge,Product Mz,Product Charge,Fragment Ion,Retention Time,Area,Background,Peak Rank

@nickshulman  I went ahead and added equivalent reports for Molecule mode. Feels like these could have been handled automatically though maybe that's too much effort.

The "Peptide RT Results" report might not be important enough to deserve a small molecule version.
For the "Molecule Transition Results" report, I wonder whether we should hide the "Fragment Ion" and "Peak Rank" columns because they are unlikely to be useful in a small molecule document.

Sorry, I don't follow - is there something unique to peptides that makes the RT results report useful there?
Also don't understand your second point - why would users not want to know about fragments? Or peak rank?

Sorry, I don't follow - is there something unique to peptides that makes the RT results report useful there?
Also don't understand your second point - why would users not want to know about fragments? Or peak rank?

"Peptide RT Results" report gets mentioned in the "Advanced Peak Picking" tutorial.
That tutorial does not get used by small molecule people because there is no such thing as a decoy for a small molecule target.
I am not sure that "Peptide RT Results" is an important enough report to deserve to have a small molecule version (but I might be wrong).
For the Molecule Transition Results, I was trying to imagine what we might want to do to make the report particularly suited for small molecules. What I had in my head was that most people do not give their fragment ions names, so the "Fragment Ion" column ends up not being as useful for molecules as it is for peptides (but, you are right, it's still pretty useful to distinguish precursors, precursor isotopes and fragments).
Maybe the report should have the "Precursor Adduct" and "Product Adduct" columns instead of "Precursor Charge" and "Product Charge"?
These default reports are our opportunity to demonstrate the best practices for building a report. Are there any other columns that would be particularly useful to include on a Molecule Transition Results report?

"Peptide RT Results" report gets mentioned in the "Advanced Peak Picking" tutorial. That tutorial does not get used by small molecule people because there is no such thing as a decoy for a small molecule target. I am not sure that "Peptide RT Results" is an important enough report to deserve to have a small molecule version (but I might be wrong).

I feel like we want parity, even if it's not mentioned in any tutorial. Users shouldn't wonder why a report goes missing when the UI mode is changed (unless it something whose content is just completely proteomic, but this isn't that)

For the Molecule Transition Results, I was trying to imagine what we might want to do to make the report particularly suited for small molecules. What I had in my head was that most people do not give their fragment ions names, so the "Fragment Ion" column ends up not being as useful for molecules as it is for peptides (but, you are right, it's still pretty useful to distinguish precursors, precursor isotopes and fragments).

It's true that fragments are often nameless, but not always. Easier for a user to them to ignore than add.

Maybe the report should have the "Precursor Adduct" and "Product Adduct" columns instead of "Precursor Charge" and "Product Charge"?

Good point - I'd say "additionally" though, rather than "instead of". I've added those.

These default reports are our opportunity to demonstrate the best practices for building a report. Are there any other columns that would be particularly useful to include on a Molecule Transition Results report?

Ideally a report would also have things like SMILES, InCHi, CAS etc but different folks use different combinations (or, often as not, none)  of those, so it's probably a matter for customization unless we can think of something clever like columns that are omitted when empty.


10/7 Cut Ruby language family release

https://github.com/paketo-buildpacks/ruby/releases/tag/v0.16.2


TIM-225 User profile per comment

[!WARNING]
This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

#138  👈
#137
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @tamrivera05 and the rest of your teammates on  Graphite


Gateway Feature - Add Amount On Pending Transaction

When you bridge your funds, you will get a pending transaction with a lot of details. But I think the most important data is missing at first glance. And that is the amount you are bridging. I know you can click on the 'details' button and see the amount in the explorer. But thats an extra step for the user. I would love to see an amount on the pending transaction.

great idea - the amount information is currently not in the api-watcher payload, but could and should be.

@sk-enya FYI the watcher-api already trues the amount, so the only thing to do is to display that information in the pending and in the history:
See response.action.amount
https://github.com/omgnetwork/optimism/tree/develop/ops_omgx/api/watcher-api
So, please, where possible, display this value to the user, per the @MitchellUnknown 's screenshot above.
You will have to:
1/ get the value of response.action.amount
2/ convert it to the correct representation, suggest toFixed(2)
3/ get the token, and display the token too, ending up with 1.00 ETH (for example)


Test windows and more Python version in the CI

At the moment we only test 3.10 on Linux to save on CI minutes. Once development has slowed down, we should test all supported Python versions and operating systems

Done


update method is misleading

Hi,
We had a tough issue with twitter as we found some very inconsistent behavior regarding the tweets we store.
The fact that the update method will return the last tweet sent if it is a duplicate was not expected and caused some really hard to debug errors.
Wouldn't it be better if the update method returned nil instead of the last sent tweet ?
Cheers

Indeed this is very error prone as you can't know if it's your tweet or not.
If it doesn't raise it should just return nil.

The method you'll want to use instead is Twitter::REST::Tweets#update! which will raise a Twitter::Error::DuplicateStatus on duplicates whereas update works as you've described above.

I agree, that the documentation on update could be clearer and will make sure we adjust our documentation in the next release.

Yes, we saw it and we'll use the update! method for sure, we don't understand why the update method even exist like this :) We just want to avoid other users loosing as much time as we did on this issue. We ended up having duplicated id in our DB with post that didn't even exists on twitter, causing all kind of threading issues. We never suspected the gem could do something like this, doing another API call to return a plain correct response with a totally different tweet when the server is actually returning an error is kind of crazy.
And by the way, if this was implemented thinking "if it's a duplicate error it'll be the same tweet anyway", this is plain wrong. If you post A, then B, then A, twitter will return an error and you'll return B. So the return value of update is actually meaningless and dangerous.

It's not apparent from the commit where it was introduced (02b6cb31ccf1fcea3452bb84aa2113d00809eec3) but if I ventured to guess, it was to support a graceful fallback.
@sferik what are your thoughts around deprecating update in favor of update! in 6.x? I think I'd be in favor of always having it raise an error in this scenario.

It seems there's even a spec for this:
  it 'returns a Tweet' do
    tweet = @client.update("The problem with your code is that it's doing exactly what you told it to do.")
    expect(tweet).to be_a Twitter::Tweet
    expect(tweet.text).to eq('Happy Birthday @imdane. Watch out for those @rally pranksters!')
  end

So this was probably done on purpose ? In this case I would like to know why ;)
Otherwise to me it's fine to have two version, one which raises and one silent, but the silent should definitely not return the last tweet (moreover this is another API call, which can fail too...), It should simply return nil.

Yes, 2 versions are fine but the problem lies in the behavior of update, it's unexpected and not even documented, therefore error prone. I can't see the use case of returning the last tweet, you want to know when your tweet is not published.

I’m open to reconsidering the default behavior in version 6.

Also, while we're there, I noticed there is an inconsistency with the create_direct_message method, this one will raise Twitter::Error::Forbidden: There was an error sending your message: Whoops! You already said that. if a private message is a duplicate, shouldn't we also raise an Twitter::Error::DuplicateStatus instead ?

It's probably because twitter answers "Status is a duplicate" for public tweets and "Whoops, you already said that" for private messages.
Would you like a pull request that adds this case to error.rb and some specs ?


iOS, build & run ipa file in physical device

Hi!
I can't generate a Mnemonic from String when I build ipa file (release mode) and then run it in a physical device. But when I run the app with VSCode and physical device is plugged into computer the plugin works correctly.
I reproduced this issue with the project example of this repository, and the result is the same, I couldn't restore the "alice wallet".
Stack trace of Sentry console of my app:
_Exception: Exception: Subclasses of `FlutterRustBridgeBase` should be singletons - there should not be two instances (runtimeType=RustBdkFfiPlatform)
  File "basic.dart", line 51, in FlutterRustBridgeBase._sanityCheckSingleton
  File "basic.dart", line 27, in new FlutterRustBridgeBase
  File "bindings.dart", line 1827, in new RustBdkFfiPlatform
  File "bindings.dart", line 23, in new RustBdkFfiImpl
  File "loader.dart", line 16, in loaderApi
  File "root.dart", in Mnemonic.fromString

Plugin version - bdk_flutter: ^0.29.2
Doctor
➜  ~ flutter doctor
Doctor summary (to see all details, run flutter doctor -v):
[✓] Flutter (Channel stable, 3.16.5, on macOS 13.5.2 22G91 darwin-arm64 (Rosetta), locale en-MX)
[✓] Android toolchain - develop for Android devices (Android SDK version 33.0.1)
[✓] Xcode - develop for iOS and macOS (Xcode 14.3.1)
[✗] Chrome - develop for the web (Cannot find Chrome executable at /Applications/Google
    Chrome.app/Contents/MacOS/Google Chrome)
    ! Cannot find Chrome. Try setting CHROME_EXECUTABLE to a Chrome executable.
[✓] Android Studio (version 2021.3)
[✓] VS Code (version 1.85.1)
[✓] Connected device (2 available)
[✓] Network resources

Can you try the following steps please:
Open Xcode and navigate to your project's settings.
Select the "Target Runner" option.
In the "Build Settings" tab, locate the "Strip Style".
Change the value from "All Symbols" to "Non-Global Symbols."

Thanks @BitcoinZavior! It was solved my issue. 🤟


move test command to gcb

move release qualification test command from airflow to google cloud builder

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approver: rkpagadala
If they are not already assigned, you can assign the PR to them by writing /assign @rkpagadala in a comment when ready.
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

release/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@rkpagadala: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-pilot-multicluster-e2e.sh
fc348b238b960a0b20e56c7677e13d6869b46931
link
/test istio-pilot-multicluster-e2e

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@hklai fixed

@rkpagadala: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/e2e-mixer-no_auth-mcp.sh
a7969a48c733b55d4268c7fd02a658d2601f7f1f
link
/test e2e-mixer-no_auth-mcp

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@rkpagadala: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-unit-tests.sh
55de8953d7cfb82bdd0d2712222efd811ad908ed
link
/test istio-unit-tests

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@hklai PTAL

@rkpagadala There are still two copies as in https://github.com/istio/istio/blob/fb861e733b89224430323e78138e830d37a1dae3/release/generate_manifest.sh#L291
Why is that needed?

one is used by subsequent steps in the build, the other one is used to compare and make sure that subsequent builds are from shas after the current one

How are they used? And why is one of them specific to master?
On Mon, Oct 1, 2018, 10:31 PM Krishna Pagadala<EMAIL_ADDRESS>wrote:

one is used by subsequent steps in the build, the other one is used to
compare and make sure that subsequent builds are from shas after the
current one
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/istio/istio/pull/9060#issuecomment-426153600, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AeRtkPvMYpFQ2AjXgVD3fq9YD9JzvzCzks5ugvoogaJpZM4XBi1z
.

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: hklai
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

release/OWNERS [hklai]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment


Logout issue

I dont see any option from where i can logout from this app and login with some other account. Please help..

We are still missing a logout button, if you want to logout you need to remove the account manually through your device's settings.
The logout functionality is planned and so is the multiple account support #51

+1

I also miss the logout feature. This is a minimum feature, which is required!

@webmaster33 PR welcome :wink:


[FEATURE] Overlap waybar's exclusive zone.

Description of the requested feature
I know this is completely useless for 99% of the users, but I think it would be cool if eww widgets could invade waybar's reserved space. I'm trying to make a fullscreen eww widget and waybar is in the way. Same thing happens when I set a eww bar and make it exclusive. If I were in X I guess I could just fullscreen eww with wm because it can be, but on wayland I can't since it's not a window.
Proposed configuration syntax
No response
Additional context
No response

I don't think this is really up to eww to decide, from what I understand of zwlr_layer_shell (Wayland protocol extension that eww uses) surfaces can set an exclusive zone (where other surfaces shouldn't overlap), although the exact behavior is compositor dependent that would mean you'd need to disable that in waybar.
I could be wrong tho
It's also possible that changing the layer would work, but idk how to do that

I don't think this is really up to eww to decide, from what I understand of zwlr_layer_shell (Wayland protocol extension that eww uses) surfaces can set an exclusive zone (where other surfaces shouldn't overlap), although the exact behavior is compositor dependent that would mean you'd need to disable that in waybar.
I could be wrong tho
It's also possible that changing the layer would work, but idk how to do that

I see. Apparently it's hard :( Thanks for replying tho.

It could be possible, especially considering I can't really reproduce, what compositor do you use and do you have MRE ?

Wait, are you telling me that you've actually made it possible that eww overtakes waybar's exclusive zone? I'm on Hyprland. I'm sorry I don't know what MRE is. I tried googling but it says military meals.

Should be fixed by #609 if exclusive is set to "ignore", not sure if or when this it'll get merged tho.

Wow. Thank you. I should apologize for my noobness though, how can I test this in my machine?
Also I think the minimal reproducible example is pretty much just installing both eww and waybar and set waybar first then open eww. I'm not sure what more information I should give since this is pretty much a minimal hyprland setup under a virtual machine.
Could screenshots or config files help?

Don't worry about that, I already reproduced with hyprland and waybar (to test my fix).
To use the fix you should either wait for it to be merged, or build eww from source from my branch:
Instead of
git clone https://github.com/elkowar/eww

do
git clone -b exclusive --single-branch --depth 1 https://github.com/viandoxdev/eww

(you could also clone the regular eww directory, add a new remote and git switch to the branch)
There might be better solutions depending on your distro (local pkgbuild on arch, or patch on gentoo, ...) tho, which one are you on ?

I am on arch linux. I know it's not for noobs like me but I really liked Hyprland's wacky animation and it's easiest to install through aur XD
Thank you so much for the fix. It's too late in australia so gotta sleep but I'll definitely do it tomorrow.

I just removed elk's eww with yay -R eww-wayland and compiled viandoxdev's eww from source. But when I set :exclusive "ignore"and do eww reload it says :exclusive needs to be either true or false.
 I can't appreciate enough :)


Can I combine string and children values and map them to one property?

titleItem: figma.nestedProps('_Contained list title item', {
  label: figma.boolean('Tooltip', {
    true: figma.string('List title text') + figma.children('Tooltip'), <--how can I do this?
    false: figma.string('List title text'),
  }),
}),

In this stage of code-connect (v 1.0.6) it is not possible. but we can get same results with variant restriction.
see this -> https://github.com/figma/code-connect/issues/80#issuecomment-2200476356

@Chanki-Min I'm not sure variant restrictions would help me here since its a nested prop, unless I missed something and variant restrictions supported nesting.

+1


Text wrapped onto additional line splits into multiple cells.

First time poster, long time lurker. First off, thank you to everyone who contributed to this incredible tool. Your work is sincerely appreciated.
I have a PDF article which includes several tables containing ~340 rows of data. So, manually entering this data into excel for manipulation would be extremely time consuming.
Unfortunately, each row of data in the PDF contains at least one "cell" with wrapped text (line breaks). Since the data appears on multiple lines, I can't get tabula (or any other PDF data extraction tool) to recognize the data is related and should be contained within a single cell.
I've included several screenshots below to illustrate the issue. Hoping someone has a work around to this frustrating issue. Thanks!

have u tried lattice model？
发自网易邮箱大师
On 10/08/2018 05:18, entreprenny wrote: First time poster, long time lurker. First off, thank you to everyone who contributed to this incredible tool. Your work is sincerely appreciated.
I have a PDF article which includes several tables containing ~340 rows of data. So, manually entering this data into excel for manipulation would be extremely time consuming.
Unfortunately, each row of data in the PDF contains at least one "cell" with wrapped text (line breaks). Since the data appears on multiple lines, I can't get tabula (or any other PDF data extraction tool) to recognize the data is related and should be contained within a single cell.
I've included several screenshots below to illustrate the issue. Hoping someone has a work around to this frustrating issue. Thanks!
—You are receiving this because you are subscribed to this thread.Reply to this email directly, view it on GitHub, or mute the thread.
{"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/tabulapdf/tabula","title":"tabulapdf/tabula","subtitle":"GitHub repository","main_image_url":"https://assets-cdn.github.com/images/email/message_cards/header.png","avatar_image_url":"https://assets-cdn.github.com/images/email/message_cards/avatar.png","action":{"name":"Open in GitHub","url":"https://github.com/tabulapdf/tabula"}},"updates":{"snippets":[{"icon":"DESCRIPTION","message":"Text wrapped onto additional line splits into multiple cells. (#933)"}],"action":{"name":"View Issue","url":"https://github.com/tabulapdf/tabula/issues/933"}}}
[
{
"@context": "http://schema.org",
"@type": "EmailMessage",
"potentialAction": {
"@type": "ViewAction",
"target": "https://github.com/tabulapdf/tabula/issues/933",
"url": "https://github.com/tabulapdf/tabula/issues/933",
"name": "View Issue"
},
"description": "View this Issue on GitHub",
"publisher": {
"@type": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
},
{
"@type": "MessageCard",
"@context": "http://schema.org/extensions",
"hideOriginalBody": "false",
"originator": "AF6C5A86-E920-430C-9C59-A73278B5EFEB",
"title": "Text wrapped onto additional line splits into multiple cells. (#933)",
"sections": [
{
"text": "",
"activityTitle": "entreprenny",
"activityImage": "https://assets-cdn.github.com/images/email/message_cards/avatar.png",
"activitySubtitle": "@entreprenny",
"facts": [
{
"name": "Repository: ",
"value": "tabulapdf/tabula"
},
{
"name": "Issue #: ",
"value": 933
}
]
}
],
"potentialAction": [
{
"name": "Add a comment",
"@type": "ActionCard",
"inputs": [
{
"isMultiLine": true,
"@type": "TextInput",
"id": "IssueComment",
"isRequired": false
}
],
"actions": [
{
"name": "Comment",
"@type": "HttpPOST",
"target": "https://api.github.com",
"body": "{\n"commandName": "IssueComment",\n"repositoryFullName": "tabulapdf/tabula",\n"issueId": 933,\n"IssueComment": "{{IssueComment.value}}"\n}"
}
]
},
{
"name": "Close issue",
"@type": "HttpPOST",
"target": "https://api.github.com",
"body": "{\n"commandName": "IssueClose",\n"repositoryFullName": "tabulapdf/tabula",\n"issueId": 933\n}"
},
{
"targets": [
{
"os": "default",
"uri": "https://github.com/tabulapdf/tabula/issues/933"
}
],
"@type": "OpenUri",
"name": "View on GitHub"
},
{
"name": "Unsubscribe",
"@type": "HttpPOST",
"target": "https://api.github.com",
"body": "{\n"commandName": "MuteNotification",\n"threadId": 389032944\n}"
}
],
"themeColor": "26292E"
}
]


Adding Home Objects Learning

Introducing a feature to showcase common household objects, organized by room categories such as kitchen , living room etc enhancing learning clarity and engagement for children
I would like to work on this please assign me

I would like to work on this issue as part of my contribution to GGSOC. Could you please assign it to me?

please assign this issue to me


fix:conjur: set POSTGRES_HOST_AUTH_METHOD=trust

This is a new thing in postgres:9.4 to allow all connections allow all connections without a password.

how does this not affect our pg tests? are they pinned at specific versions, so they haven't been upgraded to the point of it causing an issue yet?
maybe we need a card for bumping those at some point too?

@izgeri yup, it's pinned to 9:3. i'm not sure what the motivation to upgrade is. this test could as well have been changed to use 9:3 instead of 9:4. but if the motivation becomes clear then we can do the bump.


Add depth estimation pipeline

This PR adds support for the depth-estimation pipeline w/ DPT and GLPN
Closes #350
Example usage:
import { pipeline } from '@xenova/transformers';

let url = 'https://huggingface.co/datasets/Xenova/transformers.js-docs/resolve/main/cats.jpg';
let depth_estimator = await pipeline('depth-estimation', 'Xenova/dpt-hybrid-midas');
let out = await depth_estimator(url);
// {
//   predicted_depth: Tensor {
//     dims: [ 384, 384 ],
//     type: 'float32',
//     data: Float32Array(147456) [<PHONE_NUMBER>59375,<PHONE_NUMBER>304688,<PHONE_NUMBER>921875, ... ],
//     size: 147456
//   },
//   depth: RawImage {
//     data: Uint8Array(307200) [ 86, 86, 86, ... ],
//     width: 640,
//     height: 480,
//     channels: 1
//   }
// }

Input

Output:

Python (baseline):

Code used: https://huggingface.co/Intel/dpt-hybrid-midas#how-to-use

JavaScript (quantized):

JavaScript (unquantized):

Xenova you need to STOP. enough is Enough. "i'm xenova and along with the ort web and optimium teams i'm going to get literally all the <1gb sota ML models quantized and running in the browser, and make it really easy for web devs to use"-- NO. This is not Natural. Web devs are meant to struggle with op support on a tflite model for 2 weeks before realising that they really can't get around the TF Select op requirements, and then steel themselves for creating a custom tflite build, but then find out that the build tooling required for adding TF Select ops is Google-internal, and then try to port the model to tfjs instead, but end up with weird errors, which they eventually fix by breaking the model apart into multiple models and implementing some operations in JS to glue the model back together, with one component actually being executed via the tflite runtime because it has support for a particular op that tfjs didn't have, but then the results for one part of the tfjs model are different from the Python model, so they post an issue with a Colab that isolates and minimally replicates it, but that isn't replied to until 6 months later and that reply is actually just the stale bot.

I should probably post this as a separate issue, but is there a way to get a trimmed down version of transformers.js that only has the depth estimation pipeline? I.e. a "treeshaking" type feature?

@josephrocca ❤ and we're just getting started 😏

is there a way to get a trimmed down version of transformers.js that only has the depth estimation pipeline?

This has actually been requested quite a lot by others, like for use-cases where only tokenizers are used (so, we don't need onnxruntime-web to be bundled). So, please feel free to open up a feature request. Perhaps some others might be able to contribute to the discussion.
For the most part, I think this responsibility should be transferred to build tools like webpack or rollup, as they have much better and advanced support for this. In the worst case, you can just fork the repo and remove everything you don't need :)


Is it possible to get lets-chat as small widget window over any website page.

for example, the way gmail chat is provided.
means every room should get a little widget window (which can be minimized or maximized)
on bottom right or bottom left.
so that user can do other other simultaneously, on the same page, while having chats.

Hope u guys can make it Cooler  than irc / hangouts!

Hope u guys can make it Cooler  than irc / hangouts!

No plans do this at the moment :(
Maybe it's something a custom client can take care of.


Allow position failsafe sensitivity to be adjusted for different platform types

The description for the parameters created contain recommended values for fixed wing platforms.
Partially addresses https://github.com/PX4/Firmware/issues/7609

Would it be more intuitive for users to enter the params in units of seconds? We can also add minimum and maximum metadata to limit it in QGC.
Appropriate default values for FW can be placed here. https://github.com/PX4/Firmware/blob/master/ROMFS/px4fmu_common/init.d/rc.fw_defaults#L11

Would it be more intuitive for users to enter the params in units of seconds?

I'd vote "yes".

We can also add minimum and maximum metadata to limit it in QGC.

Also vote "yes" here.

Appropriate default values for FW can be placed here. https://github.com/PX4/Firmware/blob/master/ROMFS/px4fmu_common/init.d/rc.fw_defaults#L11

This seem very important, as the defaults for VTOL are very bad for fixed wing.  The FW defaults suggested in the code comments seem like good defaults to add to the rc.fw_defaults.  Relying on users to set them appropriately is too risky for an important failsafe such as this.

Also, for fixed wing applications I might consider setting COM_POS_FS_GAIN = 0.   Overall I think the arguments for "probation" on fixed wing are outweighed by the benefits of using position immediately once available.  Would be interested in others opinions here.

@Antiheavy Thinking about your comment about COM_POS_FS_GAIN I agree. Now that fixed wing has the ability to recover from a bad magnetometer at launch by resetting the heading using GPS, we can afford to exit the failsafe soon after that the EKF has completed its reset because it is much less likely that the GPS rejection will be repeated.


add licence, as of issue #16

add licence, as of #16

oopsie :P

fixed
(see fix missed template b2e0ee7 above)


IProduceWithPatches returns Immutable while IProduce is not

🐛 Bug Report
IProduceWithPatches returns Immutable while IProduce is not:
In our Typescript code the following line requires nextState to be Immutable:
    const [nextState, redoPatches, undoPatches] = produceWithPatches(state, draft => {

while that one not:
    const nextState = produce(state, draft => {

As a workaround we're casting to  the returned state of produceWithPatches.
Expected behavior
I would expect produceWithPatches() following the same constraint as produce()
Environment
Immer 9.0.1
Typescript: 4.2.3
Thanks for your hard work.

Did you try to type either the draft or state argument explicitly with the mutable type? Otherwise please provide a minimal sandbox to take a closer look.

@mweststrate here is a sandbox so that you can take a look: https://codesandbox.io/s/immer-immutabe-type-mismatch-wvlid
As you can see, newData can't be reassigned when using produceWithPatches because of the Immutability. If it is more convenient for you, I can open a new issue, but I believe it would be easier just to reopen this one


wsl1 username alway username not root even on root login

The problem
wsl1 username alway username not root even on root login
Relevant Zsh configuration
wsl1 username alway username not root even on root login

What is version of Spaceship are you using?
starship 1.11.0
What is version of Zsh are you using?
bash 5
What operation system are you running?
Linux
Do you use any Zsh framework or plugin manager?
No response
Which terminal emulator do you use?
No response
Additional information
No response

Wrong repo. It's Spaceship not Starship.


Allow playbooks to run using ansible-runner from automate

We need the parent playbook id in order to find the filesystem
path for the playbook later on.

Looks good to me.  I will get this merged.


AL includes symbols from apps not in the .alpackages folder

AL Extension Version: v9.4.663067

The app files in the main app folder are loaded as symbols and causes it to complain objects already exist in the symbols when they do not in the .alpackages folder

This seems to occur when compiling at which point the new app file is complained about

Can you share what's the value (if any) of the setting al.packageCachePath in your settings.json?

That value is not set

Can you share the contents of your settings.json for both the project and VSCode level? Or share a workspace which reproduces this issue.

This a typical settings.json
{
"CRS.AlSubFolderName":"Source",
"CRS.ObjectNameSuffix":" ",
"CRS.FileNamePattern":"..al",
"CRS.FileNamePatternExtensions":".EXT..al",
"CRS.FileNamePatternPageCustomizations":".EXT..al",
"al.enableCodeAnalysis":true,
"al.enableCodeActions":true,
"al.ruleSetPath":".codeAnalysis\ruleset.json",
"al.codeAnalyzers":["${CodeCop}",
"${PerTenantExtensionCop}",
"${UICop}"],
"alVarHelper.ignoreALSuffix":"",
"editor.minimap.scale":3
}

@lvlaanderen Are you still experiencing this issue? Can you also share all the settings you have defined on a user/workspace/project level?

We cannot reproduce this internally. If this is still happening on the latest version of the AL Extension for VSCode, please re-open and provide all relevant settings.json files.


Handlers matching the same message should execute in parallel

Currently, if there are multiple handlers for the same message type, they are executed sequentially in the loop, as soon as the message is received. This defeats the purpose of  Lamba which is to do scalable parallel processing, and risks getting over the processing limit easily. Each message should be processed in a separate AWS Lambda invocation.

Implemented some way of parallelising the messages, using queues from #4. The message stores the state allowing it to be targeted at a certain handler as opposed to all handlers.


Support for scoped setups

Allow using hxp from local scopes:

This PR depends on #21, and changes Haxelib.runCommand and Haxelib.runProcess to always pre-concatenate the arguments. It allows haxelib to be run from a non-executable command (for instance with lix). The concatenation is pretty naive, so care needs to be taken when dealing with paths.
HXML.buildFile is added and gives the possibility to build a hxml file from a given directory. To work this required to remove the comments from hxml files - see changes in fromString.
A few calls have been updated to allow non-executables commands (namely neko, haxelib and haxe).

Anyone aware of the status of this change?


Update Autofac.Extensions.DependencyInjection to v9.0.0 to allow keyed service support

New Feature Proposal
For more information, see the CONTRIBUTING guide.
Description
Allow keyed service support in the Shell.
Background
When trying to embed my shell in an Aspire Project, I've encountered a issue when hitting the Builder.build() with the following exception : This service descriptor is keyed. Your service provider may not support keyed services
It seems that an update was done to the Autofac.Extensions.DependencyInjection to support keyed service with DotNet8.
I've forced the NuGet package in my AppShell so everything is ok, but I suggest that this library be updated in the Piral.Blazor.Orchestrator nuget.

THanks for the hint - yeah we can update that!

Part of the next preview release.


Revert "image_transport_plugins: 1.15.0-1 in 'noetic/distribution.yam…

…l' [bloom] (#35994)"
This reverts commit 5720a82bf34d8d319f184b7906b1bc0a7f93201c.
Context: https://github.com/ros/rosdistro/pull/35994#issuecomment-1444734306
@ijnek FYI my intent is to undo this ~release~ revert after finishing the EOL process for Debian Buster.

Thanks @sloretz!

Thanks @sloretz, does that mean I wouldn't have to look into the buildfarm failure? 😄

If the catkin/ros-noetic-catkin mixup is only happening on Buster, then I don't see a need to fix it. It is very odd though. May I ask what platform you ran bloom-release on? I might try to reproduce it.

I was doing this in a dev container, and I can't quite recall which base image I was using.
I did do the melodic and noetic release at the same time, so I may have been using osrf/ros-melodic-desktop or osrfros-noetic-desktop.


Add 2d meshes and materials

Objective
The current 2d rendering is specialized to render sprites, we need a generic way to render 2d items, using meshes and materials like we have for 3d.
Solution
I cloned a good part of bevy_pbr into bevy_sprite/src/mesh2d, removed lighting and pbr itself, adapted it to 2d rendering, added a ColorMaterial, and modified the sprite rendering to break batches around 2d meshes.
The PR is a bit crude; I tried to change as little as I could in both the parts copied from 3d and the current sprite rendering to make reviewing easier. In the future, I expect we could make the sprite rendering a normal 2d material, cleanly integrated with the rest.
Remaining work

don't require mesh normals
add an example
support 2d meshes & materials in the UI
bikeshed names (I didn't think hard about naming, please check if it's fine)

Remaining questions

should we add a depth buffer to 2d now that there are 2d meshes?
should we add MSAA support to the sprites, or remove it from the 2d meshes?
how to customize vertex attributes? (#3120)

@cart this appears to be needed for bevy_prototype_lyon to migrate; do you want to add it to the milestone? (ping @Nilirad)

This fixes #3326 so it's part of the 0.6 milestone
For bevy_prototype_lyon, it's using its own shaders / pipeline so probably not related to this one

For bevy_prototype_lyon, it's using its own shaders / pipeline so probably not related to this one

This PR is what will allow people to use their own shaders/pipelines in 2d along the new sprite pipeline.

This implementation has an important difference with how it worked in 0.5 with SpriteBundle. The vertices' positions used to be scaled with the sprite's size. I don't think we should keep that behaviour, but I'm open to feedback.

This implementation has an important difference with how it worked in 0.5 with SpriteBundle. The vertices' positions used to be scaled with the sprite's size. I don't think we should keep that behaviour, but I'm open to feedback.

The default orthographic camera is set to render 1 world unit as 1 pixel. If we change this to be 1-1 with world units then the default 2d camera (and sprite scaling) should also be changed, right?
For the record I much prefer keeping the meshes in world unit scale and adjusting the camera projection scale to correctly display the target pixels per unit.

Attempted to port bevy_prototype_lyon, but I think it needs some sort of support for vertex colors. I think it's really only possible to do solid colors, but strokes and fill can be different colors and they are crammed into the same mesh.
Is that possible as-is with a custom pipeline / shader, or would something like #3120 be required?
I suppose it could generate a separate mesh for stroke and fill, but that doesn't seem ideal.
bevy_prototype_lyon could also use UI support if it were added, but I'm not sure how many people were actually using that feature. "ui shapes" never even made it into a crate release.

Attempted to port bevy_prototype_lyon, but I think it needs some sort of support for vertex colors. I think it's really only possible to do solid colors, but strokes and fill can be different colors and they are crammed into the same mesh.
Is that possible as-is with a custom pipeline / shader, or would something like #3120 be required?
I suppose it could generate a separate mesh for stroke and fill, but that doesn't seem ideal.
bevy_prototype_lyon could also use UI support if it were added, but I'm not sure how many people were actually using that feature. "ui shapes" never even made it into a crate release.

The default orthographic camera is set to render 1 world unit as 1 pixel. If we change this to be 1-1 with world units then the default 2d camera (and sprite scaling) should also be changed, right?

I'm not planning on touching sprite or camera scaling, that stays the same. The difference only applies for people that used a SpriteBundle in 0.5 with custom meshes, and switch to the new 2d meshes with ColorMaterial. Those that use the new SpriteBundle won't be affected.

Attempted to port bevy_prototype_lyon, but I think it needs some sort of support for vertex colors. I think it's really only possible to do solid colors, but strokes and fill can be different colors and they are crammed into the same mesh.
Is that possible as-is with a custom pipeline / shader, or would something like #3120 be required?

It's already possible to define the vertex buffer as you need if you use a custom pipeline and shader, I think #3120's goal it to make it less involved.

I suppose it could generate a separate mesh for stroke and fill, but that doesn't seem ideal.

It sounds like a good temporary hack until #3120 is merged.

bevy_prototype_lyon could also use UI support if it were added, but I'm not sure how many people were actually using that feature. "ui shapes" never even made it into a crate release.

The UI rendering is basically a copy of the sprite rendering already. When we reach a consensus on how 2d meshes and materials should work, I should be able to either clone it into bevy_ui, or maybe add a generic parameter somewhere to reuse it.

The default orthographic camera is set to render 1 world unit as 1 pixel. If we change this to be 1-1 with world units then the default 2d camera (and sprite scaling) should also be changed, right?

I'm not planning on touching sprite or camera scaling, that stays the same. The difference only applies for people that used a SpriteBundle in 0.5 with custom meshes, and switch to the new 2d meshes with ColorMaterial. Those that use the new SpriteBundle won't be affected.

Attempted to port bevy_prototype_lyon, but I think it needs some sort of support for vertex colors. I think it's really only possible to do solid colors, but strokes and fill can be different colors and they are crammed into the same mesh.
Is that possible as-is with a custom pipeline / shader, or would something like #3120 be required?

It's already possible to define the vertex buffer as you need if you use a custom pipeline and shader, I think #3120's goal it to make it less involved.

I suppose it could generate a separate mesh for stroke and fill, but that doesn't seem ideal.

It sounds like a good temporary hack until #3120 is merged.

bevy_prototype_lyon could also use UI support if it were added, but I'm not sure how many people were actually using that feature. "ui shapes" never even made it into a crate release.

The UI rendering is basically a copy of the sprite rendering already. When we reach a consensus on how 2d meshes and materials should work, I should be able to either clone it into bevy_ui, or maybe add a generic parameter somewhere to reuse it.

I'm not planning on touching sprite or camera scaling, that stays the same. The difference only applies for people that used a SpriteBundle in 0.5 with custom meshes, and switch to the new 2d meshes with ColorMaterial. Those that use the new SpriteBundle won't be affected.

I understand, what I'm trying to say is it could be confusing to have opposite default scaling behavior between a custom 2d mesh and a 2d sprite. They should stay the same, and if we're going to change one we should change both in my opinion.

I'm not planning on touching sprite or camera scaling, that stays the same. The difference only applies for people that used a SpriteBundle in 0.5 with custom meshes, and switch to the new 2d meshes with ColorMaterial. Those that use the new SpriteBundle won't be affected.

I understand, what I'm trying to say is it could be confusing to have opposite default scaling behavior between a custom 2d mesh and a 2d sprite. They should stay the same, and if we're going to change one we should change both in my opinion.

In other words if someone makes a Mesh2dBundle with a unit sized quad for a mesh, wouldn't it make intuitive sense for it to render identically to a sprite when using the default orthographic camera?

In that case, why are they not using a sprite? 2d meshes are for a different use case IMO. Also, the texture is optional in ColorMaterial, how would it scale when it's not set?

In other words if someone makes a Mesh2dBundle with a unit sized quad for a mesh, wouldn't it make intuitive sense for it to render identically to a sprite when using the default orthographic camera?

In that case, why are they not using a sprite? 2d meshes are for a different use case IMO. Also, the texture is optional in ColorMaterial, how would it scale when it's not set?

In other words if someone makes a Mesh2dBundle with a unit sized quad for a mesh, wouldn't it make intuitive sense for it to render identically to a sprite when using the default orthographic camera?

In that case, why are they not using a sprite? 2d meshes are for a different use case IMO. Also, the texture is optional in ColorMaterial, how would it scale when it's not set?

In my case I am building a single mesh made up of unit sized squares (a tilemap basically). I'm not using individual sprites because every tile in my grid is built from the same texture and my shader reads unique data to render each tile from the mesh verts.
Of course I have no issue adjusting if the default scaling is changed, just saying it's a case where I intuitively expect it to work similar to a sprite, but maybe my use case is outside the norm.
If the handle doesn't point to a texture I would expect it to default to world scaling.

In other words if someone makes a Mesh2dBundle with a unit sized quad for a mesh, wouldn't it make intuitive sense for it to render identically to a sprite when using the default orthographic camera?

In that case, why are they not using a sprite? 2d meshes are for a different use case IMO. Also, the texture is optional in ColorMaterial, how would it scale when it's not set?

In my case I am building a single mesh made up of unit sized squares (a tilemap basically). I'm not using individual sprites because every tile in my grid is built from the same texture and my shader reads unique data to render each tile from the mesh verts.
Of course I have no issue adjusting if the default scaling is changed, just saying it's a case where I intuitively expect it to work similar to a sprite, but maybe my use case is outside the norm.
If the handle doesn't point to a texture I would expect it to default to world scaling.

Actually nevermind, now that I'm thinking about it I'm having to manually scale each "tile" anyways otherwise they would all be the size of the entire texture. I think changing the default does make sense, you were right in the first place.

Actually nevermind, now that I'm thinking about it I'm having to manually scale each "tile" anyways otherwise they would all be the size of the entire texture. I think changing the default does make sense, you were right in the first place.

No problem, thanks for testing the PR and giving feedback 😄

No problem, thanks for testing the PR and giving feedback 😄

I wasn't happy with the previous solution to break sprite batching. It simply allowed other kinds of 2d items to add their depth in ExtractedSprites (and did it for those based on 2d materials).
Pros:

keeps performance in bevymark
few modifications to bevy_sprite

Cons:

only works for sprite, it would be difficult for someone to batch their custom 2d pipeline too

In order for batching to work for all 2d pipelines, it needs to work directly on the render phase, after all items have been added.
Pros:

can work for any number of pipelines
it's easy to add batching to custom pipelines

Cons:

reduces perf in bevymark (around 15% on my computer), since the items are all copied into the render phase (instead of only adding one item per batch)

The performance comparison is not exactly fair, it was worse at first so I did an optimization pass (but that could be backported to the previous batching solution). Also, the extract function is now more than twice as fast, which will make actual pipelining even more desirable.
The new solution introduces a BatchedPhaseItem trait, based on CachedPipelinePhaseItem, and a system in the PhaseSort stage that does the batching. Batching is not added to 2d meshes.
Other changes:

most work is now done in RenderStage::Queue, is that OK or should I split as much as possible into RenderStage::Prepare at the cost of some perf?
added the image size in GpuImage to avoid having to hash the Handle of every sprite
switched to directly use GlobalTransforms instead of calculating a Mat4
changed how rect and atlas_size worked since I found it very confusing, and added a custom_size field to TextureAtlasSprite for parity with Sprite

I wasn't happy with the previous solution to break sprite batching. It simply allowed other kinds of 2d items to add their depth in ExtractedSprites (and did it for those based on 2d materials).
Pros:

keeps performance in bevymark
few modifications to bevy_sprite

Cons:

only works for sprite, it would be difficult for someone to batch their custom 2d pipeline too

In order for batching to work for all 2d pipelines, it needs to work directly on the render phase, after all items have been added.
Pros:

can work for any number of pipelines
it's easy to add batching to custom pipelines

Cons:

reduces perf in bevymark (around 15% on my computer), since the items are all copied into the render phase (instead of only adding one item per batch)

The performance comparison is not exactly fair, it was worse at first so I did an optimization pass (but that could be backported to the previous batching solution). Also, the extract function is now more than twice as fast, which will make actual pipelining even more desirable.
The new solution introduces a BatchedPhaseItem trait, based on CachedPipelinePhaseItem, and a system in the PhaseSort stage that does the batching. Batching is not added to 2d meshes.
Other changes:

most work is now done in RenderStage::Queue, is that OK or should I split as much as possible into RenderStage::Prepare at the cost of some perf?
added the image size in GpuImage to avoid having to hash the Handle of every sprite
switched to directly use GlobalTransforms instead of calculating a Mat4
changed how rect and atlas_size worked since I found it very confusing, and added a custom_size field to TextureAtlasSprite for parity with Sprite

Silly question maybe but I still don't understand why 2D and 3D are that much separated. And now, as the PR description details, we're cloning even more functionality from 3D into 2D to be on parity. Why can't there be a single path for both 2D and 3D meshes? Isn't a 2D mesh just a corner case of a 3D one? Is there any other engine going to that length to separate 2D and 3D? We have already some optimizations for 2D cases, like the layered distance calculation (Z-based instead of Euclidian). What else is so specific that it cannot be made generic over 2D and 3D?

Silly question maybe but I still don't understand why 2D and 3D are that much separated. And now, as the PR description details, we're cloning even more functionality from 3D into 2D to be on parity. Why can't there be a single path for both 2D and 3D meshes? Isn't a 2D mesh just a corner case of a 3D one? Is there any other engine going to that length to separate 2D and 3D? We have already some optimizations for 2D cases, like the layered distance calculation (Z-based instead of Euclidian). What else is so specific that it cannot be made generic over 2D and 3D?

Silly question maybe but I still don't understand why 2D and 3D are that much separated. And now, as the PR description details, we're cloning even more functionality from 3D into 2D to be on parity. Why can't there be a single path for both 2D and 3D meshes? Isn't a 2D mesh just a corner case of a 3D one? Is there any other engine going to that length to separate 2D and 3D? We have already some optimizations for 2D cases, like the layered distance calculation (Z-based instead of Euclidian). What else is so specific that it cannot be made generic over 2D and 3D?

Not a silly question actually! I think we are going in the opposite direction: increasing the divergence between 2d and 3d over time. While there are some common foundations, they are quite different. For instance, everything related to lighting (e.g. PBR, clustered rendering) only applies to 3d. We also plan to test having a specialized Transform for 2d. Having separate APIs can be more ergonomic.

Silly question maybe but I still don't understand why 2D and 3D are that much separated. And now, as the PR description details, we're cloning even more functionality from 3D into 2D to be on parity. Why can't there be a single path for both 2D and 3D meshes? Isn't a 2D mesh just a corner case of a 3D one? Is there any other engine going to that length to separate 2D and 3D? We have already some optimizations for 2D cases, like the layered distance calculation (Z-based instead of Euclidian). What else is so specific that it cannot be made generic over 2D and 3D?

Not a silly question actually! I think we are going in the opposite direction: increasing the divergence between 2d and 3d over time. While there are some common foundations, they are quite different. For instance, everything related to lighting (e.g. PBR, clustered rendering) only applies to 3d. We also plan to test having a specialized Transform for 2d. Having separate APIs can be more ergonomic.

I just added back the 2d mesh example that was removed with the old renderer. It shows how to have different vertex attributes, so @rparrett may be interested.

I just added back the 2d mesh example that was removed with the old renderer. It shows how to have different vertex attributes, so @rparrett may be interested.

Here's a quick and dirty version of bevy_prototype_lyon that uses that new example as a base and strips out the UI feature.
Seeing some occasional funky artifacts in the dynamic_shape example. These artifacts show up only on some executions of the example, so maybe there is some sort of system ordering bug?
But the artifacts themselves look an awful lot like a second shape with messed up vertex attributes is being rendered on top of the correct shape.
https://github.com/rparrett/bevy_prototype_lyon/tree/mesh2d-color
https://user-images.githubusercontent.com/200550/147862729-0453eb50-38bd-4157-8659-35344526931b.mp4

This doesn't seem to happen with the new mesh2d example, so I'm assuming that this is user error on my end somewhere.

Yep, that was definitely my bad. Appears to be working great now.

I'm not sure if I'm missing something but my shader doesn't seem to work if I read the text via a separate file with include_str!, rather than including it inline. Your example works as is, but I copy and paste your shader into a separate file and try to load it via include_str! I get this error:
2022-01-02T14:06:07.513187Z ERROR bevy_render::render_resource::pipeline_cache: failed to process shader: Unresolved import: Custom("bevy_sprite::mesh2d_view_bind_group\r").

2022-01-02T14:06:07.513187Z ERROR bevy_render::render_resource::pipeline_cache: failed to process shader: Unresolved import: Custom("bevy_sprite::mesh2d_view_bind_group\r").

Seems like that \r might have something to do with it. I think the shader wants unix line endings.

I have ported bevy_svg to a specialization of this pipeline (thanks for your code @rparrett, made my life a lot easier 😀). Works great so far, hope we can get it into the 0.6 release.

It's already possible to define the vertex buffer as you need if you use a custom pipeline and shader, I think #3120's goal it to make it less involved.

👍
Yes, #3120 primarily solves the vertex attribute sorting issue and boilerplate. Otherwise, it's easy enough to just implement your own pipeline specialization to add vertex attributes.

Things seem to be generally behaving. This example takes a stack of "square bird hexagon" and cycles through each of them first bringing them to the front of the stack, the back of the stack, and back to where they started.
https://gist.github.com/rparrett/6c83e1c193990e6e08789402748bcdb2
https://user-images.githubusercontent.com/200550/148136581-3b0df63f-cb48-495c-99e2-d9ff51c86938.mp4

I am able to reproduce the slight perf hit in bevymark vs main, but on my (mac m1) machine, it's more like 5-10% perhaps. (with cargo run --example bevymark --release -- 5 100)

The performance of bevymark on my computer has a lot of variation (even over time for a single run), so it's difficult to give a precise number. I kept 15% as a higher bound to be safe, but on average it seems closer to your numbers.

Might be a good idea to put together an example/demo to ensure that draw order / layering and stuff works properly when mixing colored sprites, textured sprites and mesh2d.

I tested it works by adding a few items to the sprite example. I didn't include it in the PR since it should be a dedicated example, and I couldn't find a nice idea of what to show. Would you like to include your example? (I think you could open a PR to this branch)

I updated my game that utilizes this (by way of bevy_prototype_lyon), without any issues in native or web builds.

That's great :smile:

It didn't seem like a super interesting example from a user's perspective to me, and it's pretty much just a mashup of sprite.rs, rect.rs, and #2973. So I'm not personally very interested in cleaning it up and trying to include it.
Seemed like a useful thing to have in the commentary section of this PR though.
Maybe a simpler example than mesh2d.rs or #2973 showing how to use Mesh2dBundle would be useful though?
Happy to work on any of the above if it helps this PR through.

I can't seem to get Mesh2dBundle to render. I made a simple test:
https://gist.github.com/sarkahn/f77b591103e88fee7e773966ab1f510a
Renders nothing for me.

I can't seem to get Mesh2dBundle to render. I made a simple test: https://gist.github.com/sarkahn/f77b591103e88fee7e773966ab1f510a
Renders nothing for me.

let material = materials.add(asset_server.load("branding/icon.png").into());

Seems to fix it.

I can't seem to get Mesh2dBundle to render. I made a simple test: https://gist.github.com/sarkahn/f77b591103e88fee7e773966ab1f510a
Renders nothing for me.

let material = materials.add(asset_server.load("branding/icon.png").into());

Seems to fix it.

Ahh yup, that did it. The new version of Sprites take the direct image handle so that's how I got mixed up, thank you!

And I'm worried that in practice this impl won't batch across z-levels as much as it could:
[A(z = 1), B(z = 2), A(z=2)]]
We could technically batch A, but because B got arbitrarily sorted in front of A, the batches will remain split. Handling that case properly would probably require moving batching back to being more local, then somehow checking if something somewhere would split the batch. That would have the benefit of allowing us to do arbitrary batch logic per-context (and maybe regain some sprite batching perf). But that would require some synchronized "is there something else on this z-level" operation. Not sure doing that work would be a net win on average, but its worth discussing.

That's an option too, we could bench it. I'm more partial to a generic solution that also accounts for the on-screen overlap to really maximize batches.

Part of me wishes we waited to implement generic batch merging: the sprite perf loss is regrettable (~100k at 60fps to ~90k). We've already lost a bit of perf as the renderer expanded, so losing even more "hurts".
If the old "non-generic" version is still available somewhere, id like to see it (github doesnt show the old version). But I wouldn't block on that.

The commit before the generic version is 798a0ba, we could use it for 0.6 and postpone the generic stuff (we might want to backport the perf improvements). Nical suggested on discord to use the copyless crate, and it does recover some of the lost fps, so we could fast-track that. We could also remove the ComputedVisibility component on sprites to reduce time spent in the visibility system at the cost of frustum culling.

I pushed the other possible perf improvements in this branch if you want to try them: https://github.com/Davier/bevy/tree/mesh2d_perf

Seems like frustum culling starts becoming a win again  in many_sprites on my machine when doubling this value
let map_size = Vec2::splat(320.0); // culling pulls ahead at 640.0 or so, or ~380k sprites

The commit before the generic version is 798a0ba,

Bawhaha my commit search was apparently laughably bad :smile:

I pushed the other possible perf improvements in this branch if you want to try them: https://github.com/Davier/bevy/tree/mesh2d_perf

I'm getting ~8k more sprites with these. Seems worth it!  Looks like removing ComputedVisibility and copyless yield similar sized wins and the partial_cmp change barely registers. I dont think we should directly expose alloc().init() where possible. Instead RenderPhase::add and BufferVec::push should do it internally. Lets add those to the impl currently on this branch and call it a day!

Seems like frustum culling starts becoming a win again in many_sprites on my machine when doubling this value

Note that Sprites don't currently have frustum culling. Visibility just gets mirrored to ComputedVisibility.

That explains a great deal.

Also: @Davier let me know if you won't be able to add the optimizations to this pr by the end of the day. Happy to pick up that work.

@cart done! I'll go to sleep now though, please handle it if I broke anything :smile:

bors r+


Design inspiration

Goodhertz

Check out the cool sine waves they have animating in the background:

Yule Log 2015
The match burns down as your scroll
http://www.watchyulelog.com/2015/#/

Pitchfork Footer


removed unnecessary link

@ruslan528 : Thanks for your contribution! The author(s) have been notified to review your proposed change.

@ruslan528 Thank you for this correction. This is better. I apologize for the delayed response. #sign-off.


InjectManifest The 'swSrc' file can't be read. ENOENT: no such file or directory error on Gitlab CI

Hi,
I am able to build the Sveltekit app successfully in my local environment (using podman with image node:18), but when I run the build command from within a Gitlab-CI runner using the same image (node:18) running the exact same commands I get the following error, after building the ssr bundle, when it's building client-side files. It instantly fails with the following error.
vite v4.4.9 building SSR bundle for production...
transforming...
✓ 321 modules transformed.

[vite-plugin-pwa:sveltekit:build] The 'swSrc' file can't be read. ENOENT: no such file or directory,
open '/builds/metier-plus/web/test/admin/.svelte-kit/output/client/service-worker.js'

		SvelteKitPWA({
			strategies: "injectManifest",
			mode: process.env.NODE_ENV,
			srcDir: "./src",
			filename: "sw.ts",
			scope: "/",
			base: "/",
			// injectRegister: null,
			selfDestroying: process.env.SELF_DESTROYING_SW === "true",
			manifest: {
				name: "App",
				short_name: "App",
				start_url: "/",
				scope: "/",
				display: "standalone",
				theme_color: "#ffffff",
				background_color: "#ffffff",
				icons: [
					{
						src: "/android-chrome-192x192.png",
						sizes: "192x192",
						type: "image/png",
					},
					{
						src: "/android-chrome-512x512.png",
						sizes: "512x512",
						type: "image/png",
					},
					{
						src: "/android-chrome-512x512.png",
						sizes: "512x512",
						type: "image/png",
						purpose: "maskable",
					},
				],
			},
			injectManifest: {
				globPatterns: ["client/**/*.{js,css,ico,png,svg,webp,woff,woff2}"],
				maximumFileSizeToCacheInBytes: 10 * 1000 * 1000,
                                // Tried with & without
				injectionPoint: undefined,
			},
                       // Tried with & without
			workbox: {
				globPatterns: ["client/**/*.{js,css,ico,png,svg,webp,woff,woff2}"],
				maximumFileSizeToCacheInBytes: 10 * 1000 * 1000,
				injectionPoint: undefined,
			},
			devOptions: {
				enabled: !process.env.SW_DEV,
				type: "module",
				navigateFallback: "/",
			},
		}),

It might be a Vite/Sveltekit issue? It seems like Vite/Sveltekit doesn't load the configs for the client-side bundling, so Sveltekit doesn't create the .svelte-kit/output/client directory & then VitePWA errors for the directory not found?

@haleksandre have you configured kit sw entry? https://vite-pwa-org.netlify.app/frameworks/sveltekit.html#generate-custom-service-worker
Latest kit pwa plugin version will delegate sw build to kit, and so you need to configure src/sw.ts in the kit config file. CHECK the entry in the docs, you will need to include/change a few things.

Yes, my svelte.config.js config is like so
import adapter from "@sveltejs/adapter-node";
import preprocess from "svelte-preprocess";

/** @type {import('@sveltejs/kit').Config} */
const config = {
	// Consult https://github.com/sveltejs/svelte-preprocess
	// for more information about preprocessors
	preprocess: preprocess(),

	kit: {
		adapter: adapter({ out: "dist" }),
		env: {
			publicPrefix: "API_URL",
		},
		serviceWorker: {
			register: false,
		},
		files: {
			serviceWorker: "src/sw.ts",
		},
		csrf: {
			checkOrigin: process.env.NODE_ENV !== "development",
		},
	},
};

export default config;

It is peculiar that everything is building fine on my local using the exact same configs, files within the same image, and environment variables, but fails in the GitLab CI.

Check if the output folder inside .sveltekit contains service-woker.js or sw.js (ot seems former is missing)

Turns out it was indeed an error caused by an environment variable. I did not realize that I had forgotten to add a .dockerignore file in the root, so the building process had access to the .env file when building locally on the host & inside a Dockerfile.  On the CI, there were not such files so the imports of  $env/static/private variables were throwing errors, as they did not exist. Svelte Kit was throwing errors but SvelteKitPWA wasn't catching them. It then tried to build regardless but then itself was throwing an error because the directory of the previous build process was missing. Perhaps add in the build process a way to catch & throw previous build step errors, if possible?
Anyways, thanks for taking the time to help me troubleshoot this issue. :+1:


Git step by step guide - Missing pages

Hello,
I'm not sure if this is the best place to put this but I noticed when looking through your "Git step by step" guide that steps 4 & 5 are yet to be done.
I realise this isn't likely to be high up on your list of priorities but I thought I'd point it out. Also what was meant to be in those parts? If there was an outline of what should be there someone else could write it?

Hi Neil, If you look at the Home Page we intend to add :
Part 4: Using gitflow for feature branches, releases and hotfixes
Part 5: The stash is your best friend
When we gonna get less busy, we will surely add those pages.
Thanks for the notice,
-Phil

Sorry for the greatly delayed reply.
Thanks for that. If I managed to find time, which judging by how long it's taken me to get back to this might not happen, would it be fine for me to write one of the parts?

Well, after nearly 2 years there is still no other text.
I only try to push this up because i think we need this tutorial.

Hey guys, just a Headups here, the company behind this library, GSOFT, has closed his service division this winter. So the support to that library will be done on our own time. I will try to find the time to include your pull request in the next couple of days. Thanks for your patience.
-Phil


Allow custom network strategies

Open up the possibility for new network modes (and existing ones to be replaced).
The need for a "no layer-2" network mode (routing only, no bridges) motivated me to add this, instead of expecting that all possible network modes/strategies will be in libcontainer itself.
NetworkStrategies can be safely registered and queried by multiple goroutines.
Signed-off-by: Fabio Kung<EMAIL_ADDRESS>

I am okay with this but not sure if it gels with the plans for docker-network. @crosbymichael thoughts?

Any pointers on what is docker-network? :-)

ping @icecrime

Docker network plans aside, I have a project which consists of providing a library for network namespace management, with customizable "end-to-end" network strategies. I'm saying "end-to-end" here in that it encompasses both the host and container's aspect of the networking strategy (today it's a kind of a split-brain situation where the caller creates the host side and libcontainer the contained side, such as in Docker creating the bridge and libcontainer the veth pair).
It's too rough to open source yet, and it's unclear what we'll do about it just now, but I'd clearly love libcontainer to rely on it from it netns management (thus skimming the whole netlink/ and network_linux.go pieces from it).
However, IANAM, so I'm not sure my secret plans should prevent this PR from a regular review.

@icecrime is this PR not going through a regular review?

Well, as I said previously, I am not a libcontainer maintainer, and I didn't want any plans to prevent this PR from proper review. Time has passed, this has not been progressing, and docker/libnetwork has now been open sourced, so I don't know :-(

@fabiokung @mrunalp docker-network already a thing and it appeared as slightly different mechanism(pre-created network namespaces). So I'm +1 to this change.
@fabiokung Would you mind to rebase?

I think we are going to focus the networking work in the libnetwork repo now.  The contract between libnetwork and libcontainer is that libnetwork will provide the configured network namespace and libcontainer will just join it.
It really does provide much more flexibility and customization with this type of model.  Anyone using libcontainer outside of docker can also use this model as we have done alot of testing and it's super robust and clean.


chore: move test utilities outside of hglib

Description
The exported test-helpers.js from app/scripts/utils includes
"enzyme" as a dependency, which adds about ~1Mb (0.5 minified) to the
3.7Mb (1.9 minified) totoal of HiGlass.
If this is is only used internally, I think we should move these methods to
the /test/ folder and outside the final bundle.
Before
higlass on  develop [$!?] is 📦 v1.11.11 via  v18.1.0 took 11s

❯ ls -la dist
.rw-r--r--  51k manzt 30 Aug 15:35 hglib.css
.rw-r--r-- 3.7M manzt 30 Aug 15:35 hglib.js
.rw-r--r-- 1.9M manzt 30 Aug 15:35 hglib.min.js
.rw-r--r-- 8.8k manzt 30 Aug 15:35 index.html

After
higlass on  develop [$✘!?] is 📦 v1.11.11 via  v18.1.0 took 13s

❯ ls -la dist
.rw-r--r--  51k manzt 30 Aug 15:58 hglib.css
.rw-r--r-- 2.7M manzt 30 Aug 15:58 hglib.js
.rw-r--r-- 1.4M manzt 30 Aug 15:58 hglib.min.js
.rw-r--r-- 8.8k manzt 30 Aug 15:58 index.html

What was changed in this pull request?

Moved app/scripts/utils/tests-helpers.jsx to test/utils/test-helpers.jsx and
remove exports from hglib.js.

Why is it necessary?

Fixes #___
Checklist

[ ] Set proper GitHub labels (e.g. v1.6+, ignore if you don't know)
[ ] Unit tests added or updated
[ ] Documentation added or updated
[ ] Example(s) added or updated
[ ] Update schema.json if there are changes to the viewconf JSON structure format
[ ] Screenshot for visual changes (e.g. new tracks or UI changes)
[ ] Updated CHANGELOG.md

Would it be possible to export those functions that you removed from hglib as another library (hglib.test.js or something to that effect)? They can be useful to plugin libraries that wish to implement tests. I don't know which ones actually do so off the top of my head.
Another potential solution: pass in the mount function as an argument to remove the enzyme dependency.

Would it be possible to export those functions that you removed from hglib as another library (hglib.test.js or something to that effect)? They can be useful to plugin libraries that wish to implement tests. I don't know which ones actually do so off the top of my head.

Yes. I have now implemented this by adding a ./testing entrypoint to the higlass package (./dist/hglib.test.js).

Another option would be to move test/utils/test-helpers.js to the root of the repo and include this file in package.json files. That way consumers would have:
import * as hglib from 'higlass';
import * as helpers from 'higlass/test-helpers.js';

Of the two options you mentioned, which one do you think is better? They seem more or less equivalent to me so the only thing I'd judge on is aesthetics and in that regard the second option wins.


@AutomaticFeature annotation deprecation warning from GraalVM native-image build

Just noticed the following warning from a rewrite-clj native-image test build:

Warning: Feature class InitAtBuildTimeFeature is annotated with the deprecated annotation @AutomaticFeature. Support for this annotation will be removed in a future version of GraalVM. Applications should register a feature using the option --features=InitAtBuildTimeFeature

Thought it would be good to record here as we might have to actually act on it someday.

Yeah, probably just documentation that users should add that flag to their build?

I think it might be better to add an explicit package to that class as well.

Yup and yes.
This is technically a breaking change.
So might as well go to a v1.x release.

I don't think this is a breaking change since users didn't have to reference the class name before, it was automatic.

But the build interface will have changed, no?
After users bump graal-build-time, builds will break if they don't take action of adding --features=.....
(assuming that we also remove the @AutomaticFeature annotation which is slated for removal by Graal team).
The break is imposed by changes to Graal, but still breaking from a user perspective, I think.

Right, but that's not a breaking change in our library

Anyway, I'm fine with a 1.0.0 release :)

Also, I think it might be good to move to io.github instead of com.github

@borkdude, for the io.github scheme I see your old question on Slack:

For a library coordinate, do you prefer com.github.foo/lib or io.github.foo/lib or don't care? Tag with :arrow_left: for the first, :arrow_right: for the second or :shrug: with don't care.

And Alex Miller responded with:

I prefer the latter because it maps to the web page you can publish from the project (which maybe is the seed of an ownership verification scheme)

Is that still the primary benefit?
(Totally fine with this btw, just trying to understand what problem we are solving)

The problem is that everyone seems to have shifted to that, but it doesn't really matter that much

I'm making a sweep update to graal-docs, #clj-easy/graal-docs#58.
I may as well tackle this one so I can use something not-deprecated in examples.

I think I'll stick with com.github for the artifact so that tools like antq can discover the new version.
The new version won't work for folks without any changes, but at least they'll be more likely to learn about it. And the CHANGELOG/README will explain.
Does that make sense to you too?

Yeah, let's stay with com.github.

Implementation note: now that we aren't using a java annotation, thought it might be nicer to switch our java source to clojure source and use :gen-class. It did not work out (something to do with default interface methods).
Sticking with java source.

Currently our fully qualified Feature class is InitAtBuildTimeFeature (it is package-less).
New name candidates:

clj_easy.graal_build_time.InitAtBuildTimeFeature - keeps old name but adds package
clj_easy.graal_build_time.InitAtBuildTime - it will be obvious it is a feature, we can drop the suffix
clj_easy.graal_build_time.InitClojureClasses - describes specific goal
clj_easy.graal_build_time.InitClojurePackages - describes actual work
clj_easy.graal_build.time.ClojureTweaks - generic name, allows Feature to take on additional work in some later version if need be.

Because this name will be now specified on the native-image command line it deserves a bit of thought.
I seem to like the package name (as I haven't shown any alternatives!).
My wip is currently using option 3 but am very open to ideas/feeback/suggestions.

I like both 3 and 4 as make clear to users what will do as it's what they care that the feature will do

4 would be the best I think

or 3, also fine, agreed :)


Daemon authenticate for payload image download

- Description of the problem which is fixed/What is the use case
When a payload image is stored in a private repository the daemon
needs to authenticate with the registry to be able to download it.
- What I did
Two sets of changes, one in the controller the other one in the daemon.
controller:

When using a private repository for the payload image the
daemon can now use the authentification credentials from a
Kubernetes secret that is provided by the user.
This patch adds two environment variables for username and password
to the daemon pod specification. The values are taken from a
secret that the user needs to create before the pods are created.
The environment variables are declared as optional so that no error
occurs without the secret.

daemon:

When a payload image is stored in a private repository the daemon
needs to authenticate with the registry to be able to download it.
There are two environment variables defined in the daemons pod
specification. These variables are populated by a Kubernetes secret that
the user can create. It needs to be created before the daemons start to
run.
The variables and the secret are optional and will only be used when
a configmap for a custom payload image is used. See the documentation
for instructions for how to use the configmap and the secret for custom
payload containers.

- How to verify it
See description in docs/DEVELOPMENT.md
- Description for the changelog
Allow using payload containers in private repositories by providing credentials with a secret.

/lgtm

/lgtm


Make flag icon more customizable

It's really difficult to get the flag icon in template to show up where I would want it to go- is it possible to get {% render_flag_form post user %} variable as an HTML element or template variable so we can put it where we want? The icon is always at the far right regardless where I put it.

Thanks for the feedback.
I agree this is something that should be a lot easier to customize. As of now, this behavior of the icon floating towards the right comes from CSS.
https://github.com/abhiabhi94/django-flag-app/blob/509b3d56ca53a994aa9d6dcd1f0782d588e0d194/flag/static/flag/css/flag.css#L32-L36
The class flag-icon is need by the JavaScript file flag.js for some processing. So the name needs to be there. Although you can override the default static files pretty similar to how you override the default templates. For more information on this, please see https://docs.djangoproject.com/en/dev/ref/contrib/staticfiles/#collectstatic
If you have any ideas, how we can make this customization easier, I would love to know them.

There is more some information in the documentation about customizing the flag icon. Please see https://django-flag-app.readthedocs.io/en/latest/style-customisation.html#flag-icon in case, this fits your case.


doxygen.bitcoincore.org unreachable

It appears https://doxygen.bitcoincore.org/ is down at least since 2024-09-13 (irc):
% curl doxygen.bitcoincore.org
curl: (28) Failed to connect to doxygen.bitcoincore.org port 80 after 75051 ms: Couldn't connect to server

% dig doxygen.bitcoincore.org +short A
<IP_ADDRESS>

Note: this subdomain is referenced in the Bitcoin Core documentation, notably in README.md and developer-notes.md

https://doxygen.bitcoincore.org/ is up and running again
(server was moved to a new IP, and had to update the crontab script for cmake)


error with DHL

I received this error from DHL
`

| "\nInternal  Server  Error\n\nInternal  Server Error - Read\nThe server encountered an internal error  or misconfiguration and was unable to\ncomplete your  request.\nReference #3.24257e68.1680588028.ad8edecc\n\n"
-- | --

`

Einfach mal ein paar stunden warten Fehler 500 ist ein dhl Fehler

I can confirm the issue with login to DHL. I tried to wait a couple of days because I thought it might be a rate-limit but the issue seems to persist.
In the log you can see that there is also the AxiosError. So I guess #44 references the same issue.
parcel.1 | 2023-04-11 11:07:56.137 | error | "\n<TITLE>Internal Server Error</TITLE>\n\n
Internal Server Error - Read
\nThe server encountered an internal error or misconfiguration and was unable to\ncomplete your request.
\nReference #3.44d96b68.1681204076.d32431d\n\n"
parcel.1 | 2023-04-11 11:07:56.137 | error | AxiosError: Request failed with status code 500
parcel.1 | 2023-04-11 11:07:55.811 | info | Login to DHL
parcel.1 | 2023-04-11 11:07:55.773 | info | starting. Version 0.0.25 in /opt/iobroker/node_modules/iobroker.parcel, node: v16.19.0, js-controller: 4.0.24

is fixed with 0.0.27


Update citation reference

Codecov Report

Merging #385 (ef380a9) into main (20ba005) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main     #385   +/-   ##
=======================================
  Coverage   93.43%   93.43%
=======================================
  Files          56       56
  Lines        2179     2179
  Branches      288      288
=======================================
  Hits         2036     2036
  Misses         86       86
  Partials       57       57

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 20ba005...ef380a9. Read the comment docs.


Bugfix: fixes variable name generator to prevent 'do' from being generated.

Prevents variable names do from being generated which is a reserved keyword in JavaScript. The test case will fail unless the bugfix is applied.
Continuance of PR (separate branch): https://github.com/konsoletyper/teavm/pull/658

Made my own fix