Return value of Http\Client\Curl\PromiseCore::getException() must implement interface Throwable, instance of Nyholm\Psr7\Response

PHP message: PHP Fatal error: Uncaught TypeError: Return value of Http\Client\Curl\PromiseCore::getException() must implement interface Throwable, instance of Nyholm\Psr7\Response returned in /var/www/releases/20191015093018/vendor/php-http/curl-client/src/PromiseCore.php:194

Stack trace:
#0 /var/www/releases/20191015093018/vendor/php-http/curl-client/src/CurlPromise.php(103): Http\Client\Curl\PromiseCore->getException()
#1 /var/www/releases/20191015093018/vendor/sentry/sentry/src/Transport/HttpTransport.php(110): Http\Client\Curl\CurlPromise->wait()
#2 /var/www/releases/20191015093018/vendor/sentry/sentry/src/Client.php(117): Sentry\Transport\HttpTransport->send(Object(Sentry\Event))
#3 /var/www/releases/20191015093018/vendor/sentry/sentry/src/Client.php(103): Sentry\Client->captureEvent(Array, Object(Sentry\State\Scope))

TypeError: Return value of Http\Client\Curl\PromiseCore::getException() must implement interface Throwable, instance of Zend\Diactoros\Response returned
#25 /vendor/php-http/curl-client/src/PromiseCore.php(194): Http\Client\Curl\PromiseCore::getException
#24 /vendor/php-http/curl-client/src/CurlPromise.php(103): Http\Client\Curl\CurlPromise::wait
#23 /vendor/sentry/sentry/src/Transport/HttpTransport.php(110): Sentry\Transport\HttpTransport::send
#22 /vendor/sentry/sentry/src/Client.php(117): Sentry\Client::captureEvent
#21 /vendor/sentry/sentry/src/State/Hub.php(146): Sentry\State\Hub::captureEvent
#20 /vendor/sentry/sentry/src/Monolog/Handler.php(73): Sentry\Monolog\Handler::Sentry\Monolog\{closure}
#19 /vendor/sentry/sentry/src/State/Hub.php(87): Sentry\State\Hub::withScope
#18 /vendor/sentry/sentry/src/Monolog/Handler.php(74): Sentry\Monolog\Handler::write

The problem seems to be in \Http\Client\Curl\PromiseCore::reject(): $this->exception is set to the return value of an onRejected callback, but these are apparently expected to return a response or throw an exception, not to return an exception. (Especially, you definitely cannot rely on them returning an exception, but should at least check if that is the case.) See \Http\Client\Common\Plugin\RetryPlugin::handleRequest() in the php-http/client-common package for an example.

@joelwurtz could you maybe help sort out what would be the correct behaviour?


Example script that takes snapshots

Note: This PR is based on https://github.com/livekit/client-sdk-python/pull/10

 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.

Hi, thanks but we may have to create a server sdk before


Upgrade Gradle version in "github-integration"

Upgrade Gradle version in github-integration module.
Drop jcenter support.

Superseded with #1307


haste-compiler-0.5.2 does not compile

Citing from http://hydra.cryp.to/build/1378187/nixlog/1/raw:
Building haste-compiler-0.5.2...
Preprocessing library haste-compiler-0.5.2...
[ 1 of 49] Compiling Haste.Version    ( src/Haste/Version.hs, dist/build/Haste/Version.o )
[ 2 of 49] Compiling Haste.GHCPaths   ( src/Haste/GHCPaths.hs, dist/build/Haste/GHCPaths.o )
[ 3 of 49] Compiling Paths_haste_compiler ( dist/build/autogen/Paths_haste_compiler.hs, dist/build/Paths_haste_compiler.o )
[ 4 of 49] Compiling Haste.Parsing    ( libraries/haste-lib/src/Haste/Parsing.hs, dist/build/Haste/Parsing.o )
[ 5 of 49] Compiling Haste.Environment ( src/Haste/Environment.hs, dist/build/Haste/Environment.o )

src/Haste/Environment.hs:156:13:
    Ambiguous occurrence ‘openFile’
    It could refer to either ‘Control.Shell.openFile’,
                             imported from ‘Control.Shell’ at src/Haste/Environment.hs:16:1-36
                             (and originally defined in ‘shellmate-0.2.1:Control.Shell.Handle’)
                          or ‘System.IO.openFile’,
                             imported from ‘System.IO’ at src/Haste/Environment.hs:18:1-16
                             (and originally defined in ‘GHC.IO.Handle.FD’)

src/Haste/Environment.hs:157:26:
    Ambiguous occurrence ‘hGetLine’
    It could refer to either ‘Control.Shell.hGetLine’,
                             imported from ‘Control.Shell’ at src/Haste/Environment.hs:16:1-36
                             (and originally defined in ‘shellmate-0.2.1:Control.Shell.Handle’)
                          or ‘System.IO.hGetLine’,
                             imported from ‘System.IO’ at src/Haste/Environment.hs:18:1-16
                             (and originally defined in ‘GHC.IO.Handle.Text’)

I put an upper bound on the shellmate dependency on the versions currently on Hackage. This fixes the problem on my end. Can you confirm?

NixOS has updated to shellmate version 0.2.1 already, so an upper bound does not help us unfortunately, it just makes the build fail in a different way.

Oh, then I'll hurry up and push 0.5.3 out the door which fixes the problem.

That would be great!

0.5.3 is live as of yesterday. Does this solve the problem?

Yes, the new version builds fine on NixOS: http://hydra.cryp.to/job/nixpkgs/haskell-updates/haskellPackages.haste-compiler.x86_64-linux. Thank you very much for the fix!


Add a meaningful benchmark

For the sake of fairness, you should include a benchmark of nontrivial real-world code that consists of more than one statement in your documentation. As it stands, you are comparing of what I presume is a single call to your runtime to the bootstrap of a complex JIT... seriously :smiling_imp: ?

For the sake of fairness, this project is just getting started and only very limited language features are implemented. So the console.log is the only thing that is benchmarkable. I have already stated clear in the README. Please contribute if you want to see more meaningful benchmark :)

If current functionality is that limited, I would suggest removing the benchmark alltogether and wait until there is actually something to benchmark. The way it stands, the benchmark is meaningless at best and potentially misleading :smirk:

Why removing? I don't think it's really "meaningless". The benchmark is about program startup time and it's meaningful to a lot of programs. And it also proves the approach Godzilla takes is beating Node in one way currently. I made it explicit though in the README: https://github.com/jingweno/godzilla/pull/6.


[stable/rabbitmq] Fix chart not being upgradable by removing mutable label from VolumeClaimTemplate

What this PR does / why we need it:
Major version bump: Fix chart not being upgradable by removing 'chart' label from  spec.VolumeClaimTemplate.
Special notes for your reviewer:
See ~~https://github.com/helm/charts/issues/7680~~ https://github.com/helm/charts/issues/7803.
cc @prydonius @tompizmor @sameersbn @carrodher @juan131

Waiting for https://github.com/helm/charts/issues/5657 to be settled before updating this PR.

/hold
However, I still appreciate any other feedback not related to this "document how to upgrade" thing.

Updated to solve https://github.com/helm/charts/issues/7803 since https://github.com/helm/charts/issues/7680 and https://github.com/helm/charts/issues/7726 has been done in https://github.com/helm/charts/pull/7848

/unhold

Thanks for the update @desaintmartin

/ok-to-test
/lgtm

/unhold

/hold cancel


Write globe depth when picking

The globe used to only draw the depth plane on a pick pass so geometry on the other side of the globe  would not get picked. This change makes the tiles of the previous frame render depth only on a pick.
You can test by:

Going to the picking Sandcastle example.
Add the line scene.globe.depthTestAgainstTerrain = true to the example
Run.
Click the pick entity button.
Rotate so part of the billboard intersects the globe.

When run in master, the billboard will be picked where it is rendered under terrain. In this branch, it will not.

Update CHANGES.md.
This looks good, just curious about:

We talked about moving this into Scene.js. Do you think that is a good idea?

I am fine with the good as is though.

Tests and Sandcastle look good.
@bagnell is moving the depth plane in a separate PR.
Update CHANGES.md in the separate PR or master.


Truffle Migrate localnet Ganache is not working

Hi Guys,
Somebody has a tutorial to truffle migrate a smart contract to Harmony Ganache CLI?
Listen, I need to deploy smart Contracts locally using Hamony Ganache
Thanks

I am trying to deploy a smart contract locally with the docker image, by using the Dapp example, but this issue is generated


git sync: ask to remove a branch from the local machine if its remote has been deleted

As a developer syncing a feature branch that is a child of another feature branch whose tracking branch is gone
I want to be asked if the obsolete branch should be removed from my machine
So that my local Git client remains in sync with what's going on in the team.

git sync asks whether to delete the obsolete branch
if answer is yes, the branch is 'git kill'ed from the local machine (deleted, removed from branch hierarchy)
if answer is no, the branch is pushed back up to GitHub

duplicate of #663


How can I pay a bounty for an issue ?

The problem I'm trying to solve:

I want to put money on an issue to motivate its resolving
How I imagine hub could expose this functionality:

Hi, I believe this is a question about GitHub.com, the website. This issue tracker is for a command-line utility called hub, not the website itself. For reporting bugs and requesting features for GitHub the website, please go to https://github.com/github/feedback or contact Support directly at https://github.com/contact. Alternatively, you could visit or ask in https://github.community. Thank you!


Nano: WindowsFeature resource does not work on Nano because Get-WmiObject command not found

If I try to use the WindowsFeature resource, such as in the following, on a Windows 2016 Nano server:
Configuration Webserver
{
    Import-DscResource -ModuleName xWebAdministration

    Node "<IP_ADDRESS>"
    {
        WindowsFeature "Webserver"
        {
            Name = "Web-Server"
            Ensure = "Present"
            IncludeAllSubFeature = $TRUE
        }
    }
}

On Nano, I get the following error:
VERBOSE: [nano]: LCM:  [ Start  Test     ]  [[WindowsFeature]Webserver]
The term 'Get-WmiObject' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
    + CategoryInfo          : ObjectNotFound: (Get-WmiObject:) [], CimException
    + FullyQualifiedErrorId : CommandNotFoundException
    + PSComputerName        : <IP_ADDRESS>

You cannot call a method on a null-valued expression.
    + CategoryInfo          : InvalidOperation: (:) [], CimException
    + FullyQualifiedErrorId : InvokeMethodOnNull
    + PSComputerName        : <IP_ADDRESS>

VERBOSE: [nano]: LCM:  [ End    Test     ]  [[WindowsFeature]Webserver]  in 0.2670 seconds.

On Nano, the Get-WmiObject command is not defined:
[<IP_ADDRESS>]: PS C:\Users\Administrator\Documents> Get-Command Get-WmiObject
Get-Command : The term 'Get-WmiObject' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
    + CategoryInfo          : ObjectNotFound: (Get-WmiObject:String) [Get-Command], CommandNotFoundException
    + FullyQualifiedErrorId : CommandNotFoundException,Microsoft.PowerShell.Commands.GetCommandCommand

