[Switch] [Checkbox] disabled not being inherited from FormControl

disabled is not being inherited by either Checkbox or Switch (or FormControlLabel actually) when used inside a FormControl.
I tried this:
FormControl (disabled) -> checkbox (not inherited)
FormControl (disabled) -> FormControlLabel -> checkbox (not inherited)
FormControl -> FormControlLabel (disabled) -> checkbox (inherited)

[x] I have searched the issues of this repository and believe that this is not a duplicate.

Expected Behavior

when setting a FormControl to disabled the inner controls (Checkbox and Switch) should be disabled as well, both if they are directly inside or wrapper around a FormControlLabel.
Current Behavior

They don't get disabled, having to resort to also put the disabled property on them as a workaround.
Steps to Reproduce (for bugs)

https://codesandbox.io/s/w2zy4yqwml
Context

Your Environment

Tech
Version

Material-UI
latest beta

React
16

browser
Chrome 62

etc
TS 2.6-rc

This is something we do automatically on a Input.
https://github.com/callemall/material-ui/blob/9ea0d4d67dd8d3f2c9f8602856655bfd07fc70ea/src/Input/Input.js#L506-L509
I agree, it sounds like a good idea to have the same behavior on the SwitchBase.


Please Support termsrv.10.0.22000.318 from Windows 11, Thank you.

termsrv.10.0.22000.318.zip

#39


demo - Update YAML definitions

Automated updates from daily job running on demo cluster.

Plan Result (sbox-dt-availability-dashboards)
No changes. Your infrastructure matches the configuration.

Plan Result (ptlsbox-dt-availability-dashboards)
No changes. Your infrastructure matches the configuration.

Plan Result (test-dt-availability-dashboards)
No changes. Your infrastructure matches the configuration.

Plan Result (ithc-dt-availability-dashboards)
No changes. Your infrastructure matches the configuration.

Plan Result (stg-dt-availability-dashboards)
No changes. Your infrastructure matches the configuration.


Prepare 1.8.0 release

What does this PR do?
This PR prepares release of version 1.8.0, which needs to be done to be consistent with release 1.18.0 of Android SDK in terms of AP1 endpoint support.
Review checklist (to be filled by reviewers)

[ ] Feature or bugfix MUST have appropriate tests (unit, integration, e2e)
[ ] Make sure you discussed the feature or bugfix with the maintaining team in an Issue
[ ] Make sure each commit and the PR mention the Issue number (cf the CONTRIBUTING doc)

Codecov Report

Merging #157 (2b0cd5b) into release/1.8.0 (af4638a) will not change coverage.
The diff coverage is n/a.

@@               Coverage Diff                @@
##             release/1.8.0     #157   +/-   ##
================================================
  Coverage            86.92%   86.92%
  Complexity             179      179
================================================
  Files                   21       21
  Lines                  581      581
  Branches                73       73
================================================
  Hits                   505      505
  Misses                  48       48
  Partials                28       28


Upgrade to CNI v1.0.0 spec

CNI<EMAIL_ADDRESS>recently launched v1.0.0. We should upgrade (or investigate if we should upgrade)
cc @bianpengyuan

this is done


fix akka-stream on JDK 12

currently 8 and 11 are green but 12 is failing.
I have no idea why we need to mess with -release like this,
and I fear that finding a single version that works on all
three might be hard, but let's try it

https://scala-ci.typesafe.com/view/scala-2.12.x/job/scala-2.12.x-integrate-community-build/4745/
https://scala-ci.typesafe.com/view/scala-2.12.x/job/scala-2.12.x-jdk11-integrate-community-build/688/
https://scala-ci.typesafe.com/view/scala-2.12.x/job/scala-2.12.x-jdk12-integrate-community-build/308/

well the JDK12 job has failed twice with two different test failures, so I guess they're both intermittent :-)


ACMW enhancements

Don't use center tags. Use CSS Style instead.
Use HTML5 everywhere.
Put alt properly for all images.

@PriyaaIyer Any updates?

Please use the same UI UX design as ACM so that the front end architecture feels complete.


How to support a new model such as QWen?

Hybrid inference looks like a game changer. I want test it on Qwen. But how to make the model_spec.json for Qwen 1.5?
Thanks.

The specification file of Qwen1.5-7B-Chat has been added to data/models/qwen1.5_7b_chat.
Please have a try. Other models in the Qwen1.5 series can be treated similarly. Please feel free to contact us for any additional questions.

Thanks


increase size query text box

The box for the query is rather small.  Since there is enough space left, I would propose to increase the size of the search box.

How much space is left, depends on the width of your browser window. Maybe we can let the search box grow with the available space.
In any case, the edit button is there to give you more space. :-)

Also very nice: when one uses the edit button, the box growths with your query. Neat.

I think most people still have a lot of space left. Also generally, query windows are much larger, in the past it also used to be bigger.
The edit button is not convenient and unintuitive, because it requires an additional action and the resizing of the query is rather clunky imho. Why give the impression that it is restricted, only to increase in size after typing? Perhaps it is an idea to increase the default size, for instance to fill up the size of the pop up.
Anyhow, from a UI perspective, it's always best to come up with an easy solution that does not require to many additional clicks and actions. In this application querying is one of the most common actions, so it makes sense to increase the size and make it responsive to browser width.

Yes, the edit button means one extra click for the user. On the other hand, this is not a bug and since there is no funding at this moment, there is no more time for enhancements. I will mention in the user manual that the edit box expands when using a lengthy query. When additional funding is found, this might be one of the enhancements in the user interface to think of.


Add separate colors to talkformat labels

would be nicer to have the style definitions in a scss file in frontend/src/scss/components but works for now

True. Maybe we can clean up the entire frontend workspace for 2020.

Pull Request Test Coverage Report for Build 267

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 99.197%

Totals

Change from base Build 266:
0.0%

Covered Lines:
2150

Relevant Lines:
2164

💛  - Coveralls


Roadmap Add Year Popup

Have the add year popup show on top of the button instead of on the bottom. It overflows the page when it is too far on the bottom.

I can handle this one!


Only Mobile View displayed in Sidebar

Describe the bug
When opening Full Calendar in the sidebar it only opens in Mobile view where previously it has been opening in full desktop view. This seems to change intermittently.
Device info (please complete the following information):

OS: Win11
Plugin Version 0.10.6

Mobile/desktop view is determined by the width of the view in pixels. If you make the sidebar very wide, or you have a high-resolution screen, your sidebar might render the desktop view.


Enable go 1.14 in Travis

Pull Request Test Coverage Report for Build 576

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 99.74%

Totals

Change from base Build 564:
0.0%

Covered Lines:
5758

Relevant Lines:
5773

💛  - Coveralls


Incorrect Documentation: docker_container defaults to :pull action

Cookbook version
2.15.2
Chef-client version
12.16.42
Platform Details
RHEL 7
Scenario:
I wrote a chefspec assertion for a docker_image resource, expecting it to default to a pull_if_missing action, which is what is documented in the README.
Steps to Reproduce:
Follow the directions in the README, see different result.
Expected Result:
The information provided in the README should match the the default action in the resource code: I should not get an error.
Actual Result:
I got an error that [:pull] does not include :pull_if_missing
Relevant code lines:
Documentation explains that :pull_if_missing is the default: https://github.com/chef-cookbooks/docker/blob/master/README.md#actions-1
Default is actually :pull: https://github.com/chef-cookbooks/docker/blob/master/libraries/docker_image.rb#L31

Thanks for letting us know. I've updated the README to reflect the default action.


Icons not working in Firefox

I'm having trouble getting these icons to work in Firefox v38, both on http://paymentfont.io/ and in my own app. I checked the common @font-face issue in Firefox, regarding the Access-Control-Allow-Origin "*" header. My fonts are being served with that header, so that isn't the issue.

I have the same trouble.

I never got to the bottom of it, but tested on Firefox in BrowserStack with no issues. Uninstalling and reinstalling Firefox locally resolved the issue (same version). No idea what was causing it though.

