Add support for calling C++ constructors

A problem that we have to deal with when calling C++ constructors is that the ABI of a C++ constructor depends not only on the signature of the constructor but on the class on which it is defined. For example, it can be necessary to pass additional “implicit” arguments to constructors of virtual base classes.
It is therefore fundamentally not possible for SignatureExpansion (which doesn’t have access to the CXXConstructorDecl) to reliably produce the correct LLVM signature from only the type of the constructor. The approach we take is to try to get most of the way in SignatureExpansion by marking the SIL function return type with the @out attribute, representing the fact that C++ constructors take a this points to the object to be initialized.
This produces an “assumed” constructor ABI in SignatureExpansion that assumes there are no implicit arguments and that the return type of the constructor ABI is void (and indeed there is no way to represent anything else in the SIL type). If this assumed ABI doesn’t match the actual ABI, we insert a thunk in IRGen.
The thunk is marked alwaysinline, so it doesn’t incur any runtime overhead, but some compile-time overhead is required for LLVM to inline the thunk. If this turns out to be excessive, we can introduce what is essentially a peephole optimization for a full apply of a function_refthat refers to a C++ constructor and directly emit the constructor call in this case (along with any required implicit arguments) instead of calling the thunk. I’ve chosen not to tackle that in this PR though as it’s already large enough.
On some ABIs (e.g. Itanium x64), we get lucky and the ABI for a complete constructor call always matches the assumed ABI.
In addition to the core C++ constructor functionality, this PR adds some a couple of small required features:

Conversion of thin to a Clang void type
Handling of formal indirect results in SignatureExpansion::expandExternalSignatureTypes()

@swift-ci Please test

@swift-ci Please test Windows

This is now ready for review again -- sorry for the delay.
See also the discussion here:
https://forums.swift.org/t/calling-c-constructors-looking-for-feedback-on-my-approach/34787/18?u=mboehme

@rjmccall Not sure if you want to review this also?

Build failed
Swift Test OS X Platform
Git Sha - c8cd2d8b6a4b0f38c10cff1d9541c7b0a49202ef

@swift-ci Please test

Build failed
Swift Test Linux Platform
Git Sha - c8cd2d8b6a4b0f38c10cff1d9541c7b0a49202ef

Build failed
Swift Test OS X Platform
Git Sha - c8cd2d8b6a4b0f38c10cff1d9541c7b0a49202ef

@swift-ci Please test

Build failed
Swift Test Linux Platform
Git Sha - b0b13db62f22a0b70b660b384b6148a363e1a55d

Build failed
Swift Test OS X Platform
Git Sha - b0b13db62f22a0b70b660b384b6148a363e1a55d

I've tried to reproduce the LLDB test failures locally, but they pass, even with ASAN enabled. Restarting testing in case this was just an infrastructure failure (though I'm not exactly sure how it could be).

@swift-ci Please test

Build failed
Swift Test Linux Platform
Git Sha - b0b13db62f22a0b70b660b384b6148a363e1a55d

Build failed
Swift Test OS X Platform
Git Sha - b0b13db62f22a0b70b660b384b6148a363e1a55d

@swift-ci Please test

Build failed
Swift Test Linux Platform
Git Sha - 0382afd621cd4be80b39c5b03ebd774ee8310449

Build failed
Swift Test OS X Platform
Git Sha - 0382afd621cd4be80b39c5b03ebd774ee8310449

@swift-ci Please test Linux

I've now fixed the LLDB failures, all tests are passing.
Ready for further review!

@swift-ci Please test

Build failed
Swift Test OS X Platform
Git Sha - c9f6e10d450b32e563214e1d4724c0bcb23bf939

Build failed
Swift Test Linux Platform
Git Sha - c9f6e10d450b32e563214e1d4724c0bcb23bf939

@swift-ci Please test Windows

@swift-ci Please test Windows

@rjmccall Wanted to check in and see if you've had a chance to look at my changes and comments. Understand you may be busy with WWDC, just wanted to make sure this hadn't slipped off your radar. Thanks!

@rjmccall, could you please take another look at this pull request? A lot of our C++ interop work is blocked on this PR. It would be good if we could move forward, now that WWDC is over.

It would be really great to move this along. There are a few things waiting on it.

@rjmccall friendly ping :)

@swift-ci please smoke test.

@swift-ci please smoke test.

@swift-ci please smoke test.

@swift-ci please smoke test.

@swift-ci please smoke test.

@swift-ci please smoke test linux platform

@swift-ci please test Windows platform

A change in the past day or two made it so that type->hasRepresentation() is no longer true in visitMetatypeType. Fixing...

@swift-ci please smoke test.

@swift-ci please test windows platform

Let's see if that fixes the assertions on windows.
@swift-ci please test windows platform.

@swift-ci please test Windows platform.

@swift-ci please test windows platform.

Unfortunately, right now the windows crashes are a bit of a black box for me. I can only guess at what the issue may be. Hopefully, this most recent commit will fix it. Otherwise, I may have to set up a windows machine to debug this locally.

@swift-ci please test windows platform.

@swift-ci please test Windows platform.

@swift-ci please test windows platform.

@swift-ci please test windows platform.

@swift-ci please test windows platform.

@swift-ci please test windows platform.

@swift-ci please test windows platform.

@swift-ci please test Windows platform.

@swift-ci please test Windows platform.

@swift-ci please test Windows platform.

@swift-ci please test Windows platform.

Looks like an unrelated stdlib issue.
@swift-ci please test Windows platform.

@swift-ci please test Windows platform.

@swift-ci please test Windows platform.

@swift-ci please test Windows platform.

@swift-ci please test Windows platform.

@swift-ci please test Windows platform.

@swift-ci please test Windows platform.

@swift-ci please test Windows platform.

@swift-ci please test Windows platform.

@swift-ci please test Windows platform.

@swift-ci please test Windows platform.

@swift-ci please test Windows platform.

@swift-ci please test Linux platform.
@swift-ci please test OS X platform.

@swift-ci please test Linux platform.

@swift-ci please test Linux platform.

Finally, the builds are green! There are a few minor review comments I need to address, but I think this patch is almost good to go.
@rjmccall, @hlopko, and @gribozavr thank you for all your help reviewing this patch. Do you have any more comments?

Super exciting @zoecarver !!!

@swift-ci please test Windows platform.

@swift-ci please test Windows.

@swift-ci please test Windows platform.

@swift-ci please test Windows platform.

@swift-ci please test Windows platform.

Dropped 702689480ae3a9b018ceba5f5cca7de22ee54c3c. I'm going to double-check that this crashes before I launch into debugging it.

@swift-ci please test Windows platform.

@swift-ci please test Windows platform.

@swift-ci please test Windows platform.

@swift-ci please test Windows platform.

It looks like (on Windows only?) it's possible for a function template to have a CXXConstructorName if it wraps a CXXConstructorDecl. I wonder if #33053 will fix this (I doubt it). But, if that doesn't work, I think a fairly simple fix would be to just get the constructor decl out of the function template if we find a function template in that branch.

https://github.com/apple/swift/pull/33053
@swift-ci please test Windows platform

Yeah, that didn't work. I'll try my other idea.

@swift-ci please test Windows platform.

@swift-ci please test Windows platform.

@rjmccall thank you again for the help reviewing. I really appreciate your insights. Any other comments?
Hoping to land this in the next few days.

Unless anyone has an objection, I'm going to land this patch on Wednesday.

nice!

It looks like (on Windows only?) it's possible for a function template to have a CXXConstructorName if it wraps a CXXConstructorDecl.

Oh, yes, that's right.  I don't think that's Windows only — any constructor template should have that characteristic.

Thanks, @rjmccall. Given that you've both approved this PR, I'm going to go ahead and land it now.
Before it lands, I want to run the benchmarks, though. As much to test #32721 as anything else. Hopefully, this swift-ci incantation will work.

https://github.com/apple/swift/pull/32721
@swift-ci please benchmark.

Actually, thinking about it, that won't work because even if it does correctly merge the branches before benchmarking, the benchmark will be shown as "added" so, we won't be able to get any real data from it.

Performance: -O

Regression
OLD
NEW
DELTA
RATIO

FlattenListFlatMap
3743
5255
+40.4%
0.71x (?)

Improvement
OLD
NEW
DELTA
RATIO

StringBuilderWithLongSubstring
1830
1670
-8.7%
1.10x (?)

Code size: -O
Performance: -Osize

Improvement
OLD
NEW
DELTA
RATIO

NSError
318
229
-28.0%
1.39x (?)

Code size: -Osize
Performance: -Onone

Regression
OLD
NEW
DELTA
RATIO

String.data.Medium
190
207
+8.9%
0.92x (?)

DictionaryBridgeToObjC_BulkAccess
198
213
+7.6%
0.93x (?)

Code size: -swiftlibs

How to read the data
The tables contain differences in performance which are larger than 8% and
differences in code size which are larger than 1%.
If you see any unexpected regressions, you should consider fixing the
regressions before you merge the PR.
Noise: Sometimes the performance results (not code size!) contain false
alarms. Unexpected regressions which are marked with '(?)' are probably noise.
If you see regressions which you cannot explain you can try to run the
benchmarks again. If regressions still show up, please consult with the
performance team (@eeckstein).

Hardware Overview
  Model Name: Mac Pro
  Model Identifier: MacPro6,1
  Processor Name: 12-Core Intel Xeon E5
  Processor Speed: 2.7 GHz
  Number of Processors: 1
  Total Number of Cores: 12
  L2 Cache (per Core): 256 KB
  L3 Cache: 30 MB
  Memory: 64 GB

@swift-ci please test and merge.

@swift-ci please test and merge.

Big congrats to both Martin and Zoe, impressive work!


feat: 🎸 adding 20px padding to DialogContent used by the SQFormDialog component

Adding 20px padding to DialogContent used by the SQFormDialog component.
BREAKING CHANGE: 🧨 yes
✅ Closes: #88
Loom: https://www.loom.com/share/6ead5c0298f24e4f80533f2d3e05d1af

The breaking change section should include what the breaking change actually was, it'll make its way into the changelog

The breaking change section should include what the breaking change actually was, it'll make its way into the changelog

This commit tool is so silly sometimes.  I wish it was more intuitive and user friendly.

The breaking change section should include what the breaking change actually was, it'll make its way into the changelog

This commit tool is so silly sometimes. I wish it was more intuitive and user friendly.