We may be able to replace Get-WmiObject with Get-CimInstance, which is defined on Nano.

@NickMRamirez Have you tested this fix on a Nano server?

Closing this as this seem to have been resolved in PR #258


chore: update codeowners to reflect changes in ownership

This removes the TORuS team from having library
responsibilities for this repository.
Signed-off-by: Jennifer Davis<EMAIL_ADDRESS>

Closing as obsolete


Dropout Bug in Prenet

I find a huge bug about dropout in Prenet, and maybe it's the final reason that your repo's implementation often cannot get good alignments with small reduction factor.
In tf.layers.dropout, you don't set the training flag to true when training. So in dropout's implementation, it just applies an identity op on the inputs.

Oh wow, I think you're right. That is a huge bug! I'll try training with that fixed and see what happens.

hey,
any conclusions so far?

Nice catch!  Also interested in this.
Going to do some augmentation tests soon, so would be nice to have insight if this was really missing previously or not.

After making the change to fix dropout, the model eventually learns to align during training, but there seem to be alignment issues more frequently during eval, and subjectively, the output sounds worse. This is the opposite of what I would have expected, and I need to look into why -- but unfortunately, I don't have a whole lot of time these days...

Can you now get alignment using small reduction factor? What about using dropout during eval to introduce output variance?

Hi @keithito  @npuichigo , it seems that training=True, droprate=0.0 is equivalent to training=False. It is wired that the results are different.
nn.dropout returns x / (1 - rate) * dropout_mask.
layer.Dropout returns nn.dropout(x, 1 - rate) if training else x
So if training=False, layer.Dropout returns x, if training=True and rate=0.0, layer.Dropout also returns x, since dropout_mask are all 1s.

Hi @keithito, you said that when fixing dropout, the model still cannot learn to align during training before. I found that there maybe another mistake that you should put DecoderPrenetWrapper outside AttentionWrapper. Otherwise, because the AttentionWrapper concatenates the input and previous attention vector before calling the internal cell, dropout in the DecoderPrenetWrapper will drop 50% information of previous attention vector, which makes alignments hard to learn.
Here's what I mean.
attention_cell = AttentionWrapper(
        GRUCell(hp.attention_depth),
        BahdanauAttention(hp.attention_depth, encoder_outputs),
        alignment_history=True,
        output_attention=False)
attention_cell = DecoderPrenetWrapper(attention_cell, is_training, hp.prenet_depths)


~45% speed improvement

This references issue #79, and uses a slightly different replacement for np.random.choice to get the same speed improvement without changing the number or nature of the calls to the prng.

Coverage remained the same at 99.228% when pulling 0465734a1482187509809d4403b18dffa78124e1 on wdwvt1:speed into ef3d7adf50ed9e92a914e9e3dcd55bfc1c46d859 on biota:master.

Coverage remained the same at 99.228% when pulling<PHONE_NUMBER>7b10ac08d3ea0e9785b6ebf8bbbaa2 on wdwvt1:speed into ef3d7adf50ed9e92a914e9e3dcd55bfc1c46d859 on biota:master.

@gregcaporaso - all the tests pass, but I've changed the innermost loops of gibbs_sampler so I'd like you to take a look whenever you have a chance.

This is pretty cool :)

Looks good, thanks @wdwvt1!

Thanks Greg!
On Fri, Sep 23, 2016 at 8:26 AM, Greg Caporaso<EMAIL_ADDRESS>wrote:

Merged #80 https://github.com/biota/sourcetracker2/pull/80.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/biota/sourcetracker2/pull/80#event-800558464, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AA__-V8IDCW7umlzTxupIRLVTmDNKB-sks5qs--ogaJpZM4J8inm
.


