Failed setup report on new Photon

From a tech support ticket. User eventually was able to setup using serial on his computer.
Samsung Galaxy S5 running Lollipop

Click ready on "Time to set up your Photon!"
Select photon in "Choose your Photon"
"Connecting to Photon" pops up. 15-20 seconds later it goes away.
Try again to select photon in "Choose your Photon"
"Connecting to Photon" pops up for 2 seconds-ish and goes away.
"Error. Please try running setup again after resetting your Photon and putting it back in blinking blue listen mode if needed."
Press OK
Back to "Time to set up your Photon!" screen.
Repeat steps 1-8
App crashes ("Unfortunately, Particle has stopped.")

I've seen this same issue in some of my tickets.

Hi, I reported this bug.  Is there a way for me to provide additional information so we can get some traction on this?

@TheSauceMan feel free to add additional information here in the comments of this PR.

@chobberoni sure.  I guess my question isn't where do I put the additional information, it is where do I get the information from?

@TheSauceMan here are a few other things which would help:

are you being offered a "report" button to report this bug when the app crashes?  If so, hitting that report button helps us a ton.
esp if you dont' get that button in item 1, if you could capture device logs leading up to and at the crash, that would help
your Wi-Fi AP name, the security type you're using (WPA, WPA2, etc), and if the SSID is hidden

Wow, sorry, I missed this.
I think I did get the report option once.
What's the best way to capture the device logs?
You want the brand of AP?  Or you want my SSID?  there's nothing special about my SSID.  It's not hidden, and uses WPA2.  Mind you, I can set the photons up manually.

There's an updated version of the app on the Play store.  Can you give that a spin and see if you can still reproduce this?
Thanks!

Hi @jensck ,
So I tried it and I have bad news and good news.  The bad news is the behavior didn't really change except that repeated attempts don't result in a crash.  It still tells me the list of Photons in blue flashing mode and when I pick one it just sits there forever.
The good news, however, is that I have a work-around, thanks to another app that I saw that tried to register a small wifi peripheral like that.  Basically the workaround is to go to Android Settings -> Wifi -> Disable "Smart network switch".  Then I was able to configure my Photon and re-enable "Smart network switch" when I was done.  The other app I used even did me the favor of automatically opening up the Wifi Settings page to turn it on and off so it was very user friendly.
Maybe you can try to understand why that android feature is interfering with the setup process and think of a work-around?
Sauce

Thanks for the update, that's all very helpful info!  I just discovered a potentially related issue, so hopefully we'll have a proper solution before long.
As for "Smart network switch", that's not a standard feature that I'm aware of.  Is this a Samsung device by any chance?

It is indeed a Samsung Galaxy S5.
I suspected it may be a Samsung customization and was impressed that the other app had dealt with it so cleanly. Still can't help but wonder if there is a way to avoid toggling the feature, which would make it better still.
Sauce

Yeah, I'd really like to avoid making the user do it.  Asking users of the Particle app to go to their Wi-Fi settings (even if we can provide a shortcut) would already be lame and tedious, but it'd be an absolute last resort for apps using the SDK that are targeted at the masses.
I'm crossing my fingers that the related network changes I'm working on will solve this, too, since they may stem from the same core problem.  When I have the fix put together, would you be interested in beta testing it?

Sure thing, if you need a hand, I can help you test.
I'll be out of town next week but may be able to slip a Photon in my suitcase.
Sauce

@TheSauceMan the latest Play store release should fix this issue.  Can you confirm?

I have installed the latest play store release (installed today), and my particle app still crashes unless I have the "smart network switch" option disabled.

@bleathem what are your device model number and Android OS version?
Also, is smart network switch enabled by default, or did you turn it on manually?

There's been a fix/workaround for this for a while.  Closing.


Almost 100% except for some names of clothes

I think Chinese players can play this game smoothly with this translation file:)
By the way, I've killed The Overlord with every perk, but I've not reached the Shrouded Land yet.
So the names after The Overlord may be not that accurate.

Hey, thanks a lot for your help!
Why did you close the pull request? Do you still want me to merge this in to the master branch?
If you're interested, I can send over images/descriptions of entries related to the Shrouded Land.


