Cleanup Android input on render thread settings

Follow up to https://github.com/godotengine/godot/pull/93933
Clean up the set of settings used to control whether Android input should be dispatched on the render thread.
Addresses comments in https://github.com/godotengine/godot/pull/93933#discussion_r1666071821 and https://github.com/godotengine/godot/pull/93933#issuecomment-2210437977

Looks great. I also totally agree with merging the concepts of input buffering and agile flushing since they always work in tandem and that makes things simpler.
My only remaining concern is regarding accumulated input. I think whether it's enabled or nor shouldn't contribute to deciding which thread to send events through. Accumulation works regardless agile flushing is enabled or not since it will use the input buffer regardless. In case agile flushing is enabled, well, it will have fewer chances of merging events, but between flushes it will still accumulate as events come.

My only remaining concern is regarding accumulated input. I think whether it's enabled or nor shouldn't contribute to deciding which thread to send events through. Accumulation works regardless agile flushing is enabled or not since it will use the input buffer regardless. In case agile flushing is enabled, well, it will have fewer chances of merging events, but between flushes it will still accumulate as events come.

@RandomShaper I am not sure I understand the concern, can you clarify.
Input events are dispatched on the render thread whenever input buffering is disabled. With the current logic this happens when both accumulated input and agile flushing are disabled, hence why accumulated input is checked prior to deciding where to dispatch the input events.

My point is that sending via the render thread should happen if, and only if, agile input is disabled. Whether accumulation is enabled or not is unrelated. Accumulation just means that events are not parsed directly but added to a buffer and new events can be merged with the last one in the buffer. That works the same regardless which thread sends the events. The only difference is that if agile flushing is enabled (events sent from UI thread), there will be multiple flush points per frame, and if agile is disabled (events from render thread) there will be a single flush.

Make sense! I've updated the criteria for dispatching on the render thread to only depend on the state of agile input.

Thinking about it some more, I want to make sure we're all aligned on the new proposed behavior as it'll change the default input dispatch thread..
The previous criteria for dispatching input events from the UI thread was:

is there a buffer so that the UI thread doesn't block parsing and routing the input event?

This meant that both accumulated input and the default behavior (given input buffering was always enabled on Android) would dispatch input from the UI thread (a bit of a moot point though as there was no alternatives).
The new criteria for dispatching input events from the UI thread is:

is agile input enabled?

If true, we dispatch from the UI thread, otherwise we dispatch from the render thread.
The change in behavior is that previously, the default configuration (agile input disabled, accumulated input enabled) would dispatch from the UI thread.
With the update, the default configuration now dispatches from the render thread.

My notion is that before #93933 input events on Android were delivered via the UI thread uncontionally (moreover, regardless accumulation being enabled or not).
Input buffering was enabled at startup regardless any setting:
https://github.com/godotengine/godot/blob/e6448ca0aa050b71cb40d9658b7233b8ec7f7382/platform/android/display_server_android.cpp#L654
And then, for instance, when user triggered an input event, this code path woud be followed:

GodotInputHandler.onTouchEvent() would be the first function under our control getting the event that would then call back to another method of itself:
https://github.com/godotengine/godot/blob/e6448ca0aa050b71cb40d9658b7233b8ec7f7382/platform/android/java/lib/src/org/godotengine/godot/input/GodotInputHandler.java#L225

GodotInputHandler.handleTouchEvent() would then invoke the C++ implementation of dispatchTouchEvent():
https://github.com/godotengine/godot/blob/e6448ca0aa050b71cb40d9658b7233b8ec7f7382/platform/android/java/lib/src/org/godotengine/godot/input/GodotInputHandler.java#L639

Java_org_godotengine_godot_GodotLib_dispatchTouchEvent() would in turn pass the event to AndroidInputHandler:
https://github.com/godotengine/godot/blob/e6448ca0aa050b71cb40d9658b7233b8ec7f7382/platform/android/java_godot_lib_jni.cpp#L307

AndroidInputHandler::process_touch_event() would then send the event to Input to be parsed there:
https://github.com/godotengine/godot/blob/e6448ca0aa050b71cb40d9658b7233b8ec7f7382/platform/android/android_input_handler.cpp#L238

All that happens within the UI thread.

All that happens within the UI thread.

Yeah I agree, my comment was that now the default will be to use the render thread. If we are okay with that then I'm good to go.
Also should we have agile input flushing enabled by default?
Is there a reason why it's disabled by default?

That's a good question. I don't have a strong opinion. If anything, given that it's only implemented on Android, it may be better to have it as opt-in per the least astonishment principle. In the future we should have the same thread split and so agile flushing will be available everywhere. If we ever reach that point, having it as a default would make more sense. But, again, I'm not a big proponent of either way.

Working on one additional set of changes to help limit the creation of Runnable objects when dispatching input to the render thread.

Working on one additional set of changes to help limit the creation of Runnable objects when dispatching input to the render thread.

On second thought, I'll do the memory optimizations in a separate PR, so this PR is good to go.

Thanks!


update renovate.json

[ ] ignore typedoc
[ ] group commitlint

ignoring typedoc because typedoc requires typescript 3.8.x (peer-dependency) and we don't want to bump the peerDependency of dynamo-easy because of that, we don't think it's worth it because new versions of typedoc don't bring essential features


UI Tests

Still need to change string literals into constants, so I'll hold off on asking for a code review, but I wanted to put this up now that tests for what is implemented are done and working.

Can I get a code review, please?

@vokal/ios-developers Anyone free?

on it

Aside from that one test that you're (probably) removing, looks good!

Can i get another review on this, please?

Good to merge! Sorry I didn't see the new commit.

Thanks!  Actually, I should have written a comment.


Tooltips!