ok ... thank you @josiahsprague for your answer

Closing since this issue is no longer relevant to me and it's clogging up my GitHub issues. If someone wants to resume discussion on it at some point, feel free to reopen the issue.


Front (wallet keys) screen => redesign

Normal screen with wallet keys in a grid
a. Each wallet key can have an emoji. Note: it would be really cool if we could set an NFT ID as the wallet key icon.
b. We need an emoji/color picker. It doesn't necessarily need to match Seth's design exactly.
c. Wallet keys can be dragged around to re-order them. We can save the order in localStorage or prefs.yaml, whatever seems more appropriate (I would lean toward prefs.yaml as localStorage is really cluttered).

https://www.figma.com/file/waatWwVLJBLh3oPqpiuIaB/H1-2023?node-id=127%3A8327&t=Z97Bq5V1HQmdq0vL-0


Not working with AGP 8.2.1

I recently upgraded the gradle to 8.2.1
And unable to compile the project with error
Failed to resolve: com.squareup.okhttp3:okhttp-bom:4.12.0
Failed to resolve: com.squareup.okhttp3:okhttp-urlconnection

They both appear to be there
https://mvnrepository.com/artifact/com.squareup.okhttp3/okhttp-bom/4.12.0
https://mvnrepository.com/artifact/com.squareup.okhttp3/okhttp-urlconnection/4.12.0
Not sure we can help with a build issue you are facing, consider a site like stackoverflow.
If you really think it's a bug, please make a repro so we can investigate.

It was happening for me with 4.12.0 once I updated to AGP 8.2.2.  However, I replaced BOM with fully qualified dependency and it seems to work.
Not sure if it helps but I use OKHTTP in my library project which is distributed via Maven and used in the sample app. The sample app doesn't have a direct dependency on OKHTTP.


au-aa068: Develop APS2 ACCESS-G Rose suite and associated IT infrastructure at NCI for NWP research

keyword_APS2_N512_ACCESS-G_Rose_suite   |    by<EMAIL_ADDRESS>
Since early 2014 work has been going on to build an IT intrastructure at NCI to develop and support APS2 N512 ACCESS-G Rose suite. This is a collaborative effort by Fabrizio Baordo, Jin Lee, Vinod Kumar, Paul Gregory and other ESM scientists and IT staff.
The workpackage this ticket describes is very large encompassing every decision, change, bugfix, result, etc. associated with the development of the suite and attendant IT infrastructure. Unfortunately this ticket was created well after the commencement of work so a lot of relevant documentation is recorded elsewhere:
http://ngamai04.bom.gov.au:8011/APS1/wiki/APS2components

Issue migrated from trac:161 at 2024-01-31 17:40:16 +1100

<EMAIL_ADDRESS>changed owner from `` to jtl548

<EMAIL_ADDRESS>changed status from new to assigned

<EMAIL_ADDRESS>commented

Testing VAR
All the tests described here rely on the (obvious) fact that given a set of inputs to a component - e.g. inputs to OPS, VAR, SURF or UM - which is identical to a reference (in our case UKMO) the output from the component test should be identical to that from the reference within a random computational noise. The random computational noise is not zero because our test of a component may use different PE domain decomposition to UKMO reference; it can also arise from round-off errors which may or may not come from the use of different compiler settings.
The approach I've taken to deal with this random computational noise when comparing our test result and UKMO reference is to apply zonal averaging. Zonally averaged difference between our result and UKMO reference highlights major systematic differences and offers us a clue as to the cause of the difference.

<EMAIL_ADDRESS>uploaded file zonal_mean.diff.anal_inc.a207.N108_12x32.N216_8x48-uk.2014020206.qT.png (34.4 KiB)
zonally averaged difference in analysis increments for qT

<EMAIL_ADDRESS>commented

A methodology to track down problems with OPS and VAR
Motivation
During the development of the APS2 ACCESS-G suite iver diagnostics suggested persistent problems in its forecasts compared to operational APS1. The following summarises a systematic approach used in finding the source of the forecast problem.

<EMAIL_ADDRESS>commented

UKMO runs hybrid En-Var and so I had to derived a hybrid set-up (au-aa207) from our APS2 suite. The inputs to the hybrid En-Var are:

varobs and varcx
linearisation states (LS states) for N108 and N216
error modes (EM) from 44-member MOGREPS-G for N108 and N216
CovStats

First I had to test the new hybrid En-Var in au-aa207 was correct by comparing the analysis increment from the suite with that from the VAR tasks (glu_var_anal_n108 and glu_var_anal_n216) in the UKMO suite (au-aa213 which is a copy of mi-aa408). This was done.
Next, I had to have an estimate of the size of the computational noise. This is done by running VAR using different PE domain decompositions. A typical differences in the analysis increments from 2 different PE domain decompositions are shown below:

<EMAIL_ADDRESS>uploaded file zonal_mean.diff.anal_inc.a207.N108_12x32.N216_8x48-uk.2014020206.u.png (37.6 KiB)
zonally averaged difference in analysis increments for u

<EMAIL_ADDRESS>uploaded file zonal_mean.diff.anal_inc.a213.18x20-12x32.2014020206.theta.png (34.6 KiB)
zonally averaged difference in analysis increments for theta

<EMAIL_ADDRESS>uploaded file zonal_mean.diff.anal_inc.a213.18x20-12x32.2014020206.u.png (39.8 KiB)
zonally averaged difference in analysis increments for u

<EMAIL_ADDRESS>uploaded file zonal_mean.diff.anal_inc.a213.18x20-12x32.2014020206.qT.png (42.2 KiB)
zonally averaged difference in analysis increments for qT

<EMAIL_ADDRESS>commented

So an approximate estimate of the computational noise is:

for qT, ~10^-3^ g/kg
for theta, 0.1 K (mainly near the top of model)
for u, 10^-2^ m/s

For all the variables the noise is confined spatially.
So during our test if we get an analysis increment which differs from that from UKMO, and the size of the difference is larger than the computational noise then we can conclude that our set-up and that of UKMO are different. On the other hand, if our analysis increment is within the computational noise of the UKMO increment then we can conclude our settings are identical to that of UKMO.

<EMAIL_ADDRESS>commented

Testing OPS
Next step is to test OPS tasks. As an intial test I used the suite's OPS tasks to produce varobs and varcx with all the other inputs to OPS-VAR coming from UKMO - i.e. LS states, EM and bgerr.
The OPS-VAR outputs are under:
raijin5:/home/548/jtl548/da/access_verif/aps2_da_problem/data/au-aa207/from_ukmo.LS.EM.own_varobs_varcx
Plots are attached:

<EMAIL_ADDRESS>uploaded file zonal_mean.diff.anal_inc.a207-uk.2014020206.qT.png (41.9 KiB)
zonally averaged difference in analysis increments for qT - ours vs UKMO

<EMAIL_ADDRESS>commented

Compared to the computational noise the analysis increment difference between APS2 suite and UKMO is:

for qT, 1-2 orders of magnitude larger
for theta, 3 orders of magnitude larger
for u, 2-3 orders of magnitude larger

This tells us that there is a problem with one or more of our APS2 OPS task(s).

<EMAIL_ADDRESS>uploaded file zonal_mean.diff.anal_inc.a207-uk.2014020206.theta.png (30.9 KiB)
zonally averaged difference in analysis increments for theta - ours vs UKMO

<EMAIL_ADDRESS>uploaded file zonal_mean.diff.anal_inc.a207-uk.2014020206.u.png (38.7 KiB)
zonally averaged difference in analysis increments for u - ours vs UKMO

<EMAIL_ADDRESS>changed _comment0 which not transferred by tractive

<EMAIL_ADDRESS>uploaded file zonal_mean.diff.anal_inc.a220-a207.2014020206.theta.png (34.6 KiB)
zonally averaged difference in analysis increments for theta - ours vs UKMO