I agree.  Or you could just do git commit --amend and change the text. I'm 99% sure (Maybe Sean knows more) it'll pull the text off the commit, whatever it is, as merge time to generate the changelog. Of course you'll need to git push --force after a commit amend.


OAK-10671- [Indexing Job] Improve Mongo regex query: remove condition on non-indexed _path field to speed-up traversal

Regex path filtering currently is implemented with a condition like:
_id in [^[0-9]{1,3}:\Q/foo/bar/\E.*$] OR ('_id' in [^[0-9]{1,3}:h.*$}] AND _path in [^\Q/foo/bar/\E.*$]

The second condition is necessary to deal with long path documents, whose _id is an hash instead of the path of the document, and that have an additional _path property with the full path of the document. The _id field is part of the index used by the query, but _path is not indexed. So the performance of this query will be very sensitive to how many time the query condition can be resolved without having to lookup the value of _path, which requires retrieving the full document from the column store. If the condition can be evaluated only using the _id value, them if there is no match the document should not be retrieved from the column store.
Unfortunately, Mongo does not seem to properly optimize this query and is retrieving the document from the column storage even when _id does not match the path /foo/bar and the _id is not in the hash format. This leads to very poor performance as both the index and the column store have to be fully read by this query.
We can instead use the following condition:
_id in [^[0-9]{1,3}:\Q/foo/bar/\E.*$ , ^[0-9]{1,3}:h.*$}]

That is, download the document if the _id matches the path or if it is an hash. This has the disadvantage that it will download all long path documents from the repository, many of which might not be needed. However, this query condition only uses the _id field so it is guaranteed to be evaluated fully using only the data on the index. And the number of long paths documents is usually very small, some environments don't even have any long path documents, so downloading them should not take much time. And the indexing job will anyway reapply the filter on paths locally, to eliminate the long path documents which are not required by the indexing job.
The gains of scanning only the index can be substantial. For instance, in one experiment, reindexing an index that requires 400K documents out of 29M I got the following results to build the FFS:

With filter on _path: 30 minutes
No filter on _path: 1m30

On another instance, downloading 14M nodes out of 250M:

With filter on _path: 1h30
No filter on _path: 20 minutes.

The gains will be bigger the smaller the fraction of the OAK tree that has to be downloaded, but there should be benefits even when downloading a large fraction of the tree.
Limitations
Using only the _id field on the filter condition improves the performance significantly when having only includedPaths, but it does not change the performance when there are excluded paths or there are custom regex exclude filters. The reason is that Mongo needs to retrieve the document when evaluating a condition like not regex(_id, "/tmp/.*"), because a value of null would also matches this condition and the index does not contain null values. A future PR will address this limitation.

Don't have anything to add LGTM.


Update data type and sample rate calculation

What does this Pull Request accomplish?
Change the "Min Sample Rate" to "Actual Sample Rate" as the input of "dt" calculation when using the Graph control in UI.

Change type of Record Length from DBL to I32.
Why should this Pull Request be merged?
The calculation should use the "actual sample rate", which is addressing the same comment raised in Frequency Domain measurement.
Type of Record Length should be changed.
What testing has been done?
Tests are done using the build outcome in "Services" folder.
Setup:

IS:

TS:

Please update the TestStand sequence file to update the data type.


Add host name to default meta server instead of just port :8091

[Yes] CHANGELOG.md updated
[ Yes] Rebased/mergable
[ Yes] Tests pass
[ Yes] Sign CLA (if not already signed)

Windows does not like URL's without host names,getSnapshot (Get http://:8091?index=0) results in error ( ConnectEx tcp: The requested address is not valid in its context.). The fix is to add hostname to the URL. It was done while adding list of servers to meta service.
Have tested in both windows and debian Linux, no breaking changes in Linux, and now build works without a config change in windows. Fixes #5848.

No longer applicable as the clustering code is changed now.


How applying the model to a different language

Hi authors, your work is interesting. May I ask steps of applying this model to a different language (i.e., JavaScript)?

Create ASDL grammar on tranX?
Convert raw data (source code) to the ginhubedit dataset format?
Make edit sequence generation (could you please suggest how to do?)

Data Preprocessing and Sanity Check
Todo: when applying the model to a different programming language, how to check/debug the ASDL grammar implementation, the abstract syntactic tree preprocessing, and the ground-truth edit sequence generation?

Hi @chontipan, sorry about the late reply!
We have updated the README with suggestions on applying the model to other PLs (https://github.com/neulab/incremental_tree_edit#4-faq). We have also refactored part of the ASDL implementation accordingly. Please make sure you pull down the latest code.
To your other questions:
Q2: We do not have the code for converting the raw C# code to the AST in the GHE dataset. This is provided by the Graph2Tree paper (https://arxiv.org/pdf/1810.13337.pdf); please check out their released code for this part. However, since you are using the model for your own PL, I guess this code may not be very necessary. As we discuss in README 4.1, the TranX library could be useful as it includes ASDL for some other languages.
Q3: The generation of the target edit sequence has been included when you run the experiments following our instruction. It is language-agnostic, meaning that once you implement the ASDL for your own PL, by running the experiments you will collect the target edit sequences for your case. You can also do a sanity check by writing a demo_edits.py script.
Hopefully these have addressed your concerns. Please let us know if you have more questions!

Thanks!


Should be able to import from a GitHub tag or branch

The import "github.com/..." syntax is a great way to get people started, but it should allow importing from a specific tag or branch instead of the default master. This can be used to specify releases and will, for example, prevent that snippets around the web stop working and rot because of changes in the master branch of a smart contracts repo.

That is pushed


Modification in main DITA Map does not seem to be detected

I create the milestone. I modify the main DITA Map, I add an extra topicref to an existing topic, I try to create the package containing changes, the plugin says that there are no changes.

In this scenario the Map should have been detected as modified and included in the package.


Error installing packages: "Not Found"

Steps to repro:

Log in as user
go to project
launch jupyter notebook
go to conda tab
select a large number of packages to install (customer can reproduce reliably with as little as 35 packages)
Expected result: packages are installed and confirmation message updates the user
Actual result: packages ARE installed BUT on-screen error message saying "An error occured while installing packages. Not Found"

Hi @damianavila - is this reproducible in any of your envs? cc: @csoja

Log files from the customer attached
anaconda_logs.zip

refer to Anaconda-Platform/nb_conda/issues/61

@stephenakearns fair chance this is due to a network timeout.  A whack of packages will take some time to install.  I was going to test for you on the datalab system but it seems AE4 has gone down and a few minutes of effort do not reveal why wk-server is spin-crashing.  Could possibly also test via AE4 Trial VM.

@stephenakearns fair chance this is due to a network timeout.

It could be a timeout issue, that is a good guess. We should try to reproduce it to isolate where the problem comes from.


Serialize Map types in GraphQLQuery

Pull request checklist

[x] Please read our contributor guide
[ ] Consider creating a discussion on the discussion forum
first
[x] Make sure the PR doesn't introduce backward compatibility issues
[x] Make sure to have sufficient test cases

Pull Request type

[x] Bugfix
[ ] Feature
[ ] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] Other (please describe):

Changes in this PR
Issue #290
Support Maps in GraphQLQuery serialization.  This is useful for JSON and Object scalars.
Alternatives considered
n/a

Did the CI checks have some kind of environmental issue not related to this pull request?

Did the CI checks have some kind of environmental issue not related to this pull request?

Yes, I think so. Several other builds also failed.

@richardcresswell I've restarted the builds, fingers crossed that just fixes it

I'm looking at the build failures. Will disable test-reporting for now to get this going.

@richardcresswell could you please rebase against master?

Should be all set.

@paulbakker @richardcresswell boggles the mind that the CI Workflows are still trying to Publish the Tests. This was disabled and both master as well as @richardcresswell 's branch reflect it.

The code changes look fine and and the project build as well. The failures are based on the failure to publish the JUnit Reports.
There is a caveat on using the pull_request action that I was not aware and affects the publishing of such reports, if the PR comes from an external fork. In addition, it looks like this build is being triggered against the Github actions available when this PR was created instead of the ones available in master that have such publishing disabled.
Ref.

https://github.blog/2020-08-03-github-actions-improvements-for-fork-and-pull-request-workflows/
https://securitylab.github.com/research/github-actions-preventing-pwn-requests/

@paulbakker @richardcresswell , the build is green.

Thanks @richardcresswell for the PR and patience with the build.

Thanks for merging!  So we can plan on our side, do you know when you will be publishing the next RC or release?

@richardcresswell - we will release this week, likely in the next day or two.


webui on nas LAN

i installed ipfs on a nas for LAN using docker
when i try to access webui i get this
Is your IPFS daemon running?
Failed to connect to the API.

ipfs companion works tho
exactly what i need to do and get this working

This is likely a problem with the CORS configuration of your ipfs node. If you are accessing the webui via a local IP address on your LAN, then you need to add that origin to the allowed domains config.
$ ipfs config --json API.HTTPHeaders.Access-Control-Allow-Origin '["<ip address and port of remote api>"]'