[api] Added Early stopping configuration (#38)

Description
This PR implements a listener for early stopping as described in #38. And takes the code @gforman44  and implements that in a TrainingListener
resolves #38

Local build is happy now, let's see if CI agrees with that. Also fixed your comments.

I was able to reproduce the failing ci build locally with JDK11. Fixed it in commit 402df41

Codecov Report
Attention: 1361 lines in your changes are missing coverage. Please review.

Comparison is base (bb5073f) 72.08% compared to head (402df41) 72.04%.
Report is 898 commits behind head on master.

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@             Coverage Diff              @@
##             master    #2806      +/-   ##
============================================
- Coverage     72.08%   72.04%   -0.05%
- Complexity     5126     7106    +1980
============================================
  Files           473      703     +230
  Lines         21970    31751    +9781
  Branches       2351     3294     +943
============================================
+ Hits          15838    22875    +7037
- Misses         4925     7303    +2378
- Partials       1207     1573     +366

Files
Coverage Δ

...ava/ai/djl/inference/streaming/StreamingBlock.java
100.00% <100.00%> (ø)

api/src/main/java/ai/djl/metric/Dimension.java
100.00% <100.00%> (ø)

api/src/main/java/ai/djl/metric/Unit.java
100.00% <100.00%> (ø)

api/src/main/java/ai/djl/modality/audio/Audio.java
100.00% <100.00%> (ø)

api/src/main/java/ai/djl/modality/cv/Image.java
69.23% <ø> (-4.11%)
:arrow_down:

...rc/main/java/ai/djl/modality/cv/MultiBoxPrior.java
76.00% <ø> (ø)

...ava/ai/djl/modality/cv/output/DetectedObjects.java
96.29% <100.00%> (+1.29%)
:arrow_up:

...rc/main/java/ai/djl/modality/cv/output/Joints.java
71.42% <100.00%> (ø)

.../main/java/ai/djl/modality/cv/output/Landmark.java
100.00% <ø> (ø)

...i/djl/modality/cv/transform/RandomResizedCrop.java
94.11% <100.00%> (+5.22%)
:arrow_up:

... and 226 more

... and 373 files with indirect coverage changes

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


LogUp-GKR tracking PR

This is a tracking PR for the LogUp GKR work. The plan right now is:

Get the end-to-end process working.
Move all generic code to Winterfell (probably for Winterfell v0.10.0 release).

At this point we should finalize the public interface for LogUp-GKR in Winterfell.

Update this branch to use the new release of Winterfell.

Closing in favor of #1504


Merges source code from VSO/releases/prod into GitHub repo.

npm package version - 0.3.7.

Hi @ignatvilesov, I'm your friendly neighborhood Microsoft Pull Request Bot (You can call me MSBOT). Thanks for your contribution!

It looks like you're a Microsoft contributor (Vilesov Ignat (Akvelon)). If you're full-time, we DON'T require a Contribution License Agreement. If you are a vendor, please DO sign the electronic Contribution License Agreement. It will take 2 minutes and there's no faxing! https://cla.microsoft.com.

TTYL, MSBOT;


Reworked syntax diagrams creation for ease of use and simplicity.

Fixes #583
Fixes #548

Coverage remained the same at 100.0% when pulling d59ccc0cd30d5b8c0fc0822c99d2a9c649445b16 on diag into a25d2ad94c3bebc0524ddf15928924bb68903a5c on master.

Coverage remained the same at 100.0% when pulling 5d627bb577e164ac3c47e846bfb2902bd81a37c7 on diag into a25d2ad94c3bebc0524ddf15928924bb68903a5c on master.


feat: block queue metrics and stalled submission alarm

Closes #1629
Overview
Publish various block queue metrics (see the list in Changes section) and block_submit_stalled alarm.
Changes
Telemetry

Publishes :blknum_submitting telemetry event with the blknum when a block is about to be submitted
Publishes :blknum_submitted telemetry event with the blknum when a block is successfully submitted

These are used for metrics reporting.
OMG.Bus

Broadcasts :block_submitting event with the blknum when a block is about to be submitted
Broadcasts :block_submitted event with the blknum when a block is successfully submitted

These are used by BlockQueue.Monitor to keep tracking of stalled blocks.
Datadog metrics

block_queue_blknum_submitting: Reports the blknum being attempted (e.g. 1000, 1000, 2000, 1000, 2000, 3000, 2000, 3000, ...)
block_queue_blknum_submitted: Reports the blknum succesfully submitted (e.g. 1000, 2000, 3000, ...)
block_submission_attempt: Increments by 1 when a block submission is attempted
block_submission_success: Increments by 1 when a block submission is successfully submitted
block_queue_num_blocks_stalled: Reports the number of stalled blocks at the moment of metric collection (e.g. 0, 0, 2, 1, 0, 1, 0, ...)
Rename block_submission gauge to block_submission_gas for better naming accuracy

Alarm

Raises :block_submit_stalled alarm when at least one block has been submitting for the past BLOCK_SUBMIT_STALL_THRESHOLD_BLOCKS root chain blocks or longer
Clears :block_submit_stalled alarm when all submitting blocks have been submitting for less than BLOCK_SUBMIT_STALL_THRESHOLD_BLOCKS root chain blocks
Defaults BLOCK_SUBMIT_STALL_THRESHOLD_BLOCKS env var to 4 root chain blocks

The threshold is in number of root chain blocks because blocktime can vary greatly between networks. Even on mainnet blocktime can vary between ~ 1-60 seconds, and a block submission should not be considered stalled, for example, after 30 seconds of submitting if the blocktime is 45 seconds.
Miscellaneous

Change log level for block formation from debug to info

Testing

Set geth's --miner.gasprice to a very high value, e.g. --miner.gasprice "500000000000" (500 Gwei)
Submit some transactions to the network
block_queue_blknum_submitting should increase and block_submission_attempt is tallied
Childchain block submissions stay pending, not getting included in root chain blocks
block_submit_stalled alarm should raise
Set geth's --miner.gasprice to a very low value, e.g. --miner.gasprice "100000000" (0.1 Gwei)
Childchain block submissions start getting included in root chain blocks
block_queue_blknum_submitted should increase and block_submission_success is tallied
block_submit_stalled alarm should be cleared

Tagging quite a bit more reviewers than usual since it's touching the BlockQueue, although only emitting out telemetry and bus events.

Metrics

Submission stall monitor
$ curl -s <dev_url>/alarm.get -w "\n" | jq

{
  "data": [
    {
      "block_submit_stalled": {
        "node"<EMAIL_ADDRESS>        "reporter": "Elixir.OMG.ChildChain.BlockQueue.SubmissionMonitor"
      }
    }
  ],
  "service_name": "child_chain",
  "success": true,
  "version": "1.0.3+733aab2"
}


Hex payload send to TCP Client (IDFGH-8644)

Answers checklist.

[X] I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
[X] I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
[X] I have searched the issue tracker for a similar issue and not found a similar issue.

General issue report
Hi All,
I am facing one problem with tcp_client example, I have a UHF reader as a client and creating socket connection with that, the connection is successful but when I am sending the data, it is not responding anything.
It is working well with below python script -
import socket, time, sys

TCP_IP = '<IP_ADDRESS>'
TCP_PORT = 60000
BUFFER_SIZE = 1024

str1 = "\x53\x57\x00\x05\xFF\x24\x02\x00\x2D"
str2 = "\x53\x57\x00\x03\xFF\x01\x24"

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
try:
  s.connect((TCP_IP, TCP_PORT))
except:
  print('failed ' + TCP_IP + ' down')
  sys.exit()

s.sendall(str1)
time.sleep(0.2)
while True:
   s.sendall(str2)
   time.sleep(0.2)
s.close()

It is not working with C code : below attached is code snippet -
char *readerCmd = "\x53\x57\x00\x05\xFF\x24\x02\x00\x2C";
char *readerAnswerModeCmd = "\x53\x57\x00\x03\xFF\x01\x53";

static void tcp_client_task(void *pvParameters)
{
    char rx_buffer[128];
    char host_ip[] = HOST_IP_ADDR;
    int addr_family = 0;
    int ip_protocol = 0;

    while (1) {
#if defined(CONFIG_EXAMPLE_IPV4)
        struct sockaddr_in dest_addr;
        dest_addr.sin_addr.s_addr = inet_addr(host_ip);
        dest_addr.sin_family = AF_INET;
        dest_addr.sin_port = htons(PORT);
        addr_family = AF_INET;
        ip_protocol = IPPROTO_IP;
#elif defined(CONFIG_EXAMPLE_IPV6)
        struct sockaddr_in6 dest_addr = { 0 };
        inet6_aton(host_ip, &dest_addr.sin6_addr);
        dest_addr.sin6_family = AF_INET6;
        dest_addr.sin6_port = htons(PORT);
        dest_addr.sin6_scope_id = esp_netif_get_netif_impl_index(EXAMPLE_INTERFACE);
        addr_family = AF_INET6;
        ip_protocol = IPPROTO_IPV6;
#elif defined(CONFIG_EXAMPLE_SOCKET_IP_INPUT_STDIN)
        struct sockaddr_storage dest_addr = { 0 };
        ESP_ERROR_CHECK(get_addr_from_stdin(PORT, SOCK_STREAM, &ip_protocol, &addr_family, &dest_addr));
#endif
        int sock =  socket(addr_family, SOCK_STREAM, ip_protocol);
        if (sock < 0) {
            ESP_LOGE(TAG, "Unable to create socket: errno %d", errno);
            break;
        }
        ESP_LOGI(TAG, "Socket created, connecting to %s:%d", host_ip, PORT);

        int err = connect(sock, (struct sockaddr *)&dest_addr, sizeof(struct sockaddr_in6));
        printf("error is %d ", err);
        if (err != 0) {
            ESP_LOGE(TAG, "Socket unable to connect: errno %d", errno);
            break;
        }

        err = send(sock, readerCmd, strlen(readerCmd), 0);
        if (err < 0) {
                ESP_LOGE(TAG, "Error occurred during sending: errno %d", errno);
                break;
            }
        vTaskDelay(500/portTICK_PERIOD_MS);

        ESP_LOGI(TAG, "Successfully connected");

        while (1) {
            err = send(sock, readerAnswerModeCmd, strlen(readerAnswerModeCmd), 0);
            if(err < 0){
                ESP_LOGE(TAG, "Error occurred during sending: errno %d", errno);
                break;
            }
            vTaskDelay(500 / portTICK_PERIOD_MS);
        }
        if (sock != -1) {
            ESP_LOGE(TAG, "Shutting down socket and restarting...");
            shutdown(sock, 0);
            close(sock);
        }
    }
    vTaskDelete(NULL);
}

How can I send the Hex payload in socket send command. Please provide me some inputs on how we can resolve this issue.

Solved it by sending "\r\n" to socket after sending array data. Closing it.


How to setup Geth account password

Hi,
I'm running the whole backend well and want to import the geth accounts of into my Metamask wallet. It requires the password of geth account. I checked the "dev_geth.ex" file and found your procedure of creating geth accounts. Seems you set the password as blank with an empty text file by command line. MetaMask, however, forcibly requires a password to import the account.
Can I set password of the initial geth accounts in this system?


Uploaded Summary Invisible To Some Team Members

When the build uploads a custom summary using either ##vso[build.uploadsummary]$local_file or ##vso[task.attachment type=Distributedtask.Core.Summary;name=Custom Summary;]$local_file commands, the uploaded summary is visible to some team members while invisible to others. Not all team members have the same permissions and privileges but everyone can access the builds. Is it a bug? If not, what permissions determine the visibility of uploaded summary; and how to tweak those?
Thanks!

"View build" permissions is all we need.
I am able to reproduce where in some cases the markdown is not displayed.
This is has to do with bundling of javascripts, it's a UI bug.
Will fix this in M100.

fixed, fix will be rolled out in next sprint.

Thanks for the quick turnaround! Is it possible to link here the pull request(s) which fix this issue?

That is not a task fix, it's a fix for internal code, I don't think it's possible to link here.


Fixed #10403 -- Added a declarative syntax for FormSet, ModelFormSet & InlineFormSet.

This patch is an update of @Parth1811 's closed PR.
It includes classes for FormSet, ModelFormSet, and InlineFormSet, allowing for the creation of formsets using a declarative syntax instead of a factory.

Thanks @Mitchina, for taking the time to work on this ancient PR.
I have lost the context for this, but the overall changes look promising to me.

Thanks @Mitchina, for taking the time to work on this ancient PR. I have lost the context for this, but the overall changes look promising to me.

Hi @Parth1811, thank you for the encouragement! I'm glad to hear that you find the changes promising. Your changes have been fundamental to me and I truly appreciate the opportunity to build upon them. I hope we can get it in!

I was confused by this for a second, the Trac ID is the same as this PR number. Though not sure if this is still being worked on.


Allow narrowband IBM SR model

I don't know why this is hardcoded to broadband but some people need narrowband.

Any problem with this? Can it be merged please?


Update README

This addresses some of the migration items in #243

[Current coverage][cc-pull] is 84.02%

Merging [#248][cc-pull] into [master][cc-base-branch] will not change coverage

@@             master       #248   diff @@
==========================================
  Files            63         63
  Lines           757        757
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
  Hits            636        636
  Misses          121        121
  Partials          0          0

Powered by Codecov. Last updated by [0a22b86...1f9df9e][cc-compare]
[cc-base-branch]: https://codecov.io/gh/TechnologyAdvice/stardust/branch/master?src=pr
[cc-compare]: https://codecov.io/gh/TechnologyAdvice/stardust/compare/0a22b8631d2ce7955fe3b178f7550b6ee5091d44...1f9df9e26d2aad10d3d74215e65d0130287bb559
[cc-pull]: https://codecov.io/gh/TechnologyAdvice/stardust/pull/248?src=pr


regexp.MatchString does not work as expected IMHO

Please answer these questions before submitting your issue. Thanks!

What version of Go are you using (go version)?

go1.6 darwin/amd64

What operating system and processor architecture are you using (go env)?

Mac OS X 10.11.3
GOARCH="amd64"
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOROOT="/usr/local/go"
GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"
GO15VENDOREXPERIMENT="1"
CC="clang"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fno-common"
CXX="clang++"
CGO_ENABLED="1"

What did you do?

Match a string to a pattern by using regexp. MatchString behaviour is similar to FindString, where the left-most string matching the pattern is found. Because of this, a simple regex like the following does not work as expected:
var myRegex = regexp.MustCompile(`[A-Za-z0-9]+`)
result := myRegex.MatchString("hello goodbay")
fmt.Printf("Match? %v, Expected=false\n", result)

Link to code: http://play.golang.org/p/kV_MibkKFv

What did you expect to see?

After running above code, result variable gets a true value.

What did you see instead?

I would have expected to get false, like in other languages (e.g. Java)

It seems to work as documented and consistently between MatchString and FindString. FindString matches too: http://play.golang.org/p/YnL9JVDqmL
I'm not seeing a bug here, so let's move this to a forum. See https://golang.org/wiki/Questions.


Implement the details, picture and marquee elements

This pull request adds implementations for the <details> and <picture> elements, as well as a stub for <marquee>.
The <details> "toggle" event is implemented, though it is missing one step involving a task queue which I wasn't entirely sure how to approach. Besides that, it passes all tests. It uses the Event constructor, as it seems to be needed to set isTrusted.
I believe these are the last HTML elements with their own interfaces that are not yet present in jsdom.

"queue task" in jsdom is just going to be setTimeout(, 0).
So to implement this we'll want to store the return value of that setTimeout, and null it out when the function starts. Then we can add an if check that prevents dispatching the event if the stored timeout ID is non-null.
For marquee, I think you need to set up the event handlers by using code similar to https://github.com/tmpvar/jsdom/blob/0b4b8e0f548d1c6568c5902b3b6773b11f839e29/lib/jsdom/living/nodes/GlobalEventHandlers-impl.js#L87 . I think maybe because HTMLElement already mixes in globalEventHandlers, only the createEventAccessor will be what you need, not the rest of the stuff. I guess the event handlers aren't tested anywhere :-/

@domenic Thanks for the advise! I have implemented it now, and all tests except for one is passing in toggleEvent.html. I've not yet determined what is needed to pass the failing test, but interestingly this particular test is failing in Chrome and Safari as well.
It is tempting to dismiss the test itself as being incorrect, but since Firefox does pass it I suppose this will require some further investigation. I'll be busy for the next few days, so if anyone else would like to take a look it would be appreciated :-)
As for the details of <marquee>, I'm content to leave it as a stub for now. I'd imagine that there are other areas of jsdom where my time would be better spent ;-)


added edit feature to entries

added two functions in script.js called handleEditEntry(id) and handleSaveEntry(id) to initiate editing process and save edited contents also modified renderEntries()

Hi @sooryadev007 The functionality you have implemented is efficiently working. But fixing these two issues in your feature would be helpful.

When the edit option is clicked, the ui of the edit feature is not so professional. Please enhance it. You can refer this ss .

The edit icon is ok but anything better would look much more efficient and the current one placed horizontally and can be improved.

So please fix these, but the functionality that you have implemented is good.

Hi @sooryadev007 can you please provide the screen shots of what ever changes you have made.

hey @TheOpenInnovator in the current commit i have pushed recently I have made changes to script.js

and style.css

Hi @sooryadev007 , Please make sure these changes are implemented :
The edit logo is horizontal and it requires to be in proper position(tilted vertical prefered) :

The UI of the edit function could be enhanced.

If the following changes are implemented, please do attach the ss of only the changes made as attached in this comment instead of the whole code part which is changed.

hey made the necessary changes

Congratulations @sooryadev007 Your PR has been merged. You have made a valuable contribution. Keep Contributing, keep learning.


Allow the Consumer to disable auto-commit offsets

Versions
Sarama Version: v1.17.0
Kafka Version: 2.2.0
Go Version: go1.10
Configuration
Not applicable
Logs
Not applicable
Problem Description
I have a scenario where I want to use the PartitionManager in Sarama, but disable the auto commit of offsets. I use the MarkOffset to calculate lag in my consumer.  I also see from a google search there are others with similar issues.
Since the Consumer.Offsets.CommitInterval is used in a time.NewTicker it cannot be disabled:
The duration d must be greater than zero; if not, NewTicker will panic.
Workarounds
A workaround would be to set this to a high number so the bom.timer.C never triggers.
Another workaround would be not to call MarkOffset. I then would need to keep my own store of current partition offsets in the consumer.
My own branch
I have run a branched Sarama version for some time, it has two additions:

It adds a configuration Consumer.Offsets.Enable bool
In https://github.com/Shopify/sarama/blob/v1.17.0/offset_manager.go#L417 we check if Consumer.Offsets.Enable is false, and then calls bom.timer.Stop().

This might not be the ideal solution, or right place to put the check, but it works for me.
Since I need to reapply my patch for every release of Sarama, perhaps this could be addressed and fixed in the library?

A possibly better approach would be to check for Consumer.Offsets.Enable in https://github.com/Shopify/sarama/blob/v1.17.0/offset_manager.go#L445 so we do not tamper with the bom.timer but only block the OffsetCommitRequest as long as Consumer.Offsets.Enable is set.
I could prepare a PR

@kjelle PR is definitely welcome.

@varun06 Any way of getting #1164  merged? CLA is signed

Will do today. Thanks.
On Mon, Sep 16, 2019 at 7:18 AM Kjell Tore Fossbakk <
<EMAIL_ADDRESS>wrote:

@varun06 https://github.com/varun06 Any way of getting #1164
https://github.com/Shopify/sarama/pull/1164 merged? CLA is signed
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Shopify/sarama/issues/1158?email_source=notifications&email_token=AAJZPZVGAC6VNGNBIQMFGKTQJ52R5A5CNFSM4FRMQ4UKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6Y6MJY#issuecomment-531752487,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAJZPZR7YLFQWMDRJXMDQYDQJ52R5ANCNFSM4FRMQ4UA
.

@varun06 What's the status on this?

Hey Friend, there is one comment on PR, please have a look, once that is resolved, will merge it.

I am closing this issue since the PR #1164 was merged.


Loading Asset from AssetBundle causing crash

Hi, I am currently trying to break down your source code to learn.
I am currently crashing when I am trying to LoadAsset from the bundle. This is the code:
                var bundle = AssetBundle.LoadFromFile(Path.Combine(Application.dataPath, "outline"));
                OutlineShader = bundle.LoadAsset<Shader>("assets/outline.shader");

Would be nice if you can help out, thank you.

You are probably missing this outline file in your EFT installation. It is expected when you are compiling the trainer yourself with Visual Studio.
You can either:

use the universal install to install all dependencies for you, then building on top of that
or you can do it manually, the outline file is here and must be copied in your [TARKOV_INSTALLATION]\\EscapeFromTarkov_Data


-xcb-native-painting flag in bv_qt causes build failure on some systems.

Describe the bug
Wanted to keep track of this, as I believe we have had multiple reports, but the only one I could find was this
SRE ticket 280
The flag was added to fix toolbar issues over X-forwarding. (#3484, #5593)
Do we need to find another way to resolve the x-forwarding toolbar issue, or conditionally add the flag? Eg not add it for specific systems where it fails (Linux Mint)?
Expected behavior
build_visit should build Qt properly.

Perhaps having all the packages mentioned in https://doc.qt.io/qt-5/linux-requirements.html would resolve the failure.
There is a ticket #5768 to document these requirements.


Calculations exclude zeros

When you have a dataset that includes 0-values, the calculation ignores them. (eg: if you give it [[2010, 1],[2011, 3], [2012,0],[2013,1]], it will ignore the [2012,0] value). I've looked at the code, and it appears the problem is this line:
         if (data[n][1]) {
            sum[0] += data[n][0]; //Σ(X)
            sum[1] += data[n][1]; //Σ(Y)
            sum[2] += data[n][0] * data[n][0]; //Σ(X^2)
            sum[3] += data[n][0] * data[n][1]; //Σ(XY)
            sum[4] += data[n][1] * data[n][1]; //Σ(Y^2)
          } else {
            N -= 1;
          }

note that if(data[n][1])  evaluates to false even if data[n][1] = 0, so line 150 should be replaced with if(data[n][1] = null). Probably some other lines too.
I think this is also the cause of issue #21

could you fork and create a pull request?


[Feature Request] Touching Nested Parent Timestamps

Just like Eloquent lets you eager load nested relationships like this:
$books = Book::with('author.contacts')->get();

It would be awesome if we could do this also with touching timestamps. Perhaps in a way like this:
protected $touches = array('author.contacts');

Guys but the problem is with belongsToMany:
let`s say there are 3 models A, B, C
A: belongsTo('B'), $touches = array('B');
B: belongsToMany('C')
C: belongsToMany('B')
If I do A->save() it will update A, B but not C because is not possible to write something like:
// in model A
function cs() {
// error since $this->bs is collection and not a model...
return $this->bs-cs();
}

@anatolymd your answer seems to make good sense! However, it isn't working for me. Could it be because I'm on 5.2? I have a Signup, Post, and Reaction.
class Signup extends Model
{
    public function posts()
    {
        return $this->hasMany(Post::class)->with('tagged');
    }
}

class Post extends Model
{
    protected $touches = ['signup'];

    public function reactions()
    {
        return $this->hasMany(Reaction::class);
    }

    public function signup()
    {
        return $this->belongsTo(Signup::class);
    }
}

class Reaction extends Model
{
    protected $touches = ['post', 'signup'];

    public function post()
    {
        return $this->belongsTo(Post::class);
    }

    public function signup()
    {
        return $this->post->signup();
    }
}

Am I doing anything wrong?


91 implement the repository pattern

CheepRepository:

inheriting from IRepository
using CheepDTOs
called from Razor
limit return to 32 Cheeps per page
can filter cheeps by author

The project can run without any compile warnings or errors.


Encrypt the configuration cache in a separate thread

@bot-gradle test APT

@bot-gradle test APT

I've triggered the following builds for you:

AllPerformanceTestsReadyForRelease build


[Event Request] Codeunit 7000005 "Invoice-Split Payment"- Add new parameter in OnBeforeSplitSalesInvCreateBills()

Hello,
We would need a new parameters in the event OnBeforeSplitSalesInvCreateBills().
Resulting event:
    [IntegrationEvent(false, false)]
    local procedure OnBeforeSplitSalesInvCreateBills(var GenJournalLine: Record "Gen. Journal Line"; SalesHeader: Record "Sales Header"; Installment: Record Installment; CurrDocNo: Integer; PaymentTerms: Record "Payment Terms"; RemainingAmount: Decimal; RemainingAmountLCY: Decimal);
    begin
    end;

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. Please do not reply to this, as we do not monitor closed issues. If you have follow-up questions or requests, please create a new issue where you reference this one.


[BUG]Exception when use requires

exception when use requires
starlette/authentication.py  line 60
    elif asyncio.iscoroutinefunction(func):
        # Handle async request/response functions.
        @functools.wraps(func)
        async def async_wrapper(
            *args: typing.Any, **kwargs: typing.Any
        ) -> Response:
            request = kwargs.get("request", args[idx])   #  this place Exception when the idx=0 but args = ()
            assert isinstance(request, Request)

The Exception context
[ERROR 2020-01-13 20:20:33,617 httptools_impl.py 388] Exception in ASGI application
Traceback (most recent call last):
File "/data/server/pyenv/py3.7.4/lib/python3.7/site-packages/uvicorn/protocols/http/httptools_impl.py", line 385, in run_asgi
result = await app(self.scope, self.receive, self.send)
File "/data/server/pyenv/py3.7.4/lib/python3.7/site-packages/uvicorn/middleware/proxy_headers.py", line 45, in call
return await self.app(scope, receive, send)
File "/data/server/pyenv/py3.7.4/lib/python3.7/site-packages/fastapi/applications.py", line 140, in call
await super().call(scope, receive, send)
File "/data/server/pyenv/py3.7.4/lib/python3.7/site-packages/starlette/applications.py", line 134, in call
await self.error_middleware(scope, receive, send)
File "/data/server/pyenv/py3.7.4/lib/python3.7/site-packages/starlette/middleware/errors.py", line 178, in call
raise exc from None
File "/data/server/pyenv/py3.7.4/lib/python3.7/site-packages/starlette/middleware/errors.py", line 156, in call
await self.app(scope, receive, _send)
File "/data/server/pyenv/py3.7.4/lib/python3.7/site-packages/starlette/middleware/authentication.py", line 48, in call
await self.app(scope, receive, send)
File "/data/server/pyenv/py3.7.4/lib/python3.7/site-packages/starlette/middleware/base.py", line 25, in call
response = await self.dispatch_func(request, self.call_next)
File "/data/server/pyenv/py3.7.4/lib/python3.7/site-packages/starlette_exporter/middleware.py", line 40, in dispatch
raise e
File "/data/server/pyenv/py3.7.4/lib/python3.7/site-packages/starlette_exporter/middleware.py", line 37, in dispatch
response = await call_next(request)
File "/data/server/pyenv/py3.7.4/lib/python3.7/site-packages/starlette/middleware/base.py", line 45, in call_next
task.result()
File "/data/server/pyenv/py3.7.4/lib/python3.7/site-packages/starlette/middleware/base.py", line 38, in coro
await self.app(scope, receive, send)
File "/data/server/pyenv/py3.7.4/lib/python3.7/site-packages/starlette/exceptions.py", line 73, in call
raise exc from None
File "/data/server/pyenv/py3.7.4/lib/python3.7/site-packages/starlette/exceptions.py", line 62, in call
await self.app(scope, receive, sender)
File "/data/server/pyenv/py3.7.4/lib/python3.7/site-packages/starlette/routing.py", line 590, in call
await route(scope, receive, send)
File "/data/server/pyenv/py3.7.4/lib/python3.7/site-packages/starlette/routing.py", line 208, in call
await self.app(scope, receive, send)
File "/data/server/pyenv/py3.7.4/lib/python3.7/site-packages/starlette/routing.py", line 41, in app
response = await func(request)
File "/data/server/pyenv/py3.7.4/lib/python3.7/site-packages/fastapi/routing.py", line 127, in app
raw_response = await dependant.call(**values)
File "/data/server/pyenv/py3.7.4/lib/python3.7/site-packages/starlette/authentication.py", line 62, in async_wrapper
request = kwargs.get("request", args[idx])
IndexError: tuple index out of range
To produce
from fastapi import APIRouter, Query, Depends, Header, HTTPException
from starlette.authentication import requires
from starlette.requests import Request
from zyservice.user.auth import AuthAPI, LoginResponse
from zycommon.helper.auth import get_current_user, JWTUser
router = APIRouter()
@router.post("/login", response_model=LoginResponse)
async def login(
*,
username: str = Query(..., max_length=100, description="user name"),
password: str = Query(
..., min_length=8, max_length=100, description="user password"
),
):
""" login
"""
return await AuthAPI().login(username, password)
@router.get("/info")
@requires("authenticated")
async def user_info(*, request: Request, user: JWTUser = Depends(get_current_user)):
""" get user info
"""
return {"username": user.username}
Environment

OS: [e.g. Linux ]
FastAPI Version [0.46.0, 0.45.0]

Thanks for the help here @dmontagu ! :cake: :bowing_man:
And thanks @xidianwlc  for reporting back and closing the issue :+1:


no corpus after a period of time

Stats：

revision
d216d8a0

config
XXXX

uptime
20m34s

fuzzing
0s

corpus
0

triage queue
0

signal
0

coverage
0

crash types
1 (60/min)

crashes
6 (360/min)

exec total
0 (0/hour)

max signal
0 (0/hour)

new inputs
0 (0/hour)

rotated inputs
0 (0/hour)

suppressed
0 (0/hour)

vm restarts
0 (0/hour)

config:
{
	"name": "XXXX",
	"target": "linux/arm64",
	"http": "<IP_ADDRESS>:50000",
	"rpc": ":0",
	"workdir": "/home/tr4v3ler/data/tools/syzkaller/projects/XXXX/workdir",
	"kernel_obj": "/home/tr4v3ler/data/src/XXXX/chipset/out/target/product/XXXX/obj/KERNEL_OBJ",
	"kernel_src": "/home/tr4v3ler/data/src/XXXX/chipset/kernel/linux-5.10",
	"kernel_build_src": "/home/tr4v3ler/data/src/XXXX/chipset",
	"ssh_user": "root",
	"syzkaller": "/home/tr4v3ler/data/tools/syzkaller",
	"procs": 8,
	"max_crash_logs": 100,
	"sandbox": "none",
	"sandbox_arg": 0,
	"cover": true,
	"cover_filter": {},
	"raw_cover": false,
	"reproduce": true,
	"preserve_corpus": true,
	"ignores": [
		"CPU",
		"INFO",
		"WARNING"
	],
	"strace_bin": "",
	"type": "adb",
	"vm": {
		"devices": [
			"XXXX",
			"XXXX"
		]
	},
	"asset_storage": null
}

need logs. were any programs executed?

need logs. were any programs executed?

It looks like everything is running normally, but there is no coverage.
$ ./bin/syz-manager -config android.cfg
2023/08/19 20:42:21 loading corpus...
2023/08/19 20:42:21 serving http on http://<IP_ADDRESS>:50000
2023/08/19 20:42:21 serving rpc on tcp://[::]:42113
2023/08/19 20:42:21 booting test machines...
2023/08/19 20:42:21 wait for the connection from test machine...
2023/08/19 20:43:52 boot completed
2023/08/19 20:43:52 failed to associate adb device 23R0123621000486 with console: no unassociated console devices left
2023/08/19 20:43:52 falling back to 'adb shell dmesg -w'
2023/08/19 20:43:52 note: some bugs may be detected as 'lost connection to test machine' with no kernel output
2023/08/19 20:43:52 associating adb device 23R0123621000486 with console adb
2023/08/19 20:43:52 device 23R0123621000486: battery level 77%, OK
2023/08/19 20:44:02 boot completed
2023/08/19 20:44:02 failed to associate adb device 23R0123621000523 with console: no unassociated console devices left
2023/08/19 20:44:02 falling back to 'adb shell dmesg -w'
2023/08/19 20:44:02 note: some bugs may be detected as 'lost connection to test machine' with no kernel output
2023/08/19 20:44:02 associating adb device 23R0123621000523 with console adb
2023/08/19 20:44:03 device 23R0123621000523: battery level 92%, OK

I found that the reason for this issue is that I added a large description file with a size of 64M.

crash types | 1 (60/min)
-- | --
crashes | 6 (360/min)

What was that single crash?

crash types | 1 (60/min)
-- | --
crashes | 6 (360/min)

What was that single crash?

lost connection to test machine

I will try to avoid using overly large files as description files, and I will close this issue first.


k8s 1.29 support for Harvester-csi-driver

Add k8s 1.29 support for Harvester-csi-driver

Hi @Sahota1225, v1.29 support is already done on the PR https://github.com/rancher/charts/pull/3301
Thanks!

Verified fixed on Rancher v2.9.0-alpha5 with Harvester v1.3.1 for K8s v1.29.5.
Close this issue.
Result
$\color{green}{\textsf{PASS}}$   Can provision v1.29.5 RKE2 cluster well $~~$

$\color{green}{\textsf{PASS}}$   default csi driver version is 0.1.1700 $~~$

$\color{green}{\textsf{PASS}}$  Check the default storage class set to `Harvester` $~~$

$\color{green}{\textsf{PASS}}$  Can create nginx application pvc correctly $~~$

$\color{green}{\textsf{PASS}}$  Can create nginx application pv $~~$

$\color{green}{\textsf{PASS}}$  nginx pvc created one Harvester $~~$

Test Information

Test Environment: Single nodes harvester on local kvm machine
Harvester version: v1.3.1
Rancher version: v2.9.0-alpha5
K8s version: v1.29.5

Verify Steps
Necessary checks for cloud provider and csi driver

Import Harvester v1.3.1 to Rancher v2.9.0-alpha5
Provision the v1.29.5 RKE2 guest cluster from Rancher
Check the RKE2 cluster can provisioned and running well
Access the RKE2 clsuter
Check the bundled Harvester cloud provider version in the applications
Check the bundled Harvester csi driver version in the applications
Create a nginx deployment and set Harvester storage type pvc
Check the pvc and pv can created well
Access Harvester volumes page
Check the corresponding volume also created


use discriminating union for query result type

This PR adds back discriminated union types, I don't know where they create overhead and why they were removed, but I would argue that they are one of the few things that bring real benefits when using typescript.
https://github.com/tannerlinsley/react-query/discussions/1102#discussioncomment-85980
https://github.com/tannerlinsley/react-query/discussions/922#discussioncomment-56912

Hi @MrLoh! There are a couple of reasons why they have been removed:

It introduces the need for casting because QueryResult is not a concrete type anymore. When casting we loose some type safety.
It introduces a lot of types (also the mutation types would need to be added).
Discriminated unions do not work when destructuring.
Is the example below not sufficient?

const { data, error } = useQuery('posts')

if (error) {
  return
Error: {error}

}

if (!data) {
  return
Loading...

}

return
Data: {data}

@boschni well it's just unfortunate to have the exposed types be subpar because of internal use of those types also casting does still provide some type safety, it will error if it is not castable to some degree.
As to the suggested approach, this library just has the problem of providing 3 different ways to check on the status (status enum, boolean flags, and checking on the actual data). The docs suggest using the flags or status, but this is incompatible with typescript. If the way to use it is to just check on the data, than the flags and status should be removed. If this library wants to expose the status and the flags and wants to be typescript first, than it should also support using those with typescript without needing to do a non null assertion. The exposed types should not be worse because they are exported from the code. The extra 60 lines of type code shouldn't be a hindrance.

If you think that checking on data and error is the right way of using it, then just deprecate the other fields and update the docs. As a consumer of this library I just don't want to think about this and the fact that the examples from the docs are not typescript compatible is confusing.

I think you are addressing a valid point about the many ways results can be handled. In some examples the status property is used, in some examples the bools, and on the overview page it even uses a mixture of value checking and bool checking. I can imagine this could confuse people and possibly also lead to inconsistent codebases. Personally I think we should pick one direction and preferably the "safest" one. For the discussion about which one is safest I'll consider the status and bool methods equal. This way we can boil it down to "status" checking and "value" checking:
Status checking:
if (result.isSuccess) {
  return
{result.data.name}

}

Value checking:
if (data) {
  return
{data.name}

}

When checking for the status, it could be that data is actually undefined during runtime, which would result in a crash. This would not happen when checking for the value, but if not handled properly we could end up in a different UI state. If I look other libraries, most seem to prefer value checking, but this does not mean it is the best way. Would be great to get some opinions on this! @tannerlinsley

Status checking is true to the state machine internally. The data, error and other properties are more like state meta, not state definitions and should never really be relied on for exhaustive state checking. Technically, a successful query could have undefined data, and an unsuccessful query could throw undefined. At the end of the day, this would depend on your own types and generics.

Technically, a successful query could have undefined data

I think this is a very good point, and why data checking is sufficient imo. In the above example, we would show a loading spinner even though the query already completed, just because it yielded no data.
The given example also only works if you check the fields in that order. Switch the data and the error check and you will wind up with a loading spinner even if you have an error...

Discriminated unions do not work when destructuring.

true, but I don't think we should optimize for that. People can still destruct if they want to, especially if you are a javascript user. Once you have more than one useQuery usage in a component, destructuring becomes suboptimal anyways:
const { data: posts, status: postsStatus } = useQuery('posts')
const { data: users, status: usersStatus } = useQuery('users')

I would much rather keep the context of where things come from and not destruct:
const posts = useQuery('posts')
const users = useQuery('users')

posts.data / posts.status
users.data / users.status

This is personal preference, for sure, but I think typescript users are used to not destruct if there is a discriminated union involved, because it doesn't narrow the type if you do :)

The given example also only works if you check the fields in that order. Switch the data and the error check and you will wind up with a loading spinner even if you have an error...

This is true, but I think the order in which the fields are checked is also unique to every situation. For example, in some situations you might favor data above error. For example: when some data has already been fetched, but a background refetch failed, we might still want to show the data:
const { data, error } = useQuery('posts')

if (data) {
  return
Data: {data}

}

if (error) {
  return
Error: {error}

}

return
Loading...

Or maybe a component is configured to not refetch automatically and every error is important:
const { data, error } = useQuery('posts')

if (error) {
  return
Error: {error}

}

if (data) {
  return
Data: {data}

}

return
Loading...

Or if you want to be runtime resilient:
const { data, error, isLoading } = useQuery('posts')

if (data) {
  return
Data: {data}

}

if (error) {
  return
Error: {error}

}

if (isLoading) {
  return
Loading...

}

return
Something is wrong here...

Just to be clear, I don't have a strong opinion on status vs value checking. But I think it's an interesting discussion to have.

I also think it's an interesting discussion. As a typescript user, I do tend to trust the types, even to the level that I am willing to do exhaustive matching on discriminated unions:
const posts = useQuery('posts')

switch (posts.type) {
    case 'loading': return
loading...

    case 'error': return
Error: {error}

    case 'success': return
Data: {data}

    case 'idle': return
idle...

}

no default case needed if I match on all the possible cases, and I will even get a typescript error if react-query adds another state to the enum.
Further, all your examples are still possible even if status is a discriminated union, and people will still check on whichever fields they want. Since there is really no preferred way of doing it, maybe we should point out the different possibilities in the docs or explain why examples are using different checks, or, if we want, streamline the examples (but then we would need to decide on a "best practice", which is hard). So I'm more concerned with the internal implications this approach has - the type cast. Would it not be possible without it?
Maybe a bit off-topic, but why is isFetching (and others) not part of the QueryStatus ? If I want to show a background loading spinner, I usually do: posts.isFetching && !posts.isLoading because for isLoading, I want to show a big spinner where the data would be, and I would want to avoid two spinners ...

Although all variations are possible, it would be interesting to see if we can pinpoint the advantages and disadvantages to each approach and maybe come to a preferred variation. Given the above examples, what would be the advantages of checking the state machine status above checking the data itself?
As to your second question, we could introduce a status like refetching, but it would break current apps because most users currently only show data on the success status, which would then need to be changed to 'success' || 'refetching'.

A lot of this goes back to state machine design too. The state tree is modeled something like this:
{
{
  [isIdle || status === 'idle'],
  [isLoading || status === 'loading'],
  [isError || status === 'error']: {
    error, // the error
    data, // latest known successful data
    isFetching, // background fetching
    isPreviousData,
    failureCount,
  },
  [isSuccess || status === 'success']: {
    data, // the data
    isFetching // background fetching
    isPreviousData
  }
}

The query can only be in one of those root states at once, and each root state determines what "meta" is available to the state. This list isn't exhaustive, but it illustrates that if only the met is used to determine state, then you'll immediately run into impossible combinations of meta. This is a pretty clear indicator to me that the status and safely derived booleans are the safest and easiest way of reliably detecting a query state. I have never and will never recommend to anyone to use the meta to exhaustively render a query's state. That said, there is nothing stopping people from doing it, this is Javascript at runtime after all.
My suggestion:

Align docs and examples (if they aren't already) to use and suggest at least using the status/booleans to detect query state
Where possible, prefer booleans in public documentation.

They are more terse
Easy to read/reason about
As long as they are derived from the status enum (which they are), they are just as safe as using status

Allow state machine purists to still use status
If discriminated unions come back, make sure they allow for all 3 styles (bool, status, meta) and document the safety of the first two and the caveats of the meta approach.

This PR does also support boolean flags as discriminators. If status is the preferred way and this library wants to properly support typescript than discriminating unions are not optional IMO. Unless you think that the recommended usage pattern should be to use non null assertions in typescript.

Let me otherwise list the disadvantages I see with status checking:

More prone to runtime errors because the actual data and error properties might be undefined although the status indicates they should not be.
Status checking favors status above data. Which means that if a background fetch fails, an error screen will suddenly appear instead of still showing the previous data.
In some statuses the data and error properties are optional, which means additional value checking is needed.

Would be great to get some counter arguments on these :)
If we still decide to favor status checking, then I agree we should definitely provide discriminated unions.

I thought the discussion was more about status booleans vs the status field 😅.
Ad 1: Unless there is an error in the internal state machine, I don’t see how this can happen. If we can avoid casting and use the discriminated union internally, the types have to match.
Ad 2: this is a really interesting point I never really thought about. I don’t see how this would be solvable with status checks unless we add more statuses (like backgroundError) which sounds suboptimal. That being said, most patterns I know do early returns for if (isLoading) or if (error), so unless you really check the data first, you‘ll have the same result.
Ad 3: which status would have an optional error? I assume idle can have optional data if the query was prefetched, and error can have optional data from the last successful fetch.

Thanks for the feedback @TkDodo, let's try to wrap up the discussion.

This is an edge case, it assumes something went wrong within the stack (client/transport/server) causing the data not to be what we expected.
This is something that will happen more often and I think we should mention it in the docs. Then users are aware of the pitfall and we can create an example on how to deal with it as automatic background refreshing is enabled by default.
The loading state can have an error and the error state can have data. In these cases you would need to fallback to value checking.

Think most points have been made by now. Maybe just do a vote and then pick a direction?

The loading state can have an error and the error state can have data

if that is true, than the PR is definitely wrong, as it states that loading never has data or error, see here
also, I think we should get rid of the typecast here and build the currentResult depending on the disjoint union type.
if we ensure correctness, I am still in favour of discriminated unions. I would also be happy to create a typescript example that leverages them for the docs once we have them :)

Yeah the types would need to be updated to reflect the actual implementation.
So what should be the recommended pattern in the docs and examples?
Option 1
function Post {
  const result = useQuery('post')

  if (result.isLoading) {
    return
Loading...

  }

  if (result.isSuccess || (result.isError && result.data)) {
    return
Title: {result.data.title}

  }

  if (result.isError) {
    return
Error: {result.error}

  }

  return null
}

Option 2
function Post {
  const result = useQuery('post')

  if (result.status === 'loading') {
    return
Loading...

  }

  if (result.status === 'success' || (result.status === 'error' && result.data)) {
    return
Title: {result.data.title}

  }

  if (result.status === 'error') {
    return
Error: {result.error}

  }

  return null
}

Option 3
function Post {
  const { data, error } = useQuery('post')

  if (data) {
    return
Title: {data.title}

  }

  if (error) {
    return
Error: {error}

  }

  return
Loading...

}

Yeah the types would need to be updated to reflect the actual implementation.
So what should be the recommended pattern in the docs and examples?
...

Coming in from the sidelines here but what about representing the different statuses explicitly, something like:
| 'error'
| 'errorWithPreviousData' -> // would have `result.data` and `result.error`
| 'loading'
| 'success'`

Would perhaps leave less room for confusion! 🙂

@boschni according to @tannerlinsley post here, we should prefer the boolean in examples / documentation when possible.
I would maybe add a TypeScript example, because we have none, where we could use the status field if we have exhaustive matching to show off the capabilities of that.
So that would mean Option 1 to me, even though I think this is rather subjective:
  if (result.isSuccess || (result.isError && result.data)) {
    return
Title: {result.data.title}

  }

as it might hide errors of background refetches. Maybe you want to display them, maybe not. Is the error more important than showing stale data? Maybe, it it depends :)

@MrLoh are you going to implement the suggested changes? please see here: https://github.com/tannerlinsley/react-query/pull/1108#issuecomment-706527139
otherwise, I don't think this PR is gonna make it :)

Yes lets keep this discussion going :)
I definitely agree that it depends on the use case, but value checking does make it more explicit. Depending on what is more important, you either first check for data or first check for error.
The default stale time configuration in React Query is very aggressive so by default there will be a lot of (background) fetching going on. This increases the risk of errors and users might get confused when they suddenly see errors popping up. There might not even be an obvious way for them to resolve the error. That is why I think it is important to focus more on "data" being available, instead of focussing on the status of the last (background) fetch.