<EMAIL_ADDRESS>changed _comment0 which not transferred by tractive

<EMAIL_ADDRESS>uploaded file zonal_mean.diff.anal_inc.a220-a207.2014020206.qT.png (45.5 KiB)
zonally averaged difference in analysis increments for qT - ours vs UKMO

<EMAIL_ADDRESS>commented

Testing OPS - individual obsgroups - first set of trials
There are 2 APS2 ACCESS-G suites curretly available: one running on Ngamai but is controlled by SCS; another running at NCI and uses !Rose/cylc . For some reason the !Rose/cylc version running at NCI verified worse than the one running on Ngamai. So I decided to test !Rose/cylc OPS tasks using the warm-running files of Ngamai suite as a reference instead of UKMO files. This test was done before I decided to use UKMO files so the chronology of these entries in this ticket is a bit out of whack.
However the methdology is the same. In each of the test suite same OPS tasks as our APS2 Roce/Cylc suite processes obsgroups except for the obsgroup which is under the test. For each obsgroup under investigation varobs/cx comes from samtm. The analysis increments from these suites are then compared with that from au-aa171 (copy of Rose/Cylc APS2 suite). If the difference in the analysis increment is large then we can conclude that that particular obsgroup is to blame for difference.
Following suites were set up:

suite ID
obtypes whose varobs/cx come from samtm

au-aa194
AIRS, ATOVS, IASI

au-aa195
GPSRO

au-aa196
Satwind

au-aa197
Scatwind

au-aa198
Sonde, Aircraft

It turned out that the difference in the analysis increment between au-aa198 and au-aa171 was large. See plot below:

<EMAIL_ADDRESS>commented

Replying to [comment:8 jtl548]:
Another attempt at attaching plot at the right place. See "zonal_mean.diff.fc.a198-a171.2014120500.+24.T.png"

<EMAIL_ADDRESS>commented

The plot "zonal_mean.diff.fc.a198-a171.2014120500.+24.T.png" indicates that somehow Ops_as was causing forecast to be different. It turned out that Ops_as was using wrong MetDB elements file for Aircraft and Sonde: the number of vertical levels expected in the MetDB elements file did not match the actual number of vertical levels in Bufr or ODB files.

<EMAIL_ADDRESS>uploaded file zonal_mean.diff.fc.a196-a171.2014120500.+24.u.png (32.6 KiB)
zonally averaged difference in +24 forecast for u

<EMAIL_ADDRESS>uploaded file zonal_mean.diff.fc.a198-a171.2014120500.+24.T.png (21.9 KiB)
zonally averaged difference in +24 forecast for temp

<EMAIL_ADDRESS>uploaded file zonal_mean.diff.anal_inc.a220-a207.2014020206.u.png (40.4 KiB)
zonally averaged difference in analysis increments for u - ours vs UKMO

<EMAIL_ADDRESS>uploaded file zonal_mean.diff.fc.a196-a171.2014120500.+24.u.2.png (32.6 KiB)
zonally averaged difference in +24 forecast for u

<EMAIL_ADDRESS>commented

The plot above suggests that APS2's OPS task that processes AMV observations has a problem. It turned out that there was a minor bug with the app of Ops_amv, which resulted in varcx files being written to a wrong place. Without varcx for AMV's 4DVAR did not make use of AMV observations at all.

<EMAIL_ADDRESS>commented

It also turned out that the difference in the 24-forecasts between au-aa196 - varobs/cx for AMV's come from samtm but for all other obsgroups varobs/cx are produced by various tasks of the suite - and au-aa171 were very large, particular for the u-component winds. See attached plot.

<EMAIL_ADDRESS>commented

Testing OPS - individual obsgroups - second set of trials
In this second set of tests for each obsgroup the observations are processed by a suite while for other obsgroups varobs/varcx files from UKMO are used. Analysis increments from APS2 OPS/Hybrid En-Var are compared with the equivalent from UKMO. If OPS settings are identical to that of UKMO then the difference in analysis increments should be within computational noise; otherwise the difference would be larger.
In this test all the settings of APS2 OPS tasks are made as close to the UKMO settings as possible. This means all OPS control files (SatRad coefficents, radiance bias coefficients, stationlists, etc.) are identical to UKMO.
Following suites were set up:

suite ID
obtypes whose varobs/cx are processed by suite

au-aa215
AIRS, ATOVS, IASI

au-aa216
CrIS, ATMS

au-aa217
GPSRO

au-aa218
Satwind

au-aa219
Scatwind

au-aa220
Sonde, Aircraft

au-aa221
Surface

<EMAIL_ADDRESS>changed component from Accessdev Server to ACCESS model


4.7.0 Actor/Service Feedback

Bug or feature request?
Bug
Description:
I've been playing more with xstate@next. It seems that both conceptually and in Typescript, the Actor/Service (Interpreter) distinctions are a little blurred, so I'm trying to understand when to use either. My primary question is what are the different purposes for Actors and Services/Interpreters?
Here are some more specific notes for v4.7.0-rc3:
It looks like invoke creates an Actor behind the scenes. Accessing it through current.children.invokeId, you get an Actor back. Accessing it through service.children.get(invokeId), you get an Interpreter. Shouldn’t invoke always generate services/interpreters and not an actor? If invoking a “service” is really just an Actor behind the scenes, it’s be nice to always return an Actor so you consistently know what to expect from your current.children, service.children and spawn.
spawn also returns an Interpreter type in TS, but it looks like the actual object is an Actor. Why should spawn ever return an Interpreter if it’s an utility for spawning actors? Looks like the TS changed in #664
Also, a minor TS bug for spawn. It doesn’t accept a machine with custom event types since they clash with the generic EventObject.
spawn(new Machine<Ctx, Evt>())
// Type 'EventObject' is not assignable to type ‘Evt’

Finally, most of these concepts trickle out as confusing when you start to use the useService and useActor hooks. It seems that Actors are more locked down in state access, but it’s unclear as to why? It’s much easier to just use a useService, but as already noted, most of the Actors coming out of current.children and spawn aren’t accepted in useService. It’s unclear when comparing services to actors on why you’d ever want an Actor vs an Interpreter, or vice versa.
(Bug) Potential fix:
I need more understanding of the conceptual model to propose a fix, but I'd be more than happy to after I understand distinctions between Actors and Services.

I had those doubts earlier and after a quick digging up I came up with these notes, hope that helps.

Main difference between services and actors - services need to be statically written in the machine definition to be invoked, whereas actors can be dynamically spawned by any action, multiple times (if you so wish).

actors could spawn sub-actors and communicate with it's parent or other actors via event sending

In short, actors are like services on steroid, allowing developers to more flexibly model complex application logics with multi-level of machine hierarchy interacting with each other.

One of the biggest wins of having actors is now there's finally a way to totally encapsulate business logic within the statechart itself, without needing a ui layer (like react) to help gluing them.

Another big win is with useService in place, it's super easy to make ui component and actors working together, hence making one-machine-each-component a reality, this will come in handy for large application.

Lastly, actor is just a pattern for making multiple elements working with each other nicely in a system, in this case those elements happened be one of { Promise | Callbacks | Observables | Machine },  yes, they are exactly the services already existing today, hence one could think actor is just a more flexible way of running services.

Thanks @coodoo, that helps!
My feedback now is that when using xstate, it would be helpful to have spawned/invoked elements either always be an Interpreter or an Actor. e.g. the spawn helper sometimes returns an interpreter, but other times an actor; using invoke is always an interpreter; accessing these thorough service.children or current.children return different types.
Would it make sense to have both invoke and spawn refs always produce an Actor? I think that would be simpler to understand, especially so you don't have a Actor | Interpreter in .children you must guard against each time you access.

It wouldn't allow you to unpack a "nested" spawned machine with eg useService hook and use that to match against its state etc which seems really useful. I agree though that the current situations is somewhat confusing, so maybe we'll discuss alternatives in the future - it will have to wait until next major version though.

