Times out after 10 retries

After using the token solve api via this extension it returns a timed out after 10 retries. It shows up in the activity monitor but doesn't get past the POST, it returns the data of the POST and gets stuck at the GET nor does it show the GET in the activity monitor leaving me to believe it's an API issue and not an extension. I have no idea where else to report this issue however.

No you don't. You are using the legacy V1 compat layer which doesn't support setting the subscription key the way you are doing. Read the README.

After using the token solve api via this extension it returns a timed out after 10 retries. It shows up in the activity monitor but doesn't get past the POST, it returns the data of the POST and gets stuck at the GET nor does it show the GET in the activity monitor leaving me to believe it's an API issue and not an extension. I have no idea where else to report this issue however.

https://nopecha.com/discord for support.


Moving from structopt to clap according to #68

This PR is regarding #68
I felt like it would have to be done some day, so here it is :smiley:

Certainly good to get out of the way - thank you!


Metal Interconnections retrieve fails with schema error

What problem are you facing?
While retrieving connections for a project, using endpoint https://api.equinix.com/metal/v1/projects/{project_id}/connections and below sdk, getting json unmarshalling error for speed parameter for the connection
apiClient.InterconnectionsApi.
	ProjectListInterconnections(context.Background(), project.GetId()).
	Execute()

Note: Any available value of the speed (ex: 5000000 etc) is provided, the error remains the same
Error:
json: cannot unmarshal number<PHONE_NUMBER>0 into Go struct field _InterconnectionList.interconnections of type int32

How could the Equinix Metal Go SDK help solve this problem?
There seems to be a mismatch in the schema validation on the server and published api doc. Need to fix the marshalling of speed parameter from the server

Copying these lines from https://github.com/equinix/equinix-sdk-go/pull/22#issuecomment-1900912753 for broader visibility:

It's worth noting that the VlanVirtualCircuitUpdateInput and VrfVirtualCircuitUpdateInput schemas specify that speed is a string, which makes sense for the inputs since we document those fields as accepting, e.g., 10Gbps, which is not an integer.

This was resolved in #34, which was included in the v0.34.0 release.


refactor(tests): if assert.* -> require.*. Fixes #13465

Fixes #13465
Motivation
Reduce unneeded nesting by changing if assert.* to require.*.
Modifications
Updated tests where if assert.* is used to require.*
Verification
Tests

There's a missing negative case

nice catch, I totally forgot about the negative cases!

I'll leave this for a day for @agilgur5 to look at as it was his idea.

I've gone through about half of it, feel free to merge if I don't get through the rest soon


Make sure DS extensibility is backwards compatible

This is a recreation of this pr here:
https://github.com/microsoft/vscode-python/pull/14486
Essentially making sure any extension that depended upon our DS extensibility API continues to work after we ship (example: AML extension)

[ ] Pull request represents a single change (i.e. not fixing disparate/unrelated things in a single PR).
[ ] Title summarizes what is changing.
[ ] Has a news entry file (remember to thank yourself!).
[ ] Appropriate comments and documentation strings in the code.
[ ] Has sufficient logging.
[ ] Has telemetry for enhancements.
[ ] Unit tests & system/integration tests are added/updated.
[ ] Test plan is updated as appropriate.
[ ] package-lock.json has been regenerated by running npm install (if dependencies have changed).
[ ] The wiki is updated with any design decisions/details.

Codecov Report

Merging #14527 into main will decrease coverage by 0.00%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             main   #14527      +/-   ##
==========================================
- Coverage   66.40%   66.40%   -0.01%
==========================================
  Files         534      534
  Lines       24461    24463       +2
  Branches     3436     3436
==========================================
+ Hits        16243    16244       +1
- Misses       7558     7559       +1
  Partials      660      660

Impacted Files
Coverage Δ

src/client/common/utils/platform.ts
68.00% <0.00%> (-4.00%)
:arrow_down:

src/client/telemetry/index.ts
78.12% <0.00%> (+0.46%)
:arrow_up:

Continue to review full report at Codecov.

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


Use atomicons for iconography

This PR uses the built in atomicon font, which has special icons for different programming language constructs.
These are private by default, which just means they are accessible via icon-type-xxx instead of icon-xxx and aren't present in the Styleguide.
These icons are the exact same ones that are present in autocomplete-plus and can help tie together this package in with other package's functionality.
Below is a quick before and after:
Before

After

Let me know what you think! If you aren't a fan maybe it could be opt into behavior?

Hmm. I do like the breadth of icons available. But you're burying the lead — these are built-in? Let's get them into the styleguide!

Hmm. I do like the breadth of icons available. But you're burying the lead — these are built-in? Let's get them into the styleguide!

That's a great point. Have no idea why the Atom team wanted them to be private, it's a handful of icons available there, but great idea to make people aware of them lol


Install Guidelines

Hi,
Thanks for your great work.
Would you please provide a detailed introduction about how to install it on a personal platform? I tried to reproduce this project on my own GPU, but there had encountered a lot of errors. So far, after installing the necessary packages,  I also met some unknown problems. It seems that the internvideo2 not only requires internlm2_5-7b-chat, but also bert-base-uncased. After solving this, it further yielded RuntimeError:

Even not sure what will happen in the next step.
Thanks.

In our test, there is no need to download and configure InternLM2.5, we have included the corresponding modeling files in the hf file, you can find it https://huggingface.co/OpenGVLab/InternVideo2_Chat_8B_InternLM2_5/blob/main/modeling_internlm2.py
In addition, the language model we use is [1m version] (https://huggingface.co/internlm/internlm2_5-7b-chat-1m), I don't know if it is related to your error.


Add basic Reusable Go workflow

I will look at adding golangci-lint next, which will be declared as a different reusable workflow.
Passes for the following repos:

https://github.com/openconfig/goyang/pull/249
https://github.com/openconfig/ygnmi/pull/122
https://github.com/openconfig/gnoi/pull/129
https://github.com/openconfig/lsdbparse/pull/13
https://github.com/openconfig/models-ci/pull/87

For gribigo the CI is currently disabled due to a period of inactivity, it needs to be manually enabled:

https://github.com/openconfig/gribigo/pull/185

@robshakir request to add @bstoll to the @openconfig/ci-maintainers team

Any thoughts on also including github.com/mgechev/revive ?
https://github.com/openconfig/featureprofiles/blob/5276cad8bf87e1fdc6e1872bf8b9647898d009bc/.github/workflows/pull_request.yml#L90-L93
We added this in featureprofiles to catch more Go readability issues.


update/tighten modules

remove unneeded modules

npm
request
tar
Tighten all modules from ^ to ~
Update modules
fs-extra 0.24.0 -> 0.26.2
nodegit-promise 3.0.3 -> 4.0.0
promisify-node 0.2.1 -> 0.3.0
jshint 0.28.0 -> 0.29.0
mocha 2.3.3 -> 2.4.4

I'm going to pull in the update to nodegit-promise from #789 since that is passing tests. You'll have to update your PR.

NEVAR sure thing


Items needed for v2.7 release

We plan on releasing v2.7 to beta in 1-2 weeks' time. :) Below are the items that need to be completed before the release:

[ ] #252 , up to the category suggestion stage. Including the fixes below:

Fix memory leaks in Nearby
Overhaul Nearby unit tests so Travis doesn't fail
Add "?" description fix to NearbyList
Test that uploads, including direct uploads (from list and map), non-direct uploads, and multiple share uploads work as expected

[ ] #7 , including changes requested
[ ] #686 if possible
[ ] All of the above merged into master and tested on prodRelease build
[ ] Make sure that Dagger NPE fixes from previous release are included

#686 comes tomorrow:)

I think we should start featuring these updates on Tech News, which are weekly sent to village pumps of many language Wikipedias and thus could provide a lot of publicity for us. The next issue is scheduled for publication on 2018-03-05, another on 2018-03-12. Questions:

should we announce the date the change comes to beta? or the final deployment? I think the latter is correct.
should we announce in advance or after the change? I think after is OK; we often don't know the date precisely.

So it would be cool if someone tags me whenever a major change is released and I'll post it to Tech News.

Thanks @VojtechDostal ! Will ping you when we do the release.

I would go with the latter, but beta isn't too bad either if we include a link to register for beta IMO.
Definitely after. It's really hard (and stressful :)) to pinpoint an exact date beforehand. Plus people will likely just forget when the time arrives

I created the release branch https://github.com/commons-app/apps-android-commons/tree/2.7.x-release and switched the base for the 2 pending PRs required for release. @neslihanturan please feel free to test the prodRelease build on that branch. :)
Aside from PRs needed to fix urgent issues with 2.7, all other PRs and new features will go into master and scheduled for 2.8 release.

A huge thank you and congratulations to everyone who has contributed to the app so far! All of your contributions will be live in the Play Store version of the app soon. :) I plan on pushing the beta release tomorrow (since I will be heading to bed soon and won't be able to test the Play Store version if I do it today).
@VojtechDostal what information will you need for the Tech News update? I can draft that and send it to you after the release is out. I also plan on writing a blog post that we can link on FB, but that might take a bit longer to do.

Best release ever! Thanks everyone who contributed:)

Wrote a summary of the new features at
https://cookiesandcodeblog.wordpress.com/2018/04/21/commons-app-version-2-7-beta-release/ :)
Fingers crossed everything will be okay with 2.7.1 and we can push to production soon.


Better reflection equals

Current samePropertyValuesAs() has many downsides and doesn't seem to be usable in real projects:

It uses properties instead of fields
It can't work with ORM proxies
It's a shallow comparison

Unitils' assertReflectionEquals() seems to solve this problem well in general (but it's not supported and it has its own issues), I wonder if Hamcrest can also solve this problem. Approx. syntax could be:
assertThat(actual,
    ReflectionMatcher.withDepth(1)
                     .matchEndNodesUsingEqualsThenField("id")
                     .unproxyIfNeeded(new HibernateUnproxer())
                     .excludingFields("blah")
                     .modes(COLLECTION_LINIENT_ORDER)
                     .equalsTo(expected)
);

where:

depth(0) means infinite recursion
unproxyIfNeeded() will return real object instead of Hibernate (or whatever) proxy. This can't work in Hamcrest Core as it will depend on ORM. So by default it will through an exception. Multiple one-class dependencies can be implemented for different ORMs.
matchEndNodesUsingEqualsThenField("id") is needed to compare fields at deepest level if depth != 0. The objects are compared with equals() by default, but those classes may not have equals() in which case we need to compare some representative field(s). This method may accept a map of Class -> fieldNames[] if different classes have different ID fields.
excludingFields() should also be overloaded to accept Class -> fieldNames[]
modes() is similar to Unitils' modes

Even if no one is going to implement it right now I wonder if such matcher would be accepted if I were to implement it some day?

Since this seems like a big project, no one will probably take it. So I'll try to create the matcher as a separate project: https://github.com/qala-io/assert-reflection-equals


Ok to include some example code?