To see that that is doing, you can open up the config file for your node in the IPFS_HOME/config file. You need to add your origin to the array in:
{
  "API": {
    "HTTPHeaders": {
      "Access-Control-Allow-Origin": []

This is likely a problem with the CORS configuration of your ipfs node.

is the default config i dint change anything
ipfs config --json API.HTTPHeaders.Access-Control-Allow-Origin '["my_pc_ip"
does nothing

No need to blame companion just yet! It sounds like it is doing the right thing.
/ipns/webui.ipfs.io is an address for the bleeding edge dev version of the web UI. It gets updated whenever we merge code into master.
Companion is opening the stable release of Web UI, via an immutable ipfs address. It should open fine. The challenge is that you'd like it to talk to an API on a different machine on your LAN. Right now it's not easy to do that as you have to update the CORS config on your ipfs node to allow access via the LAN IP address for your nas.

http://local_ip:8080/ipns/webui.ipfs.io/#/

not longer work :(

@icf20 thank you for raising the issue of poor UX when opening Web UI from LAN IP.
We plan to simplify the way Companion opens Web UI: https://github.com/ipfs-shipyard/ipfs-companion/issues/736
(this will make it work in LAN scenario without the need of setting CORS)

Not sure how useful it is, but some additional context:

is the default config i dint change anything

Default config assumes you are running and accessing Web UI via localhost interface.
Unless you set up HTTPS, the LAN IP is not considered a Secure Context and may require additional configuration.

i found the issue

This is not related to Web UI issues. It means that if you have HTTPS website with images loaded from IPFS paths, IPFS Companion will redirect requests for those images to your node at LAN IP. If node in LAN does not have HTTPS, browsers will produce mixed content errors. It is a limitation of the web platform (Secure contexts).


Issue-1_DCR-214 - Pretty output and debug mode for extra information in stderror

Now we are no longer tracking in the standard output what we are doing... this is only staff for the new debug flag. And we use gochannels to communicate status of the connections, and an in memory slice to track the status of each. These connections do have an struct that describes their status, and allows pretty printing.
Some refactor could be possible / moving the reporting functions outside of the function raising execution threads, that could be also running in a different thread.

this covers https://github.com/dachad/check-max-tcp-connections/issues/1

@chadell , latest comments introduced, plus final code reallocation to leave this as clean as possible. Final review required

wow! it looks much cleaner now! fantastic work @dcaba !
Just fix the CI 😉

codacy picked a couple of documentation issues... not sure why travis is failing (we havent change anything related to travis, and the error looks quite generic... :thinking: )

@chadell , builds now passed (looks there was a problem with travis; no actual changes, just re-running the builds). Can you mark this as reviewed?


Convert Matrix's @\room to @\everyone or @\here in Discord

Convert @ room to @everyone or @here when sending? Discuss!

voting for @here

I concur with @TildeSlashC0re

merged


Iframe not resizing

This is the current snippet, I pass url as props to this class which uses reactiframeresizer to construct the new iframe.
import React from 'react';
import ReactIframeResizer from 'react-iframe-resizer-super';
export default class WidgetFrame extends React.Component {
constructor(props) {
    super(props);
}

render() {
    return (
    <ReactIframeResizer src={this.props.url} iframeResizerEnable ={true}  />
    )
}

}
However, the iframe that is being rendered doesn't resize. My guess is, the content loads after the iframeresizer frame has been constructed which causes it to render at a fixed height.
If this is the reason, what is the remedy for it? If no, suggestions are welcome as well.
Also, I'm being bombarded with the following errors and warnings. Though it doesn't hurt the functionality, but it surely spoils the presentation aspect of the component.

I'll be glad if someone could post a solution for this as well :)

I have the same problem

Same problem here...

For the resizer to work iframeResizer.contentWindow.min.js needs to be injected into the page inside iframe. If both pages share the same origin this component is able to inject the script but when the origins are different you have to make sure that the hosted site will have the script injected somehow.

same problem


Clarify support for 3rd party monitoring tools

Clarify support for 3rd party monitoring tools.

Yes please @MarkvanMents , thank you!


Fix handler error catching

When an error occurs while running a user handler, the development server should catch the error, stop processing logs, and display the error in the terminal UI. Then, on the next hot reload, Ponder should clear the error and begin processing logs again.
I'm not exactly sure how to do this. Also, the stack trace almost always points to some weird yoga prebuilt thing instead of the actual line with the error. Some errors will originate downstream of user code, like in the entity store (SQLite/Postgres).

Largely fixed by https://github.com/0xOlias/ponder/pull/20


Not An Issue: This is great!

Thanks for making this and sharing it with other people. I love it. I'm using this everywhere now. :+1:  :smile:

That's really nice, I made this theme just to see if I could write kinda Adwaita-like styles for the new Firefox, since it broke most of my old add-ons. It's cool that it actually turned out to be something useful. And not just for me, but for others too. I'm glad you like it! :D

Thanks for making it! I was really mad when all the firefox adwaita themes were breaking and then all the webextensions stuff messed it up too. Really makes firefox look nice in Gnome.

This indeed, quite amazing. It makes Firefox look almost as good as Epiphany aka GNOME Web. I have always wanted to use Epiphany because of how it looks and because its system integration, but it is not viable for me (yet).


Fix lint issues

LGTM. @adrianchiris @rollandf can one of you add me as a member of the project? It appears I cannot approve of PRs.


Compilation error

Hi all,
With the latest changes, while compiling I have this:
/home/giuseppe/gh_llvm_project/llvm/../mlir/include/mlir/Dialect/Linalg/IR/LinalgTypes.h:23:10: fatal error: 'mlir/Dialect/Linalg/IR/LinalgOpsDialect.h.inc' file not found
#include "mlir/Dialect/Linalg/IR/LinalgOpsDialect.h.inc"

It looks like cmake is building the repo first and then LLVM, so it does not find things that should have been generated by mlir-table-gen. Is this possible?
I tried to build things in different order, but I am not able to get rid of the error.
Also, I am using the pinned LLVM version specified in the repo.
Any suggestions?
Thanks,
Giuseppe

Ok, I found the issue. THe problematic commit is: 2d7c7cbe8d23dcf897b59fb42251c97c7eb997ac
In that commit, while a lot of dependencies have been added, one dependency was removed and that caused the problem.
Sending a PR ASAP

Hi Giuseppe, note that there is a pinned-llvm-commit file that the CI
uses.
You should be able to always use that and we bump it when we send new
changes to core.
On Fri, Nov 26, 2021 at 11:29 AM Giuseppe Rossini @.***>
wrote:

Ok, I found the issue. THe problematic commit is: 2d7c7cb
https://github.com/google/iree-llvm-sandbox/commit/2d7c7cbe8d23dcf897b59fb42251c97c7eb997ac
In that commit, while a lot of dependencies have been added, one
dependency was removed and that caused the problem.
Sending a PR ASAP
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/google/iree-llvm-sandbox/issues/43#issuecomment-979863007,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACNNU5E2FKA6GRD3R7JYETLUN5ORHANCNFSM5I2JKDWQ
.

--
N


Possibility of custom SSH port

Hi, this project is really good! I used "cBackup" but unfortunately I haven't received an update in a long time.
I use a different SSH port than the default, but I didn't find a way to make it work in the tool
ps: You're probably Brazilian like me, but I preferred to write in my pseudo English

cBackup Picture

Nice! Precisando de colaboração, me ponho a disposição. Uso o mesme nome de usuário no telegram

@fabriciomatrix The new version now supports changing the default ssh port ;)


Scatter chart props

is there a reason behind why  xKey,  yKeys, are not both singular or both plural? That is easy to overlook and think it's a bug
I also think that readme refer to them as yAxisKey and xAxisKey

currently support multiple yKey values that each produce a different data series (i.e. legend item)


Feature 1

This is really important

[ ] Task 1
[x] Task 2
[ ] Task 3

What is the status of Task 1?

Done!

Closing, this was just a test.


[RFC] Streaming ingestion (pull based)

Is your feature request related to a problem? Please describe
Today, OpenSearch exposes an HTTP-based API for indexing, in which users invoke the endpoint to push changes. It also has a “_bulk” API to group multiple operations in a single request.
There are some shortcomings with the push-based API, especially for complex applications at scale:

Ingestion spikes beyond the server capacity can result in request rejections and backpressure to the clients. Thus it adds complexity to the application producer to properly handle the back pressures.
In complex applications, not all index requests are equally important. However, today there’s no good way to differentiate the index requests based on the priority with the current HTTP API. This issue is particularly challenging for heavy ingestion workloads.
Some cases would require replaying the indexing requests. For example, the cluster is restored from a previous snapshot, and the ingestion history needs to be replayed. Another example is the live cluster migration in which the indexing needs to be applied to two clusters.
In the segment-replication mode, translog is used for the durability of staged index changes before they are committed. However, excessive Translog can result in overflow under heavy ingestion. And in the document-replication mode, it needs to wait for the completion of the document. Neither translog nor synchronous replication is necessary in the streaming ingestion mode, because the streaming buffer can provide the durability guarantee.

Describe the solution you'd like
In general, a streaming ingestion solution could bring in multiple values and address the aforementioned challenges:

By introducing a streaming buffer, it’s possible to decouple the producers (i.e. applications who generate index operations) and consumers (i.e. OpenSearch server). With that, the ingestion spike can be smoothed and buffered, without blocking the producer.
With streaming ingestion, it’s possible to enhance it with priority-aware ingestion by employing multiple Kafka topics to isolate the events based on priority, and applying different rate-limit thresholds to prioritize important events.
A streaming platform like Kafka stores messages in a durable log, and allows consumers to re-read messages from the past via offset. This is a powerful feature that offers reprocessing and replayability.
A durable messaging system like Kafka can provide the durability guarantee of the messages and still maintain a high write throughput. Thus it’s possible to simplify the ingestion component in OpenSearch to delegate the message durability problem to the messaging system.

More details of the solution can be found in this document
Related component
Indexing
Describe alternatives you've considered
As an alternative, the plugin-based approach starts a streaming-ingester process as a sidecar to the OpenSearch server in the same host, which is described in this section.
Additional context
No response

@msfroh I have reread the proposal and it sound more like pull based ingestion you've been discussion on multiple occasions, @yupeng9 I have closed the issue prematurely (sorry about that), however clarifying that this is a different model

thanks. yes, this is different from adding streaming in HTTP protocol. It aims to pull from streaming systems like Kafka, Kinesis, Pulsar, Redpanda etc

Thanks for starting the discussion. It would be interesting to see how we decouple partitions or streams from the shards espl with the work on online shard split.
+1 on the benefits of dropping translogs.

Thanks for the RFC @yupeng9. This would help bring the pro-active back-pressure to OpenSearch ingestion.

It aims to pull from streaming systems like Kafka, Kinesis, Pulsar, Redpanda etc

Does source need to be a streaming system? Can it be a database storing records and based on the checkpoint maintained, opensearch ingestion workers will be able to ingest new records. I understand that it won't be as efficient as, say Kafka, but would be more generic.
Also, if I compare this to Data Prepper (https://opensearch.org/docs/latest/data-prepper/), the advantage in pull based ingestion would be, it is inbuilt into server, so it would know the health and capacity of the server better. Is this correct understanding?

Does source need to be a streaming system? Can it be a database storing records and based on the checkpoint maintained, opensearch ingestion workers will be able to ingest new records. I understand that it won't be as efficient as, say Kafka, but would be more generic.

Ultimately, as long as something supports the API described in the Google Doc (or at least whatever the final version of is), we should be able to ingest.
I'm excited to try implementing a Parquet (or maybe JSON file in a blob store) source that would do a one-time import, where each shard fetches a subset of the input as fast as they can.
Something else I would like to support is a combined source that includes both a database and an event stream. One of the Amazon systems that I worked on previously had an upstream system of record implemented in DynamoDB. That system would receive partial updates for records and apply them to DynamoDB using optimistic locking. Once the (versioned) update succeeded, it would be sent on a Kinesis stream for live updates. The search system that I worked on would periodically rebuild the whole index by backfilling from DynamoDB while simultaneously processing live updates from Kinesis (to make sure that updates applied to records already read from DynamoDB would not be missed). Once the backfill was done, it would continue processing updates from Kinesis. From our perspective on the search side, we were just pulling documents from "somewhere" and didn't care whether they came from DynamoDB or Kinesis. A composable ingest source (that pulls from multiple ingest sources) should be pretty easy.

Thanks @yupeng9 for the detailed RFC.
I liked the alternative approach of using  Ingestion Plugin as well . That gels easily with current model of abstracting out shard from the end user as well . This makes easy for newer features like online shard split to easily carry out its activities without any disturbance to ingestion . As far as the cons listed out the request will be forwarded to the server hosting the primary shard and thus incur additional overhead , I am not sure how big of a magnitude that will be .

Thanks @yupeng9 for this detailed RFC. I really like the idea of using a Kafka-like queue between the producer and OpenSearch. This should take a lot of pressure off clients, so they don't need to build their own complex logic or queues when OpenSearch can't keep up with ingestion. I'm most familiar with Kafka, so I'll use that as an example, but the same ideas apply to other streaming systems too.
A couple things I'm curious about:
How flexible can we make the scaling between Kafka partitions and OS shards? Do we really need to stick to a 1:1 mapping, or can we let them scale independently? Both systems already have their own ways to scale, so it'd be cool if we could take advantage of that.
Can we keep the queue stuff "under the hood" as much as possible from the OS cluster's perspective? It'd be great if we could keep the learning curve low for users. Also, how can we make sure the default setup works well for most use cases without needing a ton of tweaking?
Just thinking about how this might work in real-world setups. Looking forward to seeing how this develops!

Can we keep the queue stuff "under the hood" as much as possible from the OS cluster's perspective?

Check out the linked Google Doc. There's an interface that essentially gives OpenSearch an "iterator" over the ingest source. Configuring the ingest source is part of the index configuration and is handled by the ingest source plugin (so it's exactly as complicated as whatever the ingest source requires, but is opaque to OpenSearch itself).

How flexible can we make the scaling between Kafka partitions and OS shards? Do we really need to stick to a 1:1 mapping, or can we let them scale independently?

The main challenge is making sure that the producer and shards agree on the strategy used to route documents to stream partitions.
The approach I've seen work (though it's probably not the only solution) is a consistent hash-range strategy. Essentially, with N stream partitions, you divide your hash space into N contiguous ranges (and can update that split as N changes). The producer hashes the doc ID (or custom routing value), sees which range that lands in, and writes to the appropriate partition. On the shard side, if you have M shards, you similarly split the hash space into M ranges (and can update as M changes, like if you do an online shard split). When M and N are not multiples of one another, the partition ranges and shard ranges won't line up perfectly, but shards can read documents from all partitions whose ranges overlap the shard's range. Any documents outside the shard's range are ignored. I know at least two highly-scalable production search systems that use this strategy.
Anyway, we should be able to ship with a 1:1 mapping constraint to start (since that already helps from a scaling perspective). We can solve the N:M mapping case later (probably by providing configuration to communicate the document hashing strategy) and remove that constraint.

Just thinking about how this might work in real-world setups. Looking forward to seeing how this develops!

Using stream-based ingestion is very common in lots of real-world setups, including at least three different search systems that operate within Amazon. It's so much easier to scale than a system that pretends to be a database. You can also check out what Slack did with their Astra system for log search: https://www.youtube.com/watch?v=iZt-eL1GUKo

Can we keep the queue stuff "under the hood" as much as possible from the OS cluster's perspective?

I see this as an opportunity to lean into data prepper (or other ingestion tools) as the front door for end users. These tools allow for more sophisticated and flexible features as compared to what is possible to do in an indexing coordinator inside the cluster itself. The specifics of how that ingestion tool sends data to cluster then really is "under the hood" from the user's perspective.

The main challenge is making sure that the producer and shards agree on the strategy used to route documents to stream partitions.

I think this other challenge in this category, and probably the harder one (that @yupeng9 and @Bukhtawar  mentioned): how to keep the locality with the primary shard(s) in case relocation happens for whatever reasons (this would eliminate  any network hops that other ingestion tools would exhibit).

How flexible can we make the scaling between Kafka partitions and OS shards? Do we really need to stick to a 1:1 mapping, or can we let them scale independently? Both systems already have their own ways to scale, so it'd be cool if we could take advantage of that.
This is a good question. At Uber, our current Search systems in production already use pull-based ingestion, and we used 1:1 mapping between Kafka partitions and shards. Our learning is that this provides a lot of simplicity, as we can trace the data from search shard to the input Kafka partition sharing the same sharding key. So that we can build dashboards for observability, and toolings for debugaggbility. And yes, resharding is a very involved procedure for this setup. However, we realized that resharding is a very infrequent operation, and therefore we want to optimize the systems for frequent operations, and less so for infrequent ones as the latter can introduce significant complexity to the system.
Can we keep the queue stuff "under the hood" as much as possible from the OS cluster's perspective? It'd be great if we could keep the learning curve low for users. Also, how can we make sure the default setup works well for most use cases without needing a ton of tweaking?
Yes, that's the intention. We want to make this feature pluggable, so that a separate index engine is used to ingest from streaming sources, and thus not disruptive to the existing indexing code flow. So when pull-based ingestion is enabled, we can disable the HTTP-based index API.
Just thinking about how this might work in real-world setups. Looking forward to seeing how this develops!

Can we keep the queue stuff "under the hood" as much as possible from the OS cluster's perspective?

I see this as an opportunity to lean into data prepper (or other ingestion tools) as the front door for end users. These tools allow for more sophisticated and flexible features as compared to what is possible to do in an indexing coordinator inside the cluster itself. The specifics of how that ingestion tool sends data to cluster then really is "under the hood" from the user's perspective.

That's the option described in the alternative solution. I feel a true native pull-based ingestion built into the cluster with a separate engine will achieve much better performance, as we already observed this in Uber production. We also use an ingester similar to logstash to ingest from Kafka into Elasticsearch. From our benchmark, the native pull-based ingestion not only showed much better ingestion throughput, but also reduced the significant cost by removing the compute resources of the ingesters.

Just curious how do we store the mappings between partitions and shards, is that part of the cluster metadata? Another question is that for log scenario, in traditional way, users always write documents to an alias, data streams or a concrete index with date suffix, these targets rollover based on age, shard size or index size with an ISM policy, does Streaming ingestion have an impact on this usage?

Just curious how do we store the mappings between partitions and shards, is that part of the cluster metadata? Another question is that for log scenario, in traditional way, users always write documents to an alias, data streams or a concrete index with date suffix, these targets rollover based on age, shard size or index size with an ISM policy, does Streaming ingestion have an impact on this usage?

In the initial phase, I don't plan to store these mappings, but go with the convention of 1:1 mapping between partitions and shards and have validation enforcing it. In future, we can relax this constraint
For 2nd question, do you mean if the retention policy from streaming systems shall be carried over to opensearch? I think these two are decoupled, and a separate TTL within OS controls the lifecycle of the data, which is independent from the streaming source.

Can we keep the queue stuff "under the hood" as much as possible from the OS cluster's perspective?

I see this as an opportunity to lean into data prepper (or other ingestion tools) as the front door for end users. These tools allow for more sophisticated and flexible features as compared to what is possible to do in an indexing coordinator inside the cluster itself. The specifics of how that ingestion tool sends data to cluster then really is "under the hood" from the user's perspective.

That's the option described in the alternative solution. I feel a true native pull-based ingestion built into the cluster with a separate engine will achieve much better performance, as we already observed this in Uber production. We also use an ingester similar to logstash to ingest from Kafka into Elasticsearch. From our benchmark, the native pull-based ingestion not only showed much better ingestion throughput, but also reduced the significant cost by removing the compute resources of the ingesters.

@yupeng9 I'm referring to how the data gets into the event stream (Kafka) in the first place. Users will likely need support for things like filtering, enriching, transforming, etc and that would be provided by a tool like data prepper, which would then write to the event stream. How the server pulls data from that event stream (i.e. either solution you described in the doc) becomes an implementation detail for the user as the front end API is the same no matter what. Does that make sense?

Can we keep the queue stuff "under the hood" as much as possible from the OS cluster's perspective?

I see this as an opportunity to lean into data prepper (or other ingestion tools) as the front door for end users. These tools allow for more sophisticated and flexible features as compared to what is possible to do in an indexing coordinator inside the cluster itself. The specifics of how that ingestion tool sends data to cluster then really is "under the hood" from the user's perspective.

That's the option described in the alternative solution. I feel a true native pull-based ingestion built into the cluster with a separate engine will achieve much better performance, as we already observed this in Uber production. We also use an ingester similar to logstash to ingest from Kafka into Elasticsearch. From our benchmark, the native pull-based ingestion not only showed much better ingestion throughput, but also reduced the significant cost by removing the compute resources of the ingesters.

@yupeng9 I'm referring to how the data gets into the event stream (Kafka) in the first place. Users will likely need support for things like filtering, enriching, transforming, etc and that would be provided by a tool like data prepper, which would then write to the event stream. How the server pulls data from that event stream (i.e. either solution you described in the doc) becomes an implementation detail for the user as the front end API is the same no matter what. Does that make sense?

I see. I think that's a separate problem, and a nice thing about streaming system is to decouple the producers and  consumers (i.e. OpenSearch). In the industry, there are various ways to produce to the streaming system. Streaming processing systems like Flink, Samza, Storm can be used for such filtering, enriching, and other kinds of preprocessing. And yes, data prepper is also one of them that can be enhanced for more native support.

a nice thing about streaming system is to decouple the producers and consumers (i.e. OpenSearch)

Agreed! The point I'm making is that the way you keep the queue functionality "under the hood" is offering an end-to-end solution coupled with a producer. The OpenSearch Project could offer a complete, easy-to-use solution using data prepper. Managed vendors could offer solutions that make sense in their ecosystem. Companies like Uber would have the flexibility to integrate OpenSearch into existing systems that have completely different producers.

a nice thing about streaming system is to decouple the producers and consumers (i.e. OpenSearch)

Agreed! The point I'm making is that the way you keep the queue functionality "under the hood" is offering an end-to-end solution coupled with a producer. The OpenSearch Project could offer a complete, easy-to-use solution using data prepper. Managed vendors could offer solutions that make sense in their ecosystem. Companies like Uber would have the flexibility to integrate OpenSearch into existing systems that have completely different producers.

Yes, makes a lot of sense. I believe lots more can be built/extended upon this feature

Data Prepper today supports OpenSearch API termination and an Apache Kafka based persistent buffer. Hence, while managed vendors could offer solutions that bakes other streaming offerings like Kinesis, Google Pub Sub, Red Panda etc, it makes sense for the OpenSearch Project to offer Data Prepper as a first class citizen for pull based indexing. With the OpenSearch API termination in Data Prepper, clients do not even need to updated and the same HTTP push request can be intercepted by Data Prepper. This can then be written to the Kafka topics in Data Prepper and the shards can use the pull based indexing to read the data from Data Prepper. The other advantage is that Data Prepper already has native connectors to Kinesis, dynamoDB, Mongo, S3 and also supports ingesting data from HTTP clients like FluentBit/FluentD and also Otel shippers.

Updated the design doc with the latest architecture and implementation details.


Create / View / Close / Update / Add WIs to Iterations

Reference: 1608V064
Epic: just a placeholder for a series of stories:

Create / Update Iterations (Name, Time Interval)
Add / Remove WIs to Iterations (1:n only for now)
Close Iterations (moving of WIs?)

Closing due to dupe for #378


Change output file extension to '.jsx'

Let's keep it opened and see if other people want this feature.


Type.GetMember() returns nondeterministic orderings of fields/members

see: https://github.com/mbraceproject/FsPickler/issues/92

Looks like there are failing tests in mono

strange, on my local machine it works (arch linux, mono 5.0.0)

travis seems to be running 5.2. Maybe it's a new mono bug?

thanks. seems you fixed the mono problem? what was the problem?

Looks like HashSet serialization was broken in 5.2


Arrays, AST–model type split, and general type system churn

I recommend merging #100 first.  This PRQ is based on top of and thus includes #100.
This fairly big PRQ implements arrays for Starling.  It also splits a lot of the type system logic previously shared by the AST and Starling core for cleanliness, and pushes through a few type system overhauls to allow lvalues to be things other than variables.

modulo horrible bug, this is good to go :shipit:

can I merge this?


Possible optimization for RTSP-TO-RTSP restreaming

Use https://github.com/aler9/rtsp-simple-proxy restreamer if source URL is a "rtsp://" source.
May optimize CPU usage. Must be tested thou.

closed by tag 2.1.0


Implement GTG Integrals

@sunqm We are interested in using and implementing the Gaussian type geminal integrals below.

We would like to use these integrals to separate out long and short range Coulomb interaction.
These integrals have been widely used in previous F12 calculations, and we know that the they are implemented in the libint package by Ed Valeev.
We assume that this would be easy to implement in libcint. We are open to implementing these integrals ourselves, but it might be very little effort for you to implement them.
Is this something you would be interested in? Or, do you any suggestions for us to implement them?

It's not difficult to implement the two integrals.  Particularly, the second integral can be implemented quickly with small modification to the code.

I got the coul_gtg integrals working in PySCF after your commit today.
Thanks Qiming!

Also I'm not sure if it's better to have the GTG integrals in the same file as the other F12 methods (STG and YP), since they're all F12 integrals.
The environment variables (PTR_F12_ZETA and PTR_GTG_ZETA) and naming conventions (g2e_f12 and  g2e_gtg) may confuse people down the road.

I don't recommend to use this function for now.  It does not yet fully agree to
the tests by numerical integration.
Qiming
On Thu, Oct 05, 2017 at 04:51:51PM -0700, Jordan Garside wrote:

I got the coul_gtg integrals working in PySCF after your commit today.
Thanks Qiming!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.*

--
Dr. Qiming Sun
Division of Chemistry and Chemical Engineering
California Institute of Technology
www.sunqm.net

Ok, thanks for the heads up.

will not supported in released version


Stray installed directories

When installing pz-rail-hub I get several packages which look like they should be sub-packages installed directly to the base site-packages directory.
They are:
docs
examples
scripts
tests

From looking at them I assume they shouldn't be installed at all.

It looks like the examples direcrory is expected by BPZ. So should presumably be installed, but somewhere under rail.

I'd have to check to be sure it's the same problem, but I think that's actually from the installation of pz-rail (probably as as rail-hub dependency), and is due to how we have RAIL structured and where we have package_data stored.  I had to similarly restructure the DESC_BPZ package because it was copying package data from top-level directories rather than from within desc_bpz.
I will create an issue for this if Joe doesn't beat me to it.


Debug N PHP applications: step over jumps to wrong one

Refs: https://github.com/Microsoft/vscode/issues/6160
If you debug multiple PHP scripts at once, and step over a line in the one script, the other script gets revealed in the stackframe view.

This is happening because the php adapter is first sending a stopped event before the response for step returns. I have created an issue for the PHP adapter here https://github.com/felixfbecker/vscode-php-debug/issues/37
Previously we had a workaround that would prevent this issue, but we have remoed this workaround due to other issues https://github.com/Microsoft/vscode/issues/5966

@isidorn would appreciate if @weinand could verify on your machine because I am out until next week

@bpasero there is still nothing to verify since we depend on the PHP debugger on this one

Ah ok.

assigning for verification back to @bpasero


No Cell object

the library from pip does not appear to have the Cell object included. I get an error whenever I try and run a script with WiFi.Cell saying that Cell is not in the module. help?

can you post the relevant part of your code?

Just this one line of code generates an error:

And this is the wifi package after I did "pip install wifi"

I see that you have a wifi/detect/detect.py file, it's possible that there is interference between the wifi directory in your project and the wifi library as installed.

Even if that is the package directory of my project? detect.py is the module where my code is going

I think that Eclipse is the recognizing the Python library just not the scan. py module which contains the code for the Cell class. I tried WiFi scan and it worked so I'm confused why the library won't work

Maybe you could try to rename your wifi/ directory to something else to see if it is indeed the problem.
If you are comfortable with pdb, you could also try that.

Hi,
Can you pay your code please
-rocky
2015年7月20日 上午5:04于 "Max K"<EMAIL_ADDRESS>
the library from pip does not appear to have the Cell object included. I
get an error whenever I try and run a script with WiFi.Cell saying that
Cell is not in the module. help?
—
Reply to this email directly or view it on GitHub
https://github.com/rockymeza/wifi/issues/71.

Post*
-rocky
2015年7月20日 上午7:21于 写道：
Hi,
Can you pay your code please
-rocky
2015年7月20日 上午5:04于 "Max K"<EMAIL_ADDRESS>the library from pip does not appear to have the Cell object included. I
get an error whenever I try and run a script with WiFi.Cell saying that
Cell is not in the module. help?
—
Reply to this email directly or view it on GitHub
https://github.com/rockymeza/wifi/issues/71.

No its just that code that didnt work I made sure to try out the WiFi library before anything else and when I tried using the scan module I got that error there is no other code yet but there will be :)

So I created a new project without the /wifi/detect/ package and it worked 100%. I realize now that the src  folder of the project was added to the python path and it was using itself as the wifi package. Thanks so much it works great now!


Changelog??

Where is the changelog of each updates you releasing now?

As the plugin is currently in fast flux and very new, changelogs won't be provided but you can get an idea of what has been changed through the commit list.


[Feature Request]: amd64 AppImage or tarball?

Preflight Checklist

[X] I have read the Contributing Guidelines for this project.
[X] I agree to follow the Code of Conduct that this project adheres to.
[X] I have searched the issue tracker for a feature request that matches the one I want to file, without success.

Problem Description
Would it be possible to build and provide an AMD64 AppImage or tarball?
I've been able to expand the x86_64 AppImage (possibly under Linux) and run the binary from the resulting directory on a "BrunchBook", that is, a generic amd64 PC running ChromeOS. You need to tell Electron to use Wayland instead of X11, but then it works.
I'm assuming it should work on an official ChromeBook too, and I now have one of those (but with an ARM64 CPU).
Proposed Solution
Please see the description.
Alternatives Considered
Installing "Crostini". For now I've decided against that because it's basically a VM that comes with performance issues, doesn't provide access to all hardware (camera...!) and requires installing a full additional Linux distribution on a device that probably already has limited space (32Gb in my case).
Additional Information
No response

thanks for the suggestion @RJVB . Since we use electron-builder under the hood for packaging ferdi, this needs to be supported by them. The options that they support can be found here

The way I read that is that the AppImage is built for the current architecture, and that's apparently something that can be set in the invocation (cli argument).
I was assuming (rather naively) that the existing non-Intel builds are generated on the corresponding hardware, but I realised that cross-compilation may come out-of-the-box with NodeJS?
Do the .deb files contain the same, standalone payload? If so I could try to unpack the ARM64 one and see I can do something with that?


Customer chatbot

API entry point
https://calm-violet-6179.ploomberapp.io/docs

📚 Documentation preview 📚: https://ploomber-doc--90.org.readthedocs.build/en/90/

after trying again, I got this other error:

It's unclear what type of questions can be asked. For the below queries it responds with another query:

Also, can we build a simple UI interface ?

after trying again, I got this other error:

I tried the same question and it worked ok
Redeploying currently

It's unclear what type of questions can be asked. For the below queries it responds with another query:

Also, can we build a simple UI interface ?

Added description to app
https://github.com/ploomber/doc/blob/f5058a69481a77e0f4034c67f1714b39e41f8cc3/examples/docker/fastapi-ai-helper/app.py#L12
I have been deploying solara apps the last 2 weeks, I wanted to deploy an API as the API may be used in non-python based websites

@edublancas
Redeployed, please give it a few minutes and let me know if the issue persists

Redeployed
https://calm-violet-6179.ploomberapp.io/docs
If this looks good I will make the changes to the blog

@lfunderburk please keep your commits short. otherwise, if you answer the observations with a commit that has tons of modifications, it takes more time to review them

Ok can do


Deprecating connectAdvanced

I intend to remove the connectAdvanced API from React Redux, essentially replacing connect with its contents.
Why? It's an abstraction that we don't use ourselves, so it just becomes an indirection in the code. It is only minimally used in the community. It creates a more complex code base, which is a barrier to entry for many contributions. Plus, frankly, I just don't like it; it gives me Java flashbacks.
This is mainly to give the few folks that do use it a heads up. It won't go away until the next major release. However, I intend to add a deprecation warning at some point in the future. We'll do that after Hooks, just so we're not dropping two big changes in one minor release. Plus, you can lock to that version to have your Hooks and your connectAdvanced at the same time. Sound fair?
If there are specific use cases, we can see about migrating them into the connect API, most likely as options. This isn't about completely throwing away a big chunk of functionality, just simplifying the code base a bit and making it easier to grok for everyone.

👍 I could never understand what it does or why it was added. It sounds like if you need this kind of complexity you should just vendor the connect code and maintain it yourself.

FWIW, the intended use case is for an end user to be able to customize how all the memoization and prop generation is handled, on their own.  All the logic for managing the subscription itself stays the same - it's really just changing from calling mapState and mapDispatch specifically, to (storeState, dispatch) => childProps, and connect implements its mapState/mapDispatch handling as one possible (storeState, dispatch) => childProps function.
If y'all are really dead set on removing it, we can, but I truly don't think it adds that much extra complexity.
Lemme tag three folks who I know have a particular interest in this: @jimbolla , @epeli , @mariusandra .

Bummed about this of course but I understand the reasoning and I can live with. Actually just realized I can achieve everything I want with the areStatePropsEqual option of connect().
Farewell advancedConnect().

This would be a bummer. Kea is basically built around it. I'll need to see if I can work around it and will provide a more insightful reply next week, as I'm literally boarding a plane for a weekend getaway now.
Cheers!

I'm not using Redux so I don't have an opinion on this.

Hey, after tinkering a bit with the code (read: totally rewriting Kea), I no longer need connectAdvanced.
Now that I worked with the code again, I remember why I used it in the first place: I was being sneaky, grabbed the dispatch that was given to selectorFactory and used it to initialise the redux store under certain conditions. I remember I couldn't find any other clean way to directly get dispatch from the react-redux API without caching it on store creation, so I went with connectAdvanced. It simplified a few other things as well... and made many others way too complicated.
Now I bit the bullet and switched to just stealing the store from react-redux and using it directly to dispatch hydration actions in order to regenerate the store when a new reducer needs to be added. I'm not sure if dispatching actions to regenerate the store is better than using store.replaceReducer or not... but it has never caused issues so far.
The rewrite comes with many other changes, some of which are breaking, so it's not released yet. However I got all the tests to pass, so it shouldn't be too long now. I still need to rearchitect the plugin system, integrate thunks and sagas and test it on my own app before I'm ready to release it into the wild.
Thanks for the push guys! This rewrite was long overdue!

Well, based on those responses, it sounds like the primary folks who were using it have determined that they no longer need it.  I'd say that puts a nail in it.
(I still don't think there's going to be much actual difference as far as the internal code goes, given the way things are structured, but we'll see.)

Hi to all!
I think connectAdvanced is use full, basically connect a sliced to 3 part for work with redux and i think its like tricky. I used connectAdvancedaround in our project BUSFOR, and thats awesome:
export default connectAdvanced(dispatch => {
const {
getDeparture,
getArrival,
getError,
getAllSeatMapsAreFree,
getHasSomeSelectedSeat,
getPreparedSegments,
getTripSegments,
getShortBadgeIconList,
} = createTripSelectors();
const getActions = createSelector(
({ tripId }) => tripId,
({ selectedSeats }) => selectedSeats,
({ bestPrice }) => bestPrice,
(tripId, selectedSeats, bestPrice) => bindActionCreators({
onSubmit: () => submitTrip({ tripId, selectedSeats, bestPrice }),
onResendRequest: () => submitTrip({ tripId, selectedSeats, bestPrice }),
}, dispatch)
);
let result;
return ({ search }, ownProps) => {
const { trip, isFetching } = ownProps;
const { id: tripId, selectedSeats, bestPrice } = trip;
const error = getError(trip);
const isOpen = has('isOpen', ownProps) ? ownProps.isOpen : !isFetching && search.openTrip === trip.id;
const isSeatsUnavailable = false;
const stateProps = ({
  isOpen,
  isSeatsUnavailable,
  isSeatsFetching: trip.seats.fetching,
  isSubmitting: !error && trip.isSubmitted,
  departure: getDeparture(trip),
  arrival: getArrival(trip),
  points: getTruePoints(trip.points),
  segments: getPreparedSegments(trip),
  tripSegments: getTripSegments(trip),
  badgeList: getShortBadgeIconList(trip),
  areAllSeatMapsFree: getAllSeatMapsAreFree(trip),
  hasSomeSelectedSeat: getHasSomeSelectedSeat(trip),
  error,
  price: trip.price,
  passengersCount: getPassengersCount(search.passengers),
  passengersWithSeatsCount: getSeatsCount(search.passengers),
  passengersWithoutSeatsCount: getNoSeatsCount(search.passengers),
  childrenSeatsCount: getChildrenSeatsCount(search.passengers),
  ...getActions({ tripId, selectedSeats, bestPrice }),
});

const nextProps = {
  ...ownProps,
  ...stateProps,
  dispatch,
};

if (!equals(result, nextProps)) {
  result = nextProps;
}

return result;

};
})(Trip);
`
For my think, it`s cleaner way to put some date from store\from view into Actions.
Or mb i do something wrong?
PS: and no need it more selectors func from reselect, so i do my self with equals of next props

@flipmotion : would one of the other options for customizing connect's comparisons work for your situation?

@markerikson : I think it could be, but it’s, again, more useless code. In ‘connectAdvanced’ it better cuz ur get all props from state, from component it one place, and if u need just 2-3 things, it’s more simple. Again i create selectors for data in first call, then i can combine it in second calling with some storeProps and OwnProps. And the same with actionCreators like with computed data selection. And this do in one place, without cutting it for other functions in connect options.
‘const mapDispatchToProps = (dispatch) => {
return {
dispatchSave: (items) => dispatch({type: "SAVE_ALL", items})
};
}
const mergeProps = (propsFromState, propsFromDispatch, ownProps) {
return {
save: propsFromDispatch.dispatchSave(propsFromState.items)
};
};
const SaveAllContainer = connect(mapStateToProps, mapDispatchToProps, mergeProps)(SaveAll)’
i think it more boilerplate then connectAdvanced
like i in my previous post when i can put some data from store and ownProps in actionCreator in one simple way
I understand that this is a trick, but I am aware of my actions. I consider it a very simple and effective solution.
or o do something wrong? Thx

Connecting Deck.gl layers is very convenient with connectAdvanced. Layer classes can't be wrapped directly with connect because they are not React components. To create them you can leverage connectAdvanced's feature of getting dispatch and state in one function.
const selector = dispatch => {
  const actions = mapDispatchToProps(dispatch);
  const getLayers = createLayersSelector(
    dispatch
  );

  return (nextState, nextOwnProps) => {
    const nextProps = mapStateToProps(nextState, nextOwnProps);
    const layers = getLayers(nextState, nextOwnProps);
    return {
      ...actions,
      ...nextProps,
      layers
    };
  };
};

layers selector:
export default dispatch => {
  const getData = (state) => state // there you can prepare selector

  return createSelector(
    [getData],
    (data) => {
      return [new PointsLayer({
        data,
        onClick: bindActionCreators({ someAction }, dispatch) // there you need dispatch
        // other layer props
      })];
    }
  );
};

Such approach allows you to split layer creation to different files and keep each layer near to it's own selectors. I can't see how presented solution (or similar) may be achieved with mergeProps from connect.

I would suggest that you add a deprecation note in the connectAdvanced's documentation, to prevent people, new to react-redux, from using it.
https://react-redux.js.org/api/connect-advanced

If we are deprecating it, could we add ownProps as an argument to the areStatesEqual option please ? I was hoping to use connectAdvanced to get around ownProps not being passed to areStatesEqual.
This was previously asked in this and there was also a PR.

Hello what is the final decision being made ? Is connectAdvanced going to be deprecated ?
Based on this thread it seems to be the case, but just needed confirmation that it is going to be deprecated.

Hello what is the final decision being made ? Is connectAdvanced going to be deprecated ?
Based on this thread it seems to be the case, but just needed confirmation that it is going to be deprecated.

Oh, it's very deprecated now that the hooks API exists.

Oh, it's very deprecated now that the hooks API exists.

Ok understood. Thanks. But will it actually be deleted from the code and connect used instead ?
I believe no, as for class components no further work is going to be done except bug fixes and minor fixes.
Its still gonna remain then as it is right now ?

Ok understood. Thanks. But will it actually be deleted from the code and connect used instead ?
I believe no, as for class components no further work is going to be done except bug fixes and minor fixes.
Its still gonna remain then as it is right now ?

No changes for the lifetime of the v7.x branch.
When we finally get around to doing a version 8, we will definitely still have connect - I just expect the internal implementation to be consolidated so there's no separate connectAdvanced.
No concrete plans for a version 8, yet, but I expect that we'll tackle it once Suspense and Concurrent Mode are finally done and the useMutableSource hook is released to production.

No changes for the lifetime of the v7.x branch.
When we finally get around to doing a version 8, we will definitely still have connect - I just expect the internal implementation to be consolidated so there's no separate connectAdvanced.
No concrete plans for a version 8, yet, but I expect that we'll tackle it once Suspense and Concurrent Mode are finally done and the useMutableSource hook is released to production.

Alright Mark, thanks for providing a detailed update.

once Suspense and Concurrent Mode are finally done

This seems interesting. Any blog post and/or WIP branch where I can know more about this effort ?

Alright Mark, thanks for providing a detailed update.

once Suspense and Concurrent Mode are finally done

This seems interesting. Any blog post and/or WIP branch where I can know more about this effort ?

Just the React repo, really.
I'm sure once CM/Suspense are truly "done" there will be a post on the React blog announcing that.

Just the React repo, really.
I'm sure once CM/Suspense are truly "done" there will be a post on the React blog announcing that.

oops my bad. Got confused. I thought React-Redux was doing some specific work for Suspense and concurrent mode support haha.

oops my bad. Got confused. I thought React-Redux was doing some specific work for Suspense and concurrent mode support haha.

the useMutableSource hook is released to production

And what about class components 😕 ? I didn't see any plans anywhere to expose such an API for class components.

the useMutableSource hook is released to production

And what about class components 😕 ? I didn't see any plans anywhere to expose such an API for class components.

I'm not sure what you're asking here.
useMutableSource is an as-yet-unreleased React API that will allow external state management tools to better integrate with Concurrent Mode.
The React team is definitely not adding any new features to support class components.
As for React-Redux, connect itself was reimplemented as a function component in v7, and uses hooks inside.
I'm not entirely sure if we'll be able to fully rework connect to use useMutableSource inside or not, or whether it'll only be useSelector that can benefit.  Won't know until all this stuff is actually finalized and available for us to use.
As I said, questions like this are best suited for the React repo, not here.

I'm not sure what you're asking here.
useMutableSource is an as-yet-unreleased React API that will allow external state management tools to better integrate with Concurrent Mode.
The React team is definitely not adding any new features to support class components.
As for React-Redux, connect itself was reimplemented as a function component in v7, and uses hooks inside.
I'm not entirely sure if we'll be able to fully rework connect to use useMutableSource inside or not, or whether it'll only be useSelector that can benefit.  Won't know until all this stuff is actually finalized and available for us to use.
As I said, questions like this are best suited for the React repo, not here.

yes yes sure. sorry about that. will try to find some other forum for that. I was asking because my app is using class components and connect API, as we are using Redux for state management . So was wondering if we would be able to use concurrent mode without big refactorings like changing components to hooks etc. I will wait for the concurrent mode to be "done" from the React team in that case to get a clearer answer.

yes yes sure. sorry about that. will try to find some other forum for that. I was asking because my app is using class components and connect API, as we are using Redux for state management . So was wondering if we would be able to use concurrent mode without big refactorings like changing components to hooks etc. I will wait for the concurrent mode to be "done" from the React team in that case to get a clearer answer.

Update: I've just put up #1771 , which does actually remove the connectAdvanced export and implementation entirely. There's now just a single function, named connect.
The PR is a draft atm, but I intend to merge it after the TypeScript port in #1739 gets merged into master.

And this API is now gone as of v8.0.0-alpha.0!


Missing error code when " Backend API Definition is not available for the API "

APIM-CLI version
1.14.2
API-Management version
7.7.20231130
Bug description
When exporting to json,for error:
2024-03-11 20:08:22,804 [JsonAPIExporter] ERROR: Backend API Definition is not available for the API : (TEST) BusinessPartner Data API, hence use the option -useFEAPIDefinition to export API
Exit code is 0
Steps to reproduce
No response
Relevant log output
No response

Hi @emmanuel-galindo,
The api get operation can retrieve more than one APIs (except fetching based on id) and CLI tries to export everything. If one the api does not have backend api definition, it prints an error message and continues processing the next api.
We can throw an error if we are getting api based on ids. do let me know what you think?

yup, for id it makes sense, or when the selection of apis is just 1 api ?
if not parsing stdout, i wouldn't know how to detect this issue


Question About Training Consistency and Random Seed Effects

Hello, thank you very much for your work. I noticed that if I train twice using the same configuration, I get different training results. Is this due to the setting of the random seed?
If I want to fix the random seed, is it sufficient to set “seed = a number” in the config? Will this ensure that the results of the two training sessions are the same?
If using an unfixed random seed, how do you determine whether the improvement in results is due to the new module added to the network or just the difference in random seed?
Thank you very much for your explanation.

Hi, I think it is very hard to fix training results with the same random seed for many 3D operators like SpConv. It is common that two runs get different results. I suggest that don't care too much about that.

Hi, I think it is very hard to fix training results with the same random seed for many 3D operators like SpConv. It is common that two runs get different results. I suggest that don't care too much about that.

Thank you for your response. Now, I train 2-3 times and take the average to evaluate the performance.

Hi @xiaosa269 thank you for the question. Do you remember how big your differences were when you set different random seeds?

Hi, I think it's pretty common to observe a 1-2% variation with different random seeds when training a 3D backbone from scratch. This is mostly due to the small scale of 3D data. However, using techniques like PPT (multi-dataset joint training) can make the results more stable, although they are still not entirely consistent.
We are currently working on a self-supervised PTv3 model, which is powerful and achieves strong results even with linear probing. These results are very stable and perform well on datasets with an extremely small data scale. Please look forward to the next update of Pointcept, expected around the end of this year.

Hi, I think it is very hard to fix training results with the same random seed for many 3D operators like SpConv. It is common that two runs get different results. I suggest that don't care too much about that.

Thank you for your response. Now, I train 2-3 times and take the average to evaluate the performance.

I usually run 2-3 times and take the maximum as the final result

Hi @xiaosa269 thank you for the question. Do you remember how big your differences were when you set different random seeds?

Hello, I trained on my own small dataset, and the differences are not significant. The largest mIoU difference does not exceed 1%。

Hi, I think it is very hard to fix training results with the same random seed for many 3D operators like SpConv. It is common that two runs get different results. I suggest that don't care too much about that.

Thank you for your response. Now, I train 2-3 times and take the average to evaluate the performance.

I usually run 2-3 times and take the maximum as the final result

I’m also using this strategy now, looking forward to the next update of Pointcept.

Hi @xiaosa269 thank you for the question. Do you remember how big your differences were when you set different random seeds?

Hello, I trained on my own small dataset, and the differences are not significant. The largest mIoU difference does not exceed 1%。

Good to hear that.

Hi, I think it is very hard to fix training results with the same random seed for many 3D operators like SpConv. It is common that two runs get different results. I suggest that don't care too much about that.

Thank you for your response. Now, I train 2-3 times and take the average to evaluate the performance.

I usually run 2-3 times and take the maximum as the final result

I’m also using this strategy now, looking forward to the next update of Pointcept.

Working on this now. We will soon release a super powerful self-supervised model, and the weight should be available in January of next year after some reviewing process.


Account email fetch

Fetch inbox by state

Inbox not fetched (new account)

get the first 100 message pages and loop through the inbox

Fetching inbox

check the last fetched page and start from there

Inbox fetched

check the last fetch was more than 24h ago. Get messages after the last fetch.

Updating (fetching new messages)

check the last fetch was more than 24h ago. Get messages after the last fetch.

Updated (fetched less than 24h ago)

do nothing

Move to data fetch service with last_fetched_date and page


feat(next-queries): update endpoint

In order to test this PR you need to made a build in the mono repo, add the following code in the package.json, and install dependencies:
"install:local": "npm install file:../../x/packages/x-components/empathyco-x-components-3.0.0-alpha.39.tgz file:../../x/packages/search-adapter/empathyco-x-adapter-7.0.0-alpha.8.tgz file:../../x/packages/search-types/empathyco-x-types-10.0.0-alpha.13.tgz --no-save",

EX-5198

On test everything seems to be fine. However, looks like the new endpoint is not available on staging. I don't know wether this is expected or not.

Yeah, the same history again and again, we can't do nothing about it.


Debugger doesn't break on breakpoints if pubspec contains a builder section

Steps to Reproduce
Add this here to any flutter project and try to break at a breakpoint.
builders:
  jaguar_serializer_cli:
    git:
      url: https://github.com/Jaguar-dart/jaguar_serializer.git
      path: serializer_cli

Expected results:
It breaks
Actual results:
it doesn't,
I tried it with all channels form current stable to master and it happens on all of them.
I'm now on:
[√] Flutter (Channel master, v1.14.7-pre.120, on Microsoft Windows [Version 10.0.18362.592], locale de-DE)
    • Flutter version 1.14.7-pre.120 at C:\Entwicklung\flutter
    • Framework revision 82c00c915c (2 hours ago), 2020-02-05 06:35:49 -0800
    • Engine revision 81dffd1241
    • Dart version 2.8.0 (build 2.8.0-dev.7.0 c8ed304e97)

[√] Android toolchain - develop for Android devices (Android SDK version 29.0.2)
    • Android SDK at C:\Users\escam\AppData\Local\Android\sdk
    • Android NDK location not configured (optional; useful for native profiling support)
    • Platform android-29, build-tools 29.0.2
    • Java binary at: C:\Program Files\Android\Android Studio\jre\bin\java
    • Java version OpenJDK Runtime Environment (build 1.8.0_202-release-1483-b03)
    • All Android licenses accepted.

[√] Chrome - develop for the web
    • Chrome at C:\Program Files (x86)\Google\Chrome\Application\chrome.exe

[√] Visual Studio - develop for Windows (Visual Studio Community 2019 16.4.3)
    • Visual Studio at C:\Program Files (x86)\Microsoft Visual Studio\2019\Community
    • Visual Studio Community 2019 version 16.4.29709.97

[√] Android Studio (version 3.5)
    • Android Studio at C:\Program Files\Android\Android Studio
    • Flutter plugin version 39.0.3
    • Dart plugin version 191.8423
    • Java version OpenJDK Runtime Environment (build 1.8.0_202-release-1483-b03)

[√] IntelliJ IDEA Community Edition (version 2018.2)
    • IntelliJ at C:\Program Files\JetBrains\IntelliJ IDEA Community Edition 2018.2.5
    • Flutter plugin version 29.1.3
    • Dart plugin version 182.4892.25

[√] VS Code, 64-bit edition (version 1.41.1)
    • VS Code at C:\Program Files\Microsoft VS Code
    • Flutter extension version 3.8.0

[√] Connected device (4 available)
    • SM F907B   • R3CM90AK4KM • android-arm64  • Android 9 (API 28)
    • Windows    • Windows     • windows-x64    • Microsoft Windows [Version 10.0.18362.592]
    • Chrome     • chrome      • web-javascript • Google Chrome 79.0.3945.130
    • Web Server • web-server  • web-javascript • Flutter Tools

• No issues found!

I guess that will be interesting for you  @jonahwilliams
This was reported on the Dart Code plugin but got somehow lost
https://github.com/Dart-Code/Dart-Code/issues/1976

Right now with flutter generate, I try to support builders which build to cache and not just source. To do so requires the use of a multiroot scheme - this also stops breakpoints from working.
Since there don't seem to be any builders (Besides angular) using build to cache, we could remove this feature and breakpoints would probably work as is.

Since there don't seem to be any builders (Besides angular) using build to cache

What do you mean by "cache" here?
Because if it's about build_to: source vs build_to: cache inside the build.yaml of code-generators, then I'm surprised by that statement.

Can you link to some of those builders? I would imagine if they are not already using the builders: key then they must be creating merged output directories.

Pretty much all generators that depends on source_gen/SharedPartBuilder
Some popular names:
mobx_codegen, functional_widget, built_value, json_serializable
There are many more.

Are they using a merged output directory in instructions?

I do not know what that means

Actually, let me try to answer (feel free to ignore this if I'm off-topic):
They do rely on a temporary directory where all the generated source is located.
The builders don't generate the .g.dart directly next to the source.
Instead when using SharedPartBuilder, then generate a .my_library.part somewhere inside the .dart_tool/ folder.
Then SharedPartBuilder merges all these *.part files into a single .g.dart next to the source.
So my theory is:

if the problem is caused by "trying to handle .dart files inside the .dart_tool folder", then breaking it should be fine since these generators don't output actual Dart files in that folder.
if the problem is "trying to handle anything that may output in .dart_tool", then that may be a problem

I'm not sure what really is the issue though.

Thanks for the information @rrousselGit
The multiroot scheme would only be required if the final dart file was produce in .dart_tool and it sounds like that isn't the case. The SharedPartBuilder will continue working in this case

If you're interesting, the change is pending at https://github.com/flutter/flutter/pull/50284 and could otherwise be tried out

Fixed via  #50284


Problem: sim tests are fail

thanks for the PR
If you want to backport to cronos which still use cosmos sdk 0.46. we can also backport this fix to the branch "v2.0.0-cronos-sdk-0.46" and use this branch in cronos

thanks for the PR
If you want to backport to cronos which still use cosmos sdk 0.46. we can also backport this fix to the branch "v2.0.0-cronos-sdk-0.46" and use this branch in cronos

Thanks, I can try.


[chore] Add testing configuration

This repository has no tests because it is only a probe of concept. However, it is now a good starting point to create jest configuration and npm commands.

[x] Create jest environment
[x] Add npm commands
[x] Add coverage configuration
[x] Create first tests

This PR closes this issue.


Tutorial style tweaks

A few tweaks to /tutorial styles:

Use font-size: 16px on mobile
Use a better color for comments
There was an inline display:none that was blocked by our content-security policy on Netlify; this is now in site.css
Moved the table of contents toggle next to the "Tutorial" heading so it's only on /tutorial and not in the site-wide nav bar
Went back to the previous header and background colors; after looking at it both ways, I think the docs pages should actually adopt these styles rather than the other way around! 😃

FYI @georgesboris!


Fun isConnected() returns false on LAN WiFi

I am using konnection on android for checking connection state. But it keeps returning false on isConnected() and observeHasConnection() while connecting to a LAN only WiFi. And getCurrentNetworkConnection() returns null.

Hi @OumaSyuu , so your device is connected to a Wifi network, but this network has no Internet Connection?


Cirrus: Change us-central1-a -> us-central1-f

Currently that zone is experiencing capacity overages, causing VM
creation to stall and timeout.  Reported issue to cirrus-support,
they recommended switching to us-central1-f (and they tested it).
This commit makes all the necessary changes to switch zones.
Signed-off-by: Chris Evich<EMAIL_ADDRESS>

@mheon @baude okay, this will fix cirrus-ci (for now).  Unknown if we'll need to change it back later.

/approve
LGTM

Note: This PR is optional.  It seems there was an actual problem (google was very late to report it):
https://status.cloud.google.com/incident/compute/18012
I don't think there's harm either way (merge or not).


[TEST] Update regression job K8S_DISTRO_VERSION and LONGHORN_STABLE_VERSION parameter

What's the test to develop? Please describe
Currently, we are using k3s v1.28.4 to test our environment.
However, newer versions are available, with k3s v1.29.2 for version 1.29
We need to update the regression job parameters to accommodate the new versions of k3s and Rke2. These updated parameters should ensure that Jenkins jobs function correctly with the latest versions.
Describe the tasks for the test

[ ] Update regression job parameters for k3s and Rke2 versions.
[ ] Verify that all Jenkins jobs perform as expected with the latest versions.

Additional context
https://github.com/longhorn/longhorn/issues/8191#issuecomment-2008577197

Hi @innobead :
According to our previous discussions, we will update the k8s version one month before the master-head branch release. I found out that k3s and rke2 released v1.30 three weeks ago. Currently, we are using v1.28 for v1.6.x and v1.29 for master-head (v1.7.x). Should we continue with v1.30, or should we update to the latest version of v1.29 for master-head (v1.7.x)?
cc @derekbit @longhorn/qa


Can not find the Munchausen  SAC!

thank you for sharing! I cannot find the  Munchausen SAC. but the last picture show the results of M-SAC

Have you find the M-SAC?


Add license requirement back

CTL is always a premium feature. The reference to Premium was removed from CTL in 2018 when we decided to deprecate it. Add it back to avoid additional confusion here.

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

Looks fine to me.  #sign-off


add tutorial for Teunis model

Added the markdown version of Teunis model with the case study using Woefel data.

What are your thoughts on adding the models to a models folder in the main repo? Then we can also run them against the most recent data whenever we make changes.


Update register-application and list-applications

Allow several TCP/IP addresses in /v1/register-application
/v1/list-applications to provide TCP/IP addresses for wished protocol
Fixes #186

shall we provide some default value for following attributes ,

This is a very good question, because it targets for harmonizing the application management interface with the device management interface.
I would propose sending an empty list.
The default value rule on the device management interface is a remaining of an era of mistrust and I would like to get rid of it rather sooner than later.
Maybe, we will reach convergence with the application management interface in future ONF TR-532 v3.0.

@openBackhaul  , Thank you for the detailed clarification regarding the list-applications responseBody.


(CC refactor 4) recovery: implement the loss detection timer as a struct

Merged as https://github.com/cloudflare/quiche/commit/bc952e8e09210d5b242640e3e6e56245cd780ded.


chore: adjust pool schema

Reason for This PR
Minor adjustments to the schema. Consistency, grammar and missing min/max value added. Added missing additionalProperties which is what highlights typos in config files.
License Acceptance
By submitting this pull request, I confirm that my contribution is made under
the terms of the MIT license.
PR Checklist
[Author TODO: Meet these criteria.]
[Reviewer TODO: Verify that these criteria are met. Request changes if not]

[x] All commits in this PR are signed (git commit -s).
[ ] The reason for this PR is clearly provided (issue no. or explanation).
[ ] The description of changes is clear and encompassing.
[ ] Any required documentation changes (code and docs) are included in this PR.
[ ] Any user-facing changes are mentioned in CHANGELOG.md.
[ ] All added/changed functionality is tested.

Summary by CodeRabbit

New Features

Introduced a supervisor property with constraints to enhance configuration.

Improvements

Updated descriptions and constraints for dynamic_allocator, max_workers, spawn_rate, and idle_timeout to clarify their intended use and limits.

Thank you, @nickdnk 👍🏻


[Bug]: narwhals.DataFrame.with_columns changes types for single row dataframes

Describe the bug
Example below of single row pandas df with categorical column 'a' being put through narwhals and returned with 'a' converted to float type, ideal behaviour would be for this to preserve type
Steps or code to reproduce the bug
import polars as pl
import numpy as np
import pandas as pd
import narwhals as nw

# setup single row with a null value (this will be inferred as float later)
pandas_df=pd.DataFrame({'a': [np.NaN]},)
# convert a to category type
pandas_df['a']=pd.Categorical(pandas_df['a'], categories=['dummy_value'])

narwhals_df=nw.from_native(pandas_df)
# reassign a to itself (appreciate this step looks odd, but has been stripped back to be minimal,
# in practice we would be doing something more like `narwhals_df.with_columns(nw.col('a').fill_null('dummy_value')`
# and hitting same issue
narwhals_df=narwhals_df.with_columns(nw.col('a'))
print(narwhals_df.to_native().dtypes)

# Outputs:
# a    float64
# dtype: object

Expected results
return column with preserved category type
Actual results
returned column is converted to float type
Please run narwhals.show_version() and enter the output below.
System:
    python: 3.9.18 (main, Sep 11 2023, 14:09:26) [MSC v.1916 64 bit (AMD64)]
executable: c:\Miniconda\python.exe
   machine: Windows-10-10.0.17763-SP0

Python dependencies:
     narwhals: 1.9.2
       pandas: 2.0.3
       polars: 1.9.0
         cudf:
        modin:
      pyarrow: 17.0.0
        numpy: 1.24.4

Relevant log output
No response

thanks @limlam96 , this is due to validate_dataframe_comparand trying to do broadcasting - will address

this is fixed in the latest release, now on PyPI (and probably later today on conda-forge)


Add a check for review commits that need to be squashed before merging the PR

Is this just for the automerge feature? Would you want this outside of the automerge feature at all?

automerge happens when an owner gives an LGTM?

The owner has to explicitly tell dpebot, e.g. @dpebot LGTM or @dpe merge when travis passes. DPE squashs automatically, so would this be more useful as a status check?

That's assuming master wants each PR to convert into a single commit, though that isn't every repo's workflow (e.g. in gcloud-python the merge workflow is used rather than rebase / squash, hence each PR puts n commits and 1 merge commit into master)

Gotcha, so would you want depbot to look out for trigger phrases in commits and add a negative status check?

I'd suppose you could have the bot check for one of

a commit subject that starts with (or maybe contains?) [TO SQUASH] (case insensitive)?
a PR that has a specified "squash needed" label on it

Cool - that should be pretty doable.


Adding nativescript to an existing Angular 6 project

I've gone through the NS documentation, as well as other how-tos on the web, and cannot figure out how to add @nativescript/schematics to my existing angular 6 project, without it upgrading to Angular 7.  Unfortunately my project has external dependencies that prevent an upgrade to Angular 7.  I looked through the version history of @nativescript/schematics, but couldn't determine which one will force me to upgrade to NG7.  Any advice?

It looks like I can manually downgrade the version of nativescript-angular after adding the schematic to prevent the warnings about the angular version differences

Yeah, starting from Angular 7, we might add a map that will detect the version of Angular that you are using and apply the correct version of nativescript-angular and any relevant libraries.


bug: When using Crosswalk, ionic build breaks

Type: bug
Ionic Version: 2.x
Platform: android 4.4 webview
When using crosswalk, apks are built not as android-debug.apk and android-debug-unaligned.apk but as the following: android-armv7-....apk and android-x86-....apk
But when using the ionic build android CLI command the CLI still installs the old android-debug.apk file.
Therefore after installing crosswalk the user gets confused, because when running ionic build, the old apk keeps getting installed onto the app while the newly updated x86 and armv7 apks are not installed.

remove and re-add the platform

I had this problem. The way I solved this was, after I added crosswalk I removed all the generated apks from the platforms/android/build/outputs/apk folder. Once I did that, the correct generated build is getting installed. I hope this helps you out.
I don't know if this is a bug in Ionic. I think Ionic cli team will be able to comment on this.

This issue was moved to driftyco/ionic-cli#1390

Hello all, because this issue was related to the Ionic CLI and not the framework I have moved this issue to the appropriate repo. Thanks for using Ionic!