Sorry I've been silent. I ended up going with the value checking approach and I am using error boundaries for errors, which is working fine for now. Unless there is a full agreement on the architecture and my bandwidth is also limited for implementation. I will not be able to build a solution that doesn't need casting

I guess discriminated unions could work if we had more control on which things should be considered as errors. This can be done on the query level or on the observer level.
Some ideas:
Optional flag
An optional flag could be added to indicate a fetch is optional. If such fetch fails, the error won't be persisted in the query:
queryClient.fetchQuery(‘posts’, fetchPosts, { optional: true })
useQuery('posts', fetchPosts, { refetchOnWindowFocusOptional: true })

Ignore certain errors in observers
Another option would be to ignore certain errors in the observers. If a query contains an error and the error originated from a window focus refetch, ignore it:
useQuery('posts', fetchPosts, { ignoreOnWindowFocusErrors: true })

The upside of this approach is that each observer has the ability to determine for itself what should be considered an error, but the downside is that there is no way to indicate a fetch is optional when manually fetching with for example queryClient.fetchQuery.

What about the inverse of that
queryClient.fetchQuery(‘posts’, fetchPosts, { collectErrors: ['fetch', 'refocus'] })
useQuery('posts', fetchPosts, { collectErrors: ['fetch', 'refocus'] })