I'm thinking that it would be nice to have an examples/ folder in the repo with a simple binary source showing how to connect to LND and make a query.  Ok for me to write that up?

@daveajones Examples would be great, thanks!


Rosetta Support for restaked staking rewards

Current dependencies on/for this PR:

feature/proof-of-stake

PR #59

PR #60   👈

This stack of pull requests is managed by Graphite.

Merge activity

Feb 27, 12:03 AM EST: @lazynina started a stack merge that includes this pull request via Graphite.


[Question] Storage tiering - non migratable storage class

Hello,
The question related to the new storage tiering feature.
I created a new storage class with Migratable=false parameter.

A new volume is provisioned using this new storage class in the harvester.
This storage class is specified for VM image (A new VM is provisioned using this image. From Harvester UI or from rancher RKE2 node driver)
New volume is provisioned from downstream RKE2 cluster (storage class in the downstream cluster uses this new non-migratable storage class in harvester)

I see in Longhorn that for all these cases RWX volumes are created. This type of volume is created using the longhorn NFS backend.
Is it the expected behavior for non-migratable volumes?
I would expect RWO volumes to be created for non-migratable storage classes. This type of volume is created using the iSCSI backend.
It is desired because it brings much better storage performance. It can be used in an environment where the Live migration feature can be sacrificed, e.g. single node harvester cluster.
Is it planned to have the ability to create RWO volumes?

I believe RWX within Harvester for Block devices is required for VM migration.. and I am not sure if this RWX is NFS - I thought it is iSCSI in this case.. but did not verify..

I agree about VM migration, but I am about the case when it is not needed. I would like to set migratable=false on the storage class thus getting RWO and better IO performance.
AFAIK RWX is supported in Longhorn only by using the NFS backend https://longhorn.io/docs/1.3.2/advanced-resources/rwx-workloads/

In Harvester I can see iSCSI connections to the block device volumes that have RWX. So I believe this is a different / new way and not the rwx via NFS. See also https://github.com/longhorn/longhorn/blob/master/enhancements/20210216-volume-live-migration.md#creating-a-migratable-storage-class - but as said I am not deep enough in this..
Regarding the "better IO performance" - what problem do you have with the performance and how much imporovement do you expect?

@dmitrybabeshko For your case, you can change the accessModes ReadWriteMany  to ReadWriteOnce by Edit Yaml when creating vms/volumes


Problem "split" function doesn't work with polygons/boundingboxes

My actions before raising this issue

Read/searched the docs
Searched past issues

Hi :)
When I try to use the split function on a polygon/boundingbox nothing appens. My cursors changes and when I drag the mouse over a bbx/poly the object becomes blue, but when I click nothing appens. Am i missing something here?
My goal is to be able to cut a polygon in two by drawing a cutting line.
Thanks !

Hi @Smirkey
The function of split doesn't cut a polygon into several polygons by cutting line (CVAT doesn't have such a function like you described).
Please, refer to user guide.

Hi @Smirkey
The function of split doesn't cut a polygon into several polygons by cutting line (CVAT doesn't have such a function like you described).
Please, refer to user guide.


Doesn't work with jQuery 2?

Trying to use it and it seems to be not working with jQuery 2+ ...

Closing as of now the version of jQuery is handled directly by Ember.


Make it possible to dump the heap

It would be nice if it were possible to dump the v8 heap similar to how https://github.com/bnoordhuis/node-heapdump works.

It is by design and described in #84  and #194 we cannot detect OOM from host application.
Having ability to create a memdump would be appreciated and useful tool when debugging mem issues.
Is there a way to bump this issue up and can we help with solving it?

It is by design and described in #84  and #194 we cannot detect OOM from host application.
Having ability to create a memdump would be appreciated and useful tool when debugging mem issues.
Is there a way to bump this issue up and can we help with solving it?

Hello @dejx,
ClearScript 7.1, which should be out very shortly, adds heap dump methods toV8Runtime and V8ScriptEngine.
Thanks!

Hello @dejx,
ClearScript 7.1, which should be out very shortly, adds heap dump methods toV8Runtime and V8ScriptEngine.
Thanks!

We've posted ClearScript 7.1.

We've posted ClearScript 7.1.


h264 issue with native webrtc(Android, iOS)

I created webrtc offer sdp for connecting with other webrtc clients(chrome, android, iOS).
with chrome client, it works fine. I can see the video on chrome browser without any errors.
but when I try to connecting with android or iOS which is implemented by using native webrtc.
I got errors that "No video codec supported(this is because of H264)".
I found some different about h264 between gstreamer sdp and android sdp for creating offer sdp.
gstreamer sdp offer:
a=rtpmap:96 H264/90000
a=rtcp-fb:96 nack pli
a=fmtp:96 packetization-mode=1;profile-level-id=42801f;sprop-parameter-sets=Z01AHqaAoD2mwEA=,aO48gA==
native webrtc and chrome sdp offer:
a=rtpmap:125 H264/90000
a=rtcp-fb:125 goog-remb
a=rtcp-fb:125 transport-cc
a=rtcp-fb:125 ccm fir
a=rtcp-fb:125 nack
a=rtcp-fb:125 nack pli
a=fmtp:125 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42e01f
I don't know about attributes (level-asymmetry-allowed, profile-level-id, sprop-parameter-sets).  I'm not sure but, i think because of this I'm getting error.
is there anybody tested gstreamer webrtc(h264) connecting with android or ios???

hello
I also encountered the same problem. The communication on the wen end is normal, but the h264 does not match when communicating with android and ios. Do you have a solution? Can you tell me something?

These examples have moved to https://gitlab.freedesktop.org/gstreamer/gst-examples/-/tree/master/webrtc and this repository will not be updated further.


rcc_en_reset doesn't work when paste is not imported