[BugFix] DictMappingRewriter support compoundPredicate (backport #15737)

What type of PR is this：

[x] BugFix
[ ] Feature
[ ] Enhancement
[ ] Refactor
[ ] UT
[ ] Doc
[ ] Tool

Which issues of this PR fixes ：

Fixes #
Problem Summary(Required) ：

backport #15737)
Checklist:

[x] I have added test cases for my bug fix or my new feature
[ ] This pr will affect users' behaviors
[ ] This pr needs user documentation (for new or modified features or behaviors)

[ ] I have added documentation for my new feature or new function

Bugfix cherry-pick branch check:

[x] I have checked the version labels which the pr will be auto backported to target branch

[ ] 2.5
[ ] 2.4
[ ] 2.3
[ ] 2.2

starrocks_fe_unittest

run starrocks_fe_unittest


Donations Failing Tests

FILL OUT THE FORM BELOW OR THE ISSUE WILL BE AUTO-CLOSED
Issue Type (check one)

[ ] Bug Report
[ ] Feature Idea
[ ] Documentation
[ ] Technical Discussion
[x] Tests

Description (Please type a clear and concise description below)
The tests were failing after implementing #127, so I commented them so as to be able to push and merge, as the feature was MVP critical.
Tests can be found at ./pages/Donations.test.js

Will take a look!

Fix is here https://github.com/Say-Their-Name/say-their-names-web/pull/133


Feat 20230525

Fix #366
Fix #374

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

GitHub release
v6.19.0

Your semantic-release bot :package::rocket:


partial_ratio_alignment giving wrong index values

partial_ratio_alignment giving wrong index values for source when the destination match is longer than the source match.
s1 = "a certain string"; s2 = "certainly"; res = fuzz.partial_ratio_alignment(s1, s2); print(res);
Output: ScoreAlignment(score=77.77777777777779, src_start=0, src_end=9, dest_start=0, dest_end=9)
Notice the src is (0, 9) instead of (1, 8).
Is this an expected behaviour?

fuzz.partial_ratio is using a sliding window of len(shorter_string) to determine the optimal alignment. fuzz.partial_ratio_alignment returns the indexes of one alignment which results in the optimal score.
In your example the optimal alignment found this way is: "a certain" <-> "certainly".


Other RollBonus?

RangedSpellAttack
MeleeSpellAttack
RawAbility
SkillCheck
AttackProficiencyBonus
DeathSavingThrow
RangedWeaponAttack
MeleeWeaponAttack

Enhancement somehow?

SavingThrow form is RollBonus(SavingThrow, <value>, |<Ability>|) where Ability is optional

RollBonus(Damage,val) also exists? how is this different than DamageBonus(val)


Starting a simple tunnel

Just found this repo / pypi package. Really nice to see this available.
Just one minor question, since the documentation is quite technical, and does not refer to functionality but only to technical features.
I want to use this library to create a tunnel like I do during normal development on a daily basis, using the cli: ngrok http 5000. But I cannot find the actual endpoint that I need to use for that. Is this even possible, or is there more to it?

hey @whyscream this library is purely about making requests to the ngrok HTTP API: https://ngrok.com/docs/api
we're working on a separate package which will allow you to programmatically start tunnels which will have its own repo and package


Error "Applying Character set: utf-8" for theguardian.com

I'm seeing this error in the System Log when running for theguardian.com:
Applying Character set: utf-81. plugins.local/feediron/bin/fi_logger.php(33): trigger_error(Applying Character set: utf-8, 1024)
2. plugins.local/feediron/bin/fi_helper.php(59): log(1, Applying Character set: utf-8)
3. plugins.local/feediron/filters/fi_mod_xpath/init.php(8): getDOM(
<!DOCTYPE html>
<html id="js-context" class="js-off is-not-modern id--signed-out" lang="en" data-page-path="/australia-news/2020/aug/16/coalition-must-ensure-australia-wont-be-at-end-of-queue-for-coronavirus-vaccine-labor-says">
<head>

(full log truncated)
This occurs while pulling feeds during the usual update, and also while running in the FeedIron Testing tab.
This seems to occur regardless of the config, but the simplest one I've used to cause this is:
{
    "type": "xpath",
    "xpath": [
        "article"
    ]
}

It seems to happen against any URLs appearing in the guardian feed, but one example is: https://www.theguardian.com/australia-news/2020/aug/16/coalition-must-ensure-australia-wont-be-at-end-of-queue-for-coronavirus-vaccine-labor-says
I'm running the latest versions:
tt-rss: v20.08-5497a137d
feediron: latest master (51b34463b30eecdf09d64d481d3220853405217f)

This is normal behavior as it's the way the debuging logs and it's not an actual error. Add "debug": false to your main config to disable this during background operation. When run in the testing tab this will still show.

Thanks, that clears up the logging issue, but now it appears that feediron is not being applied when the updater runs.
I started from scratch with a blank database, added the plugin and my settings, then imported my feeds. After the update ran nothing was filtered by feediron. If I go to the Feed Debugger, check Force Refresh, and then Continue, I can see lines like
[07:00:42/43] hash differs, applying plugin filters:
[07:00:42/43] ... Feediron
[07:00:42/43] === 0.1244 (sec)
[07:00:42/43] plugin data: feediron,

and the relevant feed items are filtered according to the config.
Is there a reason this would work from both the testing tab and when forcing a refresh, but not during the regular feed updates?

Feediron always runs for all feeds as it checks to see if the article url matches the config url. The only reason it won't replace the feed body is if it can't match the url link to the article with the url in the config. I'm using very simple text matching to do this so keep it as simple as possible i.e. don't use https://www.theguardian.com use theguardian.com
Your main config should look something like this.
{
    "theguardian.com":{
        "type": "xpath",
        "xpath": [
            "article"
        ]
    },
    "debug": false
}

The only time I've encountered issues is when the site uses a service like feedburner that obfuscates the original article url. Using the plugin af_unburn solves that however.
As a side note: I didn't know the feed debugger even existed... well that's embarrassing and useful

This ended up being due to incorrect permissions, I think. I'm running ttrss in docker containers on AWS, and mounted in the plugin directory as a volume from the host. After updating the scripts to clone feediron in the same way as the ttrss code itself, everything is working perfectly.


Label Convenience methods

Description
Adding getDefaultLabel() and getLabel(String locale) for convienience
Overview of Changes

Adding getDefaultLabel() and getLabel(String locale) to DefaultParamState

Type of change
Please delete options that are not relevant.

[ ] Bug fix (non-breaking change which fixes an issue)

How Has This Been Tested?
All Tests.
Additional Notes
Needed for upgrade to 1.1.0.M2 for downstream applications

You did it @lopezton-anthem!
Thank you for signing the Anthem Opensource Software CLA.


Refactor pp chatbot remove to use util instead of calling other command, Closes #5246

Closes #5246

Awesome, can't wait to have a check in this one 🤓👍. We will review it ASAP

setting to draft due to the following observations
I will provide more guidance how we should proceed with this PR in near future


Cookie not in this host's domain

I have an issue using the extension when the actual API is hidden behind Azure API Management service.
I'm making this request:
GET https://apim-BACKEND-SERVICE.azure-api.net/
Authorization: {{token}}

But get error about cookies:
OR: RequestError - Cookie not in this host's domain. Cookie:app-BACKEND-SERVICE.azurewebsites.net Request:apim-BACKEND-SERVICE.azure-api.net
RequestError: Cookie not in this host's domain. Cookie:app-BACKEND-SERVICE.azurewebsites.net Request:apim-BACKEND-SERVICE.azure-api.net
	at Sj._beforeError (c:\Users\u01sga\.vscode\extensions\anweber.vscode-httpyac-6.12.1\dist\extension.js:164:18474)
	at Sj._onResponseBase (c:\Users\u01sga\.vscode\extensions\anweber.vscode-httpyac-6.12.1\dist\extension.js:164:12741)
	at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
	at async Sj._onResponse (c:\Users\u01sga\.vscode\extensions\anweber.vscode-httpyac-6.12.1\dist\extension.js:164:14359)
	at r.setCookie (c:\Users\u01sga\.vscode\extensions\anweber.vscode-httpyac-6.12.1\dist\extension.js:159:9241)
	at c:\Users\u01sga\.vscode\extensions\anweber.vscode-httpyac-6.12.1\dist\extension.js:141:148102
	at new Promise (<anonymous>)
	at r.setCookie (c:\Users\u01sga\.vscode\extensions\anweber.vscode-httpyac-6.12.1\dist\extension.js:141:148002)
	at c:\Users\u01sga\.vscode\extensions\anweber.vscode-httpyac-6.12.1\dist\extension.js:164:12615
	at Array.map (<anonymous>)
	at Sj._onResponseBase (c:\Users\u01sga\.vscode\extensions\anweber.vscode-httpyac-6.12.1\dist\extension.js:164:12590)
	at Sj._onResponse (c:\Users\u01sga\.vscode\extensions\anweber.vscode-httpyac-6.12.1\dist\extension.js:164:14370)
	at ClientRequest.<anonymous> (c:\Users\u01sga\.vscode\extensions\anweber.vscode-httpyac-6.12.1\dist\extension.js:164:14580)
	at Object.onceWrapper (node:events:632:26)
	at ClientRequest.emit (node:events:529:35)
	at l.emit (c:\Users\u01sga\.vscode\extensions\anweber.vscode-httpyac-6.12.1\dist\extension.js:159:31404)
	at HTTPParser.parserOnIncomingClient [as onIncoming] (node:_http_client:700:27)
	at HTTPParser.parserOnHeadersComplete (node:_http_common:119:17)
	at TLSSocket.socketOnData (node:_http_client:541:22)
	at TLSSocket.emit (node:events:517:28)
	at addChunk (node:internal/streams/readable:335:12)
	at readableAddChunk (node:internal/streams/readable:308:9)
	at Readable.push (node:internal/streams/readable:245:10)
	at TLSWrap.onStreamRead (node:internal/stream_base_commons:190:23)

Console log:
ERROR: {"url":"https://apim-XXX.azure-api.net","protocol":"HTTP","method":"GET","headers":{"Authorization":"Bearer eyJ0eXA....","Accept":"*/*","User-Agent":"httpyac"},"options":{"cookieJar":{"version":"tough-cookie@4.1.3","storeType":"wE","rejectPublicSuffixes":false,"enableLooseMode":false,"allowSpecialUseDomain":true,"prefixSecurity":"silent","cookies":[{"key":"fpc","value":".....","expires":"2024-05-14T16:51:21.000Z","domain":"login.microsoftonline.com","path":"/","secure":true,"httpOnly":true,"hostOnly":true,"creation":"2024-04-14T16:51:21.474Z","lastAccessed":"2024-04-14T16:51:21.474Z","sameSite":"none"},{"key":"x-ms-gateway-slice","value":"estsfd","domain":"login.microsoftonline.com","path":"/","secure":true,"httpOnly":true,"hostOnly":true,"creation":"2024-04-14T16:51:21.475Z","lastAccessed":"2024-04-14T16:51:21.475Z","sameSite":"none"},{"key":"stsservicecookie","value":"estsfd","domain":"login.microsoftonline.com","path":"/","secure":true,"httpOnly":true,"hostOnly":true,"creation":"2024-04-14T16:51:21.475Z","lastAccessed":"2024-04-14T16:51:21.475Z","sameSite":"none"}]},"hooks":{"beforeRedirect":[null,null],"beforeRequest":[null,null]}},"proxy":""}

For some reason APIM exposes information about underlying service.
Probably, it is not right, but I don't have direct control over the instance of APIM.
I think it should not matter at the end as the same request works totally fine in other http clients lake Postman or REST Client.
And it works fine in curl:
curl -v --request GET \
  --url https://apim-BACKEND-SERVICE.azure-api.net \
  --header 'Accept: */*' \
  --header 'Authorization: Bearer eyJ0eXA.....' \
  --header 'User-Agent: httpyac'

* Host apim-BACKEND-SERVICE.azure-api.net:443 was resolved.
* IPv6: (none)
* IPv4: <IP_ADDRESS>
*   Trying <IP_ADDRESS>:443...
* Connected to apim-BACKEND-SERVICE.azure-api.net (<IP_ADDRESS>) port 443
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 / secp384r1 / RSASSA-PSS
* ALPN: server did not agree on a protocol. Uses default.
* Server certificate:
*  subject: C=US; ST=WA; L=Redmond; O=Microsoft Corporation; CN=*.azure-api.net
*  start date: Mar  1 18:04:55 2024 GMT
*  expire date: Feb 24 18:04:55 2025 GMT
*  subjectAltName: host "apim-BACKEND-SERVICE.azure-api.net" matched cert's "*.azure-api.net"
*  issuer: C=US; O=Microsoft Corporation; CN=Microsoft Azure RSA TLS Issuing CA 04
*  SSL certificate verify ok.
*   Certificate level 0: Public key type RSA (2048/112 Bits/secBits), signed using sha384WithRSAEncryption
*   Certificate level 1: Public key type RSA (4096/152 Bits/secBits), signed using sha384WithRSAEncryption
*   Certificate level 2: Public key type RSA (2048/112 Bits/secBits), signed using sha256WithRSAEncryption
* using HTTP/1.x
> GET / HTTP/1.1
> Host: apim-BACKEND-SERVICE.azure-api.net
> Accept: */*
> Authorization: Bearer eyJ0eXAiOiJK....
> User-Agent: httpyac
>
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
< HTTP/1.1 200 OK
< Transfer-Encoding: chunked
< Content-Type: application/json; charset=utf-8
< Set-Cookie: ARRAffinity=6f27b92dd8bce13e55ecabe9082f50999260186a60dac081a691ca4a1657912c;Path=/;HttpOnly;Secure;Domain=app-BACKEND-SERVICE.azurewebsites.net
< Set-Cookie: ARRAffinitySameSite=6f27b92dd8bce13e55ecabe9082f50999260186a60dac081a691ca4a1657912c;Path=/;HttpOnly;SameSite=None;Secure;Domain=app-BACKEND-SERVICE.azurewebsites.net
< Request-Context: appId=cid-v1:100f597e-acb6-4859-9828-00de061ce4a4
< Date: Sun, 14 Apr 2024 16:53:20 GMT
<
* Connection #0 to host apim-BACKEND-SERVICE.azure-api.net left intact
{"data":{...}}}%

The most interesting part here:
...
< Set-Cookie: ARRAffinity=6f27b92dd8bce13e55ecabe9082f50999260186a60dac081a691ca4a1657912c;Path=/;HttpOnly;Secure;Domain=app-BACKEND-SERVICE.azurewebsites.net
< Set-Cookie: ARRAffinitySameSite=6f27b92dd8bce13e55ecabe9082f50999260186a60dac081a691ca4a1657912c;Path=/;HttpOnly;SameSite=None;Secure;Domain=app-BACKEND-SERVICE.azurewebsites.net
...

in ARRAffinitySameSite it exposes the actual backend url. I think, the library does some validation under the hood.
Ideally it should not, or there should be a way to disable it.

nevermind, I've found "httpyac.cookieJarEnabled": false setting. looks like it helps.


@conda-forge-admin, please add bot automerge

@conda-forge-admin, please add bot automerge

Hi! This is the friendly automated conda-forge-webservice.
I just wanted to let you know that I added bot automerge in conda-forge/djangorestframework-yaml-feedstock#3.


Fix/splitpayments scrub multi wallet

Fix issue with using split payments and scrub!
split payments wasn't properly notifying wallets of a new payment!
scrub had an issue with non integer amounts, which were coming from splitpayments. amount is now rounded down to integer, and "change" the decimal part is kept in user's wallet!

Codecov Report

Merging #1040 (92a756b) into main (9654538) will decrease coverage by 0.00%.
The diff coverage is 14.28%.

@@            Coverage Diff             @@
##             main    #1040      +/-   ##
==========================================
- Coverage   51.65%   51.65%   -0.01%
==========================================
  Files         236      236
  Lines       13236    13238       +2
==========================================
+ Hits         6837     6838       +1
- Misses       6399     6400       +1

Impacted Files
Coverage Δ

lnbits/extensions/splitpayments/tasks.py
43.75% <0.00%> (ø)

lnbits/extensions/scrub/tasks.py
41.86% <25.00%> (+0.39%)
:arrow_up:

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


chore(deps): update terraform-module

This PR contains the following updates:

Package
Type
Update
Change

github.com/terraform-ibm-modules/terraform-ibm-observability-instances
module
minor
v2.12.2 -> v2.13.1

github.com/terraform-ibm-modules/terraform-ibm-resource-group
module
patch
v1.1.5 -> v1.1.6

Release Notes

terraform-ibm-modules/terraform-ibm-observability-instances (github.com/terraform-ibm-modules/terraform-ibm-observability-instances)
v2.13.1
Compare Source
Bug Fixes

remove upper limit for required terraform version (#518) (f6c7d7e)

v2.13.0
Compare Source
Features

enable_archive variable has been removed and is now replaced by two new variables log_analysis_enable_archive and activity_tracker_enable_archive to allow consumers more flexibility on what components to enable archiving on  (#515) (51cba89)

terraform-ibm-modules/terraform-ibm-resource-group (github.com/terraform-ibm-modules/terraform-ibm-resource-group)
v1.1.6
Compare Source
Bug Fixes

remove upper limit for required terraform version (#624) (0c4a55a)

Configuration
📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.

[ ] If you want to rebase/retry this PR, check this box

This PR has been generated by Renovate Bot.

/run pipeline

/run pipeline

/run pipeline

/run pipeline

/run pipeline

/run pipeline

:tada: This PR is included in version 1.26.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Amplify app Github connectivity lost

Before opening, please confirm:

[X] I have checked to see if my question is addressed in the FAQ.
[X] I have searched for duplicate or closed issues.
[X] I have read the guide for submitting questions.
[X] I have removed any sensitive information from my code snippets and submission.

App Id
d30wn2r7brpbf5
AWS Region
us-east-1
Amplify Hosting feature
Git providers
Question
This app has been running fine for a couple of months. One fine day, it lost its connectivity to Github, not just that, I don't see any git repo as an option at all in the repository setting. Before creating a new app, I wanted to see what caused it and see if we can possibly salvage this app.
Note: Service role was found missing from the Settings page, which I added back, but made no change.

Hi @vgthoppae 👋 , thanks for raising this issue!
Currently, I see that the Amplify app d30wn2r7brpbf5 does not have a git repository associated to it. If you had previously connected a git repository to this app, you can review the following resources to understand the changes made to your Amplify app resource:

Review the DeleteBranch, UpdateApp and UpdateBranch API calls made from your AWS account using AWS CloudTrail. You can also refer to the Amplify API actions here.
Verify if the GitHub app is installed appropriately as it required for read-only access to repositories.


v4.0.5-3049

Fixed: https://github.com/froala-labs/froala-editor-js-2/issues/3049

@harasunu-narayan , please check again and no required to replace code.


bugfix: not remove the metadata when remove container failed

Signed-off-by: Starnop<EMAIL_ADDRESS>
Ⅰ. Describe what this PR did
Ⅱ. Does this pull request fix one issue?

None.
Ⅲ. Why don't you add test cases (unit test/integration test)? (你真的觉得不需要加测试吗？)
None.
Ⅳ. Describe how to verify it
Ⅴ. Special notes for reviews
We should not remove the sandbox container metadata from sandboxStore until it was removed by pouchd. If that happend, there will be uncontrolled containers, it's not make sense. CRI is responsible for the life cycle of all the containers it creates and ensure consistency of container states.

Please add the reason why not to remove metadata in pull request description. @Starnop
Thanks.

@allencloud has been added.  :)

that is so great. @Starnop
LGTM


Support ES6 import in uncompiled mode

Getting started with Shaka is easy. Install shaka-player through npm and step through the basic usage documentation and quickly we're playing a video. This is good thanks.
Our application is build on ES6 modules using WebPack and Babel. Including shaka-player into our player is as simple as: import shaka from 'shaka-player';
Going from this to a uncompiled version is unclear. The good velocity from setup and getting started hit a wall.

To load the library without compiling, you will need to generate a Closure "deps file" by running ./build/gendeps.py. Then, you'll need to bootstrap your application with three < script > tags:

In order to run in uncompiled mode we have to checkout the repo, build deps, then include these files in an HTML document. What's implied is the HTML document is in the root of the shaka-player repo. This is fine when you're debugging isolated test cases. This is nearly impossible to use when debugging integration issues with application logic.
Integrating an uncompiled Shaka Player into an application is unclear. The script element recommendation won't work, dep paths are inaccessible. Importing the three files also doesn't work; they collaborate using global variables and don't understand exports. So, the import approach above doesn't work as:
import 'shaka-player/third_party/closure/goog/base';
import 'shaka-player/dist/deps';
import 'shaka-player/shaka-player.uncompiled';

It was a long shot anyway. I didn't expect the multiple import approach to work, but, hey, grasping for uncompiled straws.
Will you please consider making it easier to debug integration issues? As a developer, quickly swapping a CDNJS link from the compiled to concatenated but not mangled build would be effortless. Same is true to use a import shaka from 'shaka-player/debug'.
I'm unsure if "compiled" means concatenated and minified in the Closure Compiler world. If not, please do consider making debugging flexible while avoiding requiring users build their own players from source.
Thanks for reading!

"Compiled" in Closure means actually compiled.  The Closure compiler not only minifies and concatenates, but also takes into account type information, enforces type-safety, and applies compiler optimizations.
If you're installing from npm, the deps are already generated.  The real issue seems to be that you're using ES6 imports instead of script tags, which is honestly not something we anticipated.
As such, I'm renaming this issue as "Support ES6 import in uncompiled mode".  I'm not sure how we would do this off-hand, but we will keep it in mind when we start planning our next major release.  Thanks!

You should be able to do this with webpack. Its probably a case of using the export-loader instead of doing import statements.
https://webpack.github.io/docs/shimming-modules.html

I haven't been able to test it but, i believe this is how you would do this:
npm install script-loader

require('script!shaka-player/third_party/closure/goog/base.js');
require('script!shaka-player/dist/deps.js'')
require('script!shaka-player/shaka-player.uncompiled.js')

Now you can pass --debug to the ./build/build.py script to not rename anything and expose all private members.  This should allow you to import it the same as the non-debug version but still have the normal names.
We will also be adding the debug version of the compiled library to future versions on npm.  So you can include shaka-player.compiled.js for your production code and shaka-player.compiled.debug.js for debugging.  So once we release v2.1.0 you will be able to just pull the debug version from npm.

@mseeley does this work for you? Can I close this?

Hi @TheModMaker. It sounds like it could; thanks a lot for the ping. :)
Please feel free to close this. I'll open an issue with updated context if we have trouble.
Thanks!


Jupyter code cells

Hello. I was just testing out your examples for jupyter notebook support which is very cool!  I could easily reproduce your examples using polars.
I have a few questions: I quite like the jupyter code cells functionality.  I found that with the .nu file extension, this would not work in vscode.  However, switching it to a .py file works like a charm with the downside that the language server doesn't. Do you have an idea of how to get around this?
Secondly, I use zed quite often which offers a similar REPL functionality as the code cells.  Indeed here I could get things going with the .nu file extension (first by changing the file extension to .py, selecting the nu kernel, and then switching it back to .nu). However printing the svg resulted in printing the svg text instead of the rendered image. The Zed REPL issue of github here suggests rendering should be possible. Any ideas what I could try?
Thanks for the awesome work. I really enjoy using Nu, and the support for Jupyter was something I was very excited to discover.

I have a few questions: I quite like the jupyter code cells functionality. I found that with the .nu file extension, this would not work in vscode. However, switching it to a .py file works like a charm with the downside that the language server doesn't. Do you have an idea of how to get around this?

That feature looks interesting, I have to look into that.

Secondly, I use zed quite often which offers a similar REPL functionality as the code cells. Indeed here I could get things going with the .nu file extension (first by changing the file extension to .py, selecting the nu kernel, and then switching it back to .nu). However printing the svg resulted in printing the svg text instead of the rendered image. The Zed REPL issue of github here suggests rendering should be possible. Any ideas what I could try?

I know for zed you can also define some config to allow the repl directly with nu, but the integration is a bit wonky. About the svg text, I could imagine that zed renders the first value in the result response. Other than ipykernel do I send every data type that got successfully rendered. Try to use nuju display svg to force SVG output, maybe that helps.


Check for existence for topic requests on db level rather than on java

The idea is to use exists on db level instead of select everything and then check whether list is empty or not

thanks for taking a look
yep, it should be covered to tests


Dynamic imports aren't grouping bundles together in Mix 6

Laravel Mix Version: 6.0.13
Node Version 15.12.0
NPM Version 7.6.3
OS: Mac and ubuntu

Description:
In Mix 5 using dynamic imports produced common modules in chunks:
All (3.95 MB)
/js/dist/bundle.b7b80f.js (1.86 MB)
js/dist/vendors~orgs.8ab12f.js (472.67 KB)
js/dist/tasks.49a0dc.js (439.8 KB)
js/dist/assets.dd11d0.js (289.83 KB)
js/dist/materials.b7770f.js (285.89 KB)
js/dist/system.41c375.js (252.81 KB)
js/dist/vendors~account~admin~assets~materials~orgs~system~tasks~timesheets.587530.js (83.17 KB)
js/dist/vendors~admin.741d64.js (55.44 KB)
js/dist/orgs.dee379.js (54.42 KB)
js/dist/account.32230e.js (48.03 KB)
js/dist/vendors~account~admin~assets~materials~orgs~system~tasks.9f7e0d.js (46.42 KB)
js/dist/admin.194f45.js (41.22 KB)
js/dist/vendors~admin~assets~materials~system~tasks.b7c88b.js (24.44 KB)
js/dist/timesheets.1a8255.js (24 KB)
js/dist/vendors~assets~materials~orgs~system~tasks.7676c4.js (19.39 KB)
js/dist/error.7afdc0.js (3.3 KB)

In Mix 6 the common modules are placed in each chunk:
All (5.01 MB)
/js/dist/bundle.js (1.87 MB)
js/dist/orgs.839d2b.js (676.95 KB)
js/dist/tasks.b01083.js (623.7 KB)
js/dist/assets.75af72.js (471.2 KB)
js/dist/materials.002fd6.js (468.29 KB)
js/dist/system.ef01ec.js (435.25 KB)
js/dist/admin.8af2c4.js (249.37 KB)
js/dist/account.a14a49.js (177.37 KB)
js/dist/timesheets.482bfb.js (104.64 KB)
js/dist/error.b2be8b.js (4.35 KB)

This adds duplicate code and a bigger overall download.
I understand that I can extract all the modules to a vendor.js but this doesn't help with the initial download time if a user doesn't need the modules in the current section of the app.
I'm wondering if this was a planned change or a byproduct of something else during the v5 to v6 releases, and what is involved in getting the common modules in separate chunks again as it was in v5.
Thanks.

This is a valid issue.
Mix 6 disables webpacks's default cacheGroups, preventing code splitting (and grouping) inside dynamic imports.
https://github.com/JeffreyWay/laravel-mix/blob/d27a77abb5a32f42e47d6e3d344ba757d85ad89a/src/Chunks.js#L165

what is involved in getting the common modules in separate chunks again as it was in v5.

The simplest solution seems like is to reenable webpack's default cacheGroups from config. Something like this:
mix.webpackConfig({
  optimization: {
    splitChunks: {
      cacheGroups: {
        customDefaultVendors: {
          test: /[\\/]node_modules[\\/]/,
          priority: -10,
          reuseExistingChunk: true,
        },
        customDefault: {
          minChunks: 2,
          priority: -20,
          reuseExistingChunk: true,
        },
      },
    },
  },
});

See https://webpack.js.org/plugins/split-chunks-plugin/ for more information.

Yeah we explicitly disabled it because it can produce chunks with very inconsistent names. I think this would be a good feature to add back that can be explicitly enabled though.

@thecrypticace
Any update on this? I would appreciate it if it's handled by default to produce consistent output and avoid issues.


VSCode not open after i upgraded to vscode 1.8.0

VSCode Version: 1.8
OS Version: OSX El Captian 10.11.4 (15E65)

Steps to Reproduce:

Version 1.7 works, but after updating I stopped opening
If I reinstall 1.7 works perfectly, but I can not open it when I install 1.8
With version 1.7 deactivate all extensions and update to 1.8 but not open

Same here with same configuration.

@zephiro in step 2, are you saying that you see the same issue when downloading vscode from the website and install it newly?


It would be better to illustrate that this could only be used in Node.js

Since modern browsers support Atomics.wait may not allow to use Atomics.wait in main thread, it will throw error if anyone try to use this package in browsers.

What browsers? Did you test that it doesn't work?

I tested it in Chrome, TypeError thrown like this:
Uncaught TypeError: Atomics.wait cannot be called in this context


Document how to find CSS elements to override

📚 Documentation
https://docusaurus.io/docs/en/api-pages#styles talks about overriding default styles with custom styles, but it does not mention where to go to look for the default styles.
They are in main.css which can be inspected in one of three places:

website/node_modules/docusaurus/lib/static/css/main.css after doing a docusaurus-init or yarn install to start developing your site.
https://github.com/facebook/Docusaurus/blob/master/v1/lib/static/css/main.css
Or you can use your browsers Developer Tools to inspect elements directly to see the name of what to override.

Have you read the Contributing Guidelines on issues?
Yes. I helped write them 😄

I'm interested in working on this issue if it is still up for grabs.

Thanks @ael-mas.
We've added an issue: claimed label so that others will know not to start work on the issue. If you change your mind about the issue, no worries! Just let us know so that we can remove the label and free it up for someone else to claim.
We will check in with you periodically so that we can keep the task updated with the progress.

Fixed in #1266


appget update installs new version of Visual Studio Code, does not remove old version

I am running Windows 10 Version 1909 and AppGet version 1.0.12.
I had VS Code 1.40.2 installed manually on my system which was correctly flagged by AppGet as out-of-date.  So I did: appget update visual-studio-code
Afterwards, when I looked at the installed packages using Windows' Add/Remove Programs feature (appwiz.cpl), it showed two versions installed on the system, as follows:

An appget list only shows the newly installed version.  Curiously, during the update it was aware that an older version was present:

The newly installed version was placed under the AppData folder structure.  The old version is under Program Files.
The problem may be due to the fact that I ran appget in a non-admin CMD session.

When I tried to do appget uninstall visual-studio-code it gave me the following messages (in red):
Found more than one installed package for visual-studio-code
Microsoft Visual Studio Code (User) 1.41.1
Microsoft Visual Studio Code 1.40.2

But as I mentioned before, `appget list` seems to be aware of only the newly installed one.


Logging is always active

It would be a nice feature to have the option to disable the logging.
For me, it gets in the way of what I actually want logged and it slows down the library a lot.

You can turn logging off completely in #80


🚀 [Feature Request]- Adding a dark mode to the website

Is your feature request related to a problem ? Please describe. ✍
Adding a dark mode button for the website, for better user experience.
Describe briefly how you would implement this enhancement.
Some steps to implement this enhancement-
1. Step 1
2. Step 2
3. Step 3

Additional context or screenshots
Additional context
Are you contributing for a program?
GSSoC2023
Code of Conduct

[X] I have read and agree to the Contributing Guidelines of this project.

@anmode I am facing issue in running it using npm run dev. Please help me out. It is showing server error.

what error...ping me on discord.

discord username?

Need a update, what's the progress? @deepshikha2708

Yeh darkk kbse chl rha abhi tk kisi pr complete ni hua :)
@Abhinavcode13 wanna try?


build fail when LP64 is not defined

LP64 is not defined default when build for armv7. line 89 causes a error. It might be #ifdef __LP64__ instead of #if __LP64__

reproduce command as following:
clang -D__KERNEL_ARM_ARCH__=7 -arch armv7 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk -Wall -Wundef -Werror -c -o fishhook.o fishhook.c

and errors
fishhook.c:89:5: error: '__LP64__' is not defined, evaluates to 0 [-Werror,-Wundef]
#if __LP64__
    ^

I use Xcode 10.0.1
$ clang --version
Apple LLVM version 10.0.1 (clang-1<IP_ADDRESS>)
Target: x86_64-apple-darwin18.7.0
Thread model: posix
InstalledDir: /Applications/Xcode10.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin


chore: activate docs check for PRs

PR Type
[x] CI-related changes
What Is the Current Behavior?

refactorings can break local links in the documentation, but CI does not report errors.
link check is completely disabled on integration branch

What Is the New Behavior?

doc check runs on PRs
for integration branch a --fast check for local links is performed (@shauke I hope that is not as "disturbing" as before 😜 f4bbf676245f92c00a5cf6d77cf9c5cf38cfdc80)

Does this PR Introduce a Breaking Change?

[ ] Yes
[x] No
Other Information
AB#76053

I was just thinking about this with the docs PR and you fixed it ^^ will check it out monday 👍


Pasting into Entry/TextEdit seems to only show first 12 characters

I've been having a play with tui-go and came across this issue. I've only been able to test it on MacOS. Pasting only shows the first 12 characters, but typing directly can have more than that. Is this a known limitation?

@martinbaillie gdamore/tcell#200 was fixed in tcell v1.3.0

submitted a PR to update version: #151


blur should not change active field if the blurred field is not active

This the v6 implementation of #1002

Released in v6.0.0-alpha.14.


ImportError: cannot import name 'ftml_update'

Operating system: Ubuntu 16.04
Cuda version: cuda 9.0
Python 3.6.6
I have installed mxnet-cu90==1.0.0 using pip3. However, when I try "import mxnet", I got the following error:
Traceback (most recent call last):
File "", line 1, in
File "/usr/local/lib/python3.6/dist-packages/mxnet/init.py", line 42, in
from . import optimizer
File "/usr/local/lib/python3.6/dist-packages/mxnet/optimizer/init.py", line 19, in
from . import optimizer, contrib
File "/usr/local/lib/python3.6/dist-packages/mxnet/optimizer/optimizer.py", line 28, in
from ..ndarray import (sgd_update, sgd_mom_update, adam_update, rmsprop_update, rmspropalex_update,
ImportError: cannot import name 'ftml_update

@mxnet-label-bot add [Installation]


Bneukom/improve bp api

Added Blueprint support to:

Change the Initial Shape (Spline or StaticMesh) of a VitruvioComponent
Convert a StaticMeshActor to a VitruvioActor
Set array attribute on a VitruvioComponent

Added async support of VitruvioComponent modifications. The Blueprint functions have callbacks when the generate/rule evaluation has completed (eg when changing an attribute). This is helpful to properly chain together several Blueprint calls.
Added a copy fully qualified attribute name to the details panel
Fixed some minor issues and typos

Implemented most of the requested changes:

Evaluate attributes before all SetXYZAttribute calls
Removed the addIfNonExisting flags to SetXYZAttribute functions
Added a GenerateModel flag to all BP API functions. GenerateAutomatically is only used for changes made through the UI

Also added support to add array attribute values to the genertic SetAttributes call.

Thanks @chr11115 I fixed that and merged it!


[plugin_platform_interface] Re-evaluate for Dart 3

The reason plugin_platform_interface exists is to provide a structure to allow platform interfaces to enforce that implementations use extends rather than implements due to the extremely high potential for breakage with implements. With Dart 3, there's now a built-in way to enforce that, using base class.
The caveat is that there's a significant difference in behavior: with base you cannot mock the class, whereas with platform_plugin_interface we allow it via a mixin, for testing purposes only. We make use of this in the app-facing package unit tests, which (being unit tests) cannot use a real implementation.
I can see various options:
1. Do nothing
Keep using plugin_platform_interface as-is, and just update the package README to explain why it still exists.
Pros:

No disruption to any code.

Cons:

We have to maintain that package forever. It doesn't need a lot of changes, but it has had a few non-trivial adjustments over time, and there's https://github.com/flutter/flutter/issues/123241 open now.
It becomes non-idiomatic: the language has a way of expressing exactly what we want (for production code), but we're doing something else.
Enforcement is runtime, not compile-time.

2. Just switch to base
Switch all of our platform interfaces to use base. We could then deprecate plugin_platform_interface.
Pros:

No need to maintain plugin_platform_interface.
More idiomatic.
Compile-time enforcement.

Cons:

We would no longer be able to mock platform interfaces. Instead we would have to write manual mocks/stubs/fakes (depending on the exact testing needs) for testing the app-facing package.
Anyone else currently mocking platform interfaces (hopefully this would be a small set, but it is one of the options we list in docs even if it is somewhat discouraged) would have to do the same.

3. Switch to base + provided manual mock
Switch all of our platform interfaces to use base, but include a manual mock implementation for test purposes as part of the package API. We could then deprecate plugin_platform_interface.
Pros:

No need to maintain plugin_platform_interface.
More idiomatic.
Compile-time enforcement.
Clients with mocks would have access to relatively easy replacement.

Cons:

The provided mocks would likely be more complicated than the once we would write in option 2, since we would be maintaining our own use case plus any requested use cases from the community.

Mitigating this is that if our app-facing package tests are sufficiently good, we probably need mocks that can do almost everything, so it might not be much of a difference in practice.

The mocks would be public API, so would be much harder for us to change.
Adding test coverage in the app-facing package could require changes to the platform interface package.

This is probably not much of a problem in practice, since in general tests that would require changes there should be changes that are adding thing to the platform interface already.

I'd like to adopt base too, and remove all the gymnastics we have to check at run-time if your class is extends or implements, and leave that to the compiler.
About option 3; can we auto-generate the mock in option 3? Something like:
class WhateverTest extends WhateverPlatformInterface {}

And then somewhere else:
@GenerateNiceMocks([MockSpec<WhateverTest>()])

Then re-export whatever mockito mock that gets spit out?
(I understand that this is pushing the mockito dependency to people, and we might not want to do that)

I would only vote 1 as a temporary measure. Ignoring the language semantics moving from runtime validation to compile time validation is a big win.

Anyone else currently mocking platform interfaces (hopefully this would be a small set, but it is one of the options we list in docs even if it is somewhat discouraged) would have to do the same.

Another consideration is that while I've listed this as a con, it's arguably a pro; mocking a class that is intended to have base-like semantics from another is inherently fragile, which means anyone doing it is subject to breakage at any time. The point of the class is to make sure the whole ecosystem of plugin clients doesn't suffer that fate, but we're actively encouraging (via the existence of the mock mixin) developers to make their tests fragile. We could take an opinionated stance that people shouldn't trade one-time convenience (of writing the initial mock) against the stability of even their own test code.

I understand that this is pushing the mockito dependency to people, and we might not want to do that

If we extrapolate that out to all plugins, we'd end up in a situation where each mockito major version changes would affect plugin clients' ability to get new versions of some plugins, which seems very undesirable.

(https://github.com/dart-lang/language/issues/3106 has some relevant discussion about the philosophy of what we should support/allow.)

https://github.com/dart-lang/language/issues/3106#issuecomment-1561612339 looks like it could provide us the same sort of semantics the current approach with the mixin provides. I'll try that out when I get a chance; it would be a couple of lines in each plugin instead of the one mixin in the base class, but that's trivial.

I'm experimenting with going fully locked down (using base with no escape hatch to implements in tests), to see how it would affect us (as the people most likely to be mocking our platform interfaces, I hope). https://github.com/stuartmorgan/packages/commit/d6bbb10fb6494b0aa88e093a0977526533ae9519 replaces a mockito mock with a manual mock using extends; the mock was pretty simple to write, and interestingly I think the tests are noticeably more readable.

Should the final class MockImagePickerPlatform extends ImagePickerPlatform be vended from the _platform_interface package?
(Also if not final, I could ask mockito to give me a mock with more superpowers and things like verify?)

Should the final class MockImagePickerPlatform extends ImagePickerPlatform be vended from the _platform_interface package?

I don't love the idea of vending mocks, because it means that becomes part of our API surface and maintenance burden. But it's a possibility.

(Also if not final, I could ask mockito to give me a mock of the Mock with more superpowers and things like verify? :P)

If we did vend them we'd want to make them base rather than final to allow adding custom mock functionality. You still couldn't use mockito though, because mockito only operates via implements, and you can never implements anything in the entire class hierarchy under the platform interface once we put base on it.

you can never implements anything in the entire class hierarchy under the platform interface once we put base on it.

Aha, this was the bit of info that I was missing (x_x) I thought that once you had fully implemented a base class, you could start mocking it again :/

(dart-lang/language#3106 has some relevant discussion about the philosophy of what we should support/allow.)

https://github.com/dart-lang/site-www/issues/5143 seems to continue from the last comment in that discussion.

As an aside, I'm still not sure I understand the motivation to prevent implements in the first place. From what I can tell, this is not about forcing all platforms to inherit some private code, as the docs recommend for base, but rather to ensure that new additions are not breaking.
However, one look at most plugins shows that this is fundamentally not true. Plugin platform interfaces define each method as throwing an UnimplementedError, which means runtime failures. The new addition is breaking end-user code, but it's doing so silently. Worse, testing may not reveal this crash depending on the platform the developer tests on.
Fundamentally, I don't see how a platform interface can declare a method and be sure that all platforms can provide that behavior. The only exception would be one using method channels, as it could invoke and handle methods on the native side, independent of platforms. Still, I would see that as:
/// Every platform must define how it will implement each method
interface class MyPlatformInterface { }

/// New platforms can inherit the method channel implementation of each method
base class MyMethodChannel implements MyPlatformInterface { }

/// Implements the plugin using FFI, skipping all method channel logic
final class WindowsImplementation implements MyPlatformInterface { }

With this new structure, adding new members to a platform interface would be a breaking change, but again, this would only change the compile-time behavior -- the plugin was always a runtime failure waiting to happen. On the other hand, I do see the following scenario:

version 1.0.0 of the platform interface is implemented by iOS and Android implementations
the platform interface adds a new member, bumps its major version to 2.0.0
the iOS version implements the new member and adds a new iOS-only feature

Until Android implements the new member, end-users cannot use the new iOS feature because they are forced to use the 1.0.0 interface, which means they can't use the new iOS package. The solution would be for Android to properly implement the new member ASAP. If Android can't support that feature, they should throw UnsupportedError and document it well. Once they do, the front-facing plugin can bump both iOS and Android dependencies, then bump its own minor version.
In other words, I'm not sure that losing the new iOS-only feature or having documented failures is worse than your Android versions crashing whenever the plugin is used. And it seems trivial for an endorsed plugin implementation to stay on the same page as the platform interface as they are maintained by the same group. The real problem seems to be that a platform implementation that is kept out of sync with the other platforms can hold back the package for everyone. In that case, what about a new annotation:
@pluginPlatformInterface
interface MyPluginPlatformInterface {

This would warn when any library implements the interface outside of the declaring package unless that library's package is endorsed. That would allow plugin maintainers to be sure every method has been implemented on every platform while expressing their intent that new additions are not considered breaking changes externally.
If I'm missing an important use-case or problematic scenario please let me know, because I couldn't come up with any.

but rather to ensure that new additions are not breaking.

That is correct.

However, one look at most plugins shows that this is fundamentally not true. Plugin platform interfaces define each method as throwing an UnimplementedError, which means runtime failures. The new addition is breaking end-user code

I don't think you are using the word "breaking" the way we are. In this context, we use it in the semver sense: will existing code be broken as a result of an update?
Existing code by definition cannot be calling a method that did not exist yet.

but it's doing so silently.

I'm not clear on how throwing an UnimplementedError constitutes a silent failure. If you are referring to the compiler, that's intentional, because making existing code not compile, even when it does not use a new feature, is not the behavior we want.

Worse, testing may not reveal this crash depending on the platform the developer tests on.

That is correct. Developers should certainly not ship new functionality that they have never tested. Plugins are inherently platform-specific, so it will always be the case that testing plugin-provided functionality on one platform will not reveal bugs that happen on other platforms.

Fundamentally, I don't see how a platform interface can declare a method and be sure that all platforms can provide that behavior.

It can't.

The only exception would be one using method channels, as it could invoke and handle methods on the native side, independent of platforms.

Invoking a method channel in Dart does not guarantee that every possible native implementation of the plugin handles the method. Also, I don't know what you mean by "independent of platforms" since method channels require a different native implementation for every single platform; there is no such thing as a native side of a method channel that is independent of platform.

/// New platforms can inherit the method channel implementation of each method
base class MyMethodChannel implements MyPlatformInterface { }

In practice, this is an incredibly bad idea. It creates a completely untyped API layer based on magic strings and structures that must always exactly match across every single implementation, and getting that right across N+1 different languages is a nightmare.
And it does not solve the thing you describe, it just moves the runtime failure to the other side of the channel boundary, because the unrecognized new method string will result in a runtime failure there.

With this new structure, adding new members to a platform interface would be a breaking change

Which we don't want.

On the other hand, I do see the following scenario [...]

And this is why. We view constantly rendering existing federated implementations unusable just because we have added a new feature is undesirable.

In other words, I'm not sure that losing the new iOS-only feature or having documented failures is worse than your Android versions crashing whenever the plugin is used.

It doesn't. It throws only when you actively update your client code to try to use new functionality that never existed before, with an implementation that hasn't implemented that functionality.

And it seems trivial for an endorsed plugin implementation to stay on the same page as the platform interface as they are maintained by the same group. The real problem seems to be that a platform implementation that is kept out of sync with the other platforms can hold back the package for everyone. In that case, what about a new annotation:
@pluginPlatformInterface
interface MyPluginPlatformInterface {

This would warn when any library implements the interface outside of the declaring package unless that library's package is endorsed. That would allow plugin maintainers to be sure every method has been implemented on every platform while expressing their intent that new additions are not considered breaking changes externally.

I'm not following how "unless that library's package is endorsed" would work. Having compilation failures within the endorsed group when adding methods would be extremely bad. "Stay on the same page" is not a question of timing, it's a question of formal version constraints in the package pubspecs.

I don't think you are using the word "breaking" the way we are. In this context, we use it in the semver sense: will existing code be broken as a result of an update?
Existing code by definition cannot be calling a method that did not exist yet.

I meant this in the transitive sense: given a package a, and a package b that depends on a, a developer should be able to use both packages a and b, as long as their versions are compatible, and it shouldn't matter when the last time package b was updated.
If I wrote the Android implementation (v1.0.0) of a plugin (v1.0.0) and I use extends, then my package can be broken unless I explicitly keep it up-to-date: if the platform interface adds a new member and bumps to v1.1.0, then I inherit the implicit throw UnimplementedError.
As you said, that's fine for me because I haven't used it yet, but my downstream users will get these errors until I fix it because technically, the platform interface didn't make a breaking change. My version 1.0.0 is incompatible with the platform interface's 1.1.0, but semver can't tell you that, because the throw UnimplementedError was treated as a non-breaking change.

Invoking a method channel in Dart does not guarantee that every possible native implementation of the plugin handles the method. Also, I don't know what you mean by "independent of platforms" since method channels require a different native implementation for every single platform; there is no such thing as a native side of a method channel that is independent of platform.

Right, what I meant here is that no new Dart code is needed to use these method channels, and that the Dart logic to forward arguments to the native side and interpret the results can be re-used on all platforms. Of course, the correct native code is still needed to handle those calls on each platform.

In practice, this is an incredibly bad idea. It creates a completely untyped API layer based on magic strings and structures that must always exactly match across every single implementation, and getting that right across N+1 different languages is a nightmare.

I wasn't advocating for this approach, just pointing out what already exists: popular plugins use this approach, such as like MethodChannelFileSelector, MethodChannelCamera, DefaultLocalAuthPlatform, etc. These also aren't any less typed than method channels (which is why I prefer FFI + ffigen when possible). To clarify, I was only suggesting adding base to these to prevent someone from using implements and, say, missing out on some important method channel initialization logic.

And it does not solve the thing you describe, it just moves the runtime failure to the other side of the channel boundary, because the unrecognized new method string will result in a runtime failure there.

True, which is again, why I don't love method channels. Their presence on the Dart side does not indicate the presence of native code to actually handle the method calls. But that's a step above not even having Dart code to invoke those methods, or use any other logic like FFI (I would argue that FFI + ffigen is a pretty good indicator that native code exists). As you said though, these should be tested.
But also, this is a better reason to advocate for compile-time failures: if you add a new method to the platform interface, you'll get an UnimplementedError implementation. But if you use implements, you'll at least be warned that you're missing your method channel implementation, which you can then add. The Android and iOS versions can then refer to the method channel code when working on the native sides.

With this new structure, adding new members to a platform interface would be a breaking change

Which we don't want.

To clarify, only internally. the front-facing plugin that depends on the platform interface and endorses the platform implementations can still bump its minor version externally while bumping its platform interface internally. End-users will still get the automatic upgrades next time they run dart pub get.

Having compilation failures within the endorsed group when adding methods would be extremely bad. "Stay on the same page" is not a question of timing, it's a question of formal version constraints in the package pubspecs.

Wouldn't a plugin author want to know when one of their platforms has not yet implemented the new feature that was added to the platform interface? Once all platforms have caught up, the errors would go away, and that would be the "all clear" that the next version is ready to publish. Having your internal/endorsed platform implementations specify exact versions of the platform interface that they work with is a formal constraint in the pubspec.
Again, it all comes back to who is broken. Yes, the maintainers of individual platforms are broken more often, but only so that downstream users can know for certain which platforms will work with the given platform interface. And once a platform maintainer has published a new version that "works", they should be confident it will never start throwing UnimplementedErrors when the upstream interface adds new members. Instead, it should explicitly not have the new members until the platform maintainer has implemented and tested the new functionality and bumped the interface's major version in their pubspec to indicate so.

If I wrote the Android implementation (v1.0.0) of a plugin (v1.0.0) and I use extends, then my package can be broken unless I explicitly keep it up-to-date: if the platform interface adds a new member and bumps to v1.1.0, then I inherit the implicit throw UnimplementedError.
As you said, that's fine for me because I haven't used it yet, but my downstream users will get these errors until I fix it

Existing code won't get any errors. As Stuart said, no existing code can be calling the new methods, because they didn't previously exist.
Downstream users might later try calling the new methods. If they do that when using your plugin that doesn't support the methods — so in your example, if they do that on Android — then that's a bug in the downstream code, because they're trying to invoke your plugin in a way that isn't supported and never had been supported.
It's always nice when the compiler can tell you you're invoking something in an unsupported way. In this case, the compiler won't be able to tell the downstream developer that. That puts the situation on a par with numerous other preconditions found in all kinds of APIs — for example when you pass two incompatible arguments to a function, and the function throws an ArgumentError as a result.

My version 1.0.0 is incompatible with the platform interface's 1.1.0

This isn't true. There are good reasons that a downstream user may want to use your version 1.0.0 with the platform interface's 1.1.0: for example, they like the new method and want to use it on platforms where it has been implemented, even if it hasn't been implemented on some other platforms.
If the types or the version constraints were set up in a way that made that impossible, that would put up an obstacle that needlessly blocked your downstream users from using the new feature in situations where they otherwise could.
 Even if you always promptly respond to new releases of the platform interface, the iOS maintainer might not. It'd be a shame if none of your users (that had an iOS build) could use your work implementing the spiffy new feature for Android, just because the iOS plugin was undermaintained.

so that downstream users can know for certain which platforms will work with the given platform interface.

That's certainly an important goal. Like other API constraints that aren't enforced by the compiler, this should get a clear error at runtime (which it does — the UnimplementedError provided by the platform interface) and should be documented clearly up front.
For this reason a plugin should document any features of the platform interface it doesn't support. And if the plugin and platform interface are maintained independently, it's probably also a good idea for the plugin's README to clearly identify which version of the platform interface it's based on. That way it's straightforward for a downstream developer to see which newer features of the platform interface won't have been implemented, even before the plugin maintainer sees the new platform interface and acts on it (by implementing the new features, or by documenting that they're unimplemented).
Whether documented or not, though: ultimately, if I'm implementing some new feature in my app, it's up to me to test that it works before I ship it to end users. If a plugin I'm relying on hasn't implemented the functionality I try to use, then I'll find that out when I test it. It's the same way if I write code that trips over any other constraint in the plugin's API, whether that constraint was documented or not.

I wasn't advocating for this approach, just pointing out what already exists: popular plugins use this approach, such as like MethodChannelFileSelector, MethodChannelCamera, DefaultLocalAuthPlatform, etc.

These are legacy implementations to avoid breaking existing third-party implementations that predate federation, when the only way to support a plugin on a third-party embedding was to implement the native side of the platform channel. None of our implementations use it, and nobody should be writing new code against it.

@stuartmorgan @gnprice I wonder if we can address some of these concerns around usage with either an annotation that helps IDE's understand when the native side code is implemented (aka doe not throw unimplemented error) or by adding a method to method channel to check if native code can respond. Basically something like isXSupported that is implemented in addition to every callX method.
what I suggest should be in its own bug an not part of this one.

We have guidance around doing that when platform support will vary in our own implementations. I'm more skeptical of doing it as a general rule for every method just for unendorsed implementations since that would make usage of every API pretty complicated for a case that most people would never encounter.
I don't think there's going to be any way to do that it an automated or generic way, given that we have no idea how any implementation might implement a platform interface method (notably, it may not have a platform channel at all).

@stuartmorgan I apologize for bringing the conversation off-topic for a bit, I figured that while the official advice was changing maybe a change in approach was appropriate. I do see the point that having very strict compile time checks can get in the way of functionality that could have been preserved with simple runtime testing instead.

This issue is about changing how, mechanically, we implement an existing policy that we are happy with.

My original comment was pointing out the proposed solution from a different thread:
@implementableForTesting
class MockablePlatformInterface { }

Which would allow extends, and only allow implements in tests, so they can be mocked. I believe this annotation, if implemented, would accomplish what you're looking for.


[BUG] Stops registry editing.

When testing the plugin with a robust database, when editing the registry, the page kept crashing the browser.
When removed, operation returned to normal.

Strapi version: v4.10.2
Node Version: v18.19

Only the latest version is fully supported, I cannot reproduce this with simply changing input values and saving. Possible related to #135 . Closing for now, happy to re-open if reproducible steps on the latest version are provided.


DDCE-5030: Migrate Joda time to Java time : bc-passengers-frontend

Replaced LocalDate.parse and LocalTime.parse to parseLocalDate and parseLocalTime throughout files


Update version to 0.1.1 in Project.toml

Codecov Report
Patch and project coverage have no change.

Comparison is base (3d699ed) 86.93% compared to head (aec21dc) 86.93%.

Additional details and impacted files
@@           Coverage Diff           @@
##             main      #14   +/-   ##
=======================================
  Coverage   86.93%   86.93%
=======================================
  Files           6        6
  Lines         199      199
=======================================
  Hits          173      173
  Misses         26       26

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


WINFILE.INI's location need to be flexible to be more useful

WinPE don't have APPDATA environment variable, thus WinFile is unable to write and read config file. Seems USERPROFILE environment variable works, not sure if older systems have this environment variable. So let it be the second choice now.
Appreciate for any advice or discussion

a portable version automatically detect and use ini file in the same folder may be better


Add support for hugo relrefs and toml front matter

Is your feature request related to a problem? Please describe.
I want to use quartz to view my org-roam braindump. I export the org files with ox-hugo, but since the links are relrefs and not regular markdown links, backlinks don't work. Also the toml front matter is not read and the notes inherit their titles from the filename.
Describe the solution you'd like
Add support for relref links and toml front matter. I suspect they should be easy to implement, given that quartz is built on top of hugo to begin with.
Describe alternatives you've considered
As far as relrefs are concerned, I played around with sed but to no avail.
Using yaml for the front matter can only be set per note, as far as ox-hugo is concerned, and so makes the conversion of a lot of already written notes unrealistic.

Quartz 4 doesn't use Hugo anymore and Quartz 4 is being deprecated so I'll be closing this as no longer relevant


Loading of atlas fails in IE 11

Viewing a Nunaliit atlas in IE 11 (suspected to affect IE 10 as well) fails with only some page header and footer elements visible and everything else blank. Examining the console log reveals the following errors:
Multiple definitions of a property not allowed in strict mode
Unable to get property 'Filtered SearchDialogFactory' of undefined or null reference

JP fixed in commit 7bc2dab8099b6c29ad61d5c096e87decc825d194


The Graph sample (24) shouldn't use tenant admin scopes

We should change which Graph endpoints this bot uses so that tenant admin approval is not required.
All up samples review tracking issue https://github.com/microsoft/botframework-sdk/issues/5897

dotnet PR completed here: https://github.com/microsoft/BotBuilder-Samples/pull/2506
other languages to follow, once this is approved


fix doc for enabling rust analyzer

Using the previous config did not change the language server to rust analyzer for me. I think it is because setting it after lsp-rust has been initialized is too late.

Thanks again for the help!


JavaScript Injector: Help Systems Vityl Dashboard

Customer wants to be able to log in to their Help Systems Vityl dashboards. This is a private site integrated with AD.

Moved to Edge App List.


3.0.md links to LinkObject are broken

As per the title. I had a quick look but can't figure out why it's not working.
#linksObject ->  #links-object Works fine.
#linkObject ->  #link-object Doesn't work.

@willdady Thanks for noting. I opened pull request #966 to fix this.

I think this can be closed


rename set_aromatic_form to convert_to_aromatic_form

The Chem package is currently broken as the 1.2.8 version of MinimalLib features this API change compared to the previous version.
@MariaDolotova @StLeonidas Could you please apply this fix ASAP to avoid building a broken Chem package?
Thanks in advance!

@ptosco , merged the PR.
Thank you!


Fixes #503: Fix the camera opening on clicking the notification

So it seems the action in the intent from the notification has the action as null and its going to dispatchTakePictureIntent(); as the filepath will be null as well, so the camera app is opening on pressing notification!

Automated message from Dropbox CLA bot
@kunall17, it looks like you've already signed the Dropbox CLA. Thanks!


[release/0.28] Revert commit 88737d AKA PR #3903.

Revert https://github.com/microsoft/FluidFramework/pull/3903 since ODC does not have necessary feature for it yet and (and they might start integrating 0.28 before they do).

⯆ @fluidframework/base-host: -4 Bytes
⯅ @fluid-example/bundle-size-tests: +61.82 KB
Metric Name	Baseline Size	Compare Size	Size Diff
container.js	180.09 KB	180.13 KB	⯅ +38 Bytes
map.js	39.79 KB	39.79 KB	■ No change
matrix.js	137.45 KB	137.45 KB	■ No change
odspDriver.js	191.48 KB	253.23 KB	⯅ +61.75 KB
sharedString.js	167.6 KB	167.64 KB	⯅ +38 Bytes
Total Size	716.41 KB	778.23 KB	⯅ +61.82 KB
Baseline commit: d746f91
Generated by 🚫 dangerJS against 7ee079d

@heliocliu @ksbrar Why is this adding 60kb to the driver?

⯆ @fluidframework/base-host: -4 Bytes
⯅ @fluid-example/bundle-size-tests: +61.82 KB
Metric Name	Baseline Size	Compare Size	Size Diff
container.js	180.09 KB	180.13 KB	⯅ +38 Bytes
map.js	39.79 KB	39.79 KB	■ No change
matrix.js	137.45 KB	137.45 KB	■ No change
odspDriver.js	191.48 KB	253.23 KB	⯅ +61.75 KB
sharedString.js	167.6 KB	167.64 KB	⯅ +38 Bytes
Total Size	716.41 KB	778.23 KB	⯅ +61.82 KB
Baseline commit: d746f91
Generated by 🚫 dangerJS against 7ee079d

@heliocliu @ksbrar Why is this adding 60kb to the driver?

@christiango you almost got your first victim 👀  Christian removed usages of assert in https://github.com/microsoft/FluidFramework/pull/4144.  You need to remove the assert call that got added back with the implementation from common-utils

⯆ @fluidframework/base-host: -4 Bytes
⯅ @fluid-example/bundle-size-tests: +61.82 KB
Metric Name	Baseline Size	Compare Size	Size Diff
container.js	180.09 KB	180.13 KB	⯅ +38 Bytes
map.js	39.79 KB	39.79 KB	■ No change
matrix.js	137.45 KB	137.45 KB	■ No change
odspDriver.js	191.48 KB	253.23 KB	⯅ +61.75 KB
sharedString.js	167.6 KB	167.64 KB	⯅ +38 Bytes
Total Size	716.41 KB	778.23 KB	⯅ +61.82 KB
Baseline commit: d746f91
Generated by 🚫 dangerJS against 7ee079d

@heliocliu @ksbrar Why is this adding 60kb to the driver?

@christiango you almost got your first victim 👀 Christian removed usages of assert in #4144. You need to remove the assert call that got added back with the implementation from common-utils

Hmm, the build didn't fail. Not sure if the build here kicked off after I merged the webpack plugin. Is that why we didn't catch it?

/azp run Build - client packages

@christiango this is targeting the 0.28 branch which is why


Questions about the implementation of DeepScalper

Hi, first I'd like to thank you all for this brilliant repo!
I found you out by searching the relevant information of DeepScalper. I see this repo is maintained by a team of NTU led by Prof Bo An, who is also one of the authors of DeepScalper, so it's reasonable to assume that what is implemented here should be the same as what is described in the paper. However, I have found some major discrepancies:

The paper says DeepScalper uses both macro-level(OHLCV data and technical indicators) and micro-level(LOB data) as features, but in this repo only macro-level data is used.
The paper uses per-minute OHLCV data, while this repo only uses daily OHLCV data.
The paper states that a two-dimensional action space of (price, volume) is used:

We use a more realistic two-dimensional
fine-grained action space for intraday trading, which represents
a limit order as a tuple (𝑝𝑡𝑎𝑟𝑔𝑒𝑡, ±𝑞𝑡𝑎𝑟𝑔𝑒𝑡). 𝑝𝑡𝑎𝑟𝑔𝑒𝑡 is the target
price, 𝑞𝑡𝑎𝑟𝑔𝑒𝑡 is the target quantity and ± is the trading direction
(long/short).

However, in this repo only the volume dimension is present, and the execution price is simply assumed to be the latest trade price(close price) of the last bar, which is not a realistic assumption in the context of high frequency trading, as it ignores bid-ask spread and slippage.
All the above makes the implementation looks like only a prototype instead of a real one. I wonder what is the reason behind it? Your reply would be appreciated, thanks!

Have you reviewed the DDQN High Frequency Trading Jupyter notebook and/or configs? They are using LOB data and the same DDQN agent.
https://github.com/TradeMaster-NTU/TradeMaster/blob/1.0.0/tutorial/Tutorial6_DDQN.ipynb

Thanks for your interest :blush:! As you mentioned, the implementation of DeepScalper is a prototype version. The reason is that the original code is built based on the codebase and minute-level stock index and treasury bond data provided by our industry collaborators, which is not allowed to make them publicly available due to confidentiality requirement. While building this TradeMaster repo, our first priority is to build the whole RL for trading pipeline. So we decide to implement this prototype version first.
If you are interested in DeepScalper, we are more than happy to help you make a pull request for the full version of DeepScalper on this TradeMaster repo.
If you are interested in trading with the more realistic two-dimensional actions, we would like to recommend the current high frequency trading settings in this repo as @joshwigginton suggests.
Our team will continuously update this repo to improve its quality in the future. Could you please star and fork this repo to avoid missing new updates? Your support means a lot to us. Thank you.

I understand that the LOB/minute-level data should remain confidential because they are provided by industry collaborators, however, it seems a bit strange that the codebase(especially the RL part) is also provided by them and cannot be disclosed.
Anyway, thanks for building this great repo again! I have starred this repo and will also check the hft settings.

For the codebase, it is provided by our collaborators because it is implemented based on the company's previous internal code on some other RL for trading projects. I agree that it is possible to disclose the key RL part with some other open-source minute-level LOB and k-line data. However, there are many difficulties in practice. For instance, the performance variability of RL across different datasets is usually large so that we need to tune all knobs such as hyperparameters again. The original one and TradeMaster are built on different RL frameworks so that it takes engineering efforts to transfer the implementation.
Even though there are some difficulties, I agree with you that this is a good feature to be added. We will work on this later and hopefully it can be available by the end of next month . Thanks again for your interest !

That's great to hear! I'm very grateful for your commitment and your patience. Yes, I can imagine that it is not a trivial task to migrate the legacy code to a new framework and on a new dataset, which makes your committment on it even more precious. I'm looking forward for this new feature!

Hello! It's been a while, I wonder is there any updates on DeepScapler?


Add missing CAN{1,2}, LPUART{1,2} modules; indexify CSE_PRAM, ADC{0,1}.{SC1,R} registers

Edit: 'wip-' prefix has been removed from project name, and crate version has been set to 0.11.0.
S32K144 PAC generated with svd2rust v0.17.0. As stated in the svd2rust changelog, it generates far more compact and more generic code than previous versions.
I have made some modifications in the .svd file which includes, making CSE_PRAM EmbeddedRAM into an array. The same is done with ADC0 and ADC1 SC1 channel registers and Data Result Registers, R. CAN1 and CAN2 peripherals are also added as separate structs, so that these peripherals can be used. The same is done with LPUART1 and LPUART2.

Is there a particular reason why #3 was closed?

Maybe I am just a github noob, but I had to commit the changes I made, which required a new pull request, right?

Every pull requests tracks whatever branch you applied your changes to from your fork. In the case of #3, your issue1 branch is tracked. Any changes you make on this branch: new commits, commit reorders, history rewrites, etc. will be reflected in the pull request. There is no need to create a new one.
I recommend you try it out: the crate is still named wip-s32144 and its version isn't 0.11.0 throughout the commits in this PR. This is where you will have to rewrite history with git rebase. In case something goes wrong locally you can pull the history down again from your issue1 branch.
Or if you'd rather not, you can allow me to edit your PR.

Ah, okay. TIL. Should I just reopen #3 and commit the changes there?

Either here or #3 works.


add 'vc-export' module to export Verifiable Credentials

vc-export module provides methods to convert IDocument (the verifiable
documents created from<EMAIL_ADDRESS>type of json to VerifiableCredential
type of document (ie, the w3c VC standard compliant json). This method also
provides methods to prepare VP (Verifiable Presentation) from the IDocument,
and all methods to verify the proofs attached.

Output at the end of demo-vc now.
✅ Stream-Signature-Proof true ✧ Stream-Proof true ✧ Digest-Proof true ✧ Self-Signature-Proof true
✅ Credential revoked!
❌ Stream-Signature-Proof true ✧ Stream-Proof {verified: false, status: 'revoked'} ✧ Digest-Proof true ✧ Self-Signature-Proof true


feat(preset-mini)!: rename variant uno-layer-x to sheet-x

Breaking changes with the renaming, but only the variant. The terminology, comment label, and core api are still using layer.
Also, if the naming is not acceptable, please close the PR.

What's the reason of doing so?


Introduce empty constructor option to Shell.xaml.cs

@ViktorBergman this is for you. For everyone else, this allows you to do this:
// runs even if restored from state
public override async Task OnInitializeAsync(IActivatedEventArgs args)
{
    // setup hamburger shell
    var frame = new Frame();
    Window.Current.Content = frame;
    if (frame.Navigate(typeof(Views.Shell)))
    {
        var nav = NavigationServiceFactory(BackButton.Attach, ExistingContent.Include);
        var page = frame.Content as Views.Shell;
        page.SetNavigationService(nav);
    }
    await Task.Yield();
}

Resulting visual tree looks like this:

Why would you want to do this? Because it is required for the MS Band SDK to work.

@JerryNixon Thanks for putting time and effort into finding a solution for this! You rock!


Unable to recreate the environment.

Solving environment: failed
ResolvePackageNotFound:

nettle=3.6
libxkbcommon=1.0.1
dbus=1.13.18
gst-plugins-base=1.14.1
libstdcxx-ng=11.2.0
readline=8.2
nspr=4.35
_openmp_mutex=5.1
libedit=3.1.20221030
nss=3.89.1
libgcc-ng=11.2.0
libuuid=1.41.5
gnutls=3.6.13
ncurses=6.4
gmp=6.2.1
gstreamer=1.14.1
libvpx=1.7.0
ld_impl_linux-64=2.38
libgfortran5=13.1.0
libgfortran-ng=13.1.0
libgomp=11.2.0
openh264=2.1.1
x264=1!157.20191217

Which OS are you on?
What is the exact traceback you're getting?

I am currently using windows 11. Please find the exact error in the image below.

Are you using Conda?
Otherwise, you need to ensure your system is set up to manage Python and its packages.
Other option to avoid the conda-forge packages and just install via pip all the corresponding required libraries in environemnt.yml.

I don't have access to a Windows machine rn.
Check out https://github.com/varungupta31/dashcam_anonymizer/issues/2#issuecomment-1676337342
Do the steps mentioned in the comment, create the environment, and install the mentioned packages manually.
See if that works.

Tried it, still not working. I can see that torch is a dependency for ultralytics. I am creating a new environment and trying, with no luck.

What's the issue with installing torch?
https://pytorch.org/get-started/locally/ maybe of help.
If there is a package clash (or version), which is not supported on your OS atm, then there's little I could do.

The torch issue is sorted. Now I got a new error. it says that there is FileNotFoundError: [Errno 2] No such file or directory: 'model\\best.pt'

Please read the repo's readme.


[AppService] Fix webapp/slot creation for Windows Containers

Description
Creating Windows Container webapps and slots using non-public container images (e.g. images in ACR or in a Docker Hub private repository) is currently broken because an image validation is performed at creation time (e.g. ensure the image exist, ensure it is a supported OS version, ensure the right credentials provided, etc.) which requires container registry credentials and, before this PR, the creation from az webapp create (and az deployment slot create) was performed in two steps:

Create the webapp/slot with no container registry credentials
Update the container registry credentials

With this change, we ensure that container registry credentials are passed at creation time (step 1 above)
Testing Guide
Existing commands suffer no change as part of this PR:
az webapp create --name myWebsite --plan myAppServicePlan --resource-group myResourceGroup --deployment-container-image-name https://mycontainerregistry.azurecr.io/mycontainerimage:latest --docker-registry-server-user <<some user name>> --docker-registry-server-password <<some password>>
az webapp deployment slot create --name myWebsite --resource-group myResourceGroup --slot my-new-slot --configuration-source myWebsite
History Notes

[Component Name 1] BREAKING CHANGE: az command a: Make some customer-facing breaking change.
[Component Name 2] az command b: Add some customer-facing feature.

This checklist is used to make sure that common guidelines for a pull request are followed.

[x] The PR title and description has followed the guideline in Submitting Pull Requests.

[x] I adhere to the Command Guidelines.

FYI @jvano, @panchagnula

Looks good to me, :shipit:

Looks like this test is failing access-restrictions-slot test is failing please re-record it by running adzev test  --live and  include  the yaml(recording) that should get the build working

@vinisoto is this something we need to fix on Powershell as well? Thanks for taking care of this.

Thanks @panchagnula. Will re-record the tests. Re: powershell, I'm not sure if it is broken but it is next on my list.

AppService

All checks have passed after updating test recordings.
Thanks

kindly requesting to merge this PR


Math Magicians: tests

In this project We;

Set up React Testing Library.
Write unit tests for the files operate.js and calculate.js using Jest.
Create unit tests for all React components.
Ensured there are no linter error.

@Esmatullah12, please kindly add to the logic also. Adding only to the README file is not a valid pair programming conribution please.

Hi @blessing-michael, @Esmatullah12
While you made a great effort in this project, unfortunately, I cannot proceed to review your code.
Invalid Code Review Request
You have submitted a project where one partner has only contributed to the README file without making real contributions to the codebase during a pair-programming activity. Our guidelines explicitly state that both partners should collaborate substantively on the codebase. Editing only the README file doesn't qualify as a valid contribution, and as such, your Code Review Request is invalid.
Your Code Review Request will be marked as invalid in your Dashboard, so please submit a new one once you've made the necessary corrections 🙏.
Cheers and Happy coding! 👏👏👏
Feel free to leave any questions or comments in the PR thread if something is not 100% clear. Please, remember to tag @topeogunleye in your question so I can receive the notification.
Please, do not open a new Pull Request for re-reviews. You should use the same Pull Request submitted for the first review, either valid or invalid unless it is requested otherwise.