I don't think we should add more flags. There are already a lot of flags, and having many flags can easily result in difficult to track state. refetchOnWindowFocusOptional also sounds like the fetching is optional, not the error.
Thinking more about this, I'm beginning to like the idea of an additional state for errors that happen while we already have data, similar to the hard isLoading vs the soft isFetching:
isLoading     --> hard loading where we definitely have no data yet
isFetching    --> true every time we fetch data, including when isLoading
isError       --> hard error state where we definitely want to display the error because we have nothing else (no data yet)
is???Error??  --> true every time we have an error, including when isError

it would be breaking unless we keep isError for the state where we always have an error (along the lines of isLoading) and introduce a new state for the "hard error".
I'm aware that isFetching is just an extra boolean that is not part of the internal state machine, so I'm not sure if that would help us with exhaustive matching. But it would help the case where we display errors even though we have data if we check for flags first rather than data first

I guess the state would then look something like this?
data: 'data'
error: 'error'
isSuccess: true
isError: false

With this change React Query assumes that errors which happened during refetches are less relevant, but it does give users the possibility to act on them if needed. It doesn't allow users to differentiate between the different type of refetches though, but maybe this level of granularity is not needed?

With this change React Query assumes that errors which happened during refetches are less relevant, but it does give users the possibility to act on them if needed.