In GitLab by @brunocalado on Mar 22, 2022, 14:34
Summary
Can you add a tooltip option for conditions? So, the player can put the mouse over and with it read extra information. This will prevent have to add this to the condition name what makes the actor sheet a mess.
    [character.attributesLeft.conditions]
      type = "ListMany"
      label = "Condições"
      condition = true
      options = [
        ["Fear: "-2"], [tooltip, "description"]
      ]

This feature would be nice in other fields too.

Labels (do-not-change)
/cc @Asacolips

In GitLab by @mclemente on Nov 28, 2023, 16:40
mentioned in commit 9360b826d63f17634dd366c7acc416444c81d66d

In GitLab by @s.paquay1 on Dec 6, 2023, 09:29
mentioned in commit 799c38daeb5929040d73a22de822c3374e79c861


SPIKE: Templating for task definition JSONs

We currently use three JSON files to render and deploy task definitions for running the API, Celery, and Celery beat:

dev-api-task-definition.json
dev-celery-beat-task-definition.json
dev-celery-task-definition.json

These are all pretty much the same - all the environment variables are identical, and we don't want to have those duplicated in three places. One of the only differences is containerDefinitions[0].command, which we execute inside the container.
The field containerDefinitions[0].image is replaced by Github Actions - is there a way of doing arbitrary templating, so we can have one JSON file, and replace the command?

Things have changed since this ticket was created. No longer needed.


scipy.stats.binned_statistic regressed in v1.4.0

Summary
PR #10664 recently changed the behavior of scipy.stats.binned_statistic to raise a ValueError whenever the data contains a non-finite number (e.g., nan, inf).
This new behavior is counter-intuitive because many other statistical methods do not raise exceptions in the presence of NaNs, e.g. np.mean([np.nan]) returns nan rather than raising an exception.
This change was included in SciPy v1.4.0.  I propose that we undo #10664 as part of v1.4.2 for three reasons:

The change caused binned_statistic to start raising unnecessary exceptions in common use-cases that worked fine before (see examples below).
It is common to have nans and infs present in scientific data, so the change will likely affect (crash) a lot of existing software (e.g. it broke a feature of the Lightkurve package; https://github.com/KeplerGO/lightkurve/pull/661).
I believe the change can be reverted without negative consequences.

Examples
In SciPy v1.3.x and earlier, binned_statistic allowed NaN values to be present.  For example:
>>> import scipy.stats, numpy as np
>>> x = [0.5, 0.5, 1.5, 1.5]
>>> values = [10, 20, np.nan, 40]
>>> scipy.stats.binned_statistic(x, values, statistic='mean', bins=(0, 1, 2)).statistic
array([15., nan])

This behavior was sensible because it is consistent with e.g. np.mean:
>> np.mean([np.nan, 40])
nan

A user could choose to ignore the NaNs by providing a custom statistic function, e.g. np.nanmean:
>>> scipy.stats.binned_statistic(x, values, statistic=np.nanmean, bins=(0, 1, 2)).statistic
array([15., 40.])

As of SciPy v1.4.0, the examples above raise this ValueError:
>>> scipy.stats.binned_statistic(x, values, statistic=np.nanmean, bins=(0, 1, 2)).statistic
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/gb/bin/anaconda/envs/sp14/lib/python3.7/site-packages/scipy/stats/_binned_statistic.py", line 180, in binned_statistic
    [x], values, statistic, bins, range)
  File "/home/gb/bin/anaconda/envs/sp14/lib/python3.7/site-packages/scipy/stats/_binned_statistic.py", line 519, in binned_statistic_dd
    raise ValueError('%r or %r contains non-finite values.' % (sample, values,))
ValueError: [[0.5, 0.5, 1.5, 1.5]] or [10, 20, nan, 40] contains non-finite values.

Cause
The behavior changed because these two lines were added via #10664:
https://github.com/scipy/scipy/blob/729efb880058cf841a561c733910f2aefb0a9cf6/scipy/stats/_binned_statistic.py#L518-L519
(Unrelated note: there is a syntax error at the end of line 518; round brackets are missing after any.)
This change was made in response to issue #9010, where a user reported an exception triggered by the use of a statistic that did not deal gracefully with the presence of NaNs.  While I agree it would be worth improving the error message in such a situation, I believe that doing this by refusing NaNs altogether is a negative and unintended regression.

However, throwing it in _bin_edges() is a private method (and new in 1.4.0 release) so most users won't know what it is/does.

I don't think that matters much, as long as the exception message is clear.
Agreed that this change was unintentional. Would be good to replace so the original corner case is still handled but the reported regression is fixed, and then backporting it to 1.4.2.

However, throwing it in _bin_edges() is a private method (and new in 1.4.0 release) so most users won't know what it is/does.

I don't think that matters much, as long as the exception message is clear.

Fair point, I guess _bin_edges() is "private" method so shouldn't really matter to end user, I was thinking in terms of maintenance and development, e.g. understanding where the root cause resides.

Agreed that this change was unintentional. Would be good to replace so the original corner case is still handled but the reported regression is fixed, and then backporting it to 1.4.2.

https://github.com/scipy/scipy/issues/9010#issuecomment-520680191
was the issue you mentioned that I misread, that should be fixed in:
https://github.com/scipy/scipy/pull/11382/files
the test has a case with a np.inf but no np.nan converage. The numpy method isfinite() should catch the np.nan case as well but there isn't a test for that one. I'll add that to the PR-thanks.

Related (recently made) comment in the commit:
https://github.com/scipy/scipy/commit/c509c0fef73fba0b65b03514e1920b9347b2e633#commitcomment-37401479


Avalonia.Skia OpenGlBitmapImpl incorrect OpenGL api usage

Describe the bug
I've been working with OpenTK in Avalonia via an OpenGLControlBase.
In OpenGlBitmapImpl in Avalonia.Skia, specifically lines 163-164, the texture is bound before the active texture is then set back to 0. This is incorrect; the operations should be done in reverse order.
If a control (like I have been doing) sets the active texture to something other than GL_TEXTURE0 during OnOpenGLRender, and doesn't change it back at the end of the function, the subsequent call to glCopyTexSubImage2D fails with GL_INVALID_VALUE because the width and/or height doesn't match the expected value, as the texture in GL_TEXTURE0 - which is now the active texture - is either a null texture or something completely unrelated.
To Reproduce
Steps to reproduce the behavior:

Create a custom control inheriting from OpenGLControlBase
In OnOpenGlRender, attempt to draw some stuff to the control, and culminate with a call  to gl.ActiveTexture(GlConsts.GL_TEXTURE1);
Observe that the control is not drawn.
Now add a gl.ActiveTexture(GlConsts.GL_TEXTURE0); at the end of the function
Observe that the control is now drawn correctly.

Expected behavior
Avalonia does not care what the active texture is at the end of OnOpenGlRender; OpenGlBitmapImpl should call glActiveTexture before glBindTexture, not after.
Screenshots
Correct behavior (with the workaround of manually re-setting active texture):

Incorrect behavior (no workaround):

Desktop (please complete the following information):

OS: Windows, but probably occurs on other platforms too?
Version: 0.10.7

Additional context
N/A

I think this was fixed by #8734


how to run 'train your own HOG detector' code

hi, i have run all the linux shell commands but don't know what to do next to see the output. kindly help
http://softgladiator.com/computer-vision/how-to-train-your-own-hog-detector/#comment-21

If you compiled/built the code using the linux shell commands, and you want to run it, you can simply enter ./opencvhogtrainer to start the program


Update clear command functionality

The clear command clears the entire Dengue Hotspot Tracker.
This functionality is unlikely to be regularly used. We could expand its functionality to clear only the currently shown list. The current functionality can be preserved by listing the entire list, then clearing it.
Let's update the clear command functionality and corresponding tests.

Not... again... :") sorry!!!!


Running client = sapcai.Client('MY_TOKEN') throws Keyerror: 'act'

I am new to the SAPConversationalAI and am trying to use its python SDK.
While trying to run the command sapcai.Client('MY_TOKEN'), I keep getting this error, Keyerror: 'act'

I am new to the SAPConversationalAI and am trying to use its python SDK.
While trying to run the command sapcai.Client('MY_TOKEN'), I keep getting this error, Keyerror: 'act'

Its because the SAP CAI has launched the OAuth concept, so without OAuth authentication you cant access your bot and thats the reason your facing that error


timelimit doesn't work with pyodide

When creating an exercise, putting #| timelimit: 3 doesn't have any effect, the code still runs forever.
Example
#| exercise: ex_1_py
#| timelimit: 3
while True:
  a = 1

The code runs forever

Thanks for reporting!
Working under webR but not under Pyodide. Looks like we just need to add the interruption logic.


fix(security): update dependencies

Ref: https://github.com/advisories/GHSA-jchw-25xp-jwwc

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

npm package (@latest dist-tag)
GitHub release
1.0.5

Your semantic-release bot :package::rocket:


Are the traffic light features in the waymo open dataset used?

I checked the mtr_encoder code and did not find that the "dynamic_map_infos" feature in the processed dataset is used in scene encoding. Did I miss something?

answer found in https://github.com/sshaoshuai/MTR/issues/12


What data is passed through Arloader?

When paying with SOL, we pass https://arloader.io/sol and also a keypair. You also mentioned that if a transaction is failed, you have to manually refund.

How do you store the data? I am mainly concerned about keypairs.
Do you perform a swap for AR or hold an equivalent in SOL for the transaction?
If paying with AR, is it direct with Arweave, or does it also pass through you?
Anything else that Arloader performs as a middleman? or that it could do?

I am interested in the case where Arloader is totally neutral and when it could take a cut by offering a more streamlined process/other features.

Hi, sure - totally transparent here and hopefully handled in a way that respects the privacy of your secrets.

For AR transactions, arloader doesn't take anything, it just processes the transactions with reward going to the network. There is no place in the code even for an option to do anything like tht.
For paying with sol, arloader doesn't send your keys any where. In order to process the transaction at the arloader.io endpoint, arloader sends a prepared and signed solana transaction along with the elements of the arweave transaction needed to create a signature. Then it sends those to the endpoint, submits the sol tx to solana, verifies that the amount was correct and then signs the tx with an ar wallet and sends the signed tx back to the arloader client. Then that signature is added to the tx and submitted directly to arweave.
You can always check to see how much transactions will cost by running arloader estimate and include --with-sol to get the estimate in SOL. U.S. dollars included for both as an additional point of reference. Mostly for simplicity sake, I have that at a fixed exchange rate https://github.com/CalebEverett/arloader/blob/a7a7548c3e6512bac348aa45b1877cbf3ffef92a/src/solana.rs#L26, which currently happens to be pretty close to where the market prices are relative to dollars. I've thought about making that more dynamic, but the volume is fairly low overall and it is mostly there as a convenience.
The arloader code is complete open source, so you can check all of this to verify:. Here is the code for creating the solana tx: https://github.com/CalebEverett/arloader/blob/a7a7548c3e6512bac348aa45b1877cbf3ffef92a/src/solana.rs#L108. And here is where that gets sent to the arloader.io endpoint. https://github.com/CalebEverett/arloader/blob/a7a7548c3e6512bac348aa45b1877cbf3ffef92a/src/lib.rs#L967

Hope that helps, happy to answer any other questions.

Thanks for the explanation. I think this summary could be helpful in your
docs.
On Thu, Mar 10, 2022, 6:05 PM Caleb @.***> wrote:

Hi, sure - totally transparent here and hopefully handled in a way that
respects the privacy of your secrets.

For AR transactions, arloader doesn't take anything, it just
processes the transactions with reward going to the network. There is no
place in the code even for an option to do anything like tht.
For paying with sol, arloader doesn't send your keys any where. In
order to process the transaction at the arloader.io endpoint, arloader
sends a prepared and signed solana transaction along with the elements of
the arweave transaction needed to create a signature. Then it sends those
to the endpoint, submits the sol tx to solana, verifies that the amount was
correct and then signs the tx with an ar wallet and sends the signed tx
back to the arloader client. Then that signature is added to the tx and
submitted directly to arweave.
You can always check to see how much transactions will cost by
running arloader estimate and include --with-sol to get the estimate
in SOL. U.S. dollars included for both as an additional point of reference.
Mostly for simplicity sake, I have that at a fixed exchange rate
https://github.com/CalebEverett/arloader/blob/a7a7548c3e6512bac348aa45b1877cbf3ffef92a/src/solana.rs#L26,
which currently happens to be pretty close to where the market prices are
relative to dollars. I've thought about making that more dynamic, but the
volume is fairly low overall and it is mostly there as a convenience.
The arloader code is complete open source, so you can check all of
this to verify:. Here is the code for creating the solana tx:
https://github.com/CalebEverett/arloader/blob/a7a7548c3e6512bac348aa45b1877cbf3ffef92a/src/solana.rs#L108.
And here is where that gets sent to the arloader.io endpoint.
https://github.com/CalebEverett/arloader/blob/a7a7548c3e6512bac348aa45b1877cbf3ffef92a/src/lib.rs#L967

Hope that helps, happy to answer any other questions.
—
Reply to this email directly, view it on GitHub
https://github.com/CalebEverett/arloader/issues/17#issuecomment-1064697735,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AIKTHU7USQJZEOGY3O2QSETU7KS5NANCNFSM5QN5PCUA
.
You are receiving this because you authored the thread.Message ID:
@.***>


Remove ShelleyLedgerExamples and update cardano-ledger-specs

As by cardano-ledger-specs' PR #2298, the code that was isolated previously is
being moved to the ledger side. This PR updates the ledger-spec dependency
commit to the head of that branch and removes the relevant code.
As a side change, StandardCrypto was defined in Ouroboros.Consensus.Shelley.Protocol.Crypto as
well as in Cardano.Ledger.Crypto, with the same verbatim declaration. Now that
we generate data on ledger's side we are using their StandardCrypto definition
which is incompatible with ours, so in order to fix type errors, our definition
was removed in favor of theirs.
This shouldn't mean any real change because as stated in their code (see the
comment removed in their PR#2298, both definitions MUST have been (and remain)
equal at all times.
Note that the two first commits are related to this PR and the last one updates
ledger-specs and plutus to the correct commits, and fixes imports.
This addresses #3139

bors r+


web/ui/react-app: bump elliptic package version

The elliptic package before 6.5.3 is affected by CVE-2020-13822 (see also https://github.com/indutny/elliptic/issues/226). Though it shouldn't matter for client-side Javascript code, updating to 6.5.3 will avoid future complaints :-)

:+1: Thanks!


Passing a structure made of two Vec3 to a closure results in miscompilation

Example & Steps To Reproduce

Passing a structure containing two Vec3s to a closure results in the following error message:
error: Pointer operand 435[%435] must be a memory object declaration
    %436 = OpFunctionCall %void %sdf_shader__main_fs___closure_0_ %429 %435

    |
    = note: module "/Users/lachlansneff/dev/sdf/target/spirv-builder/spirv-unknown-unknown/release/deps/sdf_shader.spv"

  warning: internal error
    |
    = note: spirv-opt failed, leaving as unoptimized
    = note: module "/Users/lachlansneff/dev/sdf/target/spirv-builder/spirv-unknown-unknown/release/deps/sdf_shader.spv"

  error: invalid id:0:0 - Pointer operand 435[%435] must be a memory object declaration
    %436 = OpFunctionCall %void %sdf_shader__main_fs___closure_0_ %429 %435

    |
    = note: spirv-val failed
    = note: module "/Users/lachlansneff/dev/sdf/target/spirv-builder/spirv-unknown-unknown/release/deps/sdf_shader.spv"

A way to repro is with the following code:
struct Foo {
    a: Vec3,
    b: Vec3,
}

fn bar(f: impl Fn(Foo)) {
    f(Foo { a: Vec3::zero(), b: Vec3::zero() })
}

#[spirv(fragment)]
pub fn main_fs(_: Output<Vec4>) {
    bar(|_| {});
}

System Info

Rust: rustc 1.51.0-nightly (257becbfe 2020-12-27)
OS: macOS 10.15.6

Thank you for your issue! Would you also be able to include the full SPIR-V binary? It should be available at /Users/lachlansneff/dev/sdf/target/spirv-builder/spirv-unknown-unknown/release/deps/sdf_shader.spv
You can include it in the issue like so:

    SPIR-V

Thank you for your issue! Would you also be able to include the full SPIR-V binary? It should be available at /Users/lachlansneff/dev/sdf/target/spirv-builder/spirv-unknown-unknown/release/deps/sdf_shader.spv

It's easy enough to build the SPIR-V, this repros it in the test framework:
#[test]
fn fzoo() {
    val(r#"
struct Foo {
    a: glam::Vec3,
    b: glam::Vec3,
}

fn bar(f: impl Fn(Foo)) {
    f(Foo { a: glam::Vec3::zero(), b: glam::Vec3::zero() })
}

#[spirv(fragment)]
pub fn main_fs(_: Output<glam::Vec4>) {
    bar(|_| {});
}"#);
}

It looks like this would likely be fixed by https://github.com/EmbarkStudios/rust-gpu/issues/69 plus tweaks to mem2reg, but I'm not 100% sure. There's some extremely weird codegen going on, with the Foo temporary variable being wrapped in a one-element tuple (Foo,) while it's a local variable (but not when passed into f). TBH it'd be really nice to instead pass structs by value instead of by pointer, but that requires rustc work.

Is there a way to work around this for the time given?

I can't think of a workaround, if the problem is tupled closure arguments, that's a limitation caused by rustc's broken representation of variadic signatures. I've been tackling this in my spare time lately, so maybe I should try to make more progress on that front.

TBH it'd be really nice to instead pass structs by value instead of by pointer, but that requires rustc work.

OTOH, IIRC this is just the ability to hook FnAbi computation, right? So that might be more doable.

Any progress on this?

Looks like this was fixed by #690 :tada: - or, well, this updated version of the repro at least (Output<T> -> &mut T, and Vec3::zero() -> Vec3::ZERO)
struct Foo {
    a: Vec3,
    b: Vec3,
}

fn bar(f: impl Fn(Foo)) {
    f(Foo {
        a: Vec3::ZERO,
        b: Vec3::ZERO,
    })
}

#[spirv(fragment)]
pub fn main_fs(_: &mut Vec4) {
    bar(|_| {});
}


add UMD bundle for direct loading, such as CDN

@toeverything for example: https://polyfill.web-cell.dev/

Thank you for your suggestion. I am going to work on it soon. Possibly I will publish a seperate package for this.
BTW, please never at an organization or a team, as this will disturb all the developers and send a huge amount of unsolicit emails.
See https://news.ycombinator.com/item?id=31627061 for details.

BTW, please never at an organization or a team, as this will disturb all the developers and send a huge amount of unsolicit emails.\nSee https://news.ycombinator.com/item?id=31627061 for details.

I'm sorry for bother you.
But GitHub has poor Notification for new issues & PRs for years, many Busy Mainteners even don't know these added items, so that replies often come out Months or Years later...
For users, It's usually hard to find out which Developer is active, And which one should be mentioned...


API to get current symbol

Requires #23

get_symbol(opts)

opts

kind
depth
use_icon

returns single string

get_breadcrumb(opts)

opts

depth
kind
use_icon

returns a list of strings

This allows outline integration with things like statusline. Tagbar supports this

No prioritizing for now, in favor of #28


⚠ Fortnite has degraded performance

In 377e5b6, Fortnite (https://fortnite.com) experienced degraded performance:

HTTP code: 200
Response time: 1217 ms

Resolved: Fortnite performance has improved in b9eea07.


Create 03_evaluating_performance.ipynb

Summary
In this notebook, we evaluate the performance of QRAO by determining how closely it approximates the exact solution to MaxCut for 100 random 3-regular graphs. We also compare the performance of QRAO used with two different rounding schemes. In the process, we reproduce the main results of the paper (i.e. Fig. 1).
Details and comments
Running the magic rounding QRAO for a 40-node graph instance takes a while on my machine, so I've set the quantum instance that performs magic rounding to only do 1 shot. We can adjust this easily if necessary. Adding a section to the notebook that analyzes magic rounding QRAO performance (both approximation ratio and execution time) as a function of the number of shots of the rounding quantum instance could be also be interesting.

Preview here

This looks pretty good already.
After reviewing the Diátaxis framework's distinction between tutorials and how-to guides, I actually now think this should be placed in the how-tos directory.  (I was unsure where it belonged before reading this.)
The other important thing to get a handle on is the performance, so that we can continue to regularly run all notebooks as integration tests (using treon).  I'm beginning to investigate this.

I mentioned in #21:

We will probably begin by parameterizing the various basis rotations, so that a single circuit can be sent to the primitives, along with various parameter sets.

One might reasonably hypothesize that repeatedly constructing the circuits takes more time than actually running them on the simulator.  If so, then parametrizing the circuits might allow us to get many more shots than 1 without much additional cost, as we would only have to generate the circuit once, regardless of number of shots.  It would be interesting to evaluate whether my hypothesis is indeed correct (i.e., the relevant time spent generating the circuits vs. simulating them).


[BUG] Refactor SlowIntegrationTests.testDelayInSecurityIndexInitialization()

What is the bug?
That test: SlowIntegrationTests.testDelayInSecurityIndexInitialization() is heavily dependent on custom timeouts and suspending thread while testing to create test scenario.
This causes test to be highly unstable.
Originally posted by @peternied in https://github.com/opensearch-project/security/pull/3706#discussion_r1400946242
What solution would you like?
It would be a good idea to rewrite this test to make in more stable
What is the expected behavior?
Expected behavior is to be able to run tests multiple times without flaky executions.
Exit Criteria

[ ] Refactor SlowIntegrationTests.testDelayInSecurityIndexInitialization()
[ ] Run the test at least 10 times and see no failures - how to do this

[Triage] Closing as a duplicate of https://github.com/opensearch-project/security/issues/2230
@MaciejMierzwa I have opened a PR to address this test (https://github.com/opensearch-project/security/pull/3763). Please provide any review feedback if there are better ways to address the test.


Add official server to subscribe to github updates. Similar to #maplestory-news channel to publish any updates

not sure how to implement but would be cool

Now that auto-update has been enabled, i wont need such announcement server. I could just publish a new image that will do the publishing for me


Fix/furman pivi ang dep

Addresses issue #135

Remember to:

[ ]  Increase versions number
[ ] Update manual with new input
[ ] Run all tests


increment version

NetflixOSS » suro » suro-pull-requests #2 FAILURE
Looks like there's a problem with this pull request

suro-pull-requests #168 FAILURE
Looks like there's a problem with this pull request


Lab 4.2: Practice Lab – Work with data and services

Module: 04
Lab/Demo: 4.2
Exercise 01
Task: 02
Step: 05
Description of issue
I am certain this use to exist, but its not there any longer.
When you ask the users to add formulas to the Onstart property, step 5, you forget to say, select the app section and select RUN ON START. Without this the onstart formulas won't run. So this needs

adding back in
Repro steps:

MOC Labs Review did not experience this issue.


Adding CreateAddress Feature

What current issue(s) does this address, or what feature is it adding?
Adds CreateAddress Feature
How did you solve this problem?
Referenced neo-cli and talked with @ixje
How did you make sure your solution works?
Testing on my own privatenet and created a test for it.
Are there any special changes in the code that we should be aware of?
no.
Please check the following, if applicable:

[x] Did you add any tests?
[ ] Did you run make lint?
[ ] Did you run make test?
[x] Are you making a PR to a feature branch or development rather than master?
[x] Did you add an entry to CHANGELOG.rst? (if not, please do)

Coverage decreased (-0.1%) to 80.068% when pulling 1ac14579537143fb3355f06edfa1a3e9bdf4abd7 on jseagrave21:patch-6 into 3774e9522dcec603b6470c05699dcb8d009d83fc on CityOfZion:development.

I think this is working as intended. Let me know what you think.

Looks good, though the code-style check is failing

Okay, I think I fixed the style errors.

Thank you @ixje! I never used those before because I didn't know what they were.

Nice work!


[RFC] Implement SAML

Need spike for a SAML implementation.
We need to collect requirements for a SAML implementation.

@patrys Is it still something we want to work on, should we keep the task open and prioritize in the backlog?

We should instead work on externalizing the auth flow API so this can be implemented as an app.


Wacom tablet incompatibility

Godot version:
since Godot Engine v3.0.3 - stable_win64
OS/device including version:
Windows 10
Screen resolution : 1920x1080
Issue description:
hello, my wacom tablet (intuos 2015 - model CTH 690) is not working properly with godot since version 3.0.3 (it worked perfectly fine before)

On the project selection screen and when I run the game, I just can't click at all
On the editor, it clicks at the bottom of the arrow (mouse cursor) instead of clicking at the top of it

apparently, it happens with the wacom Intuos CTH-490 as well :
https://godotengine.org/qa/31141/godot-and-wacom-tablet-incompatibility

Couldn't test it with other types of tablets / other brands.
It worked fine up to Godot version 3.0.2 stable win64

thanks !

CC @RandomShaper

Looks as a dupe of #11586, already fixed by #19708.
@nonomiyo , you can expect it to be fixed on 3.0.6.

wow, that's a relief !   You're all doing a great job on Godot, please keep up  💯

I've found that it has only fixed touch but the wacom pens are still not recognized in 3.06. I can get the pens to be recognized if I set (or disable on my other less sophisticated hardware) Windows ink. I've tried with 3 different computers. A Fujitsu t904 with Windows 7 x64, disabling the "Tablet PC Input Service" restored pen function in Godot 3.0.5 and 3.0.6 but at the expense of some functionality within Windows itself. A Fujitsu q584 with Windows 8.1 32 bit where I couldn't figure how to disable Windows ink in 8.1 as disabling the equivalent of "Tablet PC Input Service" didn't help and I couldn't find any other options as the "Feel" drivers on penabled Tablets are much simpler configuration option wise to the professional tablet drivers (which aren't compatible either) so the pen still doesn't work with 3.0.6 (not a concern for me personally but that doesn't invalidate the issue). A HP Zbook X2 with Windows 10 (1703) x64 which uses a more professional pen driver so there is an option to disable Windows ink on a program by program basis. When it is set to off the pen works on 3.0.5 and 3.0.6 but when ink is set to be used it doesn't work.

Oh, that's interesting feedback. Thank you.
I'll research and try to make a definitive fix for this.

@AnnA-Ayms, would you try again with this patched Godot binary?
It it works, for you, then I'll submit a PR with the fix.

Quick answer: I've tested it and the Wacom EMR pen is still unusable in the Godot build you provided unfortunately, but thank you for your effort.
Detailed answer:
With the Fujitsu t904 with Windows 7 x64 the pen doesn't work right but I did now notice that the pen will sometimes be recognized as a single click if I double tap/press with pen so I can open a project and can select nodes in the scene tab or select a property in the inspector tab, as well as toggle boxes on or off with the pen. The pen can not be used even with the double tap to switch between 2D, 3D. Script, AssetLib but the options will get highlighted by the pen (text turns blue) when I double tap but the view doesn't change. The finger touch recognition works fine though. Also a tap then tap and hold down does not get treated as a click hold it is only treated as a single click when it is even recognized as that. In the 3D view I can't select (single click) with the double click/press trick anything though but 2D view does treat the double click/press/tap as a single click. With the script view double click/press jumps to empty lines with no code in them but won't usually select a line with even just a tab in it. It will sometimes select a line with code but not one where I was clicking at and I could not find any order or pattern to which it selected after some experimenting. It was consistent to which line with code it would jump to if the script was the same but I couldn't figure why that line was selected over those around it and changing the script would change which lines with code if any it would jump to. Also I noticed once I used the pen to click (or try to click) anything that pen, touch. and touch-pad didn't seem to be recognized by the minimize/restore/close buttons of the window and I had to use the close button in the command line window to get Godot to close unless I first switched to another program (file explore for example) then went back to Godot and in that case even the pen could minimize/restore/close with a regular single click. If I didn't use the pen then touch-screen and touch-pad both worked fine with the minimize/restore/close buttons at any time. The close confirmation box ("Save & Close" "Cancel" "Don't Save") is similar to 2D, 3D. Script, AssetLib in that the pen only highlights the option if I double tap (single tap does nothing).
With the HP Zbook X2 with Windows 10 (1703) x64 it will work properly as it did before if I disable Windows Ink in the Wacom driver's options but that option is only available on that device out of what I have as it is marketed/sold as a "pro" device so the pen and its drivers are better. With Windows Ink on The behavior seems similar to the Fujitsu t904 with Windows 7 x64 but I didn't test it as thoroughly that way.
I could not test with the Fujitsu q584 with Windows 8.1 32 bit as the provided build was 64 bit (for good measure I did try but got the obvious this program isn't supported by this version of windows error or however it was worded) but I suspect it would be the same as described above.

I'm very happy to hear that. I'm submitting a PR shortly.

Got the same problem with 3.0.4 and 3.0.6. My Wacom Intuos 3 clicks aren't registered at all if I switch to a mouse it works perfectly.

@BrahRah, could you try with the patched binary from the comments above?


Build faiiled while trying to build aar file.

⚠ Issues not using this template will be systematically closed.
While im trying to render my 3d model using filament i faced an issue similar to this so i cloned the filament repo and made changes to the bone count variable. and now i need to build the aar file to use it as android library.
im trying to build this in windows but while executing
cmake ^
    -G Ninja ^
    -DCMAKE_INSTALL_PREFIX=..\release\filament ^
    -DFILAMENT_ENABLE_JAVA=NO ^
    -DCMAKE_BUILD_TYPE=Release ^
    ..\..

this in  cmd following the Building Filament for Android on Windows article i got this below error
CMake Error at CMakeLists.txt:179 (message):
  Detected C compiler GNU is unsupported

i found a similar issue for linux but can i get the solution for windows.

Make sure you have the msvc compiler or clang.


Fix for Env late init issue due to insane Dart design

Details in https://discord.com/channels/1192313062041067520/1231903583717425153/1255280789399273482

c:\src\Friend\apps\AppWithWearable>flutter doctor
Doctor summary (to see all details, run flutter doctor -v):
[✓] Flutter (Channel stable, 3.22.2, on Microsoft Windows [Version 10.0.22631.3810], locale en-US)
[✓] Windows Version (Installed version of Windows is version 10 or higher)
[✓] Android toolchain - develop for Android devices (Android SDK version 34.0.0)
[✓] Chrome - develop for the web
[✓] Visual Studio - develop Windows apps (Visual Studio Community 2022 17.11.0 Preview 1.0)
[✓] Android Studio (version 2023.3)
[✓] VS Code (version 1.90.2)
[✓] Connected device (4 available)
[✓] Network resources

• No issues found!

@josancamon19 here's my flutter version as well
c:\src\Friend\apps\AppWithWearable>flutter --version
Flutter 3.22.2 • channel stable • https://github.com/flutter/flutter.git
Framework • revision 761747bfc5 (3 weeks ago) • 2024-06-05 22:15:13 +0200
Engine • revision edd8546116
Tools • Dart 3.4.3 • DevTools 2.34.3

I think is more of a windows issue than a flutter issue, I will ask on discord if someone else has had this issue

Updated the code to remove the multiple entry points and simplify the startup logic. Here's the Android startup now, but using flutter run and starting from the icon. Flavor is automatically determined, and the Env class is always initialized.
c:\Src\Friend\apps\AppWithWearable>flutter run --flavor dev
Launching lib\main.dart on SM J327T in debug mode...
Running Gradle task 'assembleDevDebug'...                          16.3s
✓ Built build\app\outputs\flutter-apk\app-dev-debug.apk
Installing build\app\outputs\flutter-apk\app-dev-debug.apk...        34.8s
I/flutter (27495): App flavor: dev
...

c:\Src\Friend\apps\AppWithWearable>flutter run --flavor prod
Launching lib\main.dart on SM J327T in debug mode...
Running Gradle task 'assembleProdDebug'...                         34.3s
✓ Built build\app\outputs\flutter-apk\app-prod-debug.apk
Installing build\app\outputs\flutter-apk\app-prod-debug.apk...        33.1s
I/flutter (28285): App flavor: prod
...

Start the app from the icon
c:\Src\Friend\apps\AppWithWearable>adb logcat -s flutter
07-01 14:10:46.490 29639 29686 I flutter : The Dart VM service is listening on http://<IP_ADDRESS>:50451/Uw_1CS8e85Y=/
07-01 14:10:48.138 29639 29668 I flutter : App flavor: prod
07-01 14:10:49.076 29639 29668 I flutter : initializeNotifications: true
...


New package: QConnect v1.0.0

Registering package: QConnect
Repository: https://github.com/p-casgrain/KdbConnect.jl
Created by: @p-casgrain
Version: v1.0.0
Commit: 684790004cb979ce4c34c9cc006eceb67166c66d
Git reference: v1.0.0
Description: Connect Julia and kdb

Y'all can clear this one, I've replaced it with #118203

Closing in favor of https://github.com/JuliaRegistries/General/pull/118203


Roll engine 72986c39ea36..c00364a6c8be (14 commits)

https://github.com/flutter/engine/compare/72986c39ea36...c00364a6c8be
git log 72986c39ea3669ef26d4d7d7cd0c44f513fcd117..c00364a6c8be49abed0c7cdee65cb0b94b2c0f3c --no-merges --oneline
c00364a6c [font_collection] Add missing semicolon (flutter/engine#8546)
ae4df6fd1 Revert "Change Rect internal representation from Float32List to Float64List (#8524)" (flutter/engine#8545)
ffdddb07e Roll src/third_party/skia 6d60534e95d8..76e626d9bb55 (1 commits) (flutter/engine#8544)
5ac728eb6 Roll src/third_party/skia 4d657d5e894a..6d60534e95d8 (3 commits) (flutter/engine#8543)
ee462ff68 Roll src/third_party/skia 99d792276740..4d657d5e894a (1 commits) (flutter/engine#8542)
18816c50f Roll src/third_party/skia 42280f8961fa..99d792276740 (8 commits) (flutter/engine#8539)
892591da8 Android Embedding PR28: Report app is active to Flutter in FlutterFragment.onResume() instead of onPostResume() forwarded from Activity. (flutter/engine#8536)
330c6c168 Use code cache dir for engine cache on API >= 21 (#14704). (flutter/engine#8534)
c10ae2be2 Add an option to build the GLFW shell on macOS (flutter/engine#8531)
29aa5fca0 Roll src/third_party/skia b5c685991faa..42280f8961fa (32 commits) (flutter/engine#8535)
0a2869e5c Added support for authentication codes for the VM service (flutter/engine#8527)
36d2135ad Redo a fix for cull rect calculation on TransformLayers with a perspective transform (flutter/engine#8528)
0b36d3e2f Change Rect internal representation from Float32List to Float64List (flutter/engine#8524)
b1ae0ccb7 Roll src/third_party/skia 10bf7020aa15..b5c685991faa (3 commits) (flutter/engine#8526)
The AutoRoll server is located here: https://autoroll.skia.org/r/flutter-engine-flutter-autoroll
Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+/master/autoroll/README.md
If the roll is causing failures, please contact the current sheriff (jsimmons@google.com), and stop
the roller if necessary.

Trybots failed. These were the failed builds: https://cirrus-ci.com/task/6582241097416704

Commit queue failed; closing this roll.


Singular for a workflow does not exist anymore

Describe the bug
Singular can not be set for a workflow anymore.

Maybe it is a good idea to implement this as a mutex across workflows. With an implementation like this some resources could be shared and blocked across the namespace and the singular feature is covered as well. Something like:
block: myword


Add description and documentation on ocean.js functions

For ocean.js functions add:

[ ] function description
[ ] output parameters description
[ ] input parameters description

Closing it as it was done with the latest ocean.js 2.0 release


[SUGGESTION] moon_phases.png only contains the shadow w/ alpha channel, separate from moon texture

This would allow easy implementation of custom textures for moons.

Nice idea

I provided the texture in my pull request, though it might take some doing to get it so that you don't need *_phases.png for each moon.
What I'd think to do is, rather than drawing a celestial body onto the skybox then drawing the phase on top of it, you either combine the phase with the celestial body as a single sprite, then draw that sprite onto the skybox such that there's only one transparency, or generating *_phases.png assets as needed.

What I'd think to do is, rather than drawing a celestial body onto the skybox then drawing the phase on top of it, you either combine the phase with the celestial body as a single sprite, then draw that sprite onto the skybox such that there's only one transparency

Gonna be honest here, not even a clue where one would begin that with Minecraft.

or generating *_phases.png assets as needed

Or... it could just be a lot simpler and there would be one default file the game defaults to, no need to overcomplicate it.

Gonna be honest here, not even a clue where one would begin that with Minecraft.
That's the neat part. You use some sort of java image library or something. It might be simpler and easier to have one default file, at least in the short term, but it might be nice to have it so that, with only a single planet texture, it generates phases and halo phases (which just seems to be the same halo eight times anyway).

Gonna be honest here, not even a clue where one would begin that with Minecraft.

That's the neat part. You use some sort of java image library or something. It might be simpler and easier to have one default file, at least in the short term, but it might be nice to have it so that, with only a single planet texture, it generates phases and halo phases (which just seems to be the same halo eight times anyway).

The thing is, you don't render images in Minecraft. You call RenderSystem.setShaderTexture() and provide it with the ResourceLocation (path to the file) and RenderSystem does its own thing, no info related to what is on the image involved. The way more advanced rendering is achieved is by calling additional functions afterwards, like setting blending functions and shader properties. The image stays intact.

https://tenor.com/view/dumb-and-dumber-lloyd-theres-a-chance-jim-carrey-gif-11098164

lol


Wiki - Appendix - A: Test Sites - Invalid link listed

The "Browserprint - https://browserprint.info/test" link doesn't work any more on the "Appendix - A: Test Sites" page.

Thanks

heh ... https://<IP_ADDRESS>/ works if you accept the cert risk

I'll comment it out rather than remove it for now
there wasn't much on there that other tests do anyway


How can we help?
I would like someone else to build the manifest.
Please read and ensure the following

[X] The installer meets the above requirements

Please provide the following information
Download Page Url: https://www.airlivedrive.com/en/download/
Publisher: Iniciativas Informáticas y de Comunicación
Package Name: Air Live Drive
Description: Software tool to mount online clouds as volumes under Windows
Package Version: 2.3.0
Installer URL: https://www.airlivedrive.com/downloads/AirLiveDrive-Installer.exe

#120624 120624


build azure dashboard with monitoring metrics.

Once App insights SDK is setup. Build an internal dashboard with relevant metrics. These queries will then be uses publicly for grafana dashboard.

closing because we closed https://github.com/orgs/learntocloud/projects/2/views/1?pane=issue&itemId=18188125


Adds dedicated turn lane going South.

🎉 New feature
Closes #27
Summary
Implements

Test it
To try it, run:
WIDTH=3.3 STOPLINE=True RADIUS=6.0 empy3 src/maliput_xodr/templates/dedicated_turn_lane_going_south.xml.em

Checklist

[x] Signed all commits for DCO
[ ] Added tests
[x] Added example and/or tutorial
[x] Updated documentation (as needed)
[ ] Updated migration guide (as needed)
[ ] Consider updating Python bindings (if it affects the public API)

Note to maintainers: Remember to use Squash-Merge and edit the commit message to match the pull request summary while retaining Signed-off-by messages.

Thanks for creating this! I'll test it ASAP.

@agalbachicar I am running into the following error when loading this map in maliput_malidrive:
terminate called after throwing an instance of 'maliput::common::assertion_error'
  what():  db_manager.cc:VerifyJunctions:604: When verifying JunctionId: 10 , the junction of the connecting road 9 is: -1 which does not match the expected junction id: 10

Here's the line of code that is throwing the exception:
https://github.com/maliput/maliput_malidrive/blob/6bdc024e0dfa8547107f902b9a6825f7217c7326/src/maliput_malidrive/xodr/db_manager.cc#L599-L605

CC: @agalbachicar
using xodr_validate is useful to find issues in the xodr file.
xodr_validate --xodr_file=<path> --log_level=trace
I've used it a lot for debugging, let me take a look asap

Thanks both for pointing it out. I'll get a fixed version ASAP.

Should be fixed now @liangfok , PTAL.

I confirm the new map is loadable in our downstream project. We're currently testing it. Thank you!

Initial testing revealed two issues: (1) missing stop sign, and (2) intersection should be T-shaped rather than 4-way.
(1) is strange since I see stop lines in the .geojson file. @vladimir-wp, is anything else needed for stop signs to appear in our downstream map format?
(2) was due to changes in the specification over time. The original version was 4-way, but a subsequent iteration changed it to be T-shaped. Below is the version we'd like to model. Note that it is T-shaped and there is only one stop sign.

I coordinated with @vladimir-wp and determined that the GeoJSON needs to have another new boolean key/value pair that specifies whether a stop line has an associated stop sign. Instead of:
      "properties": {
        ...
        "Type": "Stopline",
        ...
      },

it should have:
      "properties": {
        ...
        "Type": "Stopline",
        "HasStopSign": "True",
        ...
      },

This will enable our downstream tooling to model maps containing a mixture of stop lines, some with and some without stop signs.
The default value of "HasStopSign" will be "True" so for the map in this PR, the new "HasStopSign" key can be omitted.
@agalbachicar can you update the .xodr & GeoJSon to be T-shaped and while @vladimir-wp works on updating our downstream tooling to support the new "HasStopSign" key?

I coordinated with @vladimir-wp and determined that the GeoJSON needs to have another new boolean key/value pair that specifies whether a stop line has an associated stop sign. Instead of:
      "properties": {
        ...
        "Type": "Stopline",
        ...
      },

it should have:
      "properties": {
        ...
        "Type": "Stopline",
        "HasStopSign": "True",
        ...
      },

This will enable our downstream tooling to model maps containing a mixture of stop lines, some with and some without stop signs.
The default value of "HasStopSign" will be "True" so for the map in this PR, the new "HasStopSign" key can be omitted.
@agalbachicar can you update the .xodr & GeoJSon to be T-shaped and while @vladimir-wp works on updating our downstream tooling to support the new "HasStopSign" key?

Noted! I will add the fixes

Many thanks!!

Would it be possible to get an updated version of this map early next week? Our downstream users wish to have it integrated into their test suite by end of next week (Sept. 30).

Would it be possible to get an updated version of this map early next week? Our downstream users wish to have it integrated into their test suite by end of next week (Sept. 30).

Definitely!

Thank you!!

Updated intersection according to requirements:

@liangfok please take a look

CC: @agalbachicar

LGTM. I confirmed this map is sufficient for our downstream users. Eventually, we may want to implement the transitions that go from the stop sign, through the intersection, to the southbound lane, but that is not needed at this time.


Docs/gpt3 tutorial

Description
Please include a summary of the changes and the related issue. Please also include relevant motivation and context. List any dependencies that are required for this change.
Closes #(issue_number)
Type of change
Please delete options that are not relevant.

[x] Documentation update

Checklist

[x] I made corresponding changes to the documentation

@frascuchon This was merged into develop but I'd like to merge it into main to share the tutorial on social media these days. Reading the dev guides, should we usually do a PR to merge directly into main? even for new tutorials and guides?

Yes, this was a but confusing to me at first too, but it should be done directly to main.

handled in #2127


Explicit smol::run_smol and smol::run_tokio

When building multiple crates within a workspace, if one crate depends on smol with the tokio02 feature and another crate doesn't need the tokio02 feature, a workspace-wide build will build smol once, with the tokio02 feature, and use it for both dependencies. This means the crate that doesn't need tokio gets it anyway, which slows down startup, increases code size, and similar.
Would you consider adding a method smol::run_smol, which always runs just the smol runtime without tokio compatibility, even if compiled with tokio02? And a method smol::run_with_tokio, which only exists if you build with tokio02 but which explicitly declares the requirement for tokio compatibility in-code? smol::run could then just call one or the other of those depending on the tokio02 feature.

There isn't a tokio02 feature flag anymore, but I made this crate for easier compatibility with tokio: https://github.com/stjepang/async-compat


Support dist config file name phpcs.dist.xml

Describe the solution you'd like
I'd like to re-open a discussion that was started in https://github.com/PHPCSStandards/PHP_CodeSniffer/pull/371.
The reasoning for having this would be that this would allow consistency in terms of the naming of config files across various QA tooling commonly used by PHP projects. For example, PHPUnit, PHPStan, and Psalm all support config file names that conform <tool name>.dist.<file ext> scheme.
While using --standard=phpcs.dist.xml is indeed an option, it requires developers to use the flag as they run PHPCS, which is an extra thing they have to remember to do and extra characters they must type. IMO it would be a better developer experience if they did not have to do it.
Overall, I see that this is a very tiny thing that borderlines with some people's OCD (mine 😂) of wanting to have a consistent PHP tool config file naming strategy.
Regarding file precedence - in my understanding phpcs should first look for files that don't have dist in them as those could be used be developers to override the "default" projects config distributed using dist files. Next files with dist should be loaded, the order of each particular type of dist file name doesn't matter as projects very likely will not have various favours of dist and non-dist config files. In other words, if non-dist file is present then use then, if not fall back to dist.
Regarding releasing it as part of 4.0 - why do you think this addition should be considered a BC breaking change?

[x] I have read the Contribution Guidelines and this is not a support question.
[x] I intend to create a pull request to implement this feature.

I get that what others tools do doesn’t matter in context of this tool, however if we look at php ecosystem as whole having a somwaht similar approach would be awesome thing to have. I say this as a person who works on several php projects at a time, and having higher cosistency is something I would find appealing.
Regarding precedence, my thinking is that it does not matter which dist files would be loaded first as projects likley wont have two dist files. However, to reduce potential issues we could say dist.xml is loaded last, as it would be a new addition, so projects that have xml.dist dont get affected by this change. In other words xml.dist wins over dist.xml if both exist. Regarding dot prefix, i’d use same order as currently supported config files have, that is one with dot wins over one without it (if I understand code correctly, have not tried it by running phpcs with several files present).
Regarding maintenace burden, that is hard for me to judge as I’m not a maintainer of the project, however, from my subjective pov this is very little addition and should not cause too much trouble. I’d be happy to contribute the changes required for this, including tests and documentation.
I would also propose that support for file names with dot prefix would get removed in 4.0 as this would be a BC break. That would also remove the amount of supported file names from current 4 to 3 (assiming dist.xml is implemented).

I get that what others tools do doesn’t matter in context of this tool, however if we look at php ecosystem as whole having a somwaht similar approach would be awesome thing to have. I say this as a person who works on several php projects at a time, and having higher cosistency is something I would find appealing.

As I stated before, I understand the desire behind this FR, but the reality is that things are not consistent no matter what and that's not going to change without the tooling maintainers coming together and agreeing on some standards, which hasn't happened, so trying to "force" your idea of consistency on projects without the implementations actually being consistent is just making thing worse IMO.

Regarding precedence, my thinking is that it does not matter which dist files would be loaded first as projects likley wont have two dist files.

That is a logical fallacy and not acceptable. Anything users can do, they will do, so making assumptions like that will just lead to bad code and increase the support burden.
Any addition to the accepted config files would have to have a clearly documented and consistent precedence order.

I would also propose that support for file names with dot prefix would get removed in 4.0 as this would be a BC break. That would also remove the amount of supported file names from current 4 to 3 (assiming dist.xml is implemented).

Support for . prefixed config files was added via squizlabs/PHP_CodeSniffer#1566.
I hope you are joking ? Why would your "OCD"-like preference (your terminology) for how files are named be satisfied, while you want to disregard and disable the same for others ? That kind of attitude makes me even more reluctant to accept this feature request.
Either way that should be a separate discussion.

Please disregard my previous comment about dot prefixed files. I now better understand the situation and you are right, removing it would indeed hurt others which is not at all I’d like to suggest.
Going back to percedence, excuse me for my pushiness, but perhaps I’m just not seeing this as you are as I have much more limited context and scope in this. Wouldn’t adding new option as last in precedence be least harmful in backwards compatability? Regarding documenation, I 100% agree and am commited to doing it via PRs if there is an agreement that this new file name should be supported.
End of the day its your call as maintainer wether to have such feature or not. I don’t want to push anything on you as I’m sure there are bigger fish to fry in context of this project, and if this requires unreasonable effort from your side, lets just close this. From my side, I’d love if this would be possible, I checked the PRs and issues to make sure I dont reopen a closed and discussed topic, I found the PR mentioned which appeared to me as closed due to no response from the person that raised it, therefore without a closing resolution, so I decided to reopen it as a another +1 for FR.
In closing, I want to say that I find it amazing that you have put your effort into reviving this project, I really do admire it. Thank you for doing that! ❤ (please do not interpret this thank you as me trying to convince you, I genually just want to say thanks)

@martinssipenko

Going back to percedence, excuse me for my pushiness, but perhaps I’m just not seeing this as you are as I have much more limited context and scope in this. Wouldn’t adding new option as last in precedence be least harmful in backwards compatability?

Regarding precedence: making the precedence order explicit (i.e. show me a list) and agreed upon will be a prerequisite for any PR.
Note: I'm not saying I disagree with your current proposal, but I want to make sure there is no room for interpretation/misunderstandings about the precedence order.

Regarding documenation, I 100% agree and am commited to doing it via PRs if there is an agreement that this new file name should be supported.

Appreciated. For the record/note to self: this would also need updates in the wiki (which is not publicly editable).

End of the day its your call as maintainer wether to have such feature or not. I don’t want to push anything on you as I’m sure there are bigger fish to fry in context of this project, and if this requires unreasonable effort from your side, lets just close this.

I've already added the "waiting for opinions" label. At this time, I see this as a niche request with very few supporters (based on the historic tickets), so I'm doubtful the benefits outweight the cost.
Having said that, it it would turn out that this is something desired by substantially more users, I'd be open to accepting a PR, so I suggest we leave the ticket open for a while to see if it gathers more support.

In closing, I want to say that I find it amazing that you have put your effort into reviving this project, I really do admire it. Thank you for doing that! ❤ (please do not interpret this thank you as me trying to convince you, I genually just want to say thanks)

Appreciated.


NIFI-978: Support parameterized statements in ExecuteSQL

Thank you for submitting a contribution to Apache NiFi.
In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:
For all changes:

[x] Is there a JIRA ticket associated with this PR? Is it referenced
in the commit message?

[x] Does your PR title start with NIFI-XXXX where XXXX is the JIRA number you are trying to resolve? Pay particular attention to the hyphen "-" character.

[x] Has your PR been rebased against the latest commit within the target branch (typically master)?

[x] Is your initial contribution a single, squashed commit?

For code changes:

[x] Have you ensured that the full suite of tests is executed via mvn -Pcontrib-check clean install at the root nifi folder?
[x] Have you written or updated unit tests to verify your changes?
[ ] If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under ASF 2.0?
[ ] If applicable, have you updated the LICENSE file, including the main LICENSE file under nifi-assembly?
[ ] If applicable, have you updated the NOTICE file, including the main NOTICE file found under nifi-assembly?
[ ] If adding new Properties, have you added .displayName in addition to .name (programmatic access) for each of the new properties?

For documentation related changes:

[ ] Have you ensured that format looks appropriate for the output in which it is rendered?

Note:
Please ensure that once the PR is submitted, you check travis-ci for build issues and submit an update to your PR as soon as possible.

Code LGTM, ran few tests successfully, merging to master.

Hi @mattyb149, @pvillard31 , @viswaug , @christophercurrie , @malthe
May i get the patch for executesql processor in order to avoid sql injection in the select query?


Question about XTrace + matrix functions

Hey there! I found your Xtrace paper after reading your excellent blog post and was wondering if XTrace could be implemented such that it be applied to estimate the trace of an arbitrary matrix function, i.e. $\mathrm{tr}(f(A))$ where $f: [a,b] \to \mathbb{R}$ is analytic.
I saw you mentioned this briefly: To conclude, let us mention two techniques designed for computing the trace of a
standard matrix function (that is, tr f (A)). First, stochastic Lanczos quadrature approximates the spectral density of A, from which estimates of tr f (A) for any function f (·) are immediately accessible
My interpretation of what the SLQ method does comes from Ubaru's 2017 paper, wherein its used to approximate only $\mathrm{tr}(f(A))$ by averaging estimates. Based on your sentiment, and from section 1.3 in this paper, perhaps a more general technique is to build a kernel density estimate of the spectrum from the samples obtained from Lanczos and post-process the density to derive the trace of an arbitrary matrix function (I haven't read the paper you linked, but it's on my list). Is this what you mean by the "immediately accessible" comment in your paper?
Alternatively, is it obvious that SLQ could be used in conjunction with XTrace here? I suppose one idea is to try to replace all instances of $x \mapsto Ax$ in XTrace with $x \mapsto f(A) x$ using something like SLQ, but the details are a bit shady to me

@peekxc Thanks for this question.

My interpretation of what the SLQ method does comes from Ubaru's 2017 paper, wherein its used to approximate only  by averaging estimates. Based on your sentiment, and from section 1.3 in this paper, perhaps a more general technique is to build a kernel density estimate of the spectrum from the samples obtained from Lanczos and post-process the density to derive the trace of an arbitrary matrix function (I haven't read the paper you linked, but it's on my list). Is this what you mean by the "immediately accessible" comment in your paper?

Yes, the idea is to approximate the spectral density, after which the trace of any $f(A)$ can be computed by integrating $f$ against this approximate spectral density.

Alternatively, is it obvious that SLQ could be used in conjunction with XTrace here? I suppose one idea is to try to replace all instances of $x\mapsto Ax$ in XTrace with $x\mapsto f(A)x$ using something like SLQ, but the details are a bit shady to me

I think the most natural way of extending XTrace to matrix functions $\mathrm{tr} f(A)$ is to combine XTrace with the Krylov-aware trace estimators of Tyler Chen and Eric Hallman. I'm not 100% certain this will work out, but the ideas should be compatible. If you're interested in talking more, feel free to reach out to me by email; my contact info is listed on my website.


Align logo and name to center in README

Description
Thought this looks a bit nicer. Having the logo to the left felt a bit off and we were already using html in markdown anyways.
Type of change

[ ] :sunflower: Feature
[ ] :bug: Bugfix
[x] :world_map: Documentation
[ ] :robot: Test
[ ] :computer: CI/Deployment
[ ] :hamster: Trivial/Minor

Issue(s)

#

Test Plan

[ ] :muscle: Manual
[ ] :zap: Unit test
[ ] :green_heart: E2E

This is how it looks.


Allow for no short read input

Modify the code so that short reads are no longer required.
Previously, you would have to make mock short read files to get the pipeline to start if you didn't have short reads.
Changes

Modify CLI

modify rotary run_one so the -r1 and -r2 flags are optional.
modify rotary init to add a '--no_shortflag to tell therotary` that the input directory contains no short reads.
modify rotary and pungi codes so they can read and write a samples.tsv file with only a long sample file column but no short read file columns.
modify rotary.smk's set_up_sample_directories rule to take short reads optionally. Also modify it so if there are no short reads that the POLISH_WITH_SHORT_READS parameter is set to False

Limitations
Sample directories can either contain only long and short reads or all long reads, but not a mix of both. The  rotary init 's --no_short cannot be activated while importing a directory containing short reads.

@jmtsuji https://github.com/rotary-genomics/rotary/issues/118


Fix the retries counter for github pull request

Refactor tree creation in its own class
Fix typo for azure pull request comment

@codisart are you still interested in tackling this?

Hi @jeffwidman
I will try to get back to it.


Black screen with Xcode 7

The dependency simctl uses the "iOS Simulator" command to launch the Simulator. This executable has been renamed to "Simulator" in Xcode 7 and it is no longer possible to deploy to simulator.
I have created a pull-request in https://github.com/phonegap/simctl/pull/7 an ios-sim should be updated accordingly when it is merged.

Thank you! The simctl pr has been merged and published, and dep change made here: https://github.com/phonegap/ios-sim/commit/fe08555f33597a5c6b2c1713cde68fe62a6023f7


pkg/trace/api: debug log tags stored in headers by reverse-proxies

What does this PR do?
Add debug logging in the various reverse-proxies in the trace-agent.

Motivation
Ease debugging tags-related issues for the reverse-proxies that rely on HTTP headers to report container and host-level tags.

Additional Notes

Possible Drawbacks / Trade-offs

Describe how to test/QA your changes
Run the trace-agent with log level debug, the following logs should be seen (depending on the products sending data)
2024-01-19 11:11:02 CET | TRACE | DEBUG | (pkg/trace/api/profiles.go:118 in func1) | Setting header X-Datadog-Additional-Tags=host:dev.host,default_env:dev.env,agent_version:7.52.0-devel+git.122.3c47e77 for profiles proxy
2024-01-19 11:11:03 CET | TRACE | DEBUG | (pkg/trace/api/telemetry.go:117 in func1) | Setting headers DD-Agent-Hostname=dev.host, DD-Agent-Env=dev.env for telemetry proxy

Reviewer's Checklist

[ ] If known, an appropriate milestone has been selected; otherwise the Triage milestone is set.
[ ] Use the major_change label if your change either has a major impact on the code base, is impacting multiple teams or is changing important well-established internals of the Agent. This label will be use during QA to make sure each team pay extra attention to the changed behavior. For any customer facing change use a releasenote.
[ ] A release note has been added or the changelog/no-changelog label has been applied.
[ ] Changed code has automated tests for its functionality.
[ ] Adequate QA/testing plan information is provided. Except if the qa/skip-qa label, with required either qa/done or qa/no-code-change labels, are applied.
[ ] At least one team/.. label has been applied, indicating the team(s) that should QA this change.
[ ] If applicable, docs team has been notified or an issue has been opened on the documentation repo.
[ ] If applicable, the need-change/operator and need-change/helm labels have been applied.
[ ] If applicable, the k8s/<min-version> label, indicating the lowest Kubernetes version compatible with this feature.
[ ] If applicable, the config template has been updated.

/merge


setTimeout and fetch never callback/fulfill when DO gets evicted

fetch returns a promise that should eventually be fulfilled (by either resolve or reject). When a DO is evicted, this promise never fulfills.
Often this is fine because the execution environment is destroyed, so the fact that the fetch never fulfills is not observable. But in the case where the execution environment is reused, ie because a new DO is instantiated within it, application code can observe that fetch never fulfills.
A similar thing happens with setTimeout and setInterval. If you set a timer from a DO and the DO is evicted, the callback for the timer is not called. Normally this is fine because the execution environment goes away. But in the case where execution environment is reused, it can lead to weird results.
One example we have run into where this hurt us:

We have a log sink in a DO that we want to flush (by sending logs to a server) periodically
We set a periodic timer to send the logs
Somebody accidentally makes this sink global
When a DO is unloaded, the timer stops getting called
We stop sending logs
Eventually the log buffer fills up and the program crashes
We don't have any logs prior to the crash because they weren't getting sent

Here is a GitHub repo demonstrating the above issue:
https://github.com/rocicorp/cf-global-state/blob/main/README.md
We are aware of the advise to not use global variables and do attempt to follow it. However they have crept into our worker code a number of times by accident, frequently with this kind of pretty serious problem. It is difficult to completely avoid globals in larger code bases, since they are part of the javascript ecosystem.
I think that if JS contexts are going to get reused, then the platform should ensure any waiting promises and callbacks do get fired. If the promises are going to be abandoned, then the js context should also be killed so that it's not detectable. Otherwise the behavior seems inconsistent with the contract of these APIs.
Another solution that would work for us would be to provide an option to always load DOs into a new v8::Context. This would slightly slow down the launch of DOs, but would completely avoid the problem with global variables since global code would re-run at the start of each DO instantiation.

Backing up, I find it a little unexpected that APIs like setTimeout and fetch don't callback after the DO that called them is evicted. Since they are global APIs I would expect them to be "tied" to the execution context, not to individual DOs within it.

cc @joshthoward

All i/o (like fetch and setTimeout) are tied to the underlying IoContext and not to the JS global scope. When the DO is destroyed, the IoContext is destroyed and the i/o would be canceled. For setTimeout I'm not sure there's much we can do and even the standard allows for cases where the timer just gets silently canceled. For the fetch promise (and all i/o promises), it might be a good idea for us to proactively reject those if the IoContext that owns them is destroyed rather than leaving those unresolved. This just gets a bit tricky when waiting on promises across multiple IoContexts. Will have to carefully consider that tho. Interested in what @kentonv thinks here.

the standard allows for cases where the timer just gets silently canceled

Can you point to the place that defines this? I don't see it. I feel like the spec might even say the opposite:

This seems like it says that calls to setTimeout() that have the same global scope must execute in order of their deadlines. They can be delayed arbitrarily, but they can't be executed out of order. But because of the behavior I'm reporting here, out of order execution of timeouts is possible.

Our concept of I/O contexts is not standard.
In an ideal world, we'd just have a separate isolate (or JS context) for each DO and each HTTP request. Unfortunately, at present that approach does not meet our scalability needs. We'd love to extend V8 with new efficient copy-on-write features to make this possible but that'll take a while.
So as a hack we run multiple I/O contexts in the same isolate (and JS context) and we say "try not to use global variables". Each request and each DO gets its own I/O context.
When an I/O context is "done" (request finishes, or DO is evicted), all I/O initiated within that context (timers, fetches, etc.) is canceled. This is important to us for both architectural and billing reasons -- we just can't have code continuing to run in the background when there is nothing driving it anymore. As just one example of an architectural reason here: in our edge runtime, each I/O context has a thread associated with it; when the I/O context completes, the thread moves on to work on something else. So, there is no longer any thread that could continue to run callbacks after that point.
Again, what we really want is for the DO to have a private isolate that is shut down at this point -- which would also result in cancelling all timers and other I/O. But for performance reasons we're emulating that in a weird way, where there could be other I/O contexts in the same isolate that continue to run.
In any case, this is fundamental to our architecture and not something we can change.

when the I/O context completes, the thread moves on to work on something else. So, there is no longer any thread that could continue to run callbacks after that point.

I think I get it. Taking setTimeout as an example – if you run the pending timer then it can again schedule itself, causing the same problem once again. And this actually happens with aborting a fetch. If you abort the fetch and let JS code observe it, then that code could take the opp to do some other IO.
Then please count us as a strong +1 for being able to isolate DOs in their own V8 context (or isolate). This would actually be good for us on a number of levels as we would love each DO to have the whole 128 MB allotment of memory and not worry about two DOs running in same isolate and sharing.
We would pay more for this feature happily, and accept significant startup cost. If it possible to enable as an opt-in feature before the CoW glorious feature, we would love to try it.

@aboodman:

Can you point to the place that defines this? I don't see it. I feel like the spec might even say the opposite:

Look at bit further up at https://html.spec.whatwg.org/multipage/timers-and-user-prompts.html#timer-initialisation-steps, specifically item 8.1 If id does not exist in global's map of active timers, then abort these steps. .. the implication is that tasks are scheduled on timers and that the tasks can be canceled at any time or that the timer itself can be removed from the active state while the task is still pending. In our implementation, as @kentonv describes, the timer task and the timer are both canceled when underlying IoContext is destroyed.

Hm, I don't see anything that says that the UA can remove tasks. I think 8.1 exists just to handle the case of clearTimeout which does remove these ids from the map.


netapp: removing the large integer validation

Whilst this is helpful in some situations - this means that it's not
possible to build the NetApp SDK on 32 bit platforms
Fixes:
6 errors occurred:
--> freebsd/arm error: exit status 2
GNUmakefile:8: recipe for target 'compile' failed
Stderr: # github.com/terraform-providers/terraform-provider-azurerm/vendor/github.com/Azure/azure-sdk-for-go/services/netapp/mgmt/2019-06-01/netapp
vendor/github.com/Azure/azure-sdk-for-go/services/netapp/mgmt/2019-06-01/netapp/pools.go:72:87: constant<PHONE_NUMBER>104 overflows int
vendor/github.com/Azure/azure-sdk-for-go/services/netapp/mgmt/2019-06-01/netapp/volumes.go:74:99: constant<PHONE_NUMBER>00 overflows int

--> openbsd/386 error: exit status 2
Stderr: # github.com/terraform-providers/terraform-provider-azurerm/vendor/github.com/Azure/azure-sdk-for-go/services/netapp/mgmt/2019-06-01/netapp
vendor/github.com/Azure/azure-sdk-for-go/services/netapp/mgmt/2019-06-01/netapp/pools.go:72:87: constant<PHONE_NUMBER>104 overflows int
vendor/github.com/Azure/azure-sdk-for-go/services/netapp/mgmt/2019-06-01/netapp/volumes.go:74:99: constant<PHONE_NUMBER>00 overflows int

--> linux/386 error: exit status 2
Stderr: # github.com/terraform-providers/terraform-provider-azurerm/vendor/github.com/Azure/azure-sdk-for-go/services/netapp/mgmt/2019-06-01/netapp
vendor/github.com/Azure/azure-sdk-for-go/services/netapp/mgmt/2019-06-01/netapp/pools.go:72:87: constant<PHONE_NUMBER>104 overflows int
vendor/github.com/Azure/azure-sdk-for-go/services/netapp/mgmt/2019-06-01/netapp/volumes.go:74:99: constant<PHONE_NUMBER>00 overflows int

--> freebsd/386 error: exit status 2
Stderr: # github.com/terraform-providers/terraform-provider-azurerm/vendor/github.com/Azure/azure-sdk-for-go/services/netapp/mgmt/2019-06-01/netapp
vendor/github.com/Azure/azure-sdk-for-go/services/netapp/mgmt/2019-06-01/netapp/pools.go:72:87: constant<PHONE_NUMBER>104 overflows int
vendor/github.com/Azure/azure-sdk-for-go/services/netapp/mgmt/2019-06-01/netapp/volumes.go:74:99: constant<PHONE_NUMBER>00 overflows int

--> linux/arm error: exit status 2
Stderr: # github.com/terraform-providers/terraform-provider-azurerm/vendor/github.com/Azure/azure-sdk-for-go/services/netapp/mgmt/2019-06-01/netapp
vendor/github.com/Azure/azure-sdk-for-go/services/netapp/mgmt/2019-06-01/netapp/pools.go:72:87: constant<PHONE_NUMBER>104 overflows int
vendor/github.com/Azure/azure-sdk-for-go/services/netapp/mgmt/2019-06-01/netapp/volumes.go:74:99: constant<PHONE_NUMBER>00 overflows int

--> windows/386 error: exit status 2
Stderr: # github.com/terraform-providers/terraform-provider-azurerm/vendor/github.com/Azure/azure-sdk-for-go/services/netapp/mgmt/2019-06-01/netapp
vendor/github.com/Azure/azure-sdk-for-go/services/netapp/mgmt/2019-06-01/netapp/pools.go:72:87: constant<PHONE_NUMBER>104 overflows int
vendor/github.com/Azure/azure-sdk-for-go/services/netapp/mgmt/2019-06-01/netapp/volumes.go:74:99: constant<PHONE_NUMBER>00 overflows int

Automation for azure-sdk-for-python

Automation for azure-sdk-for-go

I also submitted an issue in autorest.go repo, since this may be a generator bug.

Hi @tombuildsstuff we have a fix for this in autorest.go.
When that fix is applied, this issue should be resolved.

@ArcturusZhang thanks that also works 👍
From our side I've got broader questions around the validation within the CreateOrUpdate method - since I feel like it'd be more useful as an extension method on the struct itself - but that's a question for another day :)
For the moment I'll close this issue in favour of https://github.com/Azure/autorest.go/pull/183
Thanks!


Limb: optimize constant-time comparisons

Optimizes ConstantTimeGreater/ConstantTimeLess impls by using borrowing subtraction and checking whether a borrow occurred.
Benchmarks
ops/ct_lt               time:   [900.95 ps 909.83 ps 922.37 ps]
                        change: [-76.095% -75.752% -75.373%] (p = 0.00 < 0.05)
                        Performance has improved.

ops/ct_gt               time:   [902.46 ps 938.83 ps 1.0134 ns]
                        change: [-55.763% -53.637% -50.192%] (p = 0.00 < 0.05)
                        Performance has improved.

Is it a better algorithm than the one used in CtChoice? We should pick one and use it in both places.

Definitely worth comparing options, as this is a major bottleneck for #415

Filed #418


fix: quad rendering including border only inside of the bounds

It seems that border should not be drawn outside the quad bounds. For example, a slider handle with a large border radius will leave a trail of the border color when it is dragged, because it goes un-tracked in the damage.
This change also makes tiny-skia rendering of quads more consistent with the wgpu backend, which didn't seem to draw outside the bounds as far as i could tell with the same slider test.

Hmm this might need some more testing. I'm going to mark it as a draft until i've tested it some more :sweat_smile:

This seems to be working pretty well now.


can flit install multiple packages? (like tool.poetry.packages)

Sorry if this is answered somewhere in docs or previous issues and I'm just not using the right terms to find it.
I have a project set up like this:
src
├── crowsetta
└── textgrid

The package crowsetta imports textgrid.
I guess the technical term is "vendored"?
I am not trying to do anything like a monorepo with multiple separate packages each in their own directory.
With a fancypants tool like poetry I am able to do this:
packages = [
    { include = "crowsetta", from = "src" },
    { include = "textgrid", from = "src" },
]

and when I run poetry install then they are both just there.
Is there a way to tell flit to install both crowsetta and textgrid or is that considered out of scope?
Again I'm sorry I don't know the right way to describe what I'm doing.

Is there a way to tell flit to install both crowsetta and textgrid or is that considered out of scope?

There is no way to do that; and yes, it is considered out of scope.

Yup, as @pradyunsg says, Flit is limited to a single top-level package. You can have multiple submodules and subpackages within that, e.g.
src
└── crowsetta
  ├── __init__.py
  └── textgrid.py

This pattern is common even if you're vendoring a package from someone else. E.g. pip contains vendored modules which it imports at paths like pip._vendor.colorama.

Thank you @pradyunsg and @takluyver
Ah of course, I should use a sub-package to vendor.
I did find previous issues related to pip vendoring, but couldn't immediately see how pip was doing it.
Obviously I should've read the code a little closer, _vendor seems pretty explicit.
Appreciate it!
Closing

I couldn't find any documentation on this, but if I have multiple sub-modules as shown in @takluyver 's comment above, is there anything I need to specify in the pyproject.toml for them to be picked up? Akin to find_packages from setuptools?


drop nix-build-uncached

The command nix-build-uncached does not seem to run the actual builds, so this PR replaces nix-build-uncached by nix-build.

It should build them unless the artifact is already in our nix cache. But it's a small optimization, so if it doesn't work no worries.


License of suite_test.go is updated.

In /pkg/controllers/v1alpha1/jindo/suite_test.go ,license is modified.

you should add -s when you use command "git commit"

/lgtm


Configuring redmine::database... exited with code 1

Fresh install with
version: '2'

services:
  redmine:
    image: sameersbn/redmine:3.2.5-1
    depends_on:
      - db
    environment:
      - DB_HOST=db
      - DB_USER=redmine
      - DB_PASS="yyyyyyy"
      - DB_NAME=redmine
      - REDMINE_PORT=8080
      - REDMINE_SECRET_TOKEN="zzzzzzzzz"
    ports:
      - "8000:80"
    volumes:
      - ./data:/home/redmine/data
  db:
    image: mysql:5.7
    environment:
      MYSQL_ROOT_PASSWORD: "xxxxxxx"
      MYSQL_DATABASE: redmine
      MYSQL_USER: redmine
      MYSQL_PASSWORD: "yyyyyyy"
    ports:
      - "8006:3306"

$ docker-compose up -d;docker-compose logs -f redmine

[...]
redmine_1  | Symlinking dotfiles...
redmine_1  | Installing configuration templates...
redmine_1  | Configuring redmine...
redmine_1  | Configuring redmine::database...........................................................
redmine_redmine_1 exited with code 1

How can I know what is crashing ?

You could try setting the DEBUG environment variable for the redmine service.
You can also mount the internal log directory.
    volumes:
    - ./redmine-data:/home/redmine/data
    - ./redmine-logs:/var/log/redmine

https://github.com/sameersbn/docker-redmine/search?utf8=✓&q=DEBUG&type=

$ docker-compose exec redmine ls -R /var/log/redmine

/var/log/redmine:
nginx  redmine	supervisor

/var/log/redmine/nginx:

/var/log/redmine/redmine:

/var/log/redmine/supervisor:

I can see only 3 empty directories here

Can you provide the whole start log?

The part thats printed to the screen.

You mean this one:

redmine_1  | Initializing logdir...
redmine_1  | Initializing datadir...
redmine_1  | Symlinking dotfiles...
redmine_1  | Installing configuration templates...
redmine_1  | Configuring redmine...
redmine_1  | Configuring redmine::database...........................................................

Each dot after Configuring redmine::database seems to be a try with mysqladmin [...] status

I was hoping to see the command you ran as well.  When I start my docker-compose, I also see output from the database container as it starts.  This appears to be missing in your included output.

Ok ! The key information was indeed in the db container logs (I was only checking redmine)

db_1       | 2017-03-28T13:13:51.556588Z 8 [Note] Access denied for user<EMAIL_ADDRESS>(using password: YES)

Redmine's container DB_PASS environment variable does not seem to take double quotes as variable value delimiter. I replaced:
services:
  redmine:
    environment:
      - DB_PASS="yyyyyyy"

By
services:
  redmine:
    environment:
      - DB_PASS=yyyyyyy

And it worked. Thanks @jcormier