When using the rcc_en_reset macro, I get errors that paste and cfg-if are not found. Adding them to Cargo.toml fixes the errors, but it should not be needed.
A solution would be to re-export the paste and cfg_if macros (maybe with #[doc(hidden)]) and use ::stm32_hal2::paste and ::stm32_hal2::cfg_if instead.

Could you give an example of context? rcc_en_reset is intended for internal use only.

So maybe I didn't understood how to use it. I thought I had to enable each peripheral with this macro before to use it.

Nope - that's handled in the constructors, which call rcc_en_reset. I think this confusion was caused by Rust's non-standard export mechanics of macros compared to normal fns and structs.

FWIW, I tried removing the #[macro_export] line above that macro so it's not exposed publicly, but it stopped working privately when I did.

I'm reclassifying this as a [fixed] bug. Switched to a diff syntax instead of #[macro_export], and it's now pub(crate) visibility.


Grove sensors v5

Nodes for three analogic sensors of Galileo Grove Kit that would demand some calculation over raw readings to be useful: temperature, light and rotary. The idea is to provide a simple way to use these analogic sensors.
v5:
Use constants to identify internal nodes indexes on nodes.
v4:
Small style fix
Reordering temperature_converter_data structure to save space.
v3:
Exposing more parameters on nodes, like potential divider resistor resistance;
Correctly using input range mask on formulae;
Using an exponential approximation (obtained from Grove Starter Kit booklet table, using least squares) for light sensor Lux measurements;
Grove fbp examples updated to use the new nodes;
lcd-grove moved to grove module.
v2:
More meaningful name for struct member
No more relative includes.

Tks! Integrated!


Feat: Add relay integration test

Cool! Not so clear on what this test is actually testing.

The test itself creates a session and then sends a ping


[Feature Request] Cache in memory aswell

Good job with this library! This is really great and is also a great alternative to react-native-fast-image now that it is no longer maintained.
The only thing i am missing though is the possibility to store the images in memory aswell to increase performance. Is that something that you have any plans on implementing?
Best regards

Subscribed.


Contract is unreachable when impersonating its address

Component
Anvil
Have you ensured that all of these are up to date?

[X] Foundry
[X] Foundryup

What version of Foundry are you on?
No response
What command(s) is the bug in?
No response
Operating System
macOS (Apple Silicon)
Describe the bug
When using anvil_impersonateAccount on a contract address, I would expect that calls (from user or between contracts) to this contract would work as usual. But turns out that when impersonating a contract address, its code is unreachable.
Example (using fork from Ethereum mainnet :
const ethers = require("ethers");
const PAUSE_ABI = [
  {
    constant: true,
    inputs: [],
    name: "delay",
    outputs: [{ internalType: "uint256", name: "", type: "uint256" }],
    payable: false,
    stateMutability: "view",
    type: "function",
  }
];

async function main() {
  const pauseAddress = "0xbE286431454714F511008713973d3B053A2d38f3";
  const provider = new ethers.providers.JsonRpcProvider("http://<IP_ADDRESS>:8545");
  const pauseContract = new ethers.Contract(pauseAddress, PAUSE_ABI, provider);

  await provider.send("anvil_impersonateAccount", [pauseAddress]);

  console.log(`delay: ${await pauseContract.delay()}`);

}

main().catch((e) => console.log(e));

Returns :
Error: call revert exception [ See: https://links.ethers.org/v5-errors-CALL_EXCEPTION ] (method="delay()", data="0x", errorArgs=null, errorName=null, errorSignature=null, reason=null, code=CALL_EXCEPTION, version=abi/5.7.0)
  reason: null,
  code: 'CALL_EXCEPTION',
  method: 'delay()',
  data: '0x',
  errorArgs: null,
  errorName: null,
  errorSignature: null,
  address: '0xbE286431454714F511008713973d3B053A2d38f3',
  args: [],
  transaction: {
    data: '0x6a42b8f8',
    to: '0xbE286431454714F511008713973d3B053A2d38f3'
  }
}

Verified on HardHat and the code snippet works on Hardhat.
I found https://github.com/foundry-rs/foundry/issues/1943, but not sure why we have to overwrite the contract code (seems like hardhat doesn't do this)
Having the option to impersonate a specific contract is necessary for bypassing authorization (e.g admin contract) but there are some circumstances that we still want the contract to be usable.

This, meaning the call code of an impersonated account with itself, won't work atm:
 await provider.send("anvil_impersonateAccount", [pauseAddress]);

 console.log(`delay: ${await pauseContract.delay()}`);

because impersonateAccount will temporarily remove the code because of EIP-3607


Feature/adding template filter for switch flag sample usable for if statement conditions

This PR is addressing #510, as the previous PR was out of sync

@ulgens Please see new PR rebased to master and removed updates to .po files.

@MatthewEthanTam I checked the PR and issue several times and I still don't understand the case here. I'll check it again when I have better availability. Sorry for the delay.

@ulgens So there are two cases.
First, the case explained in the issue is where code is duplicated when a Switch and a context variable are needed to display text/ elements in an HTML block. The implementation will allow for cleaner HTML code and reduced lines of code.
Before implementation:
{% switch 'switch'%}
  {% if context_variable %}
    modified message
  {% else %}
    default message
  {% endif %}
{% else %}
  default
{%endswitch%}

After implementation:
{% if 'switch'|switch_is_active and context_variable%}
  modified message
{% else %}
  default message
{% endif %}

Second, HTML linters/stylers such as DJLint do not recognize the {%switch 'switch_name'%} template tag, but do recognize {%if switch_is_active|'switch_name'%}, allowing for a better linting & styling experience.

@MatthewEthanTam do you need any help putting together the documentation?


Seeking guidance on Video fullscreen mode

Problem description
I am having a portrait orientation fixed app. I am displaying a Video (using Video widget) in one of the screen (like Youtube). I am looking for suggestions on how to get the behaviour like Full screen Play mode and return etc. (when the user touches / toggles the screen orientation). If toggle is not an option, may you suggest how can I play the same video on full screen mode (landscape like)

You should relayout your views so that the Video covers the entire screen when the screen size changes.

Closing as "resolved". Please reopen if that doesn't suite your needs.


Movie support and refactoring

Hello,
Thanks a lot for the script. This saved a lot of time at least for me and hopefully for other people too.
I initially continued on where @SinTan1729 worked on movies and seems like you already merged it in #17. IMO the changes were not quite ready yet, but of course you decide what you merge.
I tried to write the code as DRY as possible by using two abstract classes: Searcher, which searches first TinyDB for TV Shows and Movies then from Trakt. And Processor which processes the TV Time data. Both abstract classes contain the common logic and then the subclasses override any specific behavior.
I also made some other improvements like:

Added typing
Tried to simplify logic where possible
Moved some logic to own files
Shows progress as a percentage
For some movies the release date is available, this is read to avoid asking user for input
Handles any Exception when processing files (I got a: requests.exceptions.ConnectionError: ('Connection aborted.', RemoteDisconnected('Remote end closed connection without response')) when processing)

I would also be happy to implement some of the open issues.

Thanks for your contribution. This is fantastic work, and was very much needed! :)


Add limits to all resolvers

Maximum limit as an environment variable
Default 10,000
If requested number of records would exceed the maximum value generate an error.

If an error is generated use something alike to the following error message template
Error: Requested ${model.count(options)} exceeding max limit of ${BATCH_MAX_SIZE}. Please use pagination.

To give an example of possible paginated queries:
{ people(pagination: {limit: 10000, offset: 0}) {
     name
     dogs(pagination: {limit: 10000, offset: 0}) {
        breed
     }
}

Done. #e735f0


Drop default cerebro secret.

Let's require operators who want cerebro to set a non-default secret instead of recommending it in a comment 😃

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

It looks like logstash tests failed on this build, but I'm not sure why changing cerebro properties would matter for those. WDYT @Infra-Red?

Thanks, updated @Infra-Red .


Add ECS Detector and Unit tests

This PR adds the ECS detector:
The ECS detector looks for one of the two environment variables and populates and returns a resource with the container ID and hostName if available/succeeds. The ECS detector is split up into two classes since mock testing cannot be achieved otherwise.
A PR in the core repo will be created to add the CONTAINER_ID as a resource constant as an ID is something that exists quite often. A comment is in the code left as a TODO.
Currently the PHP Library has no Logging so comments were left in as TODOs for future development if logging is added.
@alolita @anuraaga @bobstrecansky

The reason the other Psalm checks are failing are because the core dependency is not added in this PR. The PR #7 should be merged before this one.


Syncfusion Production License configuration issue

Describe the bug in current situation
While opening the PDF outputs of the problematic file types , the Syncfusion watermark is getting displayed on the PDF outputs and/or subsequent PDF output files are marked as blank. The root cause of this issue was related with Syncfusion License Key configured on Prod.
Link bug to the User Story
Impact of this bug
This bug has a Production wide issue with all conversion starting from September 1st.
Chance of Occurring (high/medium/low/very low)
Pre Conditions: which Env, any pre-requesites or assumptions to execute steps?
Steps to Reproduce
Steps to reproduce the behavior:

Go to \Sfp.idir.bcgov\S177\S77104\ARR\In_Coming\IRR-2021-12586 - Sasha Andres CFR - Excel\output\Excel Documents
Open PDF outputs and we can see watermark on the TOP

Actual/ observed behaviour/ results

Expected behaviour
Water mark should not have displayed
Screenshots/ Visual Reference/ Source
If applicable, add screenshots to help explain your problem. You an use screengrab.

Issue fixed by configuring new License Key. No watermarks on Prod. now.  Refer SMOKETEST folder on \Sfp.idir.bcgov\S177\S77104\ARR\In_Coming\IRR-SMOKETEST-AJA\output\Excel Documents

@abin-aot I did a test and confirmed this issue is resolved. I also spoke with the Flex Team and the workaround put in place for them for any previous files is sufficient. This can be closed.


Fix url encoding issue causing webhook message delivery to fail

Format messages before sending.
Use curl's --data-urlencode flag to properly url encode message content.
Remove the webhook template.
Remove all manual message escaping.

Signed-off-by: Wade Barnes<EMAIL_ADDRESS>

Fixes #95

Manual testing was performed to ensure the webhook logging functioned for the reported case as well as existing info and error causes.


24 - US: As an author, I want to be able to use my web-browser to manage/author my posts

Should include editing posts


Provide all Heroku config vars as an output

This will allow running something like terraform output -json | jq '.all_django_vars.value' to get the config vars, instead of needing to use the heroku cli.


Database maintenance impacting our websites

Our hosting provider will be performing database maintenance which will impact several of our sites. The maintenance will be withing the maintenance window below, however no or minimum downtime is expected.
This maintenance only involves websites under the phpBB.com subdomain. Non phpBB.com sites should keep working.

Our hosting provider will be performing database maintenance which will impact several of our sites. The maintenance will be withing the maintenance window below, however no or minimum downtime is expected.
This maintenance only involves websites under the phpBB.com subdomain. Non phpBB.com sites should keep working.


Unable to access Grid elements

Unable to access Grid elements
Unable to access the elements inside grid
with dump_tree(), pywinauto is only dumping till grid but not elements inside it
Actual Behavior

Screenshot with Inspect.exe

Inspecting in MSAA mode

Could be related to #1242
Specifications

Pywinauto version: 0.6.8
Python version and bitness: 3.12.7
Platform and OS: Windows 11

@beuaaa @vasily-v-ryabov

@junkmd any thoughts?

Hi,
It probably has the same issues as the previous grids.
If you know which framework is implementing this GUI, it might allow for a deeper discussion.

If you know which framework is implementing this GUI, it might allow for a deeper discussion.

Inspect.exe is saying that FrameworkIdis Win32 (as in second pic)
any way that I can use to check further on framework, thanks

Hello @junkmd , digged some more information
Grid from Spy++

Dependency Walker is showing DLLs with MS WIN CORE api
Grid Info from Resource Hacker

inherited ReportGridForm: TReportGridForm
  BorderStyle = bsSizeable
  Caption = 'Report Grid'
  ClientHeight = 559
  ClientWidth = 625
  OnShow = FormShow
  ExplicitWidth = 641
  ExplicitHeight = 598
  PixelsPerInch = 96
  TextHeight = 13
  object Grid: TKalosGrid [0]
    Left = 0
    Top = 30
    Width = 625
    Height = 476
    Align = alClient
    DrawingStyle = gdsClassic
    Options = [goFixedVertLine, goFixedHorzLine, goVertLine, goHorzLine, goRangeSelect, goRowSelect, goThumbTracking]
    TabOrder = 1
    OnDrawCell = GridDrawCell
    SelectedColor = 13434828
    SortedCol = 0
    CheckMark = True
    ImageColumn = 0
    ColWidths = (
      64
      64
      64
      64
      64)
    RowHeights = (
      18
      18
      18
      18
      18)
  end
  object StatusBar: TStatusBar [1]
    Left = 0
    Top = 534
    Width = 625
    Height = 25
    Panels = <>
    SimplePanel = True
  end
  object Heading: THeading [2]
    Left = 0
    Top = 0
    Width = 625
    Height = 30
    Align = alTop
    Caption = 'Heading'
    Color = clWhite
    DoubleBuffered = True
    Font.Charset = DEFAULT_CHARSET
    Font.Color = clBlack
    Font.Height = -19
    Font.Name = 'Tahoma'
    Font.Style = [fsBold]
  end
  inherited LogPanel: TPanel
    Top = 506
    Width = 625
    ExplicitTop = 506
    ExplicitWidth = 625
    inherited FormLogMenu: TSpeedButton
      Left = 598
      ExplicitLeft = 598
    end
  end
  inherited RecordNotify: TNotifyID
    Left = 564
    Top = 4
  end
  object ActionList: TActionList
    OnExecute = ActionListExecute
    Left = 600
    object Escape: TAction
      Caption = 'Escape'
      ShortCut = 27
      OnExecute = EscapeExecute
    end
  end
end


add gdp drifter traj

Looks fantastic @philippemiron thank you. Why not plot the sst for the 6h case? The variable is called temp.

Oh, I did not realize that sst was there..

This looks really great. I will update the readme in a little bit and merge.


Use provided transition on cache hit

When provided with an URL that ends up being redirected (301), no cache hit occurs during initialization, as URLCache.cachedResponse expects the redirected URL to be provided instead.
This leads to _phase being set to .empty, even though the ensuing .load call will result in a cache hit, because URLSession.data does behave properly.
... that's my theory, at least 😬
I saw, that f24cfe71158f428e9a396a19335221f0fe19e10e did away with animating on cache hit.
What was the reason that change?

Transaction has to be used when phase changes (also according to official docs).
On cache hit phase should just be initialized to success(Image), ideally. But for some reasons this is not happening (see this). Know I try to rewrite the code avoiding URLCache.cachedResponse usage.

2977899d51535b2ddbc410e01c102846ad78698b fix redirected urls


Add missing io.k8s.description label in client artifacts

As per title

/cherry-pick release-v1.16


Allow downloading previous versions of APKs

It would be really great if apkeep allowed me to download a specific version of an APK. For example, if I wanted to download a previous version of an APK to compare its functionality to the latest version available in the Google Play store, I could use APK Pure to download both the legacy version and the current version.
I am thinking something like this:
apkeep -a<EMAIL_ADDRESS>
Where the @ is the delimiter between the package ID and the desired version to download.

https://github.com/EFForg/apkeep/commit/a2dd25c36148db4c84e94289d53d4ce43579fdd1 adds the ability to download versioned apps on APKPure and F-Droid following the convention you suggest, as well as making it possible in a separate field if you're using a CSV.
It also allows users to look up what versions are available on these sources using the -l flag.
Thanks for the suggestion!

Fantastic!! Thanks for the consideration and implementation.


Replacing callbacks to improve readability

Describe the proposal
In it's current state, the code uses two main ways to handle asynchronous operations.
The HTTP implementation uses promises, and the GRPC implementation uses (or more likely "have to use") callbacks.
Using callbacks has always been a pain in JS, as we have to deal with both synchronous and asynchronous errors, leading to some "mandatory boilerplate".
For example, in sidecar.ts
  static async isStarted(client: GRPCClient): Promise<boolean> {
    const callClient = await client.getClient(false);

    return new Promise((resolve, _reject) => {
      try {
        callClient.getMetadata(new Empty(), (err, _res: GetMetadataResponse) => {
          if (err) {
            return resolve(false);
          }

          return resolve(true);
        });
      } catch (_e) {
        return resolve(false);
      }
    });
  }
}

The purpose of this issue would be to replace most of the GRPC client callbacks with promises.
Although there is no performance benefit to doing this (nor any performance hit), it will greatly improve the readability of the code, especially as more complex features are added to the SDK (i.e Workflows), in which we may have to deal with nested callbacks.
To achieve this, we could use the promisify function (included in Node 8+).
On the same example, it would look something like this.

  static async isStarted(client: GRPCClient): Promise<boolean> {
    const callClient = await client.getClient(false);
    let isStarted = true;
    try {
      await promisify(callClient.getMetadata)(new Empty());
    } catch (e: unknown) {
      isStarted = false
    }
    return isStarted
}

I can see two ways in which this could be used. We could use the promisify function each time the GRPC client is used, which is simple.
Or we could wrap the whole GRPC client class in an adapter class, that "promisifies"  all of the client's methods, which would be more DRY, but add a bit of extra maintenance.
What do you think ?

Hi, I am new to contributing to open sources, but I'd like to do this to learn the codebase a bit. With a little guidance, I'll do a decent job.

I want to do this if it gets approved. I am new to contributing to open sources so I'll need some support.

Hi @nav-D / @SoTrx we discussed this in the team, and we would be opening - although being an aesthetic feature - to change this if a PR could be made that does take into account the test coverage as well. Is that something either of you could take up?

Theoretically speaking, there should be no breaking changes. This is just removing complexity before it gets out of hand, as I have seen in past projects.
I'll check the code to be sure, and suggest a PR.
@nav-D, once I get the PR ready, would you help me getting it right ?

/assign

@SoTrx Sure I’d love to help out.

@XavierGeerinck - is this still a good first issue for contributors? Looks like there was never a PR opened.

Adding @shubham1172 I would say it could be, but it's a bit stale so we would prefer other issues first

Thanks a lot for this PR! We had a discussion around it and are going to put it on hold. The reason for this is since the Node.JS ecosystem is becoming more fragmented daily with new runtimes such as Deno, Bun, .... with Bun having a good change of taking it over.
Introducing this PR would require us to scope the input of supporting additional runtimes as some are Node supported only while others don't carry this requirement.

That's a very good point !

The reason for this is since the Node.JS ecosystem is becoming more fragmented daily with new runtimes such as Deno, Bun, .... with Bun having a good change of taking it over.

Yikes.
I think you're wildly over-estimating the fragmentation of Node. (Have we learned nothing from yarn?)
If Bun intends to be a drop-in replacement for NodeJS then by all means let it drop-in, but don't let it block useful enhancements like this.


incorrect time after unhibernating

Describe the issue
After unhibernating the computer, the display time is wrong.
To Reproduce

hibernate
wait some time
unhibernate

Environment:

WM: i3
Distro: Arch Linux
Output of polybar -vvv:

polybar 3.4.1

Features: +alsa +curl +i3 +mpd +network(libnl) +pulseaudio +xkeyboard

X extensions: +randr (+monitors) +composite +xkb +xrm +xcursor

Build type: Release
Compiler: /usr/bin/c++
Compiler flags: -march=x86-64 -mtune=generic -O2 -pipe -fno-plt -Wall -Wextra -Wpedantic -O3 -DNDEBUG
Linker flags: -Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now```

The date module updates every interval seconds, is the time wrong even after it updates? Does the module even update?

@patrick96 Looks like it does not update at all after unhibernating. It just shows, say, 16:03 and it stays that way forever (until I click on it). My interval is set to 5 seconds like that:
[module/date]
type = internal/date
interval = 5

After I click on the time it immediately corrects itself and starts updating again.

The symptoms seem to be consistent with the ones described in https://github.com/polybar/polybar/issues/857. Any chance that your system clock moves backwards when your system wakes up?
If you can, try out the PR https://github.com/polybar/polybar/pull/1725 which should contain a fix for this. Alternatively compile the current version of polybar with clang instead of gcc (add -DCMAKE_CXX_COMPILER=clang++ to the first cmake call in the PKGBUILD).
If you want to, try both solutions separately, we're interested to hear if both work.

@patrick96 Yes, actually my system clock does move backwards after Linux wakes up. I dual-boot with Windows, which overwrites hardware clock with the local time. Linux uses UTC and since I'm in the +1 time zone after I wake up Linux the systemd-timesyncd will correct it after about 1 minute by moving it back one hour. I'm planning to fix it soon by modifying a registry setting in Windows so that it sets UTC time in the hardware clock.
I've compiled polybar with clang as you suggested and retried the scenario but it still does not work correctly. I'll try the patch you mentioned at a later time.

@patrick96 OK, I've checked the patch and it works. Although it didn't compile at first since check_symbol_exists cmake function used in cmake/03-libs.cmake was not found. But I easily fixed it by adding include(CheckSymbolExists) in the line above.
Thanks for help :)

If you can, try out the PR #1725 which should contain a fix for this. Alternatively compile the current version of polybar with clang instead of gcc (add -DCMAKE_CXX_COMPILER=clang++ to the first cmake call in the PKGBUILD).

Alone this won't work since clang is using gcc's c++ library (libstdc++) by default.
I think you also need to add the following flag to the cmake command:
-DCMAKE_EXE_LINKER_FLAGS="-stdlib=libc++ -lc++abi"
However, I don't know if the behavior of the library of clang is correct.

@patrick96 OK, I've checked the patch and it works. Although it didn't compile at first since check_symbol_exists cmake function used in cmake/03-libs.cmake was not found. But I easily fixed it by adding include(CheckSymbolExists) in the line

Hum strange, I'll check that.

@Lomadriel do you think the patch worked because we started using steady_clock everywhere or because of the custom condition_variable implementation?

@Lomadriel do you think the patch worked because we started using steady_clock everywhere or because of the custom condition_variable implementation?

Nop, with gcc it is needed to use my implementation and the a steady_clock.

Yes, I see. The module sleep method uses the m_sleephandler condition variable.
That sucks, I really don't want to have to maintain our own version of condition_variable in polybar. Maybe we should switch to clang for a while and use libc++?


Error/warning on failing build: "Can't merge pod_target_xcconfig for pod targets"

Build/Submit details page URL
No response
Summary
EAS build that has no issues with npx expo-doctor prints this (non-fatal?) error/warning during builds. Although it doesn't seem fatal, the build is failing later in the process and I can't be sure this is unrelated to the failure.
Managed or bare?
Managed
Environment
expo-env-info 1.2.0 environment info:
System:
OS: macOS 14.5
Shell: 5.9 - /bin/zsh
Binaries:
Node: 20.12.0 - ~/.nvm/versions/node/v20.12.0/bin/node
Yarn: 1.22.22 - ~/.nvm/versions/node/v20.12.0/bin/yarn
npm: 10.5.0 - ~/.nvm/versions/node/v20.12.0/bin/npm
Managers:
CocoaPods: 1.15.2 - /usr/local/bin/pod
SDKs:
iOS SDK:
Platforms: DriverKit 23.5, iOS 17.5, macOS 14.5, tvOS 17.5, visionOS 1.2, watchOS 10.5
IDEs:
Xcode: 15.4/15F31d - /usr/bin/xcodebuild
npmGlobalPackages:
eas-cli: 10.0.0
expo-cli: 6.3.10
Expo Workflow: managed
✔ Check Expo config for common issues
✔ Check package.json for common issues
✔ Check dependencies for packages that should not be installed directly
✔ Check for common project setup issues
✔ Check for issues with metro config
✔ Check npm/ yarn versions
✔ Check Expo config (app.json/ app.config.js) schema
✔ Check native tooling versions
✔ Check that packages match versions required by installed Expo SDK
✔ Check for legacy global CLI installed locally
✔ Check that native modules do not use incompatible support packages
✔ Check that native modules use compatible support package versions for installed Expo SDK
Didn't find any issues with the project!
Error output
[INSTALL_PODS] [!] [Codegen] warn: using experimental new codegen integration
[INSTALL_PODS] [!] `<PBXResourcesBuildPhase UUID=`13B07F8E1A680F5B00A75B9A`>` attempted to initialize an object with an unknown UUID. `D5A51ACEDD5444D6B50BA983` for attribute: `files`. This can be the result of a merge and the unknown UUID is being discarded.
[INSTALL_PODS] [!] Can't merge pod_target_xcconfig for pod targets: ["expo-dev-menu", "Main", "ReactNativeCompatibles", "SafeAreaView", "Vendored"]. Singular build setting DEFINES_MODULE has different values.
[INSTALL_PODS] [!] Can't merge pod_target_xcconfig for pod targets: ["expo-dev-menu", "Main", "ReactNativeCompatibles", "SafeAreaView", "Vendored"]. Singular build setting DEFINES_MODULE has different values.
[INSTALL_PODS] [!] hermes-engine has added 1 script phase. Please inspect before executing a build. See `https://guides.cocoapods.org/syntax/podspec.html#script_phases` for more information.

Reproducible demo or steps to reproduce from a blank project
Unknown

+1

+1

+1

To everyone commenting +1 and the like, it would do you much more good to:

Add a thumbs-up (maintainers can organize issues by their number of reaction emojis)
Add a meaningful comment with your findings, or otherwise subscribe to notifications on the right-hand-side to avoid cluttering the thread

Hey did you find a solution to this? I've been facing the same issue since 2 days.

Yeah I fixed it by updating expo-cli

@aimeeaidanu I also resolved it a few minutes ago by changing iOS target version from 13.0 to 13.4.

@aimeeaidanu to what version? I think expo-cli upgrades can change the iOS target version (though generally only for major releases?)
I was on the latest at the time when I filed this.

Yeah I fixed it by updating expo-cli

Wasn't this replaced by 'npx expo'?

I'm seeing this as well. Clean expo-doctor, expo 51, and am using iOS deployment target of 17.0 (because I have some native code that needs this as min version).

I see the exact msg, not sure if breaks anything tho.  I got our builds working and I'm 99% sure this warning persisted despite the functional build being output.

I'm having this issue.  Might just be a warning but further down my build fails.  This is the issue (something to do with fastlane)
https://github.com/expo/eas-cli/issues/2109
I'm thinking this might be related

Did anyone find a solution to this? We just started getting it despite everything being fine 5 days ago.

@Daniel-Cross and to any other people having this issue, try copying all files into a new directory and rebuilding. Seems to fix the issue as well.

This started to happen to me as well, fully managed project, same failure both on EAS and with --local flag.
Tried to copy the directory to a new location, doesn't work.

We just started getting this on EAS. Builds were passing on Sep 30 but we get this error as of today. No dependencies have changed.

having this same problem, someone solve it?

This issue seems to be come and go periodically. Keep me posted on any updates you guys have

I have the same issue. Did a build in late September and it worked fine. Tried building 2 days ago 8:th of October and now it doesnt want to go through. Nothing in the code except the version number on the app has gone up. And I have a clean install of expo-cli
Will it just correct itself in a few days?
https://status.expo.dev/ - says that all systems are operational

I just ran into this, and I think this warning is misleading.
Our problem was actually certificates, and that error is hidden by Fastlane piping Xcode logs to disk. By running EAS_LOCAL_BUILD_SKIP_CLEANUP=1 EAS_LOCAL_BUILD_WORKINGDIR=/tmp/eas eas build --local, I got a logfile in /tmp/eas/logs that I could look through to identify the cause of the build failure.
In our case it was something like:
/tmp/eas/build/packages/mobile/ios/MyApp.xcodeproj: error: Provisioning profile "*[expo] com.myapp.mobile AppStore 2024-10-09T23:20:03.581Z" doesn't include signing certificate "Apple Distribution: MyApp Technologies, Inc. (BQ37933Y3C)". (in target 'MyApp' from project 'MyApp')

Did anyone make this work? I am running into the same issue. It was fine a few days ago...; Suddenly build started to fail with exactly the same message no matter how I changed the Podfile.

Did anyone make this work? I am running into the same issue. It was fine a few days ago...; Suddenly build started to fail with exactly the same message no matter how I changed the Podfile.

For us one thing that helped was to upgrade Expo version to the latest minor update, and run Expo doctor to update all dependencies. This worked for a fully managed Expo project, with or without --local.
Of course, your milage may vary given many of the folks already tried this. For us the main thing that helped is to upgrade Expo SDK itself, not just upgrading other dependencies.

Having the same issue. Tried everything here, but no solution did help

Our builds are working again. For us, the error in this issue was unrelated. The real error (certificates) was hidden in the full log, which is only available when building with --local and not on EAS.

@statico  yeah I tried it locally, but no logs are written ...

@mariomurrent-softwaresolutions try upgrading my react-native to the latest patch version. This fixed it for me

@statico I tried it, too. but no luck. I created a new certificate working fine but same error.
@mariomurrent-softwaresolutions

Having the same issue. Tried everything here, but no solution did help

Same here.
@junzhengca Thank you! but when I solved the expo doctor's all issues, I am still getting the same errors.
✔ Validating global prerequisites versions passed
✔ Checking for incompatible packages passed
✔ Checking for conflicting global packages in project passed
✔ Verifying prebuild support package versions are compatible passed
✔ Checking dependency versions for compatibility with the installed Expo SDK passed
✔ Validating Expo Config passed
✔ Checking package.json for common issues passed

Didn't find any issues with the project!

The errors are the same
Pod installation complete! There are 78 dependencies from the Podfile and 77 total pods installed.

[!] [Codegen] warn: using experimental new codegen integration

[!] Can't merge pod_target_xcconfig for pod targets: ["expo-dev-menu", "Main", "ReactNativeCompatibles", "SafeAreaView", "Vendored"]. Singular build setting DEFINES_MODULE has different values.

[!] Can't merge pod_target_xcconfig for pod targets: ["expo-dev-menu", "Main", "ReactNativeCompatibles", "SafeAreaView", "Vendored"]. Singular build setting DEFINES_MODULE has different values.`

My Podfile definitely has YES only
installer.pods_project.targets.each do |target|
      target.build_configurations.each do |config|
        config.build_settings['DEFINES_MODULE'] = 'YES'
      end
    end
  end

I updated the deployment target to 15 and fixed m dependencies. Did a clean and rebuild and now it seems to work

@mariomurrent-softwaresolutions try upgrading my react-native to the latest patch version. This fixed it for me

Seems like this fixed it

I'm having this issue. Might just be a warning but further down my build fails. This is the issue (something to do with fastlane) #2109
I'm thinking this might be related

It was NOT related.
The key for me was kicking off a non-local build on eas, then getting the xcode logs through the dashboard which revealed the error (in the logs).  I couldn't find those xcode logs on my local machine when building locally, but the expo ui makes it easy to download those.

@mariomurrent-softwaresolutions
Thank you! I've upgraded React native and react as they instructed but in my case, the target 15.0 was not enough and went to 16.0. Was your react native version 0.76.0? (and React 18.3.1?)
I cleaned everything and tried it but eventually I got the same error when I run pod install
Pod installation complete! There are 87 dependencies from the Podfile and 86 total pods installed.

[!] [Codegen] warn: using experimental new codegen integration

[!] Can't merge pod_target_xcconfig for pod targets: ["expo-dev-menu", "Main", "ReactNativeCompatibles", "SafeAreaView", "Vendored"]. Singular build setting DEFINES_MODULE has different values.

[!] Can't merge pod_target_xcconfig for pod targets: ["expo-dev-menu", "Main", "ReactNativeCompatibles", "SafeAreaView", "Vendored"]. Singular build setting DEFINES_MODULE has different values.

[!] hermes-engine has added 1 script phase. Please inspect before executing a build. See `https://guides.cocoapods.org/syntax/podspec.html#script_phases` for more information.

Can anyone actually confirm ill effects from this issue? I don't want to waste the maintainers time, and so far I haven't confirmed any problems caused by it.

@mariomurrent-softwaresolutions Thank you! I've upgraded React native and react as they instructed but in my case, the target 15.0 was not enough and went to 16.0. Was your react native version 0.76.0? (and React 18.3.1?)
I cleaned everything and tried it but eventually I got the same error when I run pod install
Pod installation complete! There are 87 dependencies from the Podfile and 86 total pods installed.

[!] [Codegen] warn: using experimental new codegen integration

[!] Can't merge pod_target_xcconfig for pod targets: ["expo-dev-menu", "Main", "ReactNativeCompatibles", "SafeAreaView", "Vendored"]. Singular build setting DEFINES_MODULE has different values.

[!] Can't merge pod_target_xcconfig for pod targets: ["expo-dev-menu", "Main", "ReactNativeCompatibles", "SafeAreaView", "Vendored"]. Singular build setting DEFINES_MODULE has different values.

[!] hermes-engine has added 1 script phase. Please inspect before executing a build. See `https://guides.cocoapods.org/syntax/podspec.html#script_phases` for more information.

"react-native": "0.74.5",
"react": "18.2.0",
As the expo-doctor said. So I updated all dependencies that I have no warning in expo-doctor

Can anyone actually confirm ill effects from this issue? I don't want to waste the maintainers time, and so far I haven't confirmed any problems caused by it.

Well it breaks local builds ...

Well maybe not for you. Until I fixed the error yesterday, the build did not successfully complete locally.

I may have already commented this but my biggest advice is to try to reinitalize in a fresh new project. A lot of these expo issues seem to have a completely random cause but creating a new project and then moving the code over seems to fix them.

Until I fixed the error yesterday, the build did not successfully complete locally.

I don't see how this could be anything but an all or nothing, but your experience is duly noted.

I don't see how this could be anything but an all or nothing, but your experience is duly noted.

Surely, when I upgraded React native, the warning gone in my case like @mariomurrent-softwaresolutions said although I am now getting other errors.
In the end, I decided to re-initialize the app as it had looping errors and warnings and does not read two files anymore.

I got this error when doing a local build for IOS.
My issue was that I'd just updated Xcode, and I hadn't yet downloaded and installed simulators for the newest IOS version.
Solution:

Open Xcode
Accept the new terms and conditions (if there)
Download and Install the IOS simulators for the newest version

Getting the same error after upgrading to Expo SDK 52 ...
@jvgeee Did not help to me ...
Seems really like a random occurring error for older projects :(

if I'm not wrong it's related to react-native-svg downgrade to 15.3 and one more thing try to run pod install and show us the log

`Integrating client project
Pod installation complete! There are 92 dependencies from the Podfile and 93 total pods installed.
[!] [Codegen] warn: using experimental new codegen integration
[!] Can't merge pod_target_xcconfig for pod targets: ["expo-dev-menu", "Main", "ReactNativeCompatibles", "SafeAreaView", "Vendored"]. Singular build setting DEFINES_MODULE has different values.
[!] Can't merge pod_target_xcconfig for pod targets: ["expo-dev-menu", "Main", "ReactNativeCompatibles", "SafeAreaView", "Vendored"]. Singular build setting DEFINES_MODULE has different values.`
I am getting this issue and its breaking build in xcode ,
"react": "18.3.1",
"react-native": "^0.76.5",

`Integrating client project Pod installation complete! There are 92 dependencies from the Podfile and 93 total pods installed.
[!] [Codegen] warn: using experimental new codegen integration
[!] Can't merge pod_target_xcconfig for pod targets: ["expo-dev-menu", "Main", "ReactNativeCompatibles", "SafeAreaView", "Vendored"]. Singular build setting DEFINES_MODULE has different values.
[!] Can't merge pod_target_xcconfig for pod targets: ["expo-dev-menu", "Main", "ReactNativeCompatibles", "SafeAreaView", "Vendored"]. Singular build setting DEFINES_MODULE has different values.`
I am getting this issue and its breaking build in xcode , "react": "18.3.1", "react-native": "^0.76.5",

need full package.json file +error logs after running  npx expo run:ios

I fixed this bug with the cmd: npx expo install --check, it was causing conflict between some dependencies installed in the project


Add Hugging Face relevance training script

Fixes

#31

Description

Adds current training script for relevance model, predicts if a url and its contents are either relevant or irrelevant

@EvilDrPurple Getting this error when I try to run huggingfac_relevance.py:
RuntimeError: The size of tensor a (3598) must match the size of tensor b (2048) at non-singleton dimension 1

@EvilDrPurple also can you add multimodal_transformers to requirements.txt? also upload one of the files you used with clean_data.py?

@EvilDrPurple Getting this error when I try to run huggingfac_relevance.py: RuntimeError: The size of tensor a (3598) must match the size of tensor b (2048) at non-singleton dimension 1

@mbodeantor I went ahead and updated the requirements.txt. I could not reproduce the error in a fresh venv. If it still doesn't work would you mind using pip list and sending it my way so that I may compare with my package versions?

Additional notes about this:
I was having issues with Python 3.12 as well as newer versions of pytest and tqdm since multimodal-transformers requires some older versions of those packages. I downgraded them in the requirements.txt but if this causes problems with other scripts we may need to split the requirements and have a more localized one. This script will effectively require Python 3.11 or lower to function until certain packages are updated to support 3.12

@maxachis could you please pick up the review on this one?

@EvilDrPurple Here I am, picking up the review!
I ran into the following error when installing the requirements, specifically when I got to
Collecting scikit-learn~=1.0.2 (from multimodal-transformers>=0.3.1->-r requirements.txt (line 21))
Here is the error.txt. There was more to it than that, but this seemed the most directly relevant part. Here, additionally, is the
pip_list.txt.
I got this error under two circumstances: One while attempting to run this on my personal computer, and one while running a Dockerfile built using the following instructions (which I'd separately developed to run some of my own tests): GithubTest.zip. So it's probably not a 'works on my machine' problem.
Could you have a look at this error (perhaps using the same dockerfile as I did) and see what's going on?

@maxachis After a good bit of trial and error I figured out the issue. Basically multimodal-transformers requires an older version of scikit-learn which cannot be installed using newer versions of Cython bundled in more recent Python releases. This effectively means that installing from requirements.txt requires Python 3.10 or lower to function without a workaround. I added a README to reflect this requirement and provide instructions for setting up the environment. Let me know if you are able to run on your end using a 3.10 instance.

@maxachis After a good bit of trial and error I figured out the issue. Basically multimodal-transformers requires an older version of scikit-learn which cannot be installed using newer versions of Cython bundled in more recent Python releases. This effectively means that installing from requirements.txt requires Python 3.10 or lower to function without a workaround. I added a README to reflect this requirement and provide instructions for setting up the environment. Let me know if you are able to run on your end using a 3.10 instance.

@EvilDrPurple Got it! I intend to get to it tomorrow as my first bit of PDAP work, but if I don't, please message me about it!

@EvilDrPurple Downloading the various requirements right now. One request I'll make (as a nit) is to try breaking down the requirements so that the requirements for this module specifically exist within the module. Otherwise, we're installing all the modules for the repository, including ones not relevant to this module.
Note that this is in contradiction with a much earlier refactoring I did, where I tried to consolidate the requirements into a single requirements.txt 🙃. Lesson learned on my part.

@EvilDrPurple I'm able to get it running successfully and perform training! However, as to whether that training works, I don't know. I'm willing to tentatively approve this but will defer to you and/or @josh-chamberlain if you feel it requires additional testing.
Additionally, I recommend that in the future you have the PR conform to this PR template, just because that makes it easier for me to run it and to know what to look for.

@maxachis docstring added, I also renamed one the clean_data.py scripts to split_data.py because I think that described better what is happening


Add a command to (re)generate .htaccess

Should be closed.
Already merged : https://github.com/friends-of-presta/fop_console/pull/26


[FLINK-19134][python] Add BasicArrayTypeInfo and coder for PrimitiveArrayTypeInfo for Python DataStream API.

What is the purpose of the change
Add BasicArrayTypeInfo and coder for PrimitiveArrayTypeInfo.
Brief change log

Added BasicArrayTypeInfo for arrays boxed primitive types.
Added coder for PrimitiveArrayTypes.

Verifying this change
This pull request has test case covered by test_primitive_array_type_info() and test_basic_array_type_info() in test_data_stream.py.
Does this pull request potentially affect one of the following parts:

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

Documentation

Does this pull request introduce a new feature? (no)
If yes, how is the feature documented? ( not documented)

@HuangXingBo Thanks a lot for your comments, I have updated the PR according to your suggestions, please have a look at it.

@shuiqiangchen Thanks a lot for the update. The PR already looks quite good to me.
Let's also wait for @dianfu to take a look.

@flinkbot run azure

@flinkbot run azure

The test failure is not related to this PR. Merging...


Fix code scanning alert - Different pragma directives are used

Tracking issue for:

[x] https://github.com/dgma/miller/security/code-scanning/1

https://github.com/dgma/miller/pull/2


Specs satisfying the StripeFinancialConnections (= 22.5.1, ~> 22.5.1), StripeFinancialConnections (~> 22.7.0) dependency were found, but they required a higher minimum deployment target.

I'm trying to upgrade to latest version, but when I launch pod install i got
Specs satisfying the `StripeFinancialConnections (= 22.5.1, ~> 22.5.1), StripeFinancialConnections (~> 22.7.0)` dependency were found, but they required a higher minimum deployment target.

My minimun deployment target is 12.4 and should be enough, accordin to the documentation.
platform :ios, '12.4'

This is probably an Xcode caching issue, try cleaning your build folder in Xcode:

and maybe even clearing the ~/Library/Developer/Xcode/DerivedData/ folder.
This issue might be semi relevant : https://github.com/stripe/stripe-react-native/issues/970
Closing since this isn't a bug with the SDK and is specific to your local project, but lmk if there's more I can do to help :)


Brought togehter the latest changes in script generation 2

Things left to do:

Using @vigji 's latest code to make sure that ratatlas.py conforms to the structure and standards of the other atlas generating scrips. (@FedeClaudi )
Making sure that mouseatlas.py and fishatlas.py use the metadata_utils.py functions to create the .txt and .csv files (@vigji )
Adding the cration of structures.csv to metadata_utils.py (@adamltyson )

https://github.com/brainglobe/brainatlas-api/pull/17#issuecomment-635265919
@adamltyson  I just moved it back! 😄
What do yous prefer?

What do yous prefer?

Maybe leave it as it is for now, and we can remove anything unnecessary later. There might be a situation where someone wants to use something in here to generate their own atlas (e.g an existing atlas but at a custom resolution).

ookay.
It would still be on github in that case, but I see your point.

also I don't know why the checks are failing. I haven't looked into all the tests that you've set up.

They're failing firstly because it's not black formatted. Also, the flake8 thing is very strict, so it might be worth installing that sooner rather than later.

I think before pushing, we should all make sure that:

Black has been run
flake8 has been run
All tests pass locally

Black has been run
flake8 has been run

Any way to automate this? I keep forgetting the commands and stuff

Any way to automate this? I keep forgetting the commands and stuff

See https://github.com/brainglobe/brainatlas-api/pull/15#issuecomment-635244518
If you install with pip install -e .[dev], pre-commit will be installed, so then you can run pre-commit install, and it will check the formatting with every commit (the first one will be slow as it all gets set up).

Thanks, I'll do this and update the PR.
This is some good stuff, I should implement it in brainrender as well!

I should've fix things

Sorry, the comments might have been premature!

Do we want to add something like interrogate to check for docstrings coverage?


Source code mode: Incorrect size for heading when using setext

This is a screenshot from source code mode:

As you can see, the increased font size for the heading applies only to the setext-style underline (the dashes), not the actual heading text ("Windows settings"). The heading size should apply to both (in other words, they should have the same length).

Typora's source code mode does not render text in a monospace font, therefore the heading text and the dashes used beneath them will not be the same length.
Here is a screenshot using Typora's "GitHub" theme for comparison:

Notice that the heading text and dashes (pink) are not the same length. This is because they are rendered using the OpenSans font. Notice that the inline code blocks are the same length. This is because they are rendered using a monospace font named "Lucida Console".

Thanks for the clarification. That explains it. Are you saying that themes do not have any control over the font used in source code mode?

Hi again,
Another screenshot: This does not seem to be about the fonts used being proportional, but rather (as reported) the font size.

As you can see, both the first-level and second-level heading texts are the same size as the normal text, even though the underline for the level-1 heading is bigger than the underline for the level-2 heading (which to me looks bigger again than the normal text). Furthermore, all the text here seems very much monospace to me, not proportional.

Also, here is how it looks with Typora's GitHub theme when I try it. As you can see, it lines up:


apply branch protection rules

Require Pull Request(master)

also ensure Do not allow bypassing the above settings is set
change the ci workflow to trigger on pull requests only

With this rule in place, start using the Rebase and Merge option. This will ensure flat history


Add breadcrumbs to all modules - New Feature

New Feature - Expand current implementation to all modules.
Overview of the problem
This is about the Spark Users module
Description
In order to enable breadcrumbs in all modules we must:

Move the init command from camp-routes to main-routes:
app.use(breadcrumbs.init()); - camps_routes.js line 9

Declare Home page - this will store a persistent home page throughout the app:
app.use(breadcrumbs.setHome({ name: 'home', url: '/' + req.params.lng + '/' }));

To any new route add to the  req a breadcrumb object or object array. Each object is made of a name and a url. The name should be the translation string. For examples see camps_routes (if not merged see PR #124 )

Add page names to locals.

In case we implement across the board - remove 'if' condition from page.jade (line 45).

Test links ;)

Hey, this is really great!
But, keep in mind that any solution should be uniform to all Spark core modules.
So please as much as possible keep this solution portable.

nice, thanks @guywarburg - sounds good to me


[Question] In micro_controller, about the shape of params

Thank you for your code.
https://github.com/melodyguan/enas/blob/2734eb2657847f090e1bc5c51c2b9cbf0be51887/src/cifar10/micro_controller.py#L178
This line of code is supposed to decide the type of op (e.g. conv 3x3 or 5x5). But the shape of self.w_soft, self.b_soft is [self.lstm_size, self.num_branches] and [1, self.num_branches].
I think they should be  [self.lstm_size, self.num_type_ops] and [1, self.num_type_ops] ?

In our code, num_branches is the class variable that means number of possible operations, which is num_type_ops in your understanding.


Ideas? show if vars have to come after the vars that will reveal them

[I think this may actually be a bug I dealt with along the way and it's no longer a problem. I think I took path 1 that's the slower path. We could look into path 2 and see how much/how little that improves test speed, but it may not be an issue at this point after the recent speed increase.]
The loop through the table is linear. For example, if a hidden field comes up in row 1, it won't be set. Later on in row 2, a variable is set that reveals that hidden field. The row of the hidden field has been passed and won't be looped through again.
! If you can avoid looking at the ideas below until you've thought about it
! a bit already, it might help you come up with different (maybe better) ideas.

Ideas:

Might slow tests down a lot: Whenever a variable is found and set on the page, start the loop over again. We can tell developers that putting their rows in an accurate linear order will speed up the tests, but that defeats part of the intentional BDD nature of the table.

Might slow things down less, but would make code more complex: Don't exclude 'disabled' fields on the page. Put every found row on a list. If the field is not disabled, set the field and take the row off the list. Later, loop through that list until all the variables are used up. [Then put whatever variables are left back into the list of remaining variables. They might crop up later and it'd be good feedback for the developer. I think we need a while with a for inside it.]

I'd love other ideas.

So I think I actually already solved this one during the speed up and forgot. The code was already close - we already have a loop that loops through the whole list repeatedly until no more variables are found. Kudos to us I think for thinking it through the first time even though I didn't remember it later.
The bug cropped up because we weren't skipping fields when they were disabled, so the code thought it was setting their values when it actually wasn't. :not([disabled]) already solved that. Previous to the speed up it hadn't been an issue because puppeteer somehow does some work to make sure it doesn't get non-visible elements most of the time.
It's possible that we could speed up tests by using method 2, but I'm not sure by how much. Someone can look into it, but we should get other priority items done first.

So I think I actually already solved this one during the speed up and forgot. The code was already close - we already have a loop that loops through the whole list repeatedly until no more variables are found. Kudos to us I think for thinking it through the first time even though I didn't remember it later.
The bug cropped up because we weren't skipping fields when they were disabled, so the code thought it was setting their values when it actually wasn't. :not([disabled]) already solved that. Previous to the speed up it hadn't been an issue because puppeteer somehow does some work to make sure it doesn't get non-visible elements most of the time.
It's possible that we could speed up tests by using method 2, but I'm not sure by how much. Someone can look into it, but we should get other priority items done first.


End-to-end tests fail on iOS 15.0 with a freshly scaffolded app

What's going on?
End-to-end tests fail with a freshly scaffolded app. iOS build works, test build works, but the actual run of the tests fails.
When the test suite tries to run, we first see the app open, and then immediately crash, then the tests fails with
detox[99221] ERROR: [DetoxExportWrapper.js/DETOX_INIT_ERROR]
 DetoxRuntimeError: Aborted detox.init() execution, and now running detox.cleanup()

HINT: Most likely, your test runner is tearing down the suite due to the timeout error
    at Detox.[_assertNoPendingInit] (/Users/gabriel/Workspace/paltap-io/TestApp/node_modules/detox/src/Detox.js:204:9)
    at Detox.beforeEach (/Users/gabriel/Workspace/paltap-io/TestApp/node_modules/detox/src/Detox.js:111:37)
    at DetoxExportWrapper.<computed> (/Users/gabriel/Workspace/paltap-io/TestApp/node_modules/detox/src/DetoxExportWrapper.js:87:32)
    at DetoxAdapterImpl.beforeEach (/Users/gabriel/Workspace/paltap-io/TestApp/node_modules/detox/runners/jest/DetoxAdapterImpl.js:28:22)
    at DetoxAdapterJasmine.beforeEach (/Users/gabriel/Workspace/paltap-io/TestApp/node_modules/detox/runners/jest/DetoxAdapterJasmine.js:19:5)

and then hangs.
Simulator logs give nothing at all.
If we then run the build manually in the simulator it launches without crashing.

Steps to reproduce

$ npx ignite-cli new TestApp
$ cd TestApp
$ yarn ios --> works.
$ yarn build:e2e --> works.
$ yarn test:e2e --> fails.

npx ignite-cli doctor results:
System
  platform           darwin
  arch               x64
  cpu                16 cores     Intel(R) Core(TM) i9-9880H CPU @ 2.30GHz
  directory          TestApp      /Users/gabriel/Workspace/paltap-io/TestApp

JavaScript (and globally-installed packages)
  node               14.17.6      /Users/gabriel/.nvm/versions/node/v14.17.6/bin/node
  npm                6.14.15      /Users/gabriel/.nvm/versions/node/v14.17.6/bin/npm
    detox-cli        18.20.1
    expo-cli         4.12.0
    npm              6.14.15
    yarn             1.22.15
  yarn               1.22.15      /Users/gabriel/.nvm/versions/node/v14.17.6/bin/yarn
    detox-cli        18.20.1

Ignite
  ignite-cli         7.5.0        /Users/gabriel/.npm/_npx/99982/bin/ignite
  ignite src         build        /Users/gabriel/.npm/_npx/99982/lib/node_modules/ignite-cli/build

Android
  java               1.8.0_292    /usr/bin/java
  android home       -            /Users/gabriel/Library/Android/sdk

iOS
  xcode              13.0
  cocoapods          1.11.2       /usr/local/bin/pod

I like the more specific configuration setting of device more than name, even if Detox is updated with the fix for Fishhook, which has been merged into master, but not yet released.
Combined with an update to e2e/README.md that provides some guidance for viewing installed simulators and their OS versions in Xcode, this change to the Detox config will fix this issue for freshly ignited apps.


Release 1.0.11

Added functionality for RANGE key

Resolves https://github.com/TechnologyAdvice/leadhub/issues/39

:accept: after the forEach bit!


 When I ran the model, the following error occurred:
Traceback (most recent call last):
File "/home/yangjingying/PycharmProjects/gae-master/gae/train.py", line 53, in
adj_train, train_edges, val_edges, val_edges_false, test_edges, test_edges_false = mask_test_edges(adj)
File "/home/yangjingying/PycharmProjects/gae-master/gae/preprocessing.py", line 101, in mask_test_edges
assert ~ismember(test_edges_false, edges_all)
File "/home/yangjingying/PycharmProjects/gae-master/gae/preprocessing.py", line 62, in ismember
rows_close = np.all(np.round(a - b[:, None], tol) == 0, axis=-1)
MemoryError

Have you solve this issue?@yiyGo,if so how to deal with it ,thanks!


Interactive MSQ profile

Motivation
Druid 24 included a task-based multi-stage query engine proposed in #12262. This has proved useful for DML (REPLACE, INSERT) and querying directly from deep storage.
This proposal is to introduce the natural next evolution: an interactive "profile" of the engine. The same engine is configured to run interactively, including changes such as:

Read locally-cached data instead of pulling from deep storage.
Multithreaded workers inside shared JVMs, leveraging the work from #17057, #17048.
In-memory shuffles, leveraging the work from #16168, #16790, #16775.
No whole-worker fault-tolerance, which saves the need to checkpoint state to durable storage. (RPC fault tolerance through retries would still happen.)

The main purpose of this engine is to provide a way to run queries that are too lightweight for the task-based MSQ engine to make sense, but too heavyweight for the standard native query engine to make sense. A good example would be a GROUP BY with an intermediate resultset of hundreds of millions of rows. In general this engine would specialize in the sort of midweight, ad-hoc queries that are common in the data warehousing world. I believe with some additional work it would also be possible to run lightweight, high QPS queries competitively with the standard native query engine.
Proposed changes
Name
In the initial PR I used the name dart for this profile of the engine. Darts are lightweight and go fast, which are good qualities in an interactive query engine. It even has a possible backronym: "Distributed Asynchronous Runtime Topology".
API
Initially I'm proposing an API that is compatible with the SQL query API, to make it easy to try out the new engine.
To issue a query, POST /druid/v2/sql/dart/ the same form of JSON payload that would be accepted by /druid/v2/sql/. Results are also in the same format. This is a synchronous API, although internally the engine is asynchronous, so it is definitely possible to introduce an asychronous API later on.
To issue a query and also return a report with stages, counters, etc, POST /druid/v2/sql/dart/?fullReport. This is like an
EXPLAIN ANALYZE. The report is in the same format as the reports generated by the task-based engine.
To see a list of running queries (a feature that the native engine does not have), GET /druid/v2/sql/dart/.
To cancel a query, DELETE /druid/v2/sql/dart/{sqlQueryId}.
To check if the engine is enabled, GET /druid/v2/sql/dart/enabled (returns 200 or 404).
Servers and resource management
Controllers run on Brokers (one per query) and the workers run on Historicals. Resource management would be bare-bones in the initial version, limited to simple controls on the number of concurrent queries that can execute on each server.
On Brokers, there are three configs:

druid.msq.dart.enabled = true to enable Dart.
druid.msq.dart.controller.concurrentQueries provides a limit to the number of query controllers that can run concurrently on that Broker. Additional controllers beyond this number queue up. Default is 1.
druid.msq.dart.query.context.targetPartitionsPerWorker sets the number of partitions per worker to create during a shuffle. Generally this should be set to the number of threads available on workers, so they can process shuffled data fully multithreaded.

Brokers only run controllers, so they do not need meaningful CPU or memory resources beyond what is needed to gather partition statistics for global sorts. (And anyway, I'd like to use fewer global sorts in the future; see "Future work" around hashLocalSort.)
On Historicals, there are three configs:

druid.msq.dart.enabled = true to enable Dart.
druid.msq.dart.worker.concurrentQueries provides a limit to the number of query workers that can run concurrently on that Historical. Default is equal to the number of merge buffers, because each query needs one merge buffer. Ideally this should be set to something equal to, or larger than, the sum of the concurrentQueries setting on all Brokers.
druid.msq.dart.worker.heapFraction provides a limit to the amount of heap used across all Dart queries. The default is 0.35, or 35% of heap.

The resource management model is very simple in the initial version. I expect it will evolve over time:

Concurrency: limit on concurrent queries at the Broker and at each Historical, given by server configuration.
Broker HTTP threads: each query currently ties up an HTTP thread. But it doesn't necessarily need to; this is only happening because of hooking into the existing SqlResource code. The engine is internally async.
Historical HTTP threads: not tied up; the Broker-to-Historical protocol is async.
Memory: each concurrently-running query gets one merge buffer and one slice of heap. Each query gets the same size of heap slice. Standard processing buffers are not used.
CPU: each query can use all available CPUs in a fine-grained way. Because memory is allocated to the query, not to a processing thread, it is possible to time-slice the processing pool more finely than with the standard query engine.
Disk: usage is currently uncontrolled; it is possible to fill up local disk with a heavyweight enough query.
No timeouts, priorities, or lanes. (yet.)
The "Future work" section includes thoughts on how resource management can evolve over time.

The initial version does not run on realtime tasks, meaning realtime data is not included in queries.
Operational impact
None if the engine is disabled or if queries are not being issued. If queries are being issued, on Historicals, Dart queries use the same merge buffers and processing pool as regular native queries, so would potentially conflict with other queries that need those resources. They also use up to 35% of heap space if actually running.
On Brokers, Dart queries use the same HTTP threads as regular native queries, and could conflict there as well.
The API and all configuration parameters should be considered experimental and subject to breaking changes in upcoming Druid releases, as the initial version of the feature evolves. The ability for Dart queries to function properly in a mixed-version environment (such as during a rolling update) is also not be guaranteed for these initial experimental releases. Nevertheless, this would have no impact on regular queries.
Future work
Some thoughts on future work items.
System:

The task-based profile always pulls data from deep storage, and the initial version of the interactive profile always uses locally pre-cached data. Some hybrid is a clear next move.
Include realtime data, using workers running on realtime tasks.
Graceful shutdown of Historicals (currently, the async nature of the API means that when a Historical is TERMed, it exits immediately, even if a query is in flight).

Resource management:

Set the "concurrentQueries" and "targetPartitionsPerWorker" parameters automatically based on available resources. We should allow user-supplied configuration but it should not be required to get a good baseline level of performance.
Implement timeouts, priorities, and lanes.
Allow queries to burst up to an "attic" of additional memory. (Currently all queries get the same amount of memory, and need to use disk when they run out.)
Automatic reprioritization or relaning of queries based on runtime characteristics. Experience tells us that it is difficult for users to set good priorities on all queries before they are issued. There is a need for the system to determine the appropriate priority on its own. I think this will need to involve some degree of canceling or suspending, and then restarting, expensive queries in some cases.
Release workers when they are no longer needed. (Currently workers are held even if not all are needed for future stages.)
Controls on disk usage.

Performance items:

Multithread hashLocalSort shuffles. Currently only one partition is sorted at a time, even on a multithreaded worker. This is the main reason the initial version is using globalSort so much, even though globalSort involves more overhead on the controller.
Use hashLocalSort for aggregation rather than globalSort, once it's multithreaded, to reduce dependency on the controller and on statistics gathering.
Aggregate (combine) opportunistically during sorting.
For aggregation, use per-thread hash tables that persist across segments. Currently each segment is processed with its own hash table, then the contents of the hash tables are sorted. It would be better to continue the hash aggregation as far as possible.
Improve maximum possible QPS by reducing overheads on simple queries like SELECT COUNT(*) FROM tbl.
Add QueryMetrics to reports for better insight into performance.
Segment-level and result-level caching (currently: no caching).

I am still reviewing the changes, so it might be moot once I complete the review:

they do not need meaningful CPU or memory resources beyond what is needed to gather partition statistics for global sorts
The controller can consume up to a maximum of 300MB of heap space for the collection of statistics, and this maximum seems a lot given that it will be per query, if compared with the default value of something like maxSubqueryBytes.

For reference, a broker with 20 GB of heap space, and 50 max concurrent queries and no lookups would allocate 0.5 * 1/50 * (20GB) of heap space per query for inlining results which is 200MB, while each Dart query can theoretically take up to 300MBs. This parity will be more for brokers with smaller heap sizes. Do we require some limiting for the brokers at the moment (like we do with subqueries) or would we take this up once we start tuning concurrency?

The controller can consume up to a maximum of 300MB of heap space for the collection of statistics, and this maximum seems a lot given that it will be per query, if compared with the default value of something like maxSubqueryBytes.
For reference, a broker with 20 GB of heap space, and 50 max concurrent queries and no lookups would allocate 0.5 * 1/50 * (20GB) of heap space per query for inlining results which is 200MB, while each Dart query can theoretically take up to 300MBs. This parity will be more for brokers with smaller heap sizes. Do we require some limiting for the brokers at the moment (like we do with subqueries) or would we take this up once we start tuning concurrency?

The heap space used by partition statistics is capped to 15% of the overall Broker heap, and is split across all possible controllers based on the maximum Dart concurrency. So a Broker with 20 GB of heap and 50 max concurrent Dart queries would use at most 60 MB for partition statistics per controller. Check out DartControllerMemoryManagementModule for where this is set up.
Another thing is that I expect we won't be gathering partition statistics for most queries for very long. When these two future-work items are complete, then globalSort (and the statistics gathering) will only be needed when a query has an ORDER BY without a LIMIT at the outer level. Anything else would be able to use hash partitioning with local sorting, skipping stats gathering.

Multithread hashLocalSort shuffles. Currently only one partition is sorted at a time, even on a multithreaded worker. This is the main reason the initial version is using globalSort so much, even though globalSort involves more overhead on the controller.
Use hashLocalSort for aggregation rather than globalSort, once it's multithreaded, to reduce dependency on the controller and on statistics gathering.

There are a number of web console changes that are spread out between https://github.com/apache/druid/pull/17132, https://github.com/apache/druid/pull/17135, and https://github.com/apache/druid/pull/17147 but that were all developed together with the Dart engine as the prime motivation. Primarily the stage detail view has been updated.

Notably:

There is a visualization column that is added to showcase the structure of the stage dependency graph
There timing column has been improved to visualize a Gantt chart letting you intuitively know which stages were running concurrently (stages running concurrently is itself a new feature!)
There is a new column showing the CPU timing counters that are now available on MSQ task and Dart queries.
The output column has been condensed from two columns to afford extra space for the other additions.
Last but not least, there is a new tooltip with additional data that you will see when hovering over some of the UI elements (seen in the screenshot showing the clustering in the Output column of Stage4).

I've been doing some benchmarking of the version of this similar to the one that will be included in Druid 31 (as the experimental Dart engine). So far, it looks promising; bottom line from what I've seen is:

Dart outperforms native on individual heavyweight queries (high cardinality groupbys + distinct counts, large subqueries). This is mostly because of being able to fully parallelize through the entire query. On one query I tested below, the outperformance was nearly 7x (284s -> 42s) on an 8-core machine (my laptop).
Native and Dart have similar performance on individual lightweight queries.
Native outperforms Dart on high concurrency lightweight queries.

These results are in line with the initial focus on more complex, multi-stage queries. The performance on lightweight queries is better than I expected, and I think shows that if we put some work into it then the new engine could handle the whole spectrum of workloads.
These findings are from some test queries on the NYC Taxi dataset. There are benchmarks floating around that use the following four queries, which are all pretty lightweight:

Q1: SELECT cab_type, COUNT(*) FROM trips GROUP BY cab_type
Q2: SELECT passenger_count, AVG(total_amount) FROM trips GROUP BY passenger_count
Q3: SELECT passenger_count, FLOOR(__time TO YEAR), COUNT(*) FROM trips GROUP BY passenger_count, FLOOR(__time TO YEAR)
Q4: SELECT passenger_count, FLOOR(__time TO YEAR), trip_distance, COUNT(*) FROM trips GROUP BY passenger_count, FLOOR(__time TO YEAR), trip_distance ORDER BY FLOOR(__time TO YEAR), COUNT(*) DESC

I added two more, exercising high-cardinality groupbys and count-distincts:

Q5: SELECT ROUND(pickup_latitude, 3), ROUND(pickup_longitude, 3), ROUND(dropoff_latitude, 3), ROUND(dropoff_longitude, 3), COUNT(*) FROM trips GROUP BY 1, 2, 3, 4 ORDER BY 5 DESC LIMIT 1000
Q6: SELECT ROUND(pickup_latitude, 3), ROUND(pickup_longitude, 3), ROUND(dropoff_latitude, 3), ROUND(dropoff_longitude, 3), COUNT(DISTINCT trip_id) FROM trips GROUP BY 1, 2, 3, 4 ORDER BY 5 DESC LIMIT 1000

I also added a "needle-haystack" query, which selects just two rows matching a highly selective filter:

Q7: SELECT COUNT(*) from trips_60m where dropoff = '0101000020E6100000000000E0F87E52C00000008090564440'

I loaded an abbreviated version of this dataset on my laptop (60 million rows) and ran the test queries native and Dart. The results were (in ms):

Q1: 79 (native), 91 (Dart) [median of 5] <-- similar speeds
Q2: 312 (native), 324 (Dart) [median of 5] <-- similar speeds
Q3: 185 (native), 414 (Dart) [median of 5] <-- native faster
Q4: 611 (native), 1312 (Dart) [median of 5] <-- native faster
Q5: 37223 (native), 25110 (Dart) [median of 3] <-- Dart faster
Q6: 284314 (native), 42681 (Dart) [just 1] <-- Dart faster
Q7: 6 (native), 7 (Dart) [median of 100] <-- similar speeds

I looked into the factors driving the different performance on Q3, Q4, Q5, and Q6:

Q3: Dart is slower because it's missing the timestampResultField + timestampResultFieldGranularity optimization that native has, which swaps out timestamp_floor for granularity. This is activated for native for the FLOOR(__time TO YEAR).
Q4: Dart is slower mostly because of the same missing FLOOR(__time TO YEAR) optimization as Q3. A smaller factor comes from the slightly larger resultset here (82,418 final results; 508,581 intermediate results before cross-segment merge). With the native engine, the cross-segment merge happens uses a single concurrent hash table. With Dart, the cross-segment merge uses a sort. The concurrent hash table performs better and wins over the sort. [one of the "future work" items is relevant to this.]
Q5: Some spilling and disk-based sort is needed with both engines. Dart parallelizes through the entire query, whereas native gets bottlenecked on merging the spill files.
Q6: Again, spilling is required with both engines. Due to the COUNT(DISTINCT trip_id), there's also a large subquery. Dart parallelizes through the entire query and handles it nearly 7x faster. Native gets bottlenecked at processing the subquery.

Finally, I ran a concurrency test with the "needle-haystack" Q7, using 50 threads issuing 500 queries each, back-to-back as fast as they could. The system was configured with druid.msq.dart.controller.concurrentQueries = 25, druid.msq.dart.worker.concurrentQueries = 25, and druid.query.scheduler.numThreads = 25, so both native and Dart got to run 25 concurrent queries. The results were 1529 QPS (native), 730 QPS (Dart). There are various areas of potential improvement for this kind of workload, such as reducing the number of controller<->worker messages transferred during a query, processing multiple segments in a single frame processor, logging more quietly, etc.


autocomplete could not remove initial @ for @include => @@include (in sass)

Prerequisites

[ ] Can you reproduce the problem in safe mode?
[X] Are you running the latest version of Atom?
[ ] Did you check the debugging guide?
[ ] Did you check the FAQs on Discuss?
[ ] Are you reporting to the correct repository?
[ ] Did you perform a cursory search to see if your bug or enhancement is already reported?

For more information on how to write a good bug report or enhancement request, see the CONTRIBUTING guide.
Description
sass include autocomplete create a extra @
[Description of the bug or feature]
Steps to Reproduce

[First Step]
create a @mixin
[Second Step]
call this @mixin with @include
[and so on...]
select to use auto complete dropdown

atom will not remove the initial @ so end up @@include
Expected behavior: [What you expected to happen]
Actual behavior: [What actually happened]
Versions
You can get this information from executing atom --version and apm --version at the command line. Also, please include the OS and what version of the OS you're running.

See https://github.com/atom/autocomplete-plus/issues/788#issuecomment-254920932 for the explanation as to why this is not a bug and is working as intended.


Add sst install command to steps

Not sure if I missed a step elsewhere but I needed to run sst install after sst init, in order for a new Next.js app to successfully launch in dev mode, following the steps in this example.

I though that should be the case but I had to do the following to get my Next.js site to deploy:

install SST (macos)
sst upgrade
npx create-next-app@latest
cd into next-app
sst init
sst deploy (failed deployment with an error relating to mqtt provider)
sst install
sst deploy (sucessfully deployed stack)

It's possible at some point I mixed something up though

Hmm yeah this should be automatic

Will close for now, it's possible I made a mistake in the setup or unique problem on my machine


Syntax to get this: this into typings for function?

I'm trying to wind up with the following Typescript
class Event<T extends Function> {
  addListener(cb: T);
}
class Base {
  foo: string;
  evt: Event<(this: this, arg: number) => void>;
}

My first impulse was
/**
 * @callback Base.Callback
 * @this Base
 */
class Base {
/**
 * @type {Event<Base.Callback>}
 */
  evt = ...;
}

but that gives me Event<(this: Base, arg: number) => void>, which means that this won't work:
class Sub extends Base {
  bar: number;
}
const s = new Sub();
s.evt = function(arg) {
  this.bar = 4;
}

I tried values of the @this tag like "this" or "Base.this". The former makes bad typings, because the callback is defined in a merged namespace Base, so this doesn't exist there.  The latter isn't valid syntax.  I also tried just shoving the actual Typescript into the @type tag, with no @callback at all, but the JSDoc parser trips over @type {Event<(this: this, arg: number) => void}>.

Update: I tried the Closure syntax for this-type.  @type {Event<function(this:this)>} doesn't choke JSDoc, at least.  The bad news is that this emits in tsd-jsdoc as Event<(arg0: this, arg1: this) => void>.  It looks like the : is being treated as a , or something?
Closure also specifies function(new: Foo) but tsd-jsdoc turns that into the invalid emit (arg0: new () => , arg1: Foo) => void -- note the function arrow with an empty space where the return type would be.  Something's weird with handling colons inside of function(...) in a type context.

Have you tried @this