I think this is a valid assumption.

It doesn't allow users to differentiate between the different type of refetches though, but maybe this level of granularity is not needed?

Personally, I wouldn't need to know if a refetch happens because of window refocus or component mount or so ... maybe for debugging ...
So, regarding your example:
data: 'data'
error: 'error'
isSuccess: true
isError: false

This would show a "background fetch error" state, right? And the only difference to a hard error would be that the query is in isSuccess state rather than the isError state. And in v2, for a background error, we would have:
data: 'data'
error: 'error'
isSuccess: false
isError: true

This would prioritise showing data, even if it's stale, over an error, which I think is good. The question is what implications this might have:

what happens if you are using errorBoundaries?
"why is my query in success state even though I have an error"...

Correct! Error boundaries would not be triggered as the query is not in an error state and the isSuccess state should be explainable. The isSuccess state already is more of a “data is available” state as it is also used when there is placeholder data. @tannerlinsley what is your take on this?

I'm not sure what I'm supposed to be commenting on TBH. There are a lot of differing opinions here...

The problem we are trying to solve is how to deal with errors during refetches. Most libraries only fetch or refetch on explicit triggers. React Query however has the concept of staleness and window/reconnect refetches with aggressive defaults. Which means there will be a lot refetching going on without explicit triggers. This is fine in most cases because often we just want to show the most recent data, but because of the amount of refetches there is also a high chance that some of those refetches fail. And in my opinion, these optimistic refetches should not result in sudden error screens. These sudden errors could confuse users and they would probably not know what caused it or how to solve it.
There are a couple of ways to solve this:

Teach users to check for the status with additional checks on the existence of data.
Teach users to check for the existence of data first and errors second.
Add the ability to specify which refetches are "optional", meaning they do not result in errors if they fail.
Add the ability to specify which type of refetch errors should be ignored when rendering.
Always ignore refetch errors and keep the query in success state if a refetch fails.
Some combination of the above?

The outcome of this will also determine if discriminated unions should be added or not.

has this been modeled out as a proper state machine?
https://xstate.js.org/viz/

Modeling as a "proper" state machine wouldn't really improve the situation. You would still have to choose what you want your unique states to be and it would still result in the same questions here.
What I am hearing in this discussion is that we are trying to achieve discriminated unions without hindering the flexibility to choose which root states are most important to our applications. Not every developer will agree on what those states are, and they really shouldn't, since it depends on the situation of each individual query, not an entire library.
The idea has been thrown around to actually change the state machine (yes, it's a state machine, just not an xstate machine) to include many more top-level root states that represent all of the permutations of fetching, data, and error. That's a lot of permutations as root states compared to what we have right now; 4 possible root states (loading, success, error, idle)
I originally modeled the documentation and api to account for the pattern that I saw the most:

Is the query disabled/waiting for other dependencies? isIdle
Are we "hard" loading without data? isLoading
Do we have an error? isError

This includes refetches, which I think is still correct for most users
Errors do not overwrite the last successful data, so users who want to opt in to continue displaying the old data in their error template can still do so, but the error is there to signify that the query is stale/potentially out of data and new data failed to be fetched. That's pretty important I'd say.
We could potentially be fetching in this state, so isFetching

We must have the data and all is well. isSuccess

We could potentially be fetching in this state, so isFetching

If we were to enable discriminated unions, these are the states that would deem as both the majority use-case and also what we should continue to teach in the documentation.
Any sub states that don't fit into the majority use-case can be derived with casting or other additional checks, right?

I don't think the current defaults and recommendations are suited for most users. Let me give some examples:

Say we use a hook to fetch data which is needed to show a page. The page renders fine and the user briefly switches tabs. The user comes back and starts reading, in the background a refetch is started and after a few seconds suddenly the entire page crashes. The user would have no clue about what happened or how to resolve it.
Within that same page there is a collapsed element which the user can click to display some additional information. This element is using the same hook. The user clicks it, the information is shown, but it also triggers a refetch in the background. After a few seconds the refetch fails and suddenly the entire page crashes. The user would again have no clue about what happened.

These are just a few examples how applications would work by default when using React Query. The default stale time of 0 together with showing every background refetch error provides a sub-optimal user experience and it's an issue which is easily overlooked. Most other libraries don't have to deal with this as they do not automatically refetch that often. I like that RQ is trying to always display the most recent information, but I do think the default UX can be improved here.

Okay that use case makes way more sense and is exactly what I was liking for in this discussion. So what I’m hearing is that there are really three base states. One idle, one loading and one settled. In the settled state, we could simultaneously have data, or an error or be fetching (along with a handful of other optimal state context values that aren’t super important here)
isIdle
isLoading
isSettled(
  error
  data
  isFetching
  ...others
)
Since data and error can happen simultaneously and also independent of each other, I don’t think they should be their own root states. This new format would be easy to template and also force you to handle the case where you want to display both the last known data and any potential errors. Obviously nothing is stopping users from doing this today, but the names just don’t make sense ;) Also, nothing is stopping you from keeping the current (flawed UX) flow either if you want to check in that order. So I think together with these base states we would need to come up with a new standard of teaching. Maybe as simple as this?
isIdle
isLoading
isSettled(
  error(always show available error)
  data(always show available data)
  isFetching
  ...others
)
Not sure how this affects discriminated unions though. Regardless this could be a good change of api and UX education/standard.
Tanner Linsley
On Oct 29, 2020, 2:28 AM -0600, Niek Bosch<EMAIL_ADDRESS>wrote:

I don't think the current defaults and recommendations are suited for most users. Let me give some examples:

Say we use a hook to fetch data which is needed to show a page. The page renders fine and the user briefly switches tabs. The user comes back and starts reading, in the background a refetch is started and after a few seconds suddenly the entire page crashes. The user would have no clue about what happened or how to resolve it.
Within that same page there is a collapsed element which the user can click to display some additional information. This element is using the same hook. The user clicks it, the information is shown, but it also triggers a refetch in the background. After a few seconds the refetch fails and suddenly the entire page crashes. The user would again have no clue about what happened.

These are just a few examples how applications would work by default when using React Query. The default stale time of 0 together with showing every background refetch error provides a sub-optimal user experience and it's an issue which is easily overlooked. Most other libraries don't have to deal with this as they do not automatically refetch that often. I like that RQ is trying to always display the most recent information, but I do think the default UX can be improved here.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.

Updated my comment ☝

How would you want the state field to be then? Just these 3 (loading, idle, settled):
type Idle = {
  status: 'idle',
  isIdle: true,
  isLoading: false,
  isSettled: false, // new
  isFetching: false,
  error?: undefined,
  data?: undefined
}

type Loading = {
  status: 'loading',
  isIdle: false,
  isLoading: true,
  isSettled: false,
  isFetching: true,
  error?: undefined,
  data?: undefined
}

type Settled<TError, TData> = {
  status: 'settled', // new
  isIdle: false,
  isLoading: false,
  isSettled: true,
  isFetching: boolean,
  error?: TError,
  data?: TData
}

I think this would also work out well for discriminated unions, see this playground link

Is the query disabled/waiting for other dependencies? isIdle

I also just realised that if a query was once enabled, but is then being disabled, it will not go back to idle state. Which is fine, because we already have data, but it means the query will not refetch on window focus etc because it's "turned off" (on purpose). Is there any part of the return value that shows us this?

if (isSettled) {
return <>
{isLoading ?  : null}
{error ? error.message : null}
{data ? data.map(todo =>
{todo}
): null}
</>
}

Just for clarification, am I right that you wanted to check for isFetching here when rendering the Spinner rather than isLoading, because I don't think you can be loading when you are settled, right?
I also like about this that this proposal would treat data and error equally, so people are not going to make the possible "mistake" of early returning when checking for isSuccess / isError anymore, because they just don't exist. You are settled, and you can render data and or error as you wish, if you have it (there is no guarantee).

Oof 🤦♂ yes I meant isFetching there. I think there might be some kind of isFetched or something. But at the end of the day, the user could just reference the enabled state itself right?

But at the end of the day, the user could just reference the enabled state itself right?

Yes, you can just use the same condition that you passed to enabled 👍

I like the idea of onSettled in combination with value checking. Although I wonder how many applications would actually implement support for showing refetch spinners and errors. My guess is that in a lot of cases (apart from dashboards), developers will just try to fetch data and render it, without implementing additional UI for refetching.
They'll probably just go with the most straightforward implementation:
const { data, error, isLoading } = useQuery('post', getPost)

if (isLoading) {
  return
Loading...

}

if (error) {
  return
Error: {error}

}

return
Title: {data.title}

That is why it might also be useful to ignore refetch errors somehow. Like:
const { data, error, isLoading } = useQuery('post', getPost, {
  ignoreRefetchErrors: true // could be set as default?
})

if (isLoading) {
  return
Loading...

}

if (error) {
  return
Error: {error}

}

return
Title: {data.title}

Would this also eliminate onSuccess and onError callbacks? Mirror the checks in onSettled?

Refetch errors getting hidden by default doesn’t seem like a safe default to me. I think it would confuse a lot of people if and when errors do happen and things don’t sync up like they expect. I still think we should prescribe handling either both simultaneously or at least errors first depending on the UX needed. That said, I’m not opposed to exploring some kind of optional mechanism to do what you’re referring to. Seems like it should be another issue/discussion though.
Tanner Linsley
On Oct 30, 2020, 8:17 AM -0600, Kevin Sullivan<EMAIL_ADDRESS>wrote:

Would this also eliminate onSuccess and onError callbacks? Mirror the checks in onSettled?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.

I've been experimenting a bit with the discriminated unions and I think we can get this working for everybody by adding two additional flags. This would be backwards compatible, and allows for easy handling of different type of errors: playground example

Yeah that actually looks really good. I love the flexibility while still being very specific about the states.

Created a PR: https://github.com/tannerlinsley/react-query/pull/1247

Closed with #1247


Mention reproducing bugs and feature usage description in PR template

Adds the following two lines to the template to give hints as to what helps a PR get merged faster.
-> For fixes, description on how to reproduce the bug are appreciated and help your PR get merged faster
-> For features, description on how to use the feature is appreciated and will help your PR get merged faster

LGTM! 👍


Configure Jarvis for homepage

Add your
Specific
Features or fixes

Resolves: MWPW-NUMBER
Test URLs:

Before: https://main--homepage--adobecom.hlx.page/homepage/index-loggedout?martech=off
After: https://--homepage--adobecom.hlx.page/homepage/index-loggedout?martech=off

@narcis-radu can i have the "after" branch?


Desktop notifications as contest reminders ?

I would like to be assigned on this

Hey @vedantrathore feel free to send a PR or comment here in case of any further clarifications :)

Hey! @raj454raj I was having some trouble getting the client ID for the google calendar API, could you please elaborate on that