I haven't tried it yet, but doesn't { sync: true } to spawn allow you to read state? Maybe invoke'd actors get { sync: true } by default and other spawn'd actors are opt-in.
This way it'd be simple for the useService hook to merge with useActor and only provide current state when sync is available.

Sync is just a convenience helper - explicit data passing is much more preferred in general. It also only works with machines, so you end up with a similar problem of not being able to differentiate machine actors and different type of actors - just at a different place.

Marking this for documentation, as it is better resolved there.
In V5, there will be no distinction between services/actors, so the implementation and usage will be much simpler. This also means that { sync: true } will be better replaced with more intuitive, explicit patterns.


docs(DEVELOPER.md): add how to set up hybrid mode

Add a section for setting up hybrid mode dev environment.
Add a step for setting GITHUB_TOKEN to the section of Build and Install from source.
KAG-2027

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


[GUI] Correct the text of the attribute validation

Steps to reproduce the problem:

Click "New Template"
Click "Add New Configuration"
Select type "Device Timeout"
Click "ADD"

Affected Version: 0.3.0-nightly_20180912

Test OK.


Update CI to Swift 5.10 stable

Updates the CI Docker file to use the stable release of Swift 5.10 instead of the nightly build.

@swift-ci test

@swift-ci test


debug: Add debugServerHost launch.json attribute

This allows connecting to a debug adapter running on a remote host.
This PR fixes #113192
To give a bit more context, the lldb-vscode project from LLVM implements the debug adapter protocol in a separate tool written in C++ named lldb-vscode. I want to run lldb-vscode in a container to allow remote debugging. I'm planning on accomplishing this by running it as a xinet style systemd service. systemd will accept connections at port 4711 and for each connection, spawn an instance of lldb-vscode and connect the socket to its stdin/stdout. This all works well except VSCode is missing an option to allow connecting to a debug adapter running remotely.
The logic in vscode is already 99% percent there. The debugServer attribute already gives users the option to have vscode connect to a debug adapter listening on a socket on localhost. This PR extends that logic by also allowing users to set a debugServerHost attribute. When specified, this attribute is passed as the host argument to DebugAdapterServer's constructor which will make it connect to the debug adapter running on the given host instead of localhost.
This PR can be tested by starting lldb-vscode and passing the --port 4711 to have it wait for a connection on port 4711. Then, set the debugServer attribute in launch.json to 4711 and the debugServerHost attribute to the hostname of the host that lldb-vscode is running on. vscode will then connect to the remote instance of lldb-vscode running on the given remote host.

Closing after discussion in #113192


Release Google.Cloud.PubSub.V1 version 3.4.0 (aborted)

Changes in this release:
Bug fixes

Ack/ModAck failures in non exactly once delivery flow should not be retried. (commit a0da1f5)

New features

Make INTERNAL a retryable error for Pull (commit ad9963e)
Add temporary_failed_ack_ids to ModifyAckDeadlineConfirmation (commit 55fef61)
Add google.api.method.signature to update methods (commit cf2f61a)
Implemented IAsyncDisposable in PublisherClient and SubscriberClient (commit 2ae9ab7)
Added IServiceCollection extension methods for PublisherClient and SubscriberClient (commit fe942e0)

Documentation improvements

Add x-ref for ordering messages (commit 16a4ddc)
Clarify subscription expiration policy (commit 16a4ddc)
Clarify BigQueryConfig PERMISSION_DENIED state (commit 78feab7)
Clarify subscription description (commit 5d43a47)
Replacing HTML code with Markdown (commit f9467b0)
Fix PullResponse description (commit f9467b0)
Fix Pull description (commit f9467b0)
Update Pub/Sub topic retention limit from 7 days to 31 days (commit 7281474)
Mark revision_id in CommitSchemaRevisionRequest deprecated (commit 2a9ddbb)

This release failed; we've fixed the issue, and created #10010 to represent the new release PR.


[SEDONA-249] Add jvm flags for running tests on Java 17

Did you read the Contributor Guide?

Yes, I have read Contributor Rules and Contributor Development Guide

Is this PR related to a JIRA ticket?

Yes, the URL of the associated JIRA ticket is https://issues.apache.org/jira/browse/SEDONA-249. The PR name follows the format [SEDONA-XXX] my subject.

What changes were proposed in this PR?
Add jvm flags to test plugins to make it possible to run tests on Java 17. This will make life easier for contributors running Java 17 locally.
This PR does not add Java 17 to the test matrix for github actions.
This PR does not make the tests pass on Java 17. Currently CRSTransformationTest.testPolygonDistanceJoinWithCRSTransformation in sedona-core fails on Java 17.
How was this patch tested?
All tests pass on Java 8.
Did this PR include necessary documentation updates?

No, this PR does not affect any public API so no need to change the docs.

@umartin Thanks for bringing this up. Interestingly, I found CRSTransformationTest.testPolygonDistanceJoinWithCRSTransformation also failed on Java 11. I haven't figured why. Any idea?

I think there was a patch in a point release of Java 11 that changed the string representation of floats. For me it fails on Java 11.0.17 although I remember it passing on earlier version of Java 11. It the test reads geometries from csv files they could be interpreted differently depending on java version.
I remember tweaking some tests in sedona-sql when that change hit me. https://github.com/apache/sedona/blob/master/sql/src/test/scala/org/apache/sedona/sql/functionTestScala.scala#L163
The test runs a distance join in RDD with polygons. The Circle geometry is only valid for points. Maybe the test can be removed?

@umartin Yes! Can you remove that flaky test?

@jiayuasu No problem! I added a commit removing the test.


Full working example for SmoothCollapsingToolbarLayout

Hello @henrytao-me ,
The library seems to be awesome. But I'm not able to make SmoothCollapsingToolbarLayout from the code on readme work for me. I couldn't find a full working example of SmoothCollapsingToolbarLayout in your sample app either.
Would be super helpful if you could provide an example.
Thanks

Hi @abhiank209
Can you tell me what AppCompat and Support Design version are you using?

@henrytao-me I also find it incredibly difficult to integrate this library with the information provided in the readme.
Especially given the fact that the all of the sample's examples make use of third party libraries such as custom RecyclerView's adapters and design libraries, which I do not want to include. The sample should provide a fully working example without these additional libraries, otherwise these libraries should be declared explicitly as required dependencies in the readme.
For example, using only this library and what I was able to understand/copy from the readme and the sample, I came up with a minimal app which I've put in this repository.
The result is disappointing, here is a video. I don't know why the jitters are there.

Hi @david-perez
Thanks for feedback. I definitely will simplify the sample app. I will take a look at your repo and perhaps send PR to fix it.

I sent you a PR in your repo already. I hope it helps.


kernel/sched: Fix SMP race on pend

For historical reasons[1] suspending threads would release the scheduler lock between pend() (which places the current thread onto a wait queue) and z_swap() (which effects the context swtich).  This process happens with the caller's lock held, so local interrupts are masked.  But on SMP this opens a tiny race where another CPU could grab the pended thread and switch to it while we were still executing on its stack!
Fix this by elevating the "lock swap" code that already exists in the (portable/switch-based) z_swap() code one level so that it happens in z_pend_curr() also.  Now we hold the scheduler lock between pend and the final context switch.
Note that this technique can't work for the older z_swap_irqlock() implementation, which exists to vestigially support a few bits of arch code (mostly direct interrupts) that don't work on SMP anyway. Address with an assert to prevent future misuse.
[1] z_swap() is a historical API implemented in per-arch assembly for
older architectures (like ARM32!).  It was designed to be called
with what at the time was a global IRQ lock, so it doesn't
understand the idea of a separate scheduler lock.  When we finally
get all archictures on arch_switch() this design can be cleaned up
quite a bit.
Signed-off-by: Andy Ross<EMAIL_ADDRESS>

