我要新的 LGTM!

要这一张!

Originally posted by @h0gan1ee in https://github.com/hitszlug/wiki/pull/39#pullrequestreview-908143026

Head to https://n.hopp.top/lgtm-s.svg

Uploaded.


Attribute support: aria-labelledby

Per the summary:

Handles namespaced attributes (xlink), and other non-react attributes/tags, on component mounting, so the returned jsx will compile cleanly with babel.

One issue that we are running into, however, is using the aria-labelledby attribute. When authoring SVGs, this attribute can be used on the root <svg> element to aid screenreaders correctly announce what the SVG is supposed to be. Example usage:
<svg viewBox="0 0 126 126" xmlns="http://www.w3.org/2000/svg" aria-labelledby="close__title">
  <title id="close__title">
    Close
  </title>
  <path d="..." />
</svg>

(More background on this can be found on Tip #3 here)
React handles the aria-labelledby attribute just fine when the SVG is pasted directly into JSX - but, when loaded via svg-react-loader you get this console error:
Unknown props `ariaLabelledby` on <svg> tag. Remove these props from the element.

Would it be possible to amend SVG react loader to handle aria-labelledby, in addition to the other attributes it handles?

@chipcullen Try using the next version of svg-react-loader npm install svg-react-loader@next and let me know if that solves your issue. (make sure you read the README since some things have changed -- no need for babel for instance)
I've done away with handling special attributes, and that version has a better API for special casing these kind of things (if that becomes necessary).
Thanks,
;-j

@jhamlet I just tried, and unfortunately, no dice :(
I ran npm install svg-react-loader@next, which, finished with this in the console:
└──<EMAIL_ADDRESS>invalid

And when I run npm info svg-react-loader version I get
0.3.7

Even though the directory in /node_modules/ is clearly the 0.4.0 version (the package.json indicates this)
Anyway, I can run webpack just fine, but I still get this console error in the browser:
Warning: Unknown prop `ariaLabelledby` on <svg> tag. Remove this prop from the element. For details, see https://fb.me/react-unknown-prop
    in svg (created by ... )

When inspecting the SVG in my browser dev tools, the aria-labelledby attribute doesn't even appear, though, that may be due to React suppressing the attribute.
If it helps, here is the React file with JSX:

And here is what I'm seeing in the browser vs what is in the SVG file:

And here is the browser console:

@chipcullen thanks for the details.
I don't know what npm's issue is, but it looks like you're getting the correct version.
As a quick test (sorry, my bandwidth is limited at this time) can you try outputting an svg element through React (not using svg-react-loader, just plain react) with a property ariaLabelledby and then with ariaLabelledBy to see which one works?
The processor recognizes hyphens as places to camelCase things, however there is a way to special-case certain attribute names (look at the propsMap query parameter).

I've recreated everything as per @chipcullen above and carried on with ^^.
I dropped an SVG inline into a JSX file and got the following:

ariaLabelledby: nothing
ariaLabelledBy: nothing
aria-labelledby: aria-labelledby

All of above rendered through svg-react-loader return nothing.

I am having the same issue as @chipcullen.
I am getting Warning: Unknown prop 'ariaLabel' on <svg> tag. and warning.js:36 Warning: Unknown prop 'dataSrc' on <img> tag..
I am using version 0.4.0-beta.2´. (Although npm states 0.3.7´)
Dropping in the SVG directly the attributes are printed. I've tried to use the ´propsMap´ query parameter, but It didn't do any difference. (I don't know if I used it correctly)


[FLINK-19617] Added new metric for monitoring the JVM's Metaspace memory pool usage.

What is the purpose of the change
A new metric for monitoring the Metaspace usage needs to be introduced to finish FLIP-102.
Brief change log

Added new metric analogous to Heap and NonHeap metric.
Extended documentation accordingly.
Added note to the memory metrics documentation after we ran into problems with IBM's J9 OpenJDK implementation.
Included missing testcase for nonheap metric to check whether the metric's value is not static.

Verifying this change

Added new tests to MetricUtils to cover the new metric

Does this pull request potentially affect one of the following parts:

Dependencies (does it add or upgrade a dependency): no
The public API, i.e., is any changed class annotated with @Public(Evolving): yes
The serializers: no
The runtime per-record code paths (performance sensitive): no
Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Kubernetes/Yarn/Mesos, ZooKeeper: no
The S3 file system connector: no

Documentation

Does this pull request introduce a new feature? yes
If yes, how is the feature documented? docs

I resolved your remarks. I left the commits separated for now to make reviewing the changes easier. I'm gonna squash all of it in one commit after the review is done.


NIFI-8643: Correcting nifi.cluster.load.balance.address in properties

Description of PR
Since the code looks for nifi.cluster.load.balance.address but nifi.cluster.load.balance.host is specified in the documentation and nifi.properties file, the load balancer is always bound to localhost.  This corrects the properties and documentation.
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 main)?

[X] Is your initial contribution a single, squashed commit? Additional commits in response to PR reviewer feedback should be made on this branch and pushed to allow change tracking. Do not squash or use --force when pushing to allow for clean monitoring of changes.

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?
[ ] Have you written or updated unit tests to verify your changes?
[X] Have you verified that the full build is successful on JDK 8?
[X] Have you verified that the full build is successful on JDK 11?
[ ] 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:

[X] 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 GitHub Actions CI for build issues and submit an update to your PR as soon as possible.

Though, looking at the rest of the nifi.properties, *.host appears to be the standard for everything except nifi.cluster.load.balance.address and nifi.cluster.node.address.  Perhaps these two should be renamed to nifi.cluster.load.balance.host and nifi.cluster.node.host.  Thoughts, @markap14, @exceptionfactory?

Ha I think nifi.cluster.node.address was the property I looked at to ensure the correct naming convention when I created the nifi.cluster.load.balance.address :(
Unfortunately, though, I don't think it's a good idea to rename. It could cause a lot of problems and confusion for people upgrading from one version to another. I think it makes more sense to just use 'address' in some places and 'host' in other places.

Honestly, though, @gresockj thinking about this a bit more - this PR updates the docs to match what the code does. I think perhaps we should go the other way. The documentation is all correct about what the property name should be. In the code, we just had a bug that caused it to look at the wrong property name. If we don't update the docs and instead just fix the bug in NiFiProperties, then we remain consistent with using .host, which I like. It means anyone who did go ahead and add in the extra property would need to ensure that in 1.14.0 that they do have the correct value for .host, but I think that's fair since the docs are already calling it out.

Honestly, though, @gresockj thinking about this a bit more - this PR updates the docs to match what the code does. I think perhaps we should go the other way. The documentation is all correct about what the property name should be. In the code, we just had a bug that caused it to look at the wrong property name. If we don't update the docs and instead just fix the bug in NiFiProperties, then we remain consistent with using .host, which I like. It means anyone who did go ahead and add in the extra property would need to ensure that in 1.14.0 that they do have the correct value for .host, but I think that's fair since the docs are already calling it out.

I see your point.  I think it makes more sense the way you called out.  Updating the PR.

Thanks @gresockj merged to main

Hi
When I typed in a fqdn as the nifi.cluster.load.balance.address is still bind to localhost. I had to type in the IP address or <IP_ADDRESS>.
So the property name address seems to correspond to an actual ip address. If the property name was host I will assume it would be a fqdn.
If I have multiple network interfaces on my nodes, I would select one interface (ip address) to be the network for load balance and another for the remote access UI and S2S.
Using fqdn as host property will not provide you the possibility to select a different network for internal load balance between nodes. Therefore I will go for the address property and specified that it has to be an ip address
Kind Regards
Jens M. Kofoed


Separate interfaces for single and multiple document GET

The multi-purpose interface for single and multi-document GET confuses me!

From issue #26

How about 5 tabs at the top:
PUT Document
POST Document (this is a new feature!)
GET Document
GET Documents
DELETE Document
You could put the since field in GET Documents only, which would allow you to bring the state/activity/agent tabs up immediately below the other tabs? This would also resolve #28

I would like to think about this more. I don't like having so much tab switching, there is probably a better UI element to provide the user more interaction possibilities without clicking around so much.


[Question] Schema required for polymorphic relationship

Hi @lindyhopchris, love the package you created.
I am confused about an aspect about Polymorphic To-Many relationships because of the following problem: I have the following schema:
class GeolevelableSchema extends Schema
{
  public function fields(): array
  {
      return [
          ID::make(),
          MorphToMany::make('geolevels', [
                  BelongsToMany::make('regions')->type('regions'),
                  BelongsToMany::make('countries')->type('countries'),
           ]);
          DateTime::make('createdAt')->sortable()->readOnly(),
          DateTime::make('updatedAt')->sortable()->readOnly(),
      ];
  }
}

I have created a GeolevelCollectionQuery class as stated in the documentation, but when i access an endpoint like this:
DELETE /geolevelable/id/relationships/geolevels it throws this error :
LogicException: No schema for JSON:API resource type geolevels.

Am I supposed to create a special kind of schema for the geolevels "resource" (there are schemas for regions and countries already)? That would be like creating a schema for the "media" type (the Polymorphic To-Many  example from the documentation ) - something which makes little sense to me.
Am I missing something?
Thank you for your time!

If there is a schema for the geolevels model, you should register it in your Server.php.

Well sure, but there is no geolevels model because it's just a name to group countries and regions under a single relationship, just like media in the documentation.

I'm on holiday at the moment so can't look into this in detail. What's the stack trace of that exception? Wondering where it is being thrown from.

Hi, sorry for the delay, I've also been away on holiday. Here is a stack trace for the problem. Unfortunately, PHPUnit did not provide the stack trace for this so i uploaded a photo taken while using the debugger.

Hello @lindyhopchris, have you got any time to take a look at this?

I haven't unfortunately - extremely limited on open source time at the moment.
Just looking at your original post, you've called the class GeolevelableSchema. But it's probably looking for GeolevelSchema. Does that fix it?


Fix issue #89: Unambiguous matrix naming

The use of Columns and Rows depends on who you talk to - rather than confuse people who are used to different conventions, use unambiguous terms Vectors and Coordinates instead.
I don't have high hopes this will be merged, but it's food for thought, anyways.

This fixes both #89 and #124.

I would also be happy with Axis / Axes rather than Coordinate / Coordinates

Closed per #124.


Epic: Account management

Epic
We want to create an account management system where users can log in and sign up to the site.
User Stories

[x] #16

Closing this epic since all user stories are done.


Generating a PDF of a Vue page using Vuex store/state leads to blank pages.

Steps to reproduce
Tell us about your environment:

Puppeteer version: 2.0.0
Platform / OS version: local machine Windows 10
URLs (if applicable): N/A
Node.js version: v10.16.0

What steps will reproduce the problem?
N/A
Please include code that reproduces the issue.

for example this some code to generate the header in the invoice

<v-col cols="9" class="d-flex flex-column pt-3">

                        {{ Office__title  }}
                        {{ '(' + Office__companyno + ')' }}

                    {{ Office__address1  }}
                    {{ [Office__address2, Office__city, Office__state, Office__country].join(', ')  }}
                    {{ $t('message.tel') + ': ' + Office__contracttel  }}
                    {{ $t('message.email') + ': ' + Office__contractemail + ' ' + $t('message.website') + ': ' + Office__website }}
                </v-col>

The variables are obtained using this:

data() {
            return {
                appLogo: AppConfig.appSessionLogo,
                deliveryAddresses: [],
                loaded: false,
            };
        },
        computed: {
            ...mapFields('contract', {
                Contract__id: 'print.Contract.id',
                Contract__Bank_id: 'print.Contract.Bank.id',
                Contract__Bank_title: 'print.Contract.Bank.title',
                Contract__Bank_account: 'print.Contract.Bank.account',
                Contract__Bank_swiftcode: 'print.Contract.Bank.swiftcode',
                Contract__Bank_beneficiary: 'print.Contract.Bank.beneficiary',
                Contract__Deliveryaddress_address: 'print.Contract.Deliveryaddress.address',
         etc, etc....

Note: ...mapFields id from this package "maoberlehner/vuex-map-fields". Using standard ...mapGetters also replicates the issue.
What is the expected result?
PDF of the sales invoice should appear
What happens instead?
I get two blank pages. When I pdf.goto to another page in my site where no Vuex is used I get a render of the page.
If I pull directly from the API into the page without using Vuex the page is rendered. I would very much like to use the Vuex actions, state, mutations in the print page so I don't have to rewrite some of the code 2x. Does anyone have any experience doing this? I googled high and low and only found 1 or 2 postings but with no solution mentioned.

Most likely you are trying to use page.pdf(), while Vue hasn't finished to render the page. I think Vuex is not the case, just a slowdown trigger in particular environment. Puppeteer API and V8 runs concurrently. To be completely sure the content is rendered before printing, use page.exposeFunction() to inject a notification callback, or a WebSocket. Just await the notification on the Puppeteer thread. Consider the asynchronous nature of JS, it's up to you to find an exact trigger that the page is ready.
`
...
const reportCreated = new Promise(async (resolve, reject) => {
await page.exposeFunction('puppeteerNotifyReportReady', () => {
resolve()
},)
})
await page.goto(someURL,{waitUntil: 'networkidle2', timeout: 10 * 60 * 1000,})

await reportCreated
let result = await page.pdf({
  format: 'A4',
  printBackground: true,
},)

...
`

I was able to solve this by completely taking out vuex from the picture.I
loaded the data as usual by API and render only after all API calls have
been completed. I will try your solution on other print pages that I still
have to create.
Thanks!
On Thu, Aug 20, 2020, 11:43 PM Vitaliy<EMAIL_ADDRESS>wrote:

Most likely you are trying to use page.pdf(), while Vue hasn't finished to
render the page. I think Vuex is not the case, just a slowdown trigger in
particular environment. Puppeteer API and V8 runs concurrently. To be
completely sure the content is rendered before printing, use
page.exposeFunction() to inject a notification callback, or a WebSocket.
Just await the notification on the Puppeteer thread. Consider the
asynchronous nature of JS, it's up to you to find an exact trigger that the
page is ready.
`
...
const reportCreated = new Promise(async (resolve, reject) => {
await page.exposeFunction('puppeteerNotifyReportReady', () => {
resolve()
},)
})
await page.goto(someURL,{waitUntil: 'networkidle2', timeout: 10 * 60 * 1000,})
await reportCreated
let result = await page.pdf({
format: 'A4',
printBackground: true,
},)
...
`
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/puppeteer/puppeteer/issues/5871#issuecomment-677743770,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AM2ZLXBMFVQDW5KP3L7RRCLSBVABTANCNFSM4NBFLKTQ
.


sqlite improvements

[ ] run VACUUM on start up to shrink the database

[ ] create backup(s) using sqlite APIs

[ ] figure out how to use the backup when database seems to be corrupt


Excecutable installer

Hello, I would like to publish ipasim onto the WinGet repository, however they have a strict policy against apps that use scripts to install, and was never implemented due to agreements. Scripts within executables are allowed onto the platform, though.

I don't think executable installer is necessary, WinGet manifests can point to .msix. But they would need some real certificate, ipasim currently only has a self-signed one.
Alternatively, you can package the powershell script in a self-extracting archive - would that work? For example, I used https://superuser.com/a/929132 with the following config to produce an .exe installer which seems to work fine.
;!@Install@!UTF-8!
Title="ipasim v<IP_ADDRESS>"
ExecuteFile="powershell.exe"
ExecuteParameters="-ExecutionPolicy Bypass -File Add-AppDevPackage.ps1 -Force"
;!@InstallEnd@!

I've uploaded the installer here:
https://github.com/ipasimulator/ipasim/releases/download/v1.0.1/ipasim-build-v1.0.1-2023-01-01.exe


LUCY-295 BitVector size_t ticks

Change BitVector to use size_t instead of uint32_t to address bits in the array.

Next_Hit and To_Array still work with int32_t indices. For now, we should at least add a check like
if (ivars->cap > INT32_MAX / 8) { THROW(...) }

In the long run, I'd suggest to change the return value of Next_Hit, remove To_Array, and switch its users over to Next_Hit.


fix: variant weight can be up to 1000

About the changes

The weight of the variant can be up to 1000, so u8 isn't enough. I couldn't find a proper reference, but it's obvious when looking at the code e.g. https://github.com/Unleash/unleash/blob/main/src/lib/routes/admin-api/project/variants.ts#L117.
I don't know when this changed (or if it always was like that) but the client specification seems to be wrong/outdated e.g. here https://github.com/Unleash/client-specification/blob/main/specifications/12-custom-stickiness.json#L24.

Important files

Discussion points

hey @sighphyre - I hate to be that guy haha, but any update on this😅? Are we blocked here by this one https://github.com/Unleash/unleash-client-rust/pull/56?
By the way, how "experimental" is this yggdrasil project? Would you advise against using it at all, or is it okay (while keeping in mind that the API may break)?

hey @sighphyre - I hate to be that guy haha, but any update on thissweat_smile? Are we blocked here by this one #56?
By the way, how "experimental" is this yggdrasil project? Would you advise against using it at all, or is it okay (while keeping in mind that the API may break)?

So sorry! Apparently I'm being "that guy" here, not you! I think we're still trying to figure some stuff out with how we handle builds on this project.
@rbtcollins You open force merging this? I don't have rights on this repo

@teqm Hey, wanted to chime back in here! Would you mind rebasing this off the main branch? We've finally sorted out some of the pipeline issues that were blocking the merging of this PR and would love to get it merged now.
Of course, it's a pretty minor change, but I wanna give you the opportunity to contribute instead of just "taking" your changes and running with them. Let me know! And if I don't hear anything by, say, Monday, I'll go ahead and open another PR fixing this.
Thanks again for your contribution 😄

Thank you! And yeah, I wasn't sure whether you'd feel short-changed or anything in case we shut this PR down and opened an identical one instead, so I thought it was safer to ask. Anyway, this looks good to me!

@sighphyre Got any more input before we merge it or are we good to go?

@sighphyre Got any more input before we merge it or are we good to go?

Nah this looks great, thank you for all the hard work that it took to get to the point where we can merge this one!


Blank fields when adding integration

Hi.
When i try to follow the instructions and installing it using HACS, i get the following when i try to add to as an integration.
Can you please describe what needs to be filled out at the different fields?

login data from your inverter. IP Adress, username and password. The same you use for login on your inverters webbrowser page.

Thats perfectly correct @molelightn, thanks for clarifying!
I hope that works for you @molle1996, let me know if I can close this.
The bug has already been reported to #6

I experienced the same. I wanted to add that the IP is not enough to be put in, it needs to be the full URL including http://

Good point @melvinisken, that should be included in the description for the field.
I have updated #6 to include your comment. Please drop any additional information into that issue.
Closing this as it seems to be working (once you know what to put it 😅 )


⚠ Samsung has degraded performance

In d97145f, Samsung (https://samsung.com) experienced degraded performance:

HTTP code: 200
Response time: 2284 ms

Resolved: Samsung performance has improved in 50916c2.


BitBarDarkMode

Modifying Mac darkmenu doesn't work, process.env.BitBarDarkMode always equals 1.

Having this (darkmode) would be really nice -- especially for things that display a lot of data (ex: weather plugins, will lots of values).


[SP] Use glMatrix in SP sample instead of THREE.js.

The sample can leverage SIMD feature in Crosswalk by using glMatrix.

@huningxin @leonhsl please help to reivew.

updated, @leonhsl @huningxin please help to review. Thanks!

lgtm and merging

Merged


Can change the property value of table field ?

Hi Freddy,
Can we change the Property Value of any table field  for the app source , without getting AL Validation failed?
Basically I need to change the value of "DecimalPlaces" Property of table field and worried about the AL Validations.
Please Suggest.
Thanks in advance.

HI @divjotn,
You can read more about the validation here: Technical Validation.
It include as section where you can run the validation yourself

You can also use the AppSourceCop the know whether the change is allowed.


Error altering batch_size

Orion version: Slightly modified Tulog Colab demo
Python version:
Operating System: WIndows

Description
Running the TadGAN pipeline, I set the batch_size to 32 rather than the default 64.
I got the following error in orion.fit()
/usr/local/lib/python3.7/dist-packages/tensorflow_core/python/client/session.py in call(self, *args, **kwargs)
1470         ret = tf_session.TF_SessionRunCallable(self._session._session,
1471                                                self._handle, args,
-> 1472                                                run_metadata_ptr)
1473         if run_metadata:
1474           proto_data = tf_session.TF_GetBuffer(run_metadata_ptr)
InvalidArgumentError: Incompatible shapes: [32,100,1] vs. [64,1,1]
[[{{node random_weighted_average_1/mul}}]]
Setting batch_size to 64 runs fine.
from orion import Orion
hyperparameters = {
    "mlprimitives.custom.timeseries_preprocessing.time_segments_aggregate#1": {
        "interval": 1
    },
    "orion.primitives.tadgan.TadGAN#1": {
        'epochs': 5,
        'batch_size': 32
    }
}

orion = Orion(
    pipeline='tadgan',
    hyperparameters=hyperparameters
)
print(df_train.shape)
print(df.shape)
orion.fit(df_train)
anomalies = orion.detect(df)

Can you please explain why this is causing an error? Thank you!

Thank you for making us aware of this issue. Within the TadGAN primitive is a class called RandomWeightedAverage that implements a Keras method (random_uniform) that (in this case) always uses an input of 64,1,1 to return a tensor of uniform random distribution. There is clearly some dimensional incompatibility of the lower batch size with this specific function. I think the method itself is working fine but it possibly causes some matrix multiplication errors down the line when the dimensions are changed. I will have look deeper to see if it's unique to the data you're using or applies to different datasets. Once again, thank you for raising this issue, and I'll get back to you when I have an update.

Thank you @ajthomas1949!
That is definitely not the expected behavior. I opened an issue to resolve this problem, you can follow it here.

PR #315 was just merged. The fix should be available in the next release!


Add support for suppressing specific local notifications from a write

This adds NotificationToken::suppress_next() which can be called within a write transaction to make the write transaction not produce a notification for that specific callback. All other callbacks (including others for the same collection) will still happen. The rest of the changes are support functionality to make this possible.
All methods of advancing the read transaction version will now send notifications, including beginning a write transaction and explicitly calling Realm::refresh(). If a hard refresh is required and the notifications for that version are not ready yet, it will block until they are. The two exceptions to this are advances due to importing handover objects (just not implemented yet), and advancements due to beginning a write transaction from within a notification callback (fundamentally not possible to do in any sensible way). This also fixes a lot of edge cases and race conditions along the way which could have resulted in notifications not being delivered when they should have been.

@bdash All of the issues with this that I'm aware of are now fixed, so I'm done mucking about with it for now.


Show account form after registering

Redirect the user to the edit account page after creating their account.
The demo also includes changes from #1436.

This fixes #868.

r+wc


AVRO-2132 added missing defaults for new fields

https://issues.apache.org/jira/browse/AVRO-2132

no problem @cutting


MacOS: build error after 0.5.0

FYI:
error: failed to run custom build command for `sherpa-rs-sys v0.5.0`

Caused by:
  process didn't exit successfully: `/Users/enes/Desktop/whisper_test/target/debug/build/sherpa-rs-sys-5009514fe91242ca/build-script-build` (signal: 6, SIGABRT: process abort signal)
  --- stderr
  dyld[7708]: Library not loaded: @rpath/libbz2.1.dylib
    Referenced from: <E30A5D48-C24E-330A-B396-72358B2448D0> /Users/enes/Desktop/whisper_test/target/debug/build/sherpa-rs-sys-5009514fe91242ca/build-script-build
    Reason: tried: '/Users/enes/Desktop/whisper_test/target/debug/deps/libbz2.1.dylib' (no such file), '/Users/enes/Desktop/whisper_test/target/debug/libbz2.1.dylib' (no such file), '/Users/enes/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib/libbz2.1.dylib' (no such file), '/Users/enes/.rustup/toolchains/stable-aarch64-apple-darwin/lib/libbz2.1.dylib' (no such file), '/Users/enes/lib/libbz2.1.dylib' (no such file), '/usr/local/lib/libbz2.1.dylib' (no such file), '/usr/lib/libbz2.1.dylib' (no such file, not in dyld cache), '/Users/enes/Desktop/whisper_test/target/debug/build/ring-dc7c625d718228f9/out/libbz2.1.dylib' (no such file)
warning: build failed, waiting for other jobs to finish...

 *  The terminal process "cargo 'run', '--package', 'whispertest', '--bin', 'whispertest'" terminated with exit code: 101.

note that, the code I'm trying to execute is working in 0.4.1

@altunenes
Thanks for letting now :)
I can't reproduce it on aarch64
Do you have Intel or Apple chip?

I have Apple: M3 Air. :-(

Looks related to https://github.com/tauri-apps/tauri/issues/10983
It failed to link bzip2. though, I don't know how it find it to me. I don't have bzip2 installed from HomeBrew.
I see that this crate has static feature. I enabled it by deafult.
Can you try again with newer version of sherpa?
sherpa-rs = "=0.5.1-beta.0"

wow, that's very interesting. I do not use Tauri on my tests, It is simple CLI I run my tests to compare qualities :-)
also, now it works
sherpa-rs = "=0.5.1-beta.0"


Support runtime enabling of strict mode in sky_viewer

From @tonygentilcore on July 16, 2015 14:5
@abarth and I noticed yesterday that we don't have a mechanism for running sky dart code in strict mode in a release built mojo shell.
The dart content handler enables this via passing ?strict=true. See:
https://github.com/domokit/mojo/blob/ecf671725e139e27d8e07073e0722d10829e28c7/services/dart/content_handler_main.cc
One way to solve this is to make sky viewer do the same. But if we decide there's a better way to do it for sky, then I'd propose we should also update the dart content handler to match.
/cc @johnmccutchan
Copied from original issue: domokit/mojo#327

I started a pull request to use mojo args instead.  That seems better than putting magic into the URLs.


feat: add tests for pastebin url analyzer

@d-Rickyy-b Can you please take a look

Pull Request Test Coverage Report for Build 293

36 of 37 (97.3%)  changed or added relevant lines in 2 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.7%) to 75.729%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

pastepwn/analyzers/tests/pastebinurlanalyzer_test.py
35
36
97.22%

Totals

Change from base Build 290:
0.7%

Covered Lines:
2131

Relevant Lines:
2814

💛  - Coveralls


'User Defined Injections' feature is missing access rights to configmap

What happened?
NRI is not able to read configmaps, and in result is not able to inject user defined resources into POD specification.
In logs I see such warning
W0407 09:50:20.910817       1 main.go:189] Failed to get configmap for user-defined injections: configmaps "nri-user-defined-injections" is forbidden: User "system:serviceaccount:kube-system:network-resources-injector-sa" cannot get resource "configmaps" in API group "" in the namespace "kube-system"
What did you expect to happen?
I expect that NRI is able to get configuration from configmaps
Note
I did small research on this topic and I think that the problem are permissions defined at
https://github.com/k8snetworkplumbingwg/network-resources-injector/blob/ad8f87007972068bca901a56fb43651262eb381a/deployments/auth.yaml#L72
when I add there configmaps to the resources list, injection feature starts to work as expected.

@MichalGuzieniuk  Good stuff finding this. Can you produce a PR to fix this?

Sure, I will provide a PR with fix.


Add labels to Tree series chart lines

One-line summary [问题简述]
This is a feature request. Add the option to see labels in the lines of the Tree series chart.
Version & Environment [版本及环境]

ECharts version [ECharts 版本]:
Browser version [浏览器类型和版本]:
OS Version [操作系统类型和版本]:

Expected behaviour [期望结果]
ECharts option [ECharts配置项]

option = {

}

Other comments [其他信息]

HI @rgomesf , can you post a shot of the example you request.

Hi @pissang . Sure. Here you go

Be able to format the lines as arrow would also be a nice feature.

也想知道Echarts目前能不能实现这个功能

+1
This would be a useful feature. Is there any timeline for when this will be available?

@rgomesf hi, I would like to know how you add arrows in tree series chart, would you mind share the code ?

Is this feature available or not?

+1

Just wanted to throw this would also be valuable for me. I have a use case representing a taxonomy as a tree and it would be useful to add labels to the edges between parents and children to distinguish different types

+1 for supporting edgeLabel in tree.

+1

+1

I found a workaround! :)

I made the relationships to be nodes and I set the symbol of those nodes to "none".
Here is my chartOption data:
{
"name": "somenodelabel",
"children": [
{
"name": "somelinelabel",
"symbol": "none",
"collapsed": false,
"children": [
{
"name": "somenodelabel",
"collapsed": false,
"children": []
},
{
"name": "somenodelabel",
"collapsed": false,
"children": []
}
]
}
]
}


instrumentation bug

Despite providing very little information @matomatusov, I think I have an answer for you.

Note in my diagnostic usage the value says 8. This is wrong. I have used two API calls in this UTC day period, and the logged forecast fetches reflect this. Now open the diagnostic sensor. I expect you will see something like this. The history shows correctly, yet the API used does not.

So this is an instrumentation bug, and thanks for pointing it out. It will be fixed in a future version.
Originally posted by @autoSteve in https://github.com/BJReplay/ha-solcast-solar/issues/187#issuecomment-2424468689

I just wonder why the entire API limit was not reached.

Have a look in your HA log.  I suspect you (like many of the rest of us) have been suffering from 429 errors from Solcast that mean that some of the scheduled retrievals have been attempted but are not successful.

Have a look in your HA log. I suspect you (like many of the rest of us) have been suffering from 429 errors from Solcast that mean that some of the scheduled retrievals have been attempted but are not successful.

HA log -  Setting - System - Logs  - I only have this warning
Logger: homeassistant.components.sensor.recorder
Source: components/sensor/recorder.py:254
integration: Sensor (documentation, issues)
First occurred: 6:26:15 PM (7 occurrences)
Last logged: 6:26:15 PM
The unit of sensor.solcast_pv_forecast_day_3 (None) cannot be converted to the unit of previously compiled statistics (kWh). Generation of long term statistics will be suppressed unless the unit changes back to kWh or a compatible unit. Go to https://my.home-assistant.io/redirect/developer_statistics to fix this
The unit of sensor.solcast_pv_forecast_day_4 (None) cannot be converted to the unit of previously compiled statistics (kWh). Generation of long term statistics will be suppressed unless the unit changes back to kWh or a compatible unit. Go to https://my.home-assistant.io/redirect/developer_statistics to fix this
The unit of sensor.solcast_pv_forecast_day_5 (None) cannot be converted to the unit of previously compiled statistics (kWh). Generation of long term statistics will be suppressed unless the unit changes back to kWh or a compatible unit. Go to https://my.home-assistant.io/redirect/developer_statistics to fix this
The unit of sensor.solcast_pv_forecast_day_6 (None) cannot be converted to the unit of previously compiled statistics (kWh). Generation of long term statistics will be suppressed unless the unit changes back to kWh or a compatible unit. Go to https://my.home-assistant.io/redirect/developer_statistics to fix this
The unit of sensor.solcast_pv_forecast_day_7 (None) cannot be converted to the unit of previously compiled statistics (kWh). Generation of long term statistics will be suppressed unless the unit changes back to kWh or a compatible unit. Go to https://my.home-assistant.io/redirect/developer_statistics to fix this

I only have this warning

Repair the issues. You don't care about statistics for future forecasts. (This may be related to change that @gcoan requested to change the state_slass of these sensors.

I just wonder why the entire API limit was not reached

@matomatusov check your logs for successful fetches. Count them. If you cannot see them then enable INFO level logging for the integration. (Follow this https://github.com/BJReplay/ha-solcast-solar/discussions/38#discussioncomment-9792389, but set for info, not debug.)
There is an instrumentation issue, after all.

Repair the issues. You don't care about statistics for future forecasts. (This may be related to change that @gcoan requested to change the state_slass of these sensors.

I'll get forever tarred with any statistics issues now...
On mine, 4.2.0, I have statistics happily collating for all the pv_today/tomorrow/d3 etc, uom=kWh for all.
Whether I need the LTS for these is debateable, and I may suppress tomorrow/d3 onwards so as I can do forecast vs actual comparisons, but LTS take up very little room so may not bother.
When did you make state_class changes @autoSteve ?

where can I disable it?

@

Hi @BJReplay ,
thanks for the information on where to find it.

I see no problem there.

The original message tells you how to fix it - and has a has a redirect in it. It might take you to the original error - if it still exists.
I have seen this error myself when defining my own sensors and changing the UOM as a notification in HA: when I click on it, it offers me the opportunity to fix (update the old statistics to the current UOM) or ignore.
If you ignore, it clears the error, and you won't see it again.

Locked conversation to repo collabs.
This has become tar paper for unrelated discussions.

I can replicate this issue. But I cannot get to the root cause.
The sensor updates on forecast fetch or startup, and this is seen in the history, yet the sensor value shown is not correct, which makes no sense. Obscure HA bug?
I am going to switch that sensor to the per-five minute update interval and observe to see if it behaves.

Obscure HA bug?

Yeah, I suspect.  I think it might be the same root cause as my laggy firing of events that fire seconds, or even minutes later than they should.  The update to update the value is stuck in a queue (and maybe gets discarded as aged by some cleanup process)?

Bed for me shortly.  Early start tomorrow.

202 downloads of 2.4.2 so far. 🤞

Talk about tar paper for unrelated this issue. Pot. Kettle. Black. Bwahaha!
(So living in the past that version. Pre-Oziee, I get what you mean. 😂 I almost did that myself earlier! Two-four-two-four-two... what?)

I have not observed this issue since switching the api_used counter listener to be five minute update.

I haven't seen it for a while, but I guess safe to close this with v4.2.5

I think I need to eat some humble pie regarding sensors not updating for used and last updated.
There was a glaring issue in the coordinator sensor update code, which has since been fixed.
To be honest, I am surprised these sensors were working before.


How to hide camera icon?

We want hide camera icon.

you can find  xib file in the library folder


Sidebar that won't disappear? Not sure if bug

For some reason, I have this sidebar here that I can't get rid of. I'm not sure if it's from the Extended addon, but it's only on my main toon that this appears on.
Here's an image of what that sidebar looks like:

It gets in the way of one of my other addons, and frankly, it's kind of annoying! I don't know how to get rid of it, either.
Does anyone know how to get rid of this thing?

You currently have a campaign active in TRP3: Extended which involves using an action. Pause the campaign in the Quest Log section of TRP3 and the bar will be hidden.


Conclusion: don't install nikic/php-parser v5.1.0 (conflict analysis result)

Feature

why we need this

it looks nikic/php-parser v5.1.0 not support
  Problem 1
    - Root composer.json requires pinpoint-apm/pinpoint-php-aop v3.0.6 -> satisfiable by pinpoint-apm/pinpoint-php-aop[v3.0.6].
    - phpunit/phpunit[11.2.7, ..., 11.3.1] require phpunit/php-code-coverage ^11.0.5 -> satisfiable by phpunit/php-code-coverage[11.0.5, 11.0.6].
    - phpunit/phpunit[11.0.1, ..., 11.2.6] require phpunit/php-code-coverage ^11.0 -> satisfiable by phpunit/php-code-coverage[11.0.0, ..., 11.0.6].
    - phpunit/php-code-coverage 11.0.6 requires nikic/php-parser ^5.1.0 -> satisfiable by nikic/php-parser[v5.1.0].
    - phpunit/php-code-coverage[11.0.0, ..., 11.0.5] require nikic/php-parser ^5.0 -> satisfiable by nikic/php-parser[v5.0.0, v5.0.1, v5.0.2, v5.1.0].
    - Conclusion: don't install nikic/php-parser v5.1.0 (conflict analysis result)
    - Root composer.json requires phpunit/phpunit ^11.0.1 -> satisfiable by phpunit/phpunit[11.0.1, ..., 11.3.1].

fixed by https://github.com/pinpoint-apm/pinpoint-php-aop/releases/tag/v4.0.0
composer require pinpoint-apm/pinpoint-php-aop:^v4.0.0


Requested Maps & Visualizations

@flaneuse & @npetrovic42 - Family planning visualizations:

[ ] Current  Method use (long-term - Short term) by district and age
[ ] Family size preference by district, economic status and age
[ ] Unmet need by district, economic status and age
[ ] Mobile map by gender + distribution across wealth spectrum
[ ] infrastructure base maps
[ ] stunting by district + point estimates and ci's sorted in a dot plot with whiskers

Feel free to post drafts below in comments.

Stunting by interview date.

Stunting rates by district.


GetLineToLine Intersection incomplete

Version

Phaser Version: v3.55.2
Operating system: OS

Description

File: phaser/src/geom/intersects/GetLineToLine.js
Function: var GetLineToLine = function (line1, line2, out) {

Problem: If line1 is horizontal (line1.x1 == line1.x2) the function returns false. It does not care if the line2 is intersecting or not.
In the comments I found (Line45 - 47)
//  Make sure there is not a division by zero - this also indicates that the lines are parallel.
//  If numA and numB were both equal to zero the lines would be on top of each other (coincidental).
//  This check is not done because it is not necessary for this implementation (the parallel check accounts for this).

imho this is a wrong assumption. The lines can still intersect if dx1 === 0 --> this just means line1 is horizontal.
Workaround to this to run GetLineToLine(line2, line1)
Example Test Code
Code Pen for Testing
const l1 = new Phaser.Geom.Line(200, 150, 200, 50);
const l2 = new Phaser.Geom.Line(50, 100, 250, 100);

let resultLine1WithLine2 = Phaser.Geom.Intersects.GetLineToLine(l1, l2);
console.log(`Line1 with Line2: ${resultLine1WithLine2}`);
// Console: "Line1 with Line2: false"

let resultLine2WithLine1 = Phaser.Geom.Intersects.GetLineToLine(l2, l1);
console.log(`Line2 with Line1: ${resultLine2WithLine1}`);
// Console: "Line2 with Line1: [object Object]"

Current Workaround
let result = Phaser.Geom.Intersects.GetLineToLine(line1, line2);
if (result === false) {
    result = Phaser.Geom.Intersects.GetLineToLine(line2, line1);
}

Yeah, I had already found this when realizing the PR that modified this function had broken line to ray intersection too.
Please could you try doing a build from the main branch, where it should now work correctly, and let me know what you get?

I am just building prototypes in Codepen. I was using:
<EMAIL_ADDRESS>✅  Work's like a charm --> User is happy 😅
I removed the workaround and it works. Projekt:
Phaser3 Riddle Untangled


Port usb_dc_numaker to USB_DEVICE_STACK_NEXT

In order for the USB_DEVICE_STACK_NEXT to become the default, existing USB device drivers must be ported to it.
See #42066 for additional details.
Note that if this driver is not ported by Zephyr 4.0.0, this hardware will not work with the default USB stack in 4.0.0.
Example ports:

udc_kinetis and udc_nrf PR #38679
udc_it82xx2 PR #65792
udc_dwc2 PR  #64943
udc_stm32 PR #53408
udc_mcux PR #70401

Skeleton file to use as a starting point:
https://github.com/zephyrproject-rtos/zephyr/blob/main/drivers/usb/udc/udc_skeleton.c

CC @ccli8, @NiekIlmer

Cc @blauret @andrzej-kaczmarek

Thanks. The port to USB_DEVICE_STACK_NEXT is scheduled.

This is handled via #76078.


Remove duplicate files.

Remove duplicate files in Ultra folder.

If the ultra/ directory is being distributed on pypi standalone, shouldn't we keep the LICENSE? Or is it only needed for github.


What is the threshold for deployment?

Previous BIPs for bitcoin had Supermajority at 95% XT introduced 75% + short grace period. Such a low threshold opens up a 51% style attack where a lucky streak could occur... i.e. BC is running 40% of hash rate but clear 750 blocks... The BC chain would activate with only 40% on board essentially splitting the network 60/40 with Bitcoin Classic on the lower %

You're ridiculously overestimating the odds of a "lucky streak" triggering a fork without a majority.
The probability of "winning" 750 out of 1000 consecutive blocks with 50% or less of the hash power is 4.3 x 10^-59.   In layman's terms there a better chance of someone winning the USA "Power Ball" jackpot 8 times in a row.
Even the odds of getting 750/1000 of the block with 70% of the hash power is virtually nil.  750/1000 blocks is more than enough to ensure a definitive super majority.

I would like to change the code to only test the forking condition once every difficulty adjustment instead of every single block. That addresses the luck issue a lot.
With a 750/1000 threshold, there is a significant chance of activating with only 70% of the actual hashrate within a month or two. Support below that has very rapidly diminishing probabilities.
There are three dangers to using an excessively high threshold:

It paints a target on the back of small miners. Bitcoin is supposed to be able to make censorship-resistant decisions. If 95% support is required to make this decision, then someone could harass or blackmail a miner and convince them to not support the fork, thereby blocking the ability to make a decision. The higher the threshold, the more effective these types of tactics are. This is not simply an academic concern: Many of the Bitcoin Core developers have received death threats in the last year. One committer to Core released his commit access and dropped out of public view, likely as a result. The use of dark net marketplaces with Bitcoin payments for illicit services to carry out these attacks makes them even more plausible.

A 51% majority could enforce any other majority if it wanted to. In magical game theory land, the only threshold of miner support that is justifiable is 51%. Everything above that falls into the realm of ensuring smooth deployment.

The higher the threshold, the greater the power of a minority. With a 75% threshold, "Nay" votes are 3x as potent as "Yea" votes. I think that's more than enough. At 95%, "Nay" votes would be 19x as potent. I think that's crazy.

Some earlier comments I made on reddit:
https://www.reddit.com/r/Bitcoin_Classic/comments/40wnre/on_activation_thresholds/

There's a good chance of activating at 72% but definitely not at 70% the odds are quickly diminishing.
https://www.reddit.com/r/btc/comments/418xzh/the_odds_of_forking_with_75_hash_power/
Changing the activation code will take time. I wouldn't do it unless the miners demand it. But it would be easier to just change the activation threshold to 780/1000 blocks.

I wouldn't call a HF activation threshold political but thanks for addressing my concern.

Since this code is now deployed, I think that it doesn't make sense to leave this issue open any longer.


I want to have mandatory field validation inbuilt

So that we can ensure that mandatory fields are filled out before submitting all forms

New form layout_FOR IDOX.xlsx


change package-source to package_source for consistency

Chef_ingredient used package_source as well as chef-analytics/recipe/default.rb.  Changing this to be consistent

:+1: LGTM :shipit:


Gradle plugin to auto install the apk on emulator?

Would be great if there was a plugin which downloaded and installed the apk prior to running Android tests. Would make set up and CI setup sooo much easier!

This will help #15 to be done

This is a task I use in my projects. If requested, I can turn it into a proper Gradle plugin (though there are some subtleties...). The way I am pasting here might be useful for others.
final butlerPackage = 'com.linkedin.android.testbutler'
final butlerApkPath = "$rootDir/tools/test-butler/test-butler-app-${rootProject.ext.testButler}.apk"

/**
 * This task installs the test-butler apk in all emulators if needed
 */
task installButlerApk {

    doLast {
        logger.info("Verifying test-butler installation in emulators")

        final adb = "$android.sdkDirectory.absolutePath/platform-tools/adb"

        final String[] split = "$adb devices -l".execute().text.split("\\r?\\n")

        split.each {

            if (it.isEmpty() || !it.startsWith('emulator-'))
                return;

            logger.info("Emulator: $it")

            final emu = it.split("\\s")[0]
            // checks whether the APK is already installed
            if ("$adb -s $emu shell pm list packages".execute().text.contains(butlerPackage))
                return;

            final installResult = "$adb -s $emu install $butlerApkPath".execute().text

            if (!installResult.contains("Success"))
                logger.log(LogLevel.ERROR, "Could not install APK. Install output:\n$installResult")

            else
                logger.info("Installed $butlerApkPath in $emu successfully")
        }
    }
}

My solution is to put this somewhere in a gradle file and to source it if anyone is interested.
configurations {
    testButlerApp
}

dependencies {
    testButlerApp 'com.linkedin.testbutler:test-butler-app:1.2.0'
}

def installTestButlerApp() {
    exec {
        executable android.adbExe
        args "install", "-g", "-r", "-d", "-t", configurations.testButlerApp.singleFile
    }
}

android.testVariants.all { variant ->
    variant.connectedInstrumentTest.doFirst {
        installTestButlerApp()
    }
}

@cs-victor-nascimento if you could turn it into a gradle plugin that would be great!

@jd-alexander Sorry, but since @drewhannay said they have this on their backlog I won't publish a plugin for this feature because it would quickly (we hope) get deprecated.
I've created a gist that includes automatically downloading of the TestButler-app APK per version. It includes some instructions on how to use it. Also, if it helps, I have an archetype like project that has this enabled. Here is the link. It mentions TestButler in the README. Hope it helps until the plugin is released.

Just another update to whoever is following this issue. I've just noticed that Test Butler is mentioned in the new android gradle plugin configuration. If you've watched the TDD talk on Google I/O it seems they will be providing an apk for orchestrating test runs in the device/emulator. In order to do that, they've added a new configuration in gradle which the plugin will read and install in the device/emulator prior to running the test suite.
https://developer.android.com/studio/preview/features/new-android-plugin.html
So, if you are using 3.0.0-alpha1 you can add this configuration:
dependencies {
  androidTestUtil 'com.linkedin.testbutler:test-butler-app:1.3.0@apk'
  ...
}

This is really awesome. Once AGP 3.0 makes it to the stable channel, I'll update the Test Butler README file with how to use this and then we can (finally) close this issue.

@cs-victor-nascimento Unfortunately it doesn't work with 1.3.1.  I get an error:

@IgorGanapolsky What kind of emulator are you using?

@drewhannay Api 26, x86 emulator with Google Play.  This error actually went away if I use an emulator with Api 25...

That was my guess. The Google Play emulators for API 26 are now signed with a different key, because they include Google Play support (you also won't have root access anymore, IIRC). The AOSP emulator (which has not yet been released for API 26) will still be signed with the test-key and will still work with Test Butler.

Actually it is also failing with same reason on emulator without playstore with api 26:
system-images;android-26;google_apis;x86
Reason:
Caused by: com.android.ddmlib.InstallException: INSTALL_FAILED_SHARED_USER_INCOMPATIBLE: Package couldn't be installed in /data/app/com.linkedin.android.testbutler-BbYyEzpMbbuCNDKyVia5pQ==: Package com.linkedin.android.testbutler has no signatures that match those in shared user android.uid.system; ignoring!

I've had to replace test butler with the espresso grant permission rule. It'd be nice if Google didn't break test butler and offered a work around.

But still you also need to disable animations for UI tests and  there is no such Rule 😭

I know, I love test butler. I don't see how to make it work with the new emulators though. On firebase test lab, they are disabling the animations.

For new emulators (API 26+), use android.testOptions.animationsDisabled.
For <API 26, it disables only view animations, not transition and window animations, I think (see here). Not sure how to conditionally apply test butler for <API 26. This would be a workaround for test butler not working with Google Play emulators.

Anyone know what animationsDisabled actually does? Is it simply passing the --no-window-animation option to am instrument?

pretty sure it toggles --no-window-animation ^

Any way to skip Caused by: com.android.ddmlib.InstallException: INSTALL_FAILED_SHARED_USER_INCOMPATIBLE when installing on a physical device?

@lawonga there isn't currently a workaround (see https://github.com/linkedin/test-butler/issues/22#issuecomment-324668629)

Hello 👋
I added the dependency "com.linkedin.testbutler:test-butler-app:2.2.1" but how can I run it and install the apk in my emulator?
Thank you


Stopped announcing the AlertDialog's route since it is redundant

Description
The first item on the alert has the same text as the route, so it is redundant.
With my testing Android behaves exactly the same, on iOS the alert's name isn't announced twice.
Related Issues
https://github.com/flutter/flutter/issues/44001
Tests
Manual testing, there isn't integration tests for the accessibility code.
Checklist
Before you create this PR, confirm that it meets all requirements listed below by checking the relevant checkboxes ([x]). This will ensure a smooth and quick review process.

[x] I read the Contributor Guide and followed the process outlined there for submitting PRs.
[x] I signed the CLA.
[x] I read and followed the Flutter Style Guide, including Features we expect every widget to implement.
[x] I read the Tree Hygiene wiki page, which explains my responsibilities.
[x] I updated/added relevant documentation (doc comments with ///).
[x] All existing and new tests are passing.
[x] The analyzer (flutter analyze --flutter-repo) does not report any problems on my PR.
[x] I am willing to follow-up on review comments in a timely manner.

Breaking Change
Did any tests fail when you ran them? Please read Handling breaking changes.

[x] No, no existing tests failed, so this is not a breaking change.
[ ] Yes, this is a breaking change. If not, delete the remainder of this section.

[ ] I wrote a design doc: https://flutter.dev/go/template Replace this with a link to your design doc's short link
[ ] I got input from the developer relations team, specifically from: Replace with the names of who gave advice
[ ] I wrote a migration guide: https://flutter.dev/go/breaking-changes-template Replace this with a link to a pull request that adds the migration guide to https://flutter.dev/docs/release/breaking-changes

Hi @gaaclarke , Are you still working on this PR?

No.  After further consideration, I think the current behavior is correct after having played with iOS and Android.  On Android it is announced that an alert is presented, on iOS it doesn't.  If we removed the announcement of the route, all semantics hints of its presence will be removed.  Yes, the title of the alert and the route are the same, so it will be spoken twice.  When coming back to a dialog it would be equally valid for voiceover to select the last selected item which wouldn't be the title.  Then not speaking the route would be even more confusing.  If someone wants a different behavior I think they could get it by creating their own alert.  It wouldn't be correct to have that alert in the framework though.

Will the iOS focus anything other than the tittle when a new dialog is open?

@chunhtai the way we've currently implemented things on ios it will always select the title.  On android it selects the last selected item.

For screen changes, we now only passes in the string, we do now force iOS to pick a title, it is by default that iOS do that.
However, if that is the case,  aren't we always sure the alert title will be announce twice for iOS? in that case, should we remove the name route, or give it an empty string when the platform is iOS?

This is the correct change if you want to get rid of it I think.  I'm of the opinion that that isn't necessarily the correct thing to do.

ok, I just remembered I made a change to be able to add alert semantics label without introducing an additional node, if developer does not want this behavior they can give it an empty string.
AlertDialog(
 SemanticsLabel:  " "
)

So I think this is fine.


Reverse tethering being the tethered device the one with ADB access to the tethering device

Hi.
I tried this tool and it works! Thank you for your work.
I got it working connecting the tethering phone to the tethered phone using a USB C male to USB A female adapter in the tethered phone, and a USB A male to micro USB male cable connected to the tethered phone.
However, I am not sure if I can do the same sharing if I use an adapter from micro USB male to USB A female and a USB A male to USB C male to the tethering phone.
Would it be possible? In my first attempt, I was not able to do it. I want to try the same being the tethered Android device a tablet with only USB A female ports, so I am not sure if it would work.
Is there any way I can get it working as I mention?
Thanks again!

I mean, I would like to be able to connect to the Internet from the device that can access the tethering device using ADB, like:
$tethered: adb devices:

tethering

so you mean,
tethered - micro USB male - USB A female - USB A male - USB C female - tethering?
I haven't tested it (I don't have usb male to female cable now), but it would work.

The tethered device must be a host device and the tethered device must be running an ADB server. it is impossible to do it the other way around since gnirehtet doesn't support it.
make sure that the tethered device is a host device if it doesn't work. (there will be an option like 'USB controlled by this device')

That's what I was thinking. The problem is that I wasn't able to perform that usb control switch (it does not work) and I didn't find another way to switch the USB controller device.
Therefore, my hope is that executing that adb forward I could perform a kind of reverse ADB connection and run this script.
Something like:
tethered:
adb forward tcp:5037 tcp:5038
tethering:
adb connect localhost:5038
./gnirehtet relay
But I'm looking for a termux alternative (perhaps creating an app) to run those ADB commands from the tethered device, since termux-api and termux-adb are not working, but other adb shell apps do

I did it. connect two devices with USB cable. the tethering device is host now.
tethering device:
./gnirehtet relay # listening on 31416

tethered device:
turn on wireless debugging and pair with termux-adb
adb connect localhost:40643 # connect itself
adb -s localhost:40643 forward tcp:31416 tcp:31416
adb -s localhost:40643 reverse localabstract:gnirehtet tcp:31416
adb -s localhost:40643 shell am start -a com.genymobile.gnirehtet.START -n com.genymobile.gnirehtet/.GnirehtetActivity # start gnirehtet

Thank you for the steps @AlphaBs ! It is really nice to know it works.
My main concern with my setup is that my tethered device runs Android 10. Therefore, I can't enable wireless ADB from developer options.
Do you know if it would be possible to do the same without wireless ADB? Or to enable it without USB nor root permissions? Because that is becoming my main obstacle.
Another approach I have thought is to study the gnirehtet source to modify it to work with the 31416 port in the opposite direction, but first I need to understand better how it works.

Ok. I managed to simplify it without wireless ADB with these commands:
Tethering device:
./gnirehtet relay # listening on 31416
Tethered device;
adb forward localabstract:gnirehtet tcp:31416 # forward gnirehtet relay server
am start -a com.genymobile.gnirehtet.START -n com.genymobile.gnirehtet/.GnirehtetActivity # start gnirehtet

I'm running those commands in the tethered device outside Termux with root access. I have to check if I can do the same without root permissions inside Termux or in another app. In my real tethered device, termux-adb is not working (it always says device offline) so I'm thinking about modifying the gnirehtet app to also implement ADB and establish this forwarding, but I'm not sure how easy it will be.

on my device, termux-adb works well with adb forward. gnirehtet need to be modified to connect to tcp:31415. (source code)


Feature Request: Reports navigation framework

After reading through the reports/main.js file, I have found that it is an all-in-one solution for the Net Worth report, where the same class seems to handle navigation to and from the report as well as calculating the report and laying it out.
In order to make writing reports easier for others, please extract the actual Net Worth report into its own file, and refactor the reports navigation code so that it will open the 'reports' window and show any number of reports inside itself. Make it into a host, of sorts, so that reports can become guest areas within it.
This would simplify the writing of additional reports because the programmer of the report could focus on the code for the report only, rather than how to integrate into the Ynab app itself. I would be happy to write a report or two if it were easy to integrate into the framework, but I must admit that I do not even know where to begin with the current solution.

@damccull if you take a look at #482 and #490 you'll see a complete refactor of how that code works.
Once that code is in master reports will only have to export a calculate and createChart function. calculate must return a promise and will be passed all transactions in the current account/date filter.
I'll write up some formal documentation for this tomorrow  but for the time being you can check out those PRs to see how it will hopefully be in the near future

Wow, you see the future or something, cause this was done before I even wished it! I think that's a great way to do it.


Add simple user-frandly loader

Which is not to finish the initialization process in the fall of one of the mods.

Added catching errors: @da729bd


Use clap Derive for cleaner command line interface

Tasks:

[ ] Update dependencies (particularly clap), which introduces the Derive trait in v3
[ ] Use Derive trait over App Command.

At the user level, this is the only change (and hence, why we will only be incrementing the patch version):
Before:

After:


Server with Jax-Rs

When using a JEE container, we want to benefit from the integration capabilities provided b y JAX-RS. This fork add some interfaces around the classes such as RestfulServer, RequestDetails and ResponseDetails in order to remove the dependencies to the servlet-api.
By making use of these interfaces, it become possible to create a jax-rs server. This fork includes a working jax-rs server base, jax-rs server example and the necessary changes to the hapi-base to make it work.

Hi Peter- Just wanted to mention that I'm not ignoring this. I am in the process of releasing HAPI 1.3 and I figured it would be lower risk to land this after that release was out the door.
Will look at merging as soon as 1.3 is done, which will be very soon.

Hi @petervanhoute ,
I've merged this now. Looks amazing! I've also added you in as a committer so you can do any maintenance to it you need.
In merging, I made one change to it. I don't think paging was working correctly as the patch stood. It required the URL to have the name of the resource in it, e.g.
http://example.com/Patient?_getpages=foo
instead of
http://example.com?_getpages=foo
A bunch of other things depend on the paging requests working from the root of the server so I fixed that.. but would you be able to look at what I did and see if it makes sense?

Hello @jamesagnew ,
I'm glad you like it! Thanks for merging and adding me as a commiter.
I was struggling with the paging and the URL's (self, next, resource references, ..). It's good you found an elegant, working solution for the paging and the url's.
You can remove the commented line 389 in Dstu2BundleFactory.java:
//			theServerBase = theCompleteUrl.contains("?") ? theCompleteUrl.substring(0, theCompleteUrl.indexOf("?")) : theCompleteUrl;
Kind regards,
Peter


Bug in Drop-Down Menu.

Assign me this issue .

I want to work on this issue under JWOC

I want to work on this issue under JWOC

Design has been changed see #3


Update parcility.py

Switch from Saurik's old API to stkc.win/addrepo with support for the 4 major package managers.

STKC WIN!!!!!!!!!


Mark HoneyDB as FIPS Compliant in app metadata

Mark the app as fips_compliant
Fix Verbose Period failing test
Fix isort linting tests
Fix Compile App error

Failing Static Test:

Compile App
Min Platform Version

Static Test Failing:

Min Platform Version


Fix install script, broken by introduction of nightly flag

As of 02c1ec8bf248f4e2ec3a0b4262fb1873606aa543 the install script is broken, as it tries to dereference $1 unconditionally even though set -u is enabled for the file.
This introduces a check that it's set before trying to dereference it.

Thank you for this fix. I was excited to try SurrealDB, but was instantly stopped by this issue on the very first step: running the install script! I will just add some information for those who might be searching for this.
When running the following command to install SurrealDB on Linux:
curl -sSf https://install.surrealdb.com | sh

I received this error:
main: line 58: $1: unbound variable

As stated by @tekacs above, the issue is that the install script tries to reference a positional $1 parameter. However, this parameter is not set. Since set -u is enabled for the file on line 15, the script throws an error.
The fix is to change line 58 to the following:
if [ -v 1 ] && [ "$1" != "--nightly" ]; then

Thanks for this pull request @travishorn 🚀👍!

install works now but on my machine it still throws a v not defined error


Branch naming and Gitflow oversight

This will take a while to walk through, so my apologies. But in short, I think it might be beneficial to allow for unique country develop-branch names in the naming schema. Ex: MEX-1, ZAF-7, etc.
Let me explain why through links, pictures, and Gitflow.
The general structure of our workflow is parallel, but it's not entirely isolated: code updates from one develop branch are often needed in another. Let's take the case of this recent issue, #142 , ISCO as String. In this instance, let's say we have the following branches:

develop-merge
IDN
IND
MEX
PHL
ZAF
TUR

I'm just going to pick the first two for simplicity but the case applies to all of them. Here's a parallel snapshot of IDN and develop-merge.

The star ( ⭐ ) commit in develop-merge indicates an update that IDN needs -- similar to naming schema when @gronert-m updated the code for GLD checks that we all would need. How should that updated in (⭐ ) go to IDN?
From this guide there are two principle options in git:

Merge the branches, or
Rebase IDN from develop-merge

Merging
Merging is 100% what we've been doing so far, via a pull request. From what I understand, merging is generally preferred because it preserves the commit history of both branches. Of course, when you merge via pull request, you update the branch you merge into, so, in this case, develop-merge gets all the updates from IDN in order for the harmonizer in IDN to get the (⭐) update.

It's considered best practice to delete the IDN branch after you merge from the remote (cloud) to avoid clutter, and because after the merge, having IDN becomes redundant and necessary: all commits in IDN are in develop-merge. There's no more IDN now.
However, git keeps a copy of each branch on the remote and on your local computer: when the harmonizer deletes IDN on the remote, a copy stays locally on the harmonizer's computer by default (I believe). I think this is so you can restore the branch later if problems occur, and probably other reasons. This remote-local dynamic is important because....
You can't really do this:

The harmonizer cannot recreate IDN after merging with develop-merge because this branch already exists elsewhere in the repository history (i.e., on the harmonizer's local computer). If we follow the naming guidelines as they stand now  the new IDN develop branch should be called IDN. I see a few ways to get around this, but stating my opinion for number 2:

Do not modify the guidelines and begin a git rebase workflow
Modify the naming guidelines to allow for numbers or some quasi-infinite iteration to develop branches

The reason I suggest 2 is because git rebase can be risky if you're not careful. Let me explain.
Rebase
Instead of merging the changing of IDN into develop-merge, we could git rebase (see the guide above for the terminal command). Here's what this does:

leaves develop-merge untouched
takes all changes from develop-merge and adds commits from IDN "after" those

How is this actually accomplished? You can do this in GitHub Desktop or in GitKraken. However, I think I would prefer doing this in GitKraken because you can perform an "interactive rebase", which essentially gives you more control, and I don't think you can do this in GH desktop.
If we really really cared about keeping our naming scheme the way it is, this may solve our issue. But we would have to rebase every time to get changes in another branch like (⭐), which we've seen happens more often than we think. Also, in terms of repo cleanliness, it sort of messes with branch histories: when you rebase IDN, you are re-writing the commit history of IDN. I personally don't like that, but there are competing organizational theories out there.
In summary, I think the least-destructive option is to create some sort of counter that allows for semi-infinite iterations of develop-branches.

[AAA]-#
[AAA]#
[AAA]-[random 3 digit string]

This way, we can merge or rebase as desired, and the branch can be merged and re-created as many times as needed. It is slightly annoying, but I think we will all run into the duplicate branch problem eventually. Thoughts and opinions are obviously welcome here and I think we should obviously discuss this at our next meeting.

Thanks @buscandoaverroes for highlighting this. I have read the article from Bitbucket. I think one line that is important here was what is said about constant remerging:

If main is very active, this can pollute your feature branch’s history quite a bit. While it’s possible to mitigate this issue with advanced git log options, it can make it hard for other developers to understand the history of the project.

I guess the question here is:

Do we update main often in a way that requires feature branches to have those updates?
Do we worry about polluting the feature branch's history?

In the first case, it is not when a new harmonization is added to main that is relevant (adding PHL has no impact on feature IDN) but the general "support" kind of things. This has been happening of late though I am unsure how much of it is regular upkeep, how much is growing pains. If it is the former (and I read you as seeing it that way) it is necessary, if it is the latter, less so. I wish it were the latter, but am uncertain now.
On the second point, I think polluting the feature branch's history is not a problem, as it is thought for eventual deletion anyway.
My feeling so far is: rebasing is a good idea, but I would leave it up to whoever is running the feature branch.
Then there is the second part about names not being able to be repeated. This I did not understand. I just created a new branch called prueba from main. I made a small amendment to the readme file and committed it, so prueba was one ahead of main. Then I deleted prueba and created a new branch called prueba. This was not the old prueba (i.e., it was equal to main and not one ahead) and at no point did the system tell me the name was blocked.
I did this exclusively on the website via browser. I would request you run such a scenario with a branch you create locally on your computer and push to the web, then delete and recreate to confirm that what I did in the web is also possible via local copies on the hard drive. If deleting and recycling names is possible, would this not make the [CCC]-[###] naming convention redundant? (Which is independent of the rebasing debate).


Make dumpapp available in PyPI

It would be nice if you could publish dumpapp into PyPI, so we can install without cloning whole source tree.

Great idea, though I'm not personally familiar with pypi, any chance you
could help us get a deployment script or some kind of automation set up to
do this with each release of Stetho?
El lun., 6 de mar. de 2017 07:55, Mariotaku<EMAIL_ADDRESS>escribió:

It would be nice if you could publish dumpapp into PyPI, so we can
install without cloning whole source tree.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/facebook/stetho/issues/508, or mute the thread
https://github.com/notifications/unsubscribe-auth/AAFHT4XEdFIaFyenI3ewwJ06m8NZLdIJks5rjCx0gaJpZM4MUVIi
.

According to this http://peterdowns.com/posts/first-time-with-pypi.html
article, all you need to do is create some metadata, register PyPI account
and upload.
Since most information should be completed by Facebook/Stetho staffs
(because you guys owns the code and licenses) , I guess all I can help is
give more info and references about this feature request.
Josh Guilfoyle<EMAIL_ADDRESS>周二00:12写道：

Great idea, though I'm not personally familiar with pypi, any chance you
could help us get a deployment script or some kind of automation set up to
do this with each release of Stetho?
El lun., 6 de mar. de 2017 07:55, Mariotaku<EMAIL_ADDRESS>escribió:

It would be nice if you could publish dumpapp into PyPI, so we can
install without cloning whole source tree.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/facebook/stetho/issues/508, or mute the thread
<
https://github.com/notifications/unsubscribe-auth/AAFHT4XEdFIaFyenI3ewwJ06m8NZLdIJks5rjCx0gaJpZM4MUVIi
.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/facebook/stetho/issues/508#issuecomment-284444028,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAyrllanZP8N8ZrvB-oQldOLPWplJrH3ks5rjDBWgaJpZM4MUVIi
.

Didn't get to this in time for the next release but I'd like to tackle it for the next release.

So I got this all working in https://github.com/jasta/stetho/tree/pypi-upload but I'm unable to figure out how to assert that dumpapp can only be used with python3.  I added python_requires = '>=3' but this caused pip itself to complain, even though my system has both Python2 and Python3 installed.  I suppose I could just do the work to make dumpapp support python2 as well, but that seems regressive in a way.  I assume at this point virtually all systems contain python3 and can happily execute this code unmodified.


Web container depends on db container, fixes #3702

The Problem/Issue/Bug:

#3702

Web container should depend on db container readiness unless omit_containers
How this PR Solves The Problem:
This adds a depends_on for the web container if no omit db
Manual Testing Instructions:
Start a ddev in a new project, look in the .ddev-docker-compose-full.yaml file
Automated Testing Overview:

No tests added
Related Issue Link(s):
#3702
Release/Deployment notes:

N/A

I'm trying to figure out a manual test that will show this well. A huge DB might do it, may be able to see how long it takes for db container to get ready in that case, and keep a curl going in the db container.

I think this is causing macos-nfs to fail (more),  https://buildkite.com/drud/ddev-macos-use-nfsmount/builds/5108#bbcfd70f-75f9-474e-9604-dc494f7b0946
I've seen this plenty of times with NFS, never understood it. Essentially, the composer.json doesn't get there in time to be used, which is probably an NFS failure. But we're seeing it here on 3 different test runners.
Line 90 is this:
		args = []string{"composer", "create", "--prefer-dist", "--no-dev", "--no-install", "psr/log:1.1.0"}
		out, err = exec.RunHostCommand(DdevBin, args...)
		assert.NoError(err, "failed to run %v: err=%v, output=\n=====\n%s\n=====\n", args, err, out)

It's got --no-install even, so it's not trying to do a lot.
It will be interesting to see if it's recreatable in local with NFS. And of course this may just be random behavior, because it's been seen before. It's possible that slightly slower startup could affect this, or that the exec that's done doesn't respect the startup, etc.

Perhaps the complexity this is introducing isn't worth the change?
Maybe a better approach is, recommend someone to add an override compose file as needed for their project?

I don't consider this very complex. Just want to understand what might be happening. Would be lovely to understand why the composer.json doesn't exist when it needs to, since that's been an intermittent problem for years, and especially (only?) with NFS.  Since this one seem to fail every single time with macOS/NFS it may be a lovely situation to learn from. I'll spend a little time with it, and of course you're welcome to also. And I'm still in search of manual testing that will show the scope of this change and the impact on real users.

To test the behavior, I created an alternate healthcheck.sh for the database container (mysql/mariadb) that waits 15s before declaring the db container healthy.  I put that in .ddev/db-build
Then I added a .ddev/db-build/Dockerfile with
ARG BASE_IMAGE
FROM $BASE_IMAGE
COPY healthcheck.sh /
RUN chmod +x /healthcheck.sh

Then... export PROJ=d9simple; while true; do date && echo "===== Web container" && docker inspect --format "{{json .State.Health.Log }}" ddev-$PROJ-web |jq -r last && echo "==== DB container" && docker inspect --format "{{json .State.Health.Log }}" ddev-$PROJ-db |jq -r last && sleep 1; done
Do the ddev start in another windows.
That shows the health status of both containers, but you'll see that the web container has in fact been started and becomes healthy before the db container does. However, if you wait until ddev start completes to do things... it is behaving correctly waiting for both containers to be up. But I'm pretty sure that's true without this change.

@mikebarkas don't worry about the NFS test failure right now. It's lovely that it's predictable, I can reproduce it, have no idea why it would be impacted by the depends_on here.
I've been experimenting with the various things in

https://github.com/composer/composer/issues/9627
where composer added an environment variable COMPOSER_RUNTIME_ENV=virtualbox to deal with things just like this, doing a sleep to let the filesystem catch up. But I haven't been able to solve the problem using either that or the suggested dummy unzip command in that issue.

Always try a ddev start && ddev launch  :)
The syntax is yaml object syntax, not array syntax,
    depends_on:
      db:
        condition: service_healthy

We've all done it! :)

It's wonderful how consistent that with-NFS failure is, but I'm completely baffled how it relates to this change, and although I've chased a lot of angles with it here I haven't found anything that affects it. And since I can't recreate it with manual testing (which works fine) I'm a bit at a loss.

And now, unlike last time, we have the test failure on Windows NFS as well :( How in the world could this be affected by this PR... ??? :)

Thanks, I'm not sure it's actually changing "performance" as opposed to giving a realistic view of readiness, but I'm also interested in what you're seeing. Your result would seem to indicate that the db container is taking a really long time to come up, or that the go code that waits for it is doing something wrong.
Could you check the results of this with a plain vanilla project (ddev debug test for example) and see what you see.
I'm actually not used to ddev start taking anywhere near as long as you're seeing. You're on Linux right? I would expect 10-30s.
Oh, you're doing 10 restarts, so that's reasonable. I thought you were doing one restart.

restart overemphasizes the effect by also showing docker-compose safely tearing down the project without breaking the constraints. We lose some parallel execution that docker-compose can take advantage of if no constraints are there.
ddev poweroff
time for i in $(seq 5); do ddev debug test; done

I see no real difference:
main: 1m57s
this PR: 2m2s
@rfay are you sure we are testing the right thing here? Looking into the ddev debug test container does not show the depends_on. My test project shows it.
# with this PR:
ddev debug test
debugContainer=$(docker ps -q --filter=name='ddev-tryddevproject-.*-db')
docker inspect $debugContainer \
  | jq -r '.[].Config.Labels'

mkdir /tmp/a && cd /tmp/a
ddev config --auto
ddev start
# outputs:   "com.docker.compose.depends_on": "db:service_healthy",
docker inspect ddev-a-web \
  | jq -r '.[].Config.Labels'
ddev delete -Oy

I spotted my error ;) --filter=name='ddev-tryddevproject-.*-db' -> I checked the db container ...
Sorry for the fuss.

Rebased and excluded TestCmdComposer when running NFS-based tests. I've always thought this had to be a composer/filesystem bug, and after following the linked issues I think so more... but I can't sort it out, and I can't get composer to output enough verbosity to help me.

Thanks for this!

Unfortunately, this leads to some unfortunate behavior from docker-compose, see

https://github.com/docker/compose/issues/9732

The result is that docker-compose can just hang if the db container exits early.
I think I'll have to revert at least part of this PR.


Cells limited when scanning table with ColumnPaginationFilter

From doc https://cloud.google.com/bigtable/docs/hbase-differences
we have info that when we scanning with ColumnPaginationFilter we limited to only one column family.
I'm trying to scan my table by ONE column family and this family has more than 20 cells.
The problem that I cause:  when iterate Row - I'm limited to 10 first column.
Here is how I set up scan
        Scan scan = new Scan();
        scan.addFamily(CF_STATIC);

        FilterList scanFilters = new FilterList(FilterList.Operator.MUST_PASS_ALL);

        if (search.isSized()) {
            scanFilters.addFilter(new SingleColumnValueFilter(
                    CF_STATIC,
                    COLUMN_DISK_USAGE,
                    CompareFilter.CompareOp.GREATER_OR_EQUAL,
                    Bytes.toBytes(search.getSize())
            ));
        }

        scanFilters.addFilter(new SingleColumnValueFilter(
                CF_STATIC,
                COLUMN_ACTIVE,
                CompareFilter.CompareOp.EQUAL,
                Bytes.toBytes(true)
        ));

        if (search.isLimited()) {
            int offset = search.hasOffset() ? search.getSearchOffset() : 0;
            scanFilters.addFilter(new ColumnPaginationFilter(search.getSearchLimit(), offset));
        }

        scan.setFilter(scanFilters);
        return scan;

My com.google.cloud.bigtable version is 1.0.0, also I had a shot on 1.0.0-pre3 with same behavior.
Do we have any possibility to scan 20 cells in a single column family?
For me, it looks like a bug at least in public documentation.
@sduskis Solomon, can you put some light here, please?

It looks like we limit the number of cells per row.  Here's the code that maps HBase to Cloud Bigtable:
RowFilter.newBuilder() .setCellsPerRowLimitFilter(filter.getLimit())
Here's the full class.
This could very well be a difference between our client and HBase, which is not documented correctly.

@sduskis
Solomon, thanks a lot for the response.
My point of view: this is quite unexpected behavior.
Is it possible to upgrade code source of ColumnPaginationFilterAdapter with additional CellsLimit param support?
I'm pretty sure that a lot of guys who have much more columns than me cause some troubles here...

A second point here: you do not expect such setting inside of ColumnPaginationFilter behavior.
@sduskis
Solomon, are you agree with it?

@sweetca, I'm having a bit of trouble understanding what you're aiming for here.  ColumnPaginationFilter already takes a cell limit and an offset.
Are you looking to get a cells limit per qualifier parameter?  If so, we may need to create a new type of filter that's different than ColumnPaginationFilter.

@sduskis
Thanks.


Delivery Service Request UI issue when fulfilling a "delete" request

In Traffic Portal, when you fulfill a delete Delivery Service Request, the UI takes you back to the https://tp.example.com/#!/delivery-service-requests view that shows the table of DSRs, containing the DSR you just fulfilled, except the DSR isn't updated in the table to show that it's been fulfilled. So you need to refresh the page in order for the DSR table to update your DSR to the pending status, allowing you to click complete in order to complete the DSR.
When you fulfill a delete DSR, Traffic Portal should take you back to the https://tp.example.com/#!/delivery-service-requests view but also refresh the data so that you can complete that DSR without refreshing the page manually.

@rawlinp - this must have fixed itself. i guess a lot can happen in a year :) You want to confirm and close?

I just tried in a recent build, and it still has the same issue. Maybe you tried fulfilling a create request? This is for delete.

yep, you're right. not sure what i tested earlier :)


Turboreg issue in CIAtah 4.0.0

Hi Biafra,
I'm running CIAtah 4.0 on MATLAB R2020b, on a mac.
So far, the speed of the functions and UI are a huge improvement from the previous version! Things run a lot more smoothly.
In the preprocessing step, after the videos are cropped for motion correction, I get the following error:

Omid

Hi Omid, glad to hear about speed/UI! For that error looks like MATLAB can't find the turboreg MEX file:

What is the output when you type which('turboreg') into the command window?
If 'turboreg' not found, if you go to ciatah_root/_external_programs/turboreg/Motion_Correction_Turboreg/C in the Current Folder view, is the C folder included in the MATLAB path?

Thanks, indeed the turboreg C folder was not included in the MATLAB path. However, when I added all external programs to the path, I get this error when trying to initialize:

^^ Ok, I was able to get around this issue by adding turboreg to the path after initializing CIAtah. I might have to do the same with cnmfe.
Will let you know if I encounter anything else along the pipeline.
Thanks Biafra!

If you remove the _external_programs sub-directories from your path and run ciapkg.loadBatchFxns(); before running obj = ciatah(); do you still get that error?
For cnmfe, it is on purpose not loaded into the path by default (since the repo is not inside a package and want to avoid namespace conflicts with CNMF, etc.) unless you are running cell extraction via modelExtractSignalsFromMovie. Same with EXTRACT, CNMF, etc.
I'll push an update that should eliminate the diverging_map error (i.e. by removing calls to _external_programs functions while ciatah class is being initialized). I'm not getting that error with a fresh repo pull on MATLAB 2020b in Windows 10 but since it's not required, better to minimize the chance of any cross-OS issues.

When I remove _external_programs sub-directories from the path and run ciapkg.loadBatchFxns():, I do not get that error. I attached the output below.
Ok, so in the future, I add turboreg to the path manually, but CNMFe will be loaded through modelExtractSignalsFromMovie.

Sounds good, and I assume obj = ciatah(); loads without error now?
Turboreg should be loaded automatically (so no need for manual path adding), but I'll add an additional check within modelPreprocessMovie and ciapkg.api.turboregMovie to ensure that it is (in case user changes matlab path between loading ciatah and calling either function/method).

Great! And yes, obj = ciatah loads without error when I haven't added the entire _external_programs sub-directory to the path.

Hey Biafra,
I was able to successfully get through the entire pipeline, including cross-session alignment, on CIAtah 4.0. Very fast and smooth!
One issue in signal processing: Has something changed with 'computeSignalPeaks'? I get the following error when trying to extract traces from cnmfe output:
Undefined function 'computeSignalPeaks' for input arguments of type 'double'.

Great! That's good to hear.
For all ciatah functions now, if you want to access them using just their names, need to run
import ciapkg.api.* % import CIAtah functions in ciapkg package API.

at the start of your script or function to import the ciatah API package. Else you can call the functions with ciapkg.api.FUNCTION_NAME, e.g. in your case ciapkg.api.computeSignalPeaks. See https://github.com/bahanonu/ciatah#quick-start-command-line-or-gui-less-batch-analysis.
This was done for namespace reasons to make it so that my functions/methods did not have naming clashes with other package/MathWorks functions.


Javascript Training: Mark as outdated. Javascript in Plone 6 has fundamental changes.

While fixing broken links I stumbled upon the Javascript training. I suggest to mark it as outdated and put a friendly text, that there will be a new one for Plone 6 later. And that in the mean time the new Plone 6 documentation is the place to read.

done. training is removed.


chebi:88795, CE(20:1(11Z)), the scaffold of the cholesterol part sounds wrong

Hello ChEBI Team,
Could you please review this 2-stars chebi compound?
I was on the way to submit SLM:000500284 (11Z-eicosenoyl)-cholesterol to chebi, but when adding the xref HMDB0005193, the submission tool gave a warning about this xref already used in chebi:88795 CE(20:1(11Z)): actually the only difference is missing some stereo info in the cholesterol part of chebi:88795 ? Do I have to submit a correct compound, and then you will merge both entries (the new I would have created and chebi:88795), or do you update   chebi:88795?
Thank you in advance for your help,
Anne

Hi Anne,
There is no need to create a new entry (I will update the existing entry).

CHEBI:88795 now annotated.


Publish backissues for hhs,nation in hospital-admissions and doctor-visits

Actual Behavior:

> covidcast_meta() %>% filter(data_source == "hospital-admissions", signal == "smoothed_adj_covid19_from_claims") %>% select(geo_type, min_time, max_time)
A `covidcast_meta` data frame with 6 rows and 3 columns.

Number of data sources : 0
Number of signals      : 0

  geo_type   min_time   max_time
1   county 2020-02-01 2021-04-30
2      hhs 2020-10-04 2021-04-30
3      hrr 2020-02-01 2021-04-30
4      msa 2020-02-01 2021-04-30
5   nation 2020-10-04 2021-04-30
6    state 2020-02-01 2021-04-30
> covidcast_meta() %>% filter(data_source == "doctor-visits", signal == "smoothed_adj_cli") %>% select(geo_type, min_time, max_time)
A `covidcast_meta` data frame with 6 rows and 3 columns.

Number of data sources : 0
Number of signals      : 0

  geo_type   min_time   max_time
1   county 2020-02-01 2021-04-30
2      hhs 2021-01-05 2021-04-30
3      hrr 2020-02-01 2021-04-30
4      msa 2020-02-01 2021-04-30
5   nation 2021-01-05 2021-04-30
6    state 2020-02-01 2021-04-30

Expected behavior

Ideally, all geo levels would be available over the same time range, so e.g. if I want a nation-level analysis, I don't have to bodge it together myself from state-level signals.

(Also the epidata docs should be updated to list the additional geo-levels for these sources, once they're backfilled)

@mariajahja how awful to do would this be? we don't need county/hrr/msa/state; is it possible to 1-off just the two missing geo levels?

@krivard Yes, we can do just national/hhs. Same procedure as before (tarball), or any changes that I need to know about?

Nope, same procedure is perfect. Thanks!

Sorry for the delay, the various formats/drop locations made it tricky to automate. The regen issues are in /common/regen_hsp_nat_hhs/. I did various spot checks using other regions, and they seem to line up.
Notes:
There may be additional issues for nat/hhs which are not stored in the API -- this is because historically those drops arrived late and we didn't retrospectively run the pipeline. There are also a few early 2020 issues not included for nat/hhs, these issues were manually run during that time due to various format changes that aren't compatible with the current pipeline. I ran a couple batches where the manual changes lasted some time, but the one-offs would take a lot more time.
Hospital admissions
State, hrr, msa, county
First issue: 2020-06-21
First date: 2020-02-01
Nation/hhs
First issue: 2020-12-10
First date: 2020-10-04
Generated:

Issue 2020-06-21, for dates [2020-02-01, 2020-06-18]
Issues (2020-06-21, 2021-01-10], for dates [issue_date - 70, issue_date - 3]

Doctor visits
State, hrr, msa, county
First issue: 2020-04-29
First date: 2020-02-01
Nation/hhs
First issue: 2021-03-19
First date: 2021-01-05
Generated:

Issue 2020-06-06, for dates [2020-02-01, 2020-06-03]
Issues (2020-06-06, 2021-03-16], for dates [issue_date - 70, issue_date - 3]

🙌  thank you! flagging these for @dshemetov to log as missing data scenarios we may not have imagined in our first pass of the nans implementation.
i'll add these to the batch ingestion pool and post an update when they've been pulled in.

@krivard Is there any update on when this fix will go live?
I was just playing around with the current dashboard and noticed this myself (screenshots below) and before creating an issue I searched around and found this one.

Good catch! Looks like this got sidelined for more urgent batch uploads and was never restarted. We should be able to have these up by the end of the week.

This one slipped past me. So my understanding of what happened here was:

we manually backissued data
bypassed the regular pipeline
backissued data was therefore never aggregated to larger geos

Is that right?


Add e2e test for S3 BOM upload storage

Description

[!WARNING]
Requires https://github.com/DependencyTrack/hyades-apiserver/pull/794.

Adds an e2e test to ensure that the S3 BOM upload storage works as expected.
Also updates:

The schema.sql file used in tests, so it includes the new BOM_UPLOAD table introduced in https://github.com/DependencyTrack/hyades-apiserver/pull/794.
The create-topics.sh script to include the new dtrack.event.bom-uploaded topic

Addressed Issue

Relates to #633.
Additional Details

N/A
Checklist

[x] I have read and understand the contributing guidelines
~This PR fixes a defect, and I have provided tests to verify that the fix is effective~
[x] This PR implements an enhancement, and I have provided tests to verify that it works as intended
[x] This PR introduces changes to the database model, and I have updated the migration changelog accordingly
~This PR introduces new or alters existing behavior, and I have updated the documentation accordingly~

Blocked until https://github.com/DependencyTrack/hyades-apiserver/pull/794 is merged.