In your models/0firstrun.py change calender_token to calendar_token and restart the server.

Hey! I will work on this issue later. So if anyone wants to work on this issue, feel free.


fix path issues in update_published_models.ps1

Description
This PR addresses two path concatenation issues. One is a typo and the other is a byproduct of switching to Join-Path
Architecture
Bug Fixes
Conversational Experience
Maintenance
Language Understanding
Testing Steps

Run update_published_models.ps1 with all supported parameter sets, on Windows and Mac, using only PowerShell 6+
Script should complete without errors

Checklist
N/A

Linking to #859

Hi @ctstone, I just tried this branch on Windows with PS 6 x64 Core and it works for me, thanks!


manual: update schematic diagram in contributing -> architecture section

<EMAIL_ADDRESS>libdeno is replaced with rusty_v8. This needs to be reflected in the diagram.

let's track in https://github.com/denoland/manual/issues/235


Adding bootstrapping for MSVSMON

Hi @alanch-ms, I'm your friendly neighborhood Microsoft Pull Request Bot (You can call me MSBOT). Thanks for your contribution!

It looks like you're a Microsoft contributor (Alan Chan (IOT)). If you're full-time, we DON'T require a Contribution License Agreement. If you are a vendor, please DO sign the electronic Contribution License Agreement. It will take 2 minutes and there's no faxing! https://cla.microsoft.com.

TTYL, MSBOT;

Thanks for the feedback.  I should have address all the feedback in the 2nd commit.  Should I merge the two commits together?

No, separate commits are fine.

Address more code review feedback.  Thanks!

:+1: (but wait until Steve okays it, too)


Error in iOS release build: The Swift pod react-native-esp-idf-provisioning depends upon glog

when building iOS in release mode (to submit to appstore), we got the following error
The Swift pod `react-native-esp-idf-provisioning` depends upon `glog`, which does not define modules. To opt into those targets generating module maps (which is necessary to import them from Swift when building as static libraries), you may set `use_modular_headers!` globally in your Podfile, or specify `:modular_headers => true` for particular dependencies.

Are we missing anything causing the error?

I found the cause: the error happens on xcode 14.2. Using xcode 14.3 fixes it


Chat -Green line displays after send attachment/messages offline and come back online.

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Action Performed:

Launch the app
Log in with any account
Turn off your internet connection
Create a new room
Tap on plus button
Select Add Attachment
Send Attachment
Enable the internet connection

Expected Result:
There is no green line displayed after come back online
Actual Result:
New line displays after send attachment offline and come back online.
Workaround:
Unknown
Platform:

Where is this issue occurring?

Web
iOS
Android
Desktop App
Mobile Web

Version Number: <IP_ADDRESS>
Reproducible in staging?: Yes
Reproducible in production?: No, can not create room while offline
Email or phone of affected tester (no customers): any expensifail account
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos: Any additional supporting documentation
https://user-images.githubusercontent.com/93399543/191973668-4c1fd8aa-ec33-4dac-beae-84b95db77c75.mp4
Expensify/Expensify Issue URL:
Issue reported by: Applause - Internal Team
Slack conversation:
View all open jobs on GitHub

:wave: Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open StagingDeployCash deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:

Identify the pull request that introduced this issue and revert it.
Find someone who can quickly fix the issue.
Fix the issue yourself.

is this only on Android, or does this happen in other platforms?
It seems weird to be platform specific

@kbecciv ? (sorry forgot to tag you in the previous comment)

Also please correct the title, it's a bit confusing as New line means a empty line in programing language, aka return/enter, did you mean Green Line?
thanks :)

@marcaaron I think this change might have been the cause of it? As it's a relative new change, and I think we just added the QA testrail steps yesterday.
This said, I'm not 100% this should be a deploy blocker. Offline first stuff are a new feature, so it makes sense it's not in prod yet. Also this seems to be an edge case.
@kbecciv is this for attachements only, or would it be an issues with messages as wel:?

maybe not that change, I think it might be on componentDidUpdate

@sketchydroide Let me try with messages as well.

The same issue with message
https://user-images.githubusercontent.com/93399543/191980433-67e86fb6-3ed9-457d-af6e-048801b0f470.mp4

Ok, after some investigation I was able to reproduce the bug in Prod.
Here are the reproduction steps:

Launch the app
Log in with any account
Create a new room
Turn off your internet connection
write a new comment
Enable the internet connection

after a while the green line will appear.
I Don't think this is related to the Add Room Offline functionality. I'm inclined to remove the blocker, as I was able to reproduce something that I think it's the actual issue.

aother similar GH opened here.

idk I think it can still be a Daily and added to the Whats App Quality milestone. No reason why someone can't look into this.

I'm gonna take this off the Unread Indicators milestone and move it to Whats App quality. Looks like tester is using an optimistic report and I have no idea whether unread indicators were taken into consideration for the optimistic report stuff.

I can't replicate this on dev, none of the steps previously described, will try again on staging

I'm having some trouble checking on this today, I think it's because I'm working from a coworking space today, will chack again on monday from home

will try this again today

was busy with other things, will take a look today

demoting this to weekly, as I don't think this is happening anymore.
@kbecciv can your team take a look to see if it still happens?

@kbecciv bump :)

@sketchydroide Checking, will update you shortly

@sketchydroide Issue is reproduced with latest build 1.2.16-4
https://user-images.githubusercontent.com/93399543/196197000-be125e5a-3bc3-416e-a42f-7faa4d4b74d4.MP4

Thanks, I think it might be part of the process the login part.
let me try again.

still haven't had the time to check, busy with the deployment, will check again

Checking again this week. once I fix vagrant and php

Vagrant fixed, I can look at this again

I'm removing myself, I haven't had the time to look at this, and as daily I should be focusing on it and have not been able to

Just to confirm, this is what you're referring to @kbecciv ?

if so, I believe that's intended: since it's a new message you're sending, it makes sense to have a green line. I'm on v 1.2.23-0 and am seeing the same behaviour.

Yes, correct. I am referring to this green line above the attachment.

Thanks for confirming - so again, my understanding is that this is intended behaviour, as when you're offline and a message is sent, you shouldn't see them until you get back online, which means they'd show up as "New".
Closing this one out, but please re-open if you feel like this is bug.


single sign on (SSO) / LDAP

Clear and concise description of the problem
it would be great if, as an organization, one could log users in to their Woodpecker CI instance using their existing tools for this.
Suggested solution
this could including using LDAP or single sign on (SSO), think OIDC, SAML, OAuth2.
Alternative
No response
Additional context
has anything been done in this direction?
Validations

[X] Read the Contributing Guidelines.
[X] Read the docs.
[X] Check that there isn't already an issue that request the same feature to avoid creating a duplicate.

As Woodpecker needs a forge (Github, Gitlab, ...) anyways it is using OAuth2 to authenticate against those forges. Most forges do support the methods you asked for, so this should already be possible.

hm. allegedly OAuth is vulnerable to an attack that OIDC resolves.
perhaps that might make OIDC relevant as an OAuth alternative for Woodpecker as well?

I don't see how the login to Woodpecker is affected by this.
For authentication steps with OIDC we started a discussion in https://github.com/woodpecker-ci/woodpecker/issues/1126


Plans for async?

SQLite has asynchronous capabilities, so I was wondering if there are any plans on implementing
async to this crate.
I'd be willing to try and give it a go when I get to have free time.