Stumbled on this while banging on the zync PR fixing the long tail of issues so it can merge.
This is a really small race window, happens only on SMP, and in CI is completely buried in the noise of spurious SMP timer failures.  But I found a spot where zync + userspace + qemu_riscv64_smp (only that one platform: spent two whole days thinking it was an arch bug!)  would hang one case in tests/kernel/semaphore/semaphore with a frequency of about 40%, which I guess was good enough.
Should probably consider a backport, but I'll leave that decision to others.

Heh, that failure turns out to be due to a late assertion I put in to protect vs. the case where we call z_pend_curr() (or its wrapper z_sched_wait()) with the scheduler lock directly, which would break the lock swap trick.  We don't do this anywhere.  It's fine.  But the story is interesting as to how it failed anyway on that one test on clang, so I'm going to tell it:
On uniprocessor setups, k_spinlock is degenerate.  You can't have multiple contexts spinning with only one cpu, so there's no need to store any actual lock data and the struct has zero size[1].  Essentially "k_spin_lock()" becomes equivalent to "irq_lock()", which was an important efficiency promise when this lock was introduced.
But having zero size, that means that the object placed in memory after a struct k_spinlock will have the same address as the lock.  And, getting back to this test, that assertion was testing to see if the lock being passed to z_pend_curr() was the scheduler
lock by doing a pointer equality comparison.
By now you know where this was going: it just so happened that when building that one test with clang, the sched_spinlock lock got placed adjacent to the global work_q spinlock.  So when the work queue tried to wait using its own lock, the kernel decided it was using the scheduler spinlock and aborted.
Trivial bug to fix.  Pretty nasty bug to find.  Anyway I thought someone would be amused.  Will have the update pushed as soon as my local twister run finishes.
[1] When building for C only, anyway.  It turns out that C++ doesn't allow empty structs, so there's a 1-byte dummy when C++ builds are enabled.  Ugh.

OK, rebased and passing.  Please re-review.

I'm not sure I fully understand the explanation.
You say: "Now we hold the scheduler lock between pend and the final
context switch". But you do a k_spin_release() before calling z_swap(()
which does drop the lock before the final context switch. The local IRQs
remain masked out but on SMP that won't prevent another CPU from coming
along and grabbing that thread like you describe.
What am I missing?

On Mon, 10 Oct 2022, Andy Ross wrote:

Now it releases the caller's lock after acquiring the scheduler lock

Oh! OK. That's what I was missing: this is a different lock.


Corrected broken links to spec/mapping

Fixed links to spec for 2021 and corrected the STEP mapping spec document broken link.

Thank you!


Option to show login page instead of home page

Gitea version (or commit ref): 1.10.1

Description
In my use case, the user must always be logged in to use my gitea instance, there are no public repositories. Therefore I would like to let the user always land on the login page when they are not logged in. When they are logged in, they should be redirected to their home page, as usual.
Currently, the closest I can get there is by setting LANDING_PAGE = explore – this redirects unauthenticated users to the login page, but authenticated users are of course redirected to the explore page. Setting LANDING_PAGE = home shows the Gitea start page instead of the login page to unauthenticated users.
Am I missing a setting or is it not implemented?

@timonegk what about LANDING_PAGE = user/login?

According to the documentation and the sample app.ini, the only possible values are home, explore and organizations. But maybe other values work nevertheless, I can try later.

Only the three in the docs are supported this would need a simple fix here : https://github.com/go-gitea/gitea/blob/2f9564f993ba02ba503d7088eb8cc70536b7a6df/modules/setting/setting.go#L646
By adding a new case.


[bug] There is an issue with the window dragging size in the v2 version.

Describe the bug
The window is set with decorations: false attribute. The top and left sides are displayed normally, but the right and bottom edges are not.
https://github.com/tauri-apps/tauri/assets/55067857/1ea9cb9a-973a-4213-bbd8-215a08646ff9
And there are also some issues with the response when dragging and changing the window on the top and left sides. Sometimes when my mouse goes out, the window remains unchanged, which is normal in v1 version.
Reproduction
No response
Expected behavior
No response
Full tauri info output
[✔] Environment
    - OS: Windows 10.0.22631 X64
    ✔ WebView2: 118.0.2088.76
    ✔ MSVC: Visual Studio Community 2022
    ✔ rustc: 1.78.0 (9b00956e5 2024-04-29)
    ✔ cargo: 1.78.0 (54d8815d0 2024-03-26)
    ✔ rustup: 1.27.1 (54dd3d00f 2024-04-24)
    ✔ Rust toolchain: stable-x86_64-pc-windows-msvc (default)
    - node: 16.20.0
    - yarn: 1.22.22
    - npm: 8.19.4

[-] Packages
    - tauri [RUST]: 2.0.0-beta.20
    - tauri-build [RUST]: 2.0.0-beta.16
    - wry [RUST]: 0.40.0
    - tao [RUST]: 0.28.0
    - @tauri-apps/api [NPM]: 2.0.0-beta.12
    - @tauri-apps/cli [NPM]: 2.0.0-beta.18

[-] App
    - build-type: bundle
    - CSP: unset
    - frontendDist: ../dist
    - devUrl: http://localhost:1420/
    - framework: React
    - bundler: Vite

Stack trace
No response
Additional context
No response

@amrbashir I hope the fix for this bug can be released as soon as possible, as it significantly affects the experience of my project.


Automatic addition of GSSOC label

Issue Description
Automatic addition of GSSOC , Bug , Enchancement label's to Issues and PR.

@sunny0625 @khushi-joshi-05 please assign me this issue.

@sunny0625 @khushi-joshi-05 please assign me this issue
and also add level label to the PR https://github.com/khushi-joshi-05/Food-ordering-website/pull/1427


Support for npm-shrinkwrap.json

I almost sent a trivial PR with COPY npm-shrinkwrap.json /usr/src/app, but the obvious problem is this breaks for projects without a shrinkwrap JSON. I don't (yet?) know how to fix this, so just opening an issue.

Sorry, wrong button.
Yes, adding it to the documentation would be nice.

Closing old issue, (should be reported on the new repo https://github.com/nodejs/docker-node if you still have issues).


is there a way to call "getPerspectiveTransform"?

title

Duplicate of #13.
Please check documentation next time.


Make a directory of training datasets for ML/AI

GO + comments (often includes location in paper)
FYPO + comments (often includes location in paper)
Literature triage (curation status, other labels etc)
@afg1

We have a ML/AI directory in the new releases plan:
https://www.pombase.org/public_releases/pombase-2024-06-01/training_data_for_ML_and_AI/
There's only one file there at the moment though.


array with relations

Hi,
how I can get the relations of an array. So I have an user class and this class has field restriction with an array of relations. How I can get the data?
[   {     "__type": "Pointer",     "className": "Restriction",     "objectId": "l15bD1WdrJ"   },   {     "__type": "Pointer",     "className": "Restriction",     "objectId": "bD2hGsKetL"   } ]

@rodrigosmarques
I found an solution.
That breaks
List<ParseObject> restrictions = [];

void fetchRestrictions() async {
    List<ParseObject> restrictions = user?.get<List<ParseObject>>('restriction');
    this.restrictions = restrictions;
}

Log
The application is paused in the debugger after an exception was thrown.
Reloaded 7 of 704 libraries.
[VERBOSE-2:shell.cc(184)] Dart Error: Unhandled exception:
type 'List<dynamic>' is not a subtype of type 'List<ParseObject>'
#0      UserProvider.fetchRestrictions (package:trainer/provider/user_provider.dart:34:24)
<asynchronous suspension>
#1      new UserProvider (package:trainer/provider/user_provider.dart:14:5)
#2      UsersScreen.build.<anonymous closure>.<anonymous closure>.<anonymous closure> (package:trainer/screen/users/users_screen.dart:111:30)
#3      MaterialPageRoute.buildPage (package:flutter/src/material/page.dart:87:27)
#4      _ModalScopeState.build.<anonymous closure> (package:flutter/src/widgets/routes.dart:666:43)
#5      Builder.build (package:flutter/src/widgets/basic.dart:6427:41)
#6      StatelessElement.build (package:flutter/src/widgets/framework.dart:3974:28)
#7      ComponentElement.performRebuild (package:flutter/src/widgets/framework.dart:3924:15)
#8      Element.rebuild (package:flutter/src/widgets/framework.dart:3721:5)
#9      StatelessElement.update (package:flutter<…>

The following code works very well :-)
List<ParseObject> restrictions = [];