So, you don't want to use that. The sqlite3async code has long been abandoned.
Actually, I'm surprised there's no notice on that file, since if you take a look at ext/async (the final resting place of the asyncvfs), you can see this notice at the start of the README (which otherwise contains essentially the same text as your link, so you can be sure it's referring to the same thing):

NOTE (2012-11-29):
The functionality implemented by this extension has been superseded
by WAL-mode.  This module is no longer supported or maintained.  The
code is retained for historical reference only.

Anyway, not that it matters, but you're also a little confused about what this did back when it still was usable — it didn't make SQLite's APIs asynchronous, or add new APIs for async usage[^1]. It just let SQLite use asynchronous I/O under the hood.
So... even if you took the 9 year old abandonment notice as a challenge, and wanted to experiment with it, it wouldn't really change the situation for rusqlite's async story.
That said, it's a reasonable mistake to make, I thought the same thing when I came across it the first time.
[^1]: Well, beyond some stuff for use by custom VFSes which opt-in to async, I guess.

Anyway, I think I'm going to close this since I would be against taking a patch that added anything based on that code.
I still am interested in improving the async usage story though. In the meantime, using a spawn_blocking or a background thread are the most straightforward options, sadly.


Fixed basic_json::diff and basic_json::patch not compiling with custom string type (#4134)

Note that this has yet to be amalgamated (waiting for #4083).

Amalgamated.

coverage: 100.0%. remained the same when pulling f4b7b90a8d1757f694d6152b420b2640f20f9640 on tomalakgeretkal:custom-string-fix into fac07e22c5d7dd0423ccf31c02db5603d27e6556 on nlohmann:develop.

Please update from the develop branch as it has a working CI now.

Need anything else here? It's at the top of develop.

Looks amalgamated here :( check-amalgamate works for me!

You may be using a different version of astyle that produces different results.  The check is using 3.1.  We've seen that later versions produce different results.


Python is not installed as a framework

When Python is installed using brew on Mac, Matplotlib will complain about Python not being installed as a framework during the reporting installation.
(venv) ~/repos/chaostoolkit-documentation-code (master) $ chaos report --help
Usage: chaos report [OPTIONS]

  Warning: entry point could not be loaded. Contact its author for help.

  Traceback (most recent call last):
    File "/Users/pauljones/repos/chaostoolkit-documentation-code/venv/lib/python3.6/site-packages/click_plugins/core.py", line 37, in decorator
      group.add_command(entry_point.load())
    File "/Users/pauljones/repos/chaostoolkit-documentation-code/venv/lib/python3.6/site-packages/pkg_resources/__init__.py", line 2318, in load
      return self.resolve()
    File "/Users/pauljones/repos/chaostoolkit-documentation-code/venv/lib/python3.6/site-packages/pkg_resources/__init__.py", line 2324, in resolve
      module = __import__(self.module_name, fromlist=['__name__'], level=0)
    File "/Users/pauljones/repos/chaostoolkit-documentation-code/venv/lib/python3.6/site-packages/chaosreport/__init__.py", line 20, in <module>
      import matplotlib.pyplot as plt
    File "/Users/pauljones/repos/chaostoolkit-documentation-code/venv/lib/python3.6/site-packages/matplotlib/pyplot.py", line 115, in <module>
      _backend_mod, new_figure_manager, draw_if_interactive, _show = pylab_setup()
    File "/Users/pauljones/repos/chaostoolkit-documentation-code/venv/lib/python3.6/site-packages/matplotlib/backends/__init__.py", line 62, in pylab_setup
      [backend_name], 0)
    File "/Users/pauljones/repos/chaostoolkit-documentation-code/venv/lib/python3.6/site-packages/matplotlib/backends/backend_macosx.py", line 17, in <module>
      from matplotlib.backends import _macosx
  RuntimeError: Python is not installed as a framework. The Mac OS X backend will not be able to function correctly if Python is not installed as a framework. See the Python documentation for more information on installing Python as a framework on Mac OS X. Please either
reinstall Python as a framework, or try one of the other backends. If you are using (Ana)Conda please install python.app and replace the use of 'python' with 'pythonw'. See 'Working with Matplotlib on OSX' in the Matplotlib FAQ for more information.

Options:
  --help  Show this message and exit.

https://stackoverflow.com/questions/21784641/installation-issue-with-matplotlib-python
$ echo "backend: TkAgg" >> ~/.matplotlib/matplotlibrc

Sounds like we might be able to close this particular issue with some additional notes in the README? Or a separate FAQ document perhaps?

The readme would be the right place probably indeed :)

Closing following #13


Error running eject: TypeError: Cannot read property 'preset' of undefined

Hi,
I'm trying to eject the app like a regular React Native project, and getting this error.

npm ls react-native-scripts<EMAIL_ADDRESS>npm ls react-native<EMAIL_ADDRESS>npm ls expo<EMAIL_ADDRESS>node -v: v. 9.4.0
npm -v: 5.6.0
yarn --version: 1.3.2
watchman version: 4.9.0

Operating system: macOS High Sierra 10.13.3
Phone/emulator/simulator & version: iPhone X emulator

I have the same issue

seems to be related to https://github.com/react-community/create-react-native-app/commit/fcc9629b16265cd04a84c96516f13932c79aa793#diff-71cd56714c1de5f358b099bac7336916R200
you can add a jest key back to your package.json with just "jest": {} and run it again to fix the problem.
a PR to fix this would be appreciated


Added networks properties for postgres and nfs

Added properties to postgres and nfs so colocated jobs can find their own ip. eg consul

Hey @longnguyen11288
This seems like a simple, reasonable change.  However, those values are not accessible without a corresponding update to the spec files for those jobs.
Thanks,
@zrob & @zaksoup

Do you want me to add this to postgres even though they aren't using it? I'm adding it as a standard so colocated jobs can use them. I use it in my consul-cf integration.


Add Apache Pulsar

Motivation for this change
This PR adds support for the Apache Pulsar message bus in NixOS.  Running Pulsar involves 3 components - the Zookeeper, the Bookkeeper Bookie and the Pulsar Broker.  All component are distributed by Apache Pulsar together.
This PR:

Adding the pulsar package (containing the official distribution of zookeeper, bookie and broker)
Adds the services.pulsar module, made up of a zookeeper, bookie and broker systemd service
Adds 2 nixos tests for common configurations:

A single-node setup, where zookeeper, bookie and broker run on the same machine
A more complex multi-node setup, with two bookkeepers (for data integrity) and all services on components machines

Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[x] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[x] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[x] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

will close since you are picking up the task https://github.com/NixOS/nixpkgs/pull/65324

Is there a reason for this PR to be staled? It seems ready. Other than fixing the merge conflicts, and bumping the version, is there anything to be done?
It'd be nice to have Pulsar on nixpkgs. I see more people are interested in that, there were other PRs to add Pulsar:
https://github.com/NixOS/nixpkgs/pull/92393
https://github.com/NixOS/nixpkgs/pull/65324
@samdroid-apps @lucperkins @aahmed-se Are you still interested in getting this merged? If not, I could try to finish the work and get it merged.

Please update and finish it , overall it looks fine to me.

Closing as abandoned


Missing export

I was trying to import the normalize pack on a SvelteKit project which uses Vite from my index.pcss as demonstrated on the guide:
@import "open-props/src/extra/normalize.css";

and got the error below:
[vite] Internal server error: Missing "./src/extra/normalize.css" export in "open-props" package

A quick search yields a previously reported issue: https://github.com/vitejs/vite/issues/1505
I can import the normalize pack using:
@import 'open-props/normalize';

... but that works only because normalize is defined in the package's exports field. To import other packs individually, one needs to use relative import syntax @import '../../node_modules/open-props/....

Ty for reporting! I can resolve this quickly

it's now @import "open-props/postcss/normalize"; 🙁


File Icon Themes require baked-in padding

Does this issue occur when all extensions are disabled?: Yes

VS Code Version: 1.88.0
OS Version: OS: Ubuntu 22.04.4 LTS

Steps to Reproduce:

Use a font that does not bake padding into the glyphs to create a file icon theme:

{
  "fonts": [
    {
      "id": "fontawesome",
      "src": [
        {
          "format": "woff2",
          "path": "./fontawesome-webfont.woff2"
        }
      ]
    }
  ],
  "iconDefinitions": {
    "gavel-file": {
      "fontId": "fontawesome",
      "fontCharacter": "\\F0E3"
    }
  },
  "fileExtensions": {
    "gavel": "gavel-file"
  }
}

The icons are slammed into the twisty in the Explorer view and offset to the left in the editor tab and breadcrumbs:

Compare this with the default icons which come with baked-in padding:

It should not be necessary to bake the padding into the icon glyphs. This is not an issue when the same icon is used from a custom codicon in a TreeView by adding an item with iconPath: new ThemeIcon("gavel-file"):
"icons": {
  "gavel-file": {
    "description": "Gavel File Icon",
    "default": {
      "fontPath": "./fontawesome-webfont.woff2",
      "fontCharacter": "\\F0E3"
    }
  }
}

The logic used here produces a much more consistent icon so perhaps it should be reused in other parts of the product like the Explorer view and the editor tab and breadcrumbs:

Sorry, we're not going to make any changes in the icon sizing / positions. This is how it grew historically.

Of course everyone is welcome to investigate here and come up with a backward compatible solution. The solution needs to be well tested (all platforms, existing icon and product theme and extensions that contribute icons and language icons).
Also, I'd need some commitment to help managing issues that get reported in that area, to figure out if the change has caused any regressions.


Tableau extension

See if we can build a tableau extension for clustergrammer2
See

https://github.com/tableau/extensions-api/

https://www.tableau.com/developer/extensions#reveal

Closing this issue since it is a low priority and long term issue.


Update ios native agent to v2.3.1

Please ignore the commit message error it is because of co-authored commit

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Content is overlapping

"Sign Up" button is covering text. Can I work on rectifying this?

"Sign Up" button is covering text. Can I work on rectifying this?

This issue already raised in #88 and assigned to otherone...... Please close it....

Repeated Issue


日本語issue

What is the feature you are proposing?
hoge
What version of Hono are you using?
4.6.1
What steps can reproduce the bug?
print("hoge")

hono/src/jsx/streaming.ts

https://github.com/hamayanhamayan/hono/blob/dfbd717263ab8ecd7bf495fbd2c32d8c79854284/src/jsx/streaming.ts#L123-L130

返事


Do not search root filesystem for changelogs in CLI

Environment
Liquibase Version: 4.0
Liquibase Integration & Version: CLI
Liquibase Extension(s) & Version:
Database Vendor & Version: n/a
Operating System Type & Version: n/a
Description
In Liquibase, file paths are ALWAYS relative to one of the configured ResourceAccessor roots. All the integrations (like the CLI) have a set of default locations that are checked in addition to what is listed in the "classpath" setting.
In 3.x, the CLI's defaults were:

Current working directory
Root of the fileystem

The root filesystem was added because people expect to be able to pass an absolute path to the changelog file and have liquibase find it, which means one of our root paths has to be the root filesystem.
However, including the root filesystem as a default hurts performance because doing an <includeAll path="/"/> to pick up all the files in your current working directory also searches your entire filesystem. Even something like <includeAll="/src"/> can have surprising side effects when some users happen to have a /src dir in in their system.
Beyond the performance issue, allowing absolute paths opens users up to problems down the road because the absolute path is stored in the databasechangelog table for comparing in future updates.  If the directory is moved, liquibase is ran from a different machine against the same database, or the user wants to use other integrations, they get stuck because the paths are different and so they are seen as new changelog files.
To solve both the performance issue and to keep users doing the right thing, we are removing the root filesystem search out of 4.0.
If someone really does want to use absolute paths, or has been in the path and so needs to continue doing it, they can include "/" in their classpath setting.
Steps To Reproduce
Run liquibase --changeLogFile=/an/absolute/path/changelog.xml update
Actual Behavior
Executes changelog.
Expected/Desired Behavior
Should fail with a "cannot find changelog" error listing where we searched.
ERROR: The file <changelog name> not found in
  -<path1>
  -<path2>
  - <path N>
Specifying files by absolute path was removed in Liquibase 4.0. Please use a relative path, or add '/' to the classpath parameter.

To run the changelog, the user needs to run liquibase --classpath=/an/absolute/path --changeLogFile=changelog.xml update
Manual Test Requirements
Setup :: Put a changelog at the root of your filesystem. Deploy with an older version of Liquibase to get a row in the DBCL. Your update command should have the fully qualified path to the changelog in the --changeLogFile parameter.
Verify running update with the fully qualified path to the changelog fails with an error.
Verify error message matches expected verbiage given above.
Verify running update with classpath=path and changeLogFile=changelog.xml is successful.
Verify DBCL path is ????.
Verify running update with classpath=/ and changeLogFile=changelog.xml is successful.
Verify running update without a classpath and a changelog in the current directory is successful.
Verify rollbackOneChangeSet for the changeset deployed in setup is successful.
Verify rollbackOneChangeSet for a changeset deployed by the new Liquibase is successful.
Verify rollbackOneUpdate for a deploy from the new Liquibase is successful.

We have logic to normalize the paths coming from the databasechangelog table as well. I think stripping any c: prefixes would work just fine as well.

I added logic to the normalizePath method to strip out the drive letters that were causing problems. That seemed to solve the problem

Trying hard to figure out what exactly changed between version 3 and 4 that caused the filename for changelogs to change. Is this that change?
src/main/resources/database/db.changelog-master.xml
src/main/resources/database/changelogs
src/main/resources/database/changelogs/20180823-2054-attachments-table.xml

We pass database/db.changelog-master.xml to Liquibase and it goes from there.
In version 3.5 this setup would result in filename changelogs/20180823-2054-attachments-table.xml, whereas in version 4.9 this results in database/changelogs/20180823-2054-attachments-table.xml.
I suspect this is at the heart of it? Anything we could do to restore the previous behaviour?