void fetchRestrictions() async {
    final restrictions = user?.get<List<ParseObject>>('restriction');
    this.restrictions.clear();
    for (final ParseObject restriction in restrictions) {
      this.restrictions.add(restriction);
    }
}


Rename aux folder to fix windows checkuout.

The following reserved device names cannot be used as the name of a file: CON, PRN, AUX, CLOCK$, NUL, COM1, COM2, COM3, COM4, COM5, COM6, COM7, COM8, COM9, LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8, and LPT9. In addition, any combinations of these with extensions are not allowed.
https://msdn.microsoft.com/en-us/library/aa578688.aspx

Good catch, thanks :)


update README.md with information about trello board, other things...

On an open source project, this kind of information should be open in the public to encourage people to contribute. It could be from suggesting a new feature to I want a challenge myself and implement a feature or fix an issue that is annoying me. Without all those details in public space it hard to know what the team is working on and where a new contributor can help.

Question: is there anything else we can do besides just updating the README.md with "this kind of information" to encourage people to contribute

README only although i encourage we make a page on the website itself

I second that motion, maybe stick an Octocat somewhere inconspicuous and a
faded link "did you know this project is open-source?"
On Thu, Mar 3, 2016 at 9:48 PM Mohamed El Mahallawy <
<EMAIL_ADDRESS>wrote:

README only although i encourage we make a page on the website itself
—
Reply to this email directly or view it on GitHub
https://github.com/quran/quran.com-frontend/issues/204#issuecomment-191932534
.

waffle.io board is at https://waffle.io/quran/quran.com-frontend, trello is at https://trello.com/b/nzAua2tA/quran-com-frontend -- which do you think is best for our needs as for as project management goes?
trello has better mobile support, waffle has better issue integration


When will the fine-tuning code of 3D inpainting be released?

Hi, thanks for watching our work! We expect to release the code for inpainting around January 5th.

Hello, maybe it is time to release the code for inpainting.

hi, it is under our organization and we expect it release it in this weekend or next Monday. Thanks for your patience.

Thanks for your reply~


Usability of DEX integration

The usability and communication of the dex integrations have to be improved compared to the old release.

The outcome of this issue is not clearly specified. I think we already achieved this. Closing.


feat: validate withdrawal when validating block.

Fix #1399

@rakita Is it expected? I will add test for this feature.

Codecov Report

Merging #1521 (833776b) into main (0fc9f67) will decrease coverage by 54.30%.
The diff coverage is 0.00%.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
@@             Coverage Diff             @@
##             main    #1521       +/-   ##
===========================================
- Coverage   76.00%   21.70%   -54.30%
===========================================
  Files         358      361        +3
  Lines       42660    42964      +304
===========================================
- Hits        32423     9327    -23096
- Misses      10237    33637    +23400

Flag
Coverage Δ

integration-tests
21.70% <0.00%> (-0.16%)
:arrow_down:

unit-tests
?

Flags with carried forward coverage won't be shown. Click here to find out more.

 Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

wait for #1609

@rkrasiuk is this a blocker / needs to be closed for Shanghai? or just a "nice to have"? if it's needed, @GrapeBaBa please let us know if you'll get to it, else would like to assign to someone else

@rkrasiuk is this a blocker / needs to be closed for Shanghai? or just a "nice to have"? if it's needed, @GrapeBaBa please let us know if you'll get to it, else would like to assign to someone else

Sorry for late, already introduce mockall in this PR to fix #1609


Missing path in access logs with fpm and rewrite

1. What version of Caddy are you running (caddy -version)?
Master :
root@334f7c7a0ba3:/app# /caddy/caddy -version
Caddy 0.9.2 (+bac54de Sat Sep 24 08:26:45 UTC 2016)

2. What are you trying to do?
Display access log with docker logs command.
3. What is your entire Caddyfile?
:80 {
  root /app/public
  fastcgi / <IP_ADDRESS>:9000 php
  rewrite {
    to {path} {path}/ /index.php?{query}
  }
  gzip
  log sdtout
}

4.
Caddy is dockerized.  What did you expect to see?
The whole path in access log:
<IP_ADDRESS> - [26/Sep/2016:11:18:00 +0200] "GET /test/path?myarg=42 HTTP/1.1" 404 0

6. What did you see instead (give full error messages and/or log)?
<IP_ADDRESS> - [26/Sep/2016:11:18:00 +0200] "GET /index.php?myarg=42 HTTP/1.1" 404 0

I think there is a conflict with the rewrite as the real url after rewrite is /index.php?/test/path...
I have tried to play with log format option but I can't find the information anywhere.
log / stdout "{remote} - [{when}] \"{method} {proto} {uri}\" {status} {size} {latency} {dir} {file} {path} {query} {query_escaped} {uri} {uri_escaped} {>REQUEST_URI}"
7. How can someone who is starting from scratch reproduce this behavior as minimally as possible?

Thanks for the report!
I wonder if this is because the log directive defers the evaluation of the request's values until after the response has been written -- meaning that rewrite has already changed the request path. Maybe we should look into evaluating the request placeholders immediately and defer evaluation of the response ones until later like we do now...

Try {>Caddy-Rewrite-Original-URI}

I got a "-" with this header.

{>Caddy-Rewrite-Original-URI} should work. It's actually a bug in replacer!

Fixed! Hopefully will go out in a new release today.


[question] Can I get latest binaries or binaries for v1.1 ?

The binaries currently available to download doesn't seem to be updated ones as I could not find the new additions like CryptoConfig class and Entity class updates.
Correct me if I'm missing something.
Thanks.

You should have v1.1.2 available on maven.
You can also download it manually from
http://central.maven.org/maven2/com/facebook/conceal/conceal/1.1.2/


Revert "Using File.Exists for HitsFile creation/update validation"

Reverts tonerdo/coverlet#415

cc: @ViktorHofer @tonerdo


Improve browser support with tests and slim dependencies

Browser support should be improved:

add appropriate tests
remove dependencies/unsure the slimmest possible bundle

FYI iOS browsers run in strict mode and throw the following error:
Const declarations are not supported in strict mode.

This is weird. The code published to npm (and its dependencies) is transpiled to ES5 and shouldn't have any const declarations (only var). Could you be more specific as to how you import the client to your application?

I originally thought it was because of some of your dependencies (and you excluding node_modules from webpack). But looking at the code again it seems to remove all const appropriately. Wonder why the behavior on gremlin-bin is different. I'll give this another look.


neonvm-controller: disable cgroup management

neonvm-controller: change args in the deployment, add disable-runner-cgroup, drop enable-container-mgr as mutually exclusive

I have a similar patch: https://github.com/neondatabase/autoscaling/pull/1054/commits/d7f526dc4df548e08f6e5147a86105006cf1a129

@Omrigan I think we yesterday discussed that we want to redeploy neonvm-controller with disabled cgroup management. Should we go with merging PR #1054 (which includes your patch) instead?


It's My Money, And I Want It... When You're Done With It

This PR makes returning funds from chainlink nodes part of the tear-down step. The logic was surprisingly complex due to how chainlink manages transactions, but I managed to get a fairly performant process going. Hopefully, I can work with devs to institute an easier way, but until then, this should do the job well.
The added returnFunds(chainlinkNodes []client.Chainlink, networks *client.Networks) error function and its many helpers do the following:

Loop through each network
If that network is a simulated network (e.g. local geth instance) we don't bother to return the funds
Otherwise we go to all chainlink nodes, and if their addresses have a balance, attempt to send the remaining balance back to the network's default wallet address. (The gas calculation is a bit dirty on this, no good solution at the moment)
The chainlink nodes are monitored over 100 seconds to check if the transactions actually confirmed.
If any of these steps fail, we print out a warning "We couldn't get your money back. Leaving the environment running so you can try to do it manually." and then... well then we do that.

This doesn't make tests fail if the attempts to send back funds fail.
I also threw in a QoL framework setting that allows you to write logs whether your test passes or not. I found this to be handy for debugging while working out the quirks on this one.

Codecov Report

Merging #222 (119368f) into main (c5cb7b7) will decrease coverage by 0.12%.
The diff coverage is 17.24%.

@@            Coverage Diff             @@
##             main     #222      +/-   ##
==========================================
- Coverage   24.14%   24.01%   -0.13%
==========================================
  Files          14       14
  Lines        1793     1811      +18
==========================================
+ Hits          433      435       +2
- Misses       1325     1341      +16
  Partials       35       35

Impacted Files
Coverage Δ

client/blockchain.go
0.00% <0.00%> (ø)

client/chainlink_models.go
0.00% <ø> (ø)

client/ethereum.go
0.00% <0.00%> (ø)

client/chainlink.go
63.40% <26.31%> (-1.09%)
:arrow_down:

gauntlet/gauntlet.go
74.25% <0.00%> (+0.52%)
:arrow_up:

Continue to review full report at Codecov.

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


Add support for scoped type variables

OK, so all of my pull requests are actually requests for help in disguise.
This one is not quite done. Explained below:

Before this commit, type params were passed around in a map in convert
and related functions, but were quickly "forgotten."
This commit adds a ton of plumbing to pass around this map, accumulating
entries as scopes pile on.
I also changed the name of this variable from map to
type_params_map, for readability and because the scope of this
variable is super broad now, so it should have a specific name.
The plumbing is pretty gnarly, and hopefully this diff will cause
someone to speak out and offer a better way.
I attempted managing this data in the context, which is already passed
around, but dismissed that because it was extremely error prone because
we need to rewind the modifications as we pop stacks.
 (I will add inline
comments on GitHub as well.)

In mk_signature, method signatures seemed to depend on only the
f_type_params_map, but the changed implementation uses the fully
accumulated map, i.e., union f_type_params_map c_type_params_map.

In function_decl, I map Flow_js.subt over the type params map, just as
mk_class_elements does, which is necessary (otherwise we pass BoundT
into Flow_js.flow).

I moved the code that merges the old map with the new map into
mk_type_param_declaration, because that should happen everywhere, I'm,
like, 80% sure.

I didn't change this, but convert has a check for existentials that
changes behavior if the type params map is empty. I don't understand
what the significance of that is, but since that map accumulates more
now, is this check still sufficient?

Lastly, and most importantly, type checking doesn't actually work
correctly after these changes. For example:
var constant = function<U>(u: U) {
  return function(): U {
    return u;
  }
}
var test: number = constant(0)("")

leads to the type error:
test.js:6:20,34: U
This type is incompatible with
test.js:6:11,16: number

I was able to get a type error similar to the one in my commit message on current master, with none of these changes:
function identity<U>(x: U) {
  return x;
}
var test: number = identity(0)

generics.js:2:10,10: U
 This type is incompatible with
generics.js:4:11,16: number

A different example of scoped type variables does work correctly.
type Merge<T> = (a: T, b: T) => T;

// hypothetical immutable map
declare class Map<K,V> {
  (): Map<K,V>;
  insertWith(fn: Merge<V>, k: K, v: V): Map<K,V>;
}

declare function foldr<A,B>(fn: (a: A, b: B) => B, b: B, as: A[]): B;

function insertMany<K,V>(merge: Merge<V>, vs: [K,V][], m: Map<K,V>): Map<K,V> {
  function f([k,v]: [K,V], m: Map<K,V>): Map<K,V> {
    return m.insertWith(merge, k, v)
  }
  return foldr(f, m, vs)
}

(If you're interested in this patch, I'm happy to resolve merge conflicts. Would prefer to time it to minimize conflicts with whatever is inflight internally, of course.)

Hi Sam - if you want to resolve conflicts, we can work through any misbehavior you're still seeing and get it landed. (Aside: we should be able to replace the explicitly passed maps with scope push/pops, but no reason to block this work in the meantime.)

@bhosmer OK, rebased against master and added a couple tests. :sunglasses:

The only misbehavior I'm seeing is actually unrelated to these changes, so I filed a separate issue (#656).

This fell out of sync, but it was trivial to get things back in order. Ping?


Fix #63625 - Git: Add setting to disable automatic refresh

@joaomoreno , Here is a PR to fix #63625 .
Please review this , Thanks :)

@joaomoreno , This PR is open from a long time , can you please give some updates ?
I can at least close it if its not working for you.

@joaomoreno , Thanks!

@skprabhanjan Sorry for the delay. I'm currently sitting on a big backlog, so things are taking its time, but I'll get to it. Feel free to reopen.

@joaomoreno , Sorry for that and I understand it now , Thanks for getting back.
Will reopen it :)

@joaomoreno , i think this is already done , Since this PR was opened long time ago and now the changes here are no more valid , I am closing this , Thanks :)


SW-5125: FE - Full Module View

This PR adds the "Full Module View", as well as a placeholder page for Module Events (1:1 Session, Live Session).
See designs.
Review Notes
There are still a few details outstanding:

[ ] Update page title date format?
[ ] Update module event date/time format?
[ ] Wire up links & join session buttons

Screenshots

Thanks for the review @tommylau523 🙌 Great comments and suggestions, will make changes based on feedback and will re-request a review soon.

@tommylau523 do you know if we're planning to add an endpoint to fetch module events or just populate events content data within the modules?

Just realized you said "Because we probably won't use moduleId to query for the full event details." in your previous comment. I'll assume we'll make a separate fetch to get module event details and will make the changes required to support that.

I think I still need to add redux for module events. Should we include that as part of the ModuleService or would we prefer to create a new service? If the latter, what should we name it? ModuleEventService? Something else?
Also, what URL params do we expect to be required when fetching module event data?
@karthikbtf @tommylau523 would love to hear your thoughts when you have a free moment 🙏

The ModuleService should be able to supply event information, details as well as links that are specific to a project.

I think I still need to add redux for module events. Should we include that as part of the ModuleService or would we prefer to create a new service? If the latter, what should we name it? ModuleEventService? Something else?
Also, what URL params do we expect to be required when fetching module event data?
@karthikbtf @tommylau523 would love to hear your thoughts when you have a free moment 🙏

@joshbuchea my thought would be to leverage ModuleService for events, unless the distinction at a service level really matters.
Not up to speed on Participant Experience enough to comment on url params for module event data, will defer to @tommylau523

I think I still need to add redux for module events. Should we include that as part of the ModuleService or would we prefer to create a new service? If the latter, what should we name it? ModuleEventService? Something else?
Also, what URL params do we expect to be required when fetching module event data?
@karthikbtf @tommylau523 would love to hear your thoughts when you have a free moment 🙏

@joshbuchea my thought would be to leverage ModuleService for events, unless the distinction at a service level really matters. Not up to speed on Participant Experience enough to comment on url params for module event data, will defer to @tommylau523

Also, if you prefer to do this in stages, you can get an initial version in and iterate on that until gaps are filled.


Fix BitFieldByte is not converted correctly to human readble form

BitFieldByte is not converted correctly to human readble form.

Thanks for the PR. How did you test this?  How did you acertain it was correct?


Add Stratis Coin

Wishing to bring Stratis on board with Komodo's BarterDEX, for the time being this should work fine with the c++ daemon (https://github.com/stratisproject/stratisX), until the Stratis team completes the work on the C# NODE (as the RPC api isn't complete as of yet).
Let me know if anything needs to be done to complete this merge.

stratisX is missing 2 API-calls needed by BarterDEX: gettxout and importaddress

Hi @cipig, your comment implies you are using the built in wallet of the QT is that correct?

I don't use Stratis

I am aware of that, the two RPC methods you are asking for gettxout and importaddress a wallet related RPC methods, this implies you relay on the built in wallet of the a QT (for other clones).
We don't have them on stratisX and not sure we will.
dotnet core is now cross reference so its fairly easy to run the node in linux, not that much to do just apt-get netcore, clone the repo and run the node. however we probably dont have those RPC methods either on the C# node as we use an HD wallet.

@dangershony @cipig, I just spent some time perusing the code, and it seems that stratisX is using the RPC method gettransaction in place of gettxout.
This is the output of that command:
07:42:50
￼
gettransaction 085f19ca56e40343c1d9578cc9aa57cfd4271f946d2260cd3b821b269da8e227

07:42:50
￼
{
"txid" : "085f19ca56e40343c1d9578cc9aa57cfd4271f946d2260cd3b821b269da8e227",
"version" : 1,
"time" :<PHONE_NUMBER>,
"locktime" : 780878,
"vin" : [
{
"txid" : "bcaa4d3fec6497c6f387be780ba8cb72bec832726d6714d1606bed0747066178",
"vout" : 2,
"scriptSig" : {
"asm" : "3044022003df45e526aec188e1fb8377a27edb518ad3e60bb438810126fddfac4284fe2502204d04749aa69e27b1cb43945d5d96a140ea84ce2c05582377b4915a7359a9476601",
"hex" : "473044022003df45e526aec188e1fb8377a27edb518ad3e60bb438810126fddfac4284fe2502204d04749aa69e27b1cb43945d5d96a140ea84ce2c05582377b4915a7359a9476601"
},
"sequence" :<PHONE_NUMBER>
}
],
"vout" : [
{
"value" :<PHONE_NUMBER>0,
"n" : 0,
"scriptPubKey" : {
"asm" : "OP_DUP OP_HASH160 a4b26492e7592a63bf0cebeabd37742319932522 OP_EQUALVERIFY OP_CHECKSIG",
"hex" : "76a914a4b26492e7592a63bf0cebeabd3774231993252288ac",
"reqSigs" : 1,
"type" : "pubkeyhash",
"addresses" : [
"ScJqZFnN5uV4mJyyxWjsv1yPCRXRQUWR3C"
]
}
},
{
"value" : 5.00000000,
"n" : 1,
"scriptPubKey" : {
"asm" : "OP_DUP OP_HASH160 3f93b440fcc85ff217bebde61794de549850c8d9 OP_EQUALVERIFY OP_CHECKSIG",
"hex" : "76a9143f93b440fcc85ff217bebde61794de549850c8d988ac",
"reqSigs" : 1,
"type" : "pubkeyhash",
"addresses" : [
"ST6AYb7vRVcYZa55yBomiQ8GdFP1Zo7tab"
]
}
}
],
"amount" : 5.00000000,
"confirmations" : 25592,
"blockhash" : "9f04f63eb1683549c4fdf0ffb5e59a7c78da386f998b45c8ccc972e7c2e94bad",
"blockindex" : 2,
"blocktime" :<PHONE_NUMBER>,
"txid" : "085f19ca56e40343c1d9578cc9aa57cfd4271f946d2260cd3b821b269da8e227",
"time" :<PHONE_NUMBER>,
"timereceived" :<PHONE_NUMBER>,
"details" : [
{
"account" : "",
"address" : "ST6AYb7vRVcYZa55yBomiQ8GdFP1Zo7tab",
"category" : "receive",
"amount" : 5.00000000
}
]
}

closing this request. all coin add requests must go to https://github.com/jl777/coins now.
Also https://github.com/KomodoPlatform/BarterDEX/blob/dev/assets/coins.json is now will always be this static file.
@cipig @himu007 @siulynot please don't add or accept any coin add request to this file.


Update the comments module to new paginated API

Previously, the whole comment tree was sent at once in the responses API. The new API unbundles this into separate paginated queries at each level. #574 added support for it on showing the comments count in the responses module. This pull request now changes the comments module to use the new API as well, and removes the unsupported field from the previous API.
Fixes MA-2056.

Observation: If I am on the comments screen (i.e. only page-1 has loaded) and add a comment, the new comment gets appended after page-2, ideally it should appear after page-1 i.e. the 21st item.

Done with first pass :+1:
Lets see if fixing the observation I mentioned, brings some heavy updates.

This was because I didn't remove the LinearLayoutManager set up in the view initialization of CourseDiscussionCommentsFragment. InfiniteScrollUtils sets up it's own LinearLayoutManager for RecyclerView implementations, which was being overriden by the Fragment, causing it to return 0 for the total count, and thus prompting a new page load whenever the scroll listener was invoked. I have fixed this issue now by removing the Fragment's LinearLayoutManager setup.

:+1:

Second review, @bguertin, @BenjiLee?

I'm having trouble seeing any comments at all. On the "Add a comment" label is shown. I have verified that they exist on the desktop browser.

Ah yes, this is due to the fact that the comments count are not provided in the response objects in the current release since the change to the new API structure. Wajeeha has an old feature branch open that provides this field that should be merged into this week's release, and which can be used through the wjia-dapi-cached sandbox. I asked Wajeeha to merge the new pagination format in this sandbox too, but it looks like as a result of rebuilding it, all the existing discussions data has been wiped out. I'll get her to import the old data for easy testing tomorrow.

@BenjiLee: You should be able to test this now on the 'lahore' sandbox, which has the latest changes from master, plus that feature branch which provides the comments counts. That will probably also be merged by the end of the week.

@BenjiLee: Would you like to do a final review on this?

When adding a comment, the comment count does not increment on the comments screen

Overall :+1:
I think adding some unit tests for the counting logic may be beneficial and worth exploring.

Added logic for incrementing the comments count in the response header item.


[Add] Detailed Explanation on Execution context

There is no file that has the explanation on "Execution context".
This is the first and foremost topic of "How JS works behind the scene" ?

@ajay0180 For now the user can copy code and paste it into any of his code environment like online compiler, chrome inspect, vs code etc. later I am thinking of adding embedded javascript compiler in our website.


LongControl: improve control trajectory interpolation efficiency

Optimizes performance by precomputing ModelConstants.T_IDXS[:CONTROL_N] as the global constant CONTROL_N_T_IDX, eliminating redundant list creation and copying.

As noted in the contributing docs, we need a benchmark or metric that improved for optimization PRs.

This PR isn't performance-oriented. I haven't conducted a performance comparison test because reducing list copies here has minimal impact on controlsd's overall performance. It's simply a small improvement to remove repetitive code. I noticed these lines while reviewing the initialization performance of car/interface and thought they could be enhanced.


Speed up rocksdb checkpoint

Is your feature request related to a problem? Please describe.
We now store 10 billion alluxio inode metadata using rocksdb. The current alluxio checkpoint will tar.gz rocksdb data file by single thread, alluxio restart or re-election leader will untar.gz by single thread. This speed is not fast.
Describe the solution you'd like
To divide the rocksdb data into parts and tar.gz each part separately, so that rocksdb write to checkpoint or restore from checkpoint can speed up the speed

In addition to checkpoint, backup is also single-threaded gz. It should also be optimized too.

@jenoudet FYI as well.

Refine checkpoint by Parallel zip compression and decompression
https://github.com/Alluxio/alluxio/pull/16151
The current implementation of backup, instead of executing backup, it is better to reload it


Update to latest FsAutoComplete

Thanks for the quick merge @Krzysztof-Cieslak!
Any idea when the next Ionide release would be?
Of perhaps an insiders release if that is still a thing.
Would like to gather some feedback from that configuration file.


Geospatial smoothing

[ ] Smooth elevation using nearby readings (rather than time based)
[ ] Update Loess to support multivariate inputs

Initial testing shows that on large amounts of data, multivariate loess is slow. I believe in order for this to be implemented it needs to be run in native code