implement Viterbi on segregation prob

Function to naively-convert [0-1] seg probs to [0, 1] (just 0 or 1) - we will just use max on seg probs obtained from the current iterative sum-product (or some other future) algorithm so this is a really simple function
Function to Viterbi-convert [0-1] seg probs to [0, 1] (just 0 or 1) - as the above one, this function will work on seg probs from the current iterative sum-product (or some other future) algorithm, but we need to do the Viterbi forward pass and then the “backward max” pass to call the most likely event (which could be completed by the above naive-max function!)”

@gregorgorjanc
One way to implement the Viterbi algorithm on seg probs is by setting the loci as time, different segregation statuses as states and with transmission function depending on the recombination rate. However, the problems with this implementation are:

it does not satisfy the assumption of HMM models that it does not only depend on the first previous state.
low recombination rate would typically lead to no recombination event predicted.

The other way to implement the algorithm is by first selecting a few recombination hotspots by using the recombination rates, then applying the algorithm with the recombination hotspots $k$ as the time, the estimated segregation status (pp, pm, mp, mm) to the right of $k$ as the states. Let the transmission be dependent on the estimated recombination rate. Since the recombination hotspots are selected based on the recombination rates, they would have higher recombination rates, enabling the predictions of recombination events around the hotspots. Since segregation status only depends on the last previous segregation status in the ideal case (the sites selected are separated by a long distance), this implementation can also solve the first problem above. The probability of observing $Y_k$ given the state $X_k$ can be calculated by a quantity measuring the difference between the predicted segregation status and the real segregation data. The possible difficulties of this implementation are:

incorrect estimated recombination rate would give inaccurate predicted recombination hotspots so a high accuracy of the estimation of the recombination rate is required
how to implement the method to select the hotspots via the recombination rate
how to implement the method to measure the difference between the predicted segregation status and the real segregation data

@XingerTang as you know, having good estimates of recombination rates, and hence hotspots, is hard so we can not start from something we don't generally have.
I suggest that we first just do naive-call and see how it looks like. I suspect that it should work well, but we will have some false positives (=switch errors). Do we need an alternative algorithm that would smooth out these short recombination blips (so that we get long stretches of haplotypes - we know there are only a few recombinations between a parent and a progeny!) and create clear cuts from one parent's haplotype to another?

@gregorgorjanc Uni is trying to implement the naive-call function for the AlphaPeel format data. I experimented on my side on the segregation data in my custom data format just to see the result quickly.
The algorithm is implemented in a very simple way that takes the segregation status with the highest probability and if it encounters multiple probabilities with the same highest value, it will take the first index (so it would choose [1, 0, 0, 0] for [0.25, 0.25, 0.25, 0.25]).
I performed the experiment on the segregation data generated by the multi-locus peeling and there are 2000000 loci being evaluated in total.
For the measurement of the performance, the sum of the absolute values of the differences between the predicted segregation data and the true segregation data is used.
On the whole data set, the absolute sum of differences is 1245326.
Excluding the first generation with full of [0.25, 0.25, 0.25, 0.25], the absolute sum of differences is 645326.

@gregorgorjanc For smoothing out short recombination blips, a common practice is using the windows but it is difficult to locate the exact position of the recombination event. I'm still working on the regression matrix that uses the segregation probabilities of the neighbouring locus to predict the recombination rate, if that works well, I expect it can smooth at least some short recombination blips.

As the generation increases, the performance of the naive calling algorithm is improved.

Gen n
absolute sum of difference

2
537088

3
42458

4
29474

5
36306

This is probably a result of the improved accuracies of the segregation probabilities estimated by the AlphaPeel for the later generations.

The loci with segregation statuses that were wrongly called often appeared as intervals. Such intervals (including those with a length of 1) have occurred $1562$ times across the loci from generation 2 to generation 5.
In this block, we only consider generation 2 to 5.
The occurrences of the intervals are distributed evenly across all the individuals of all the generations. In particular, they do not tend to be close to the loci where recombination events happen. The histogram below illustrates how the intervals are distributed among the loci, with the left side representing the loci of early generations and the right side representing the loci of later generations.

However, the length of the intervals changed for different generations, below is a scatter plot of the lengths of the intervals against the sequence of the intervals. The left side still represents the early generations and the right side represents the later generations.

@XingerTang  this is my codes for "Naive-Convert" and "Viterbi-convert".
Naive-Convert
def naive_convert(seg_prob_array):
    seg_array=np.zeros(seg_prob_array.shape)
    for i in range(0,seg_prob_array.shape[0]):
        for j in range(0,seg_prob_array.shape[1]):
            seg_array[i,j,np.argmax(seg_prob_array[i,j])]=1
    return seg_array

Viterbi-convert
# use the equal recombination rate to generate transmission Vecter for loci
# if have distance, we can imitate li-Stephen model's trasition fucntion and add distance
transmission=np.ones(seg_prob_array.shape[1])*(1636/(800*2000))
def Viterbi(pointSeg, transmission):

    # Segregation estimate state ordering: pp, pm, mp, mm
    nLoci = pointSeg.shape[0]
    seg = np.full(pointSeg.shape, 0.25, dtype=np.float32)
    seg_arg=np.full(pointSeg.shape, 0, dtype=np.int16)

    for i in range(nLoci):
        for j in range(4):
            seg[i,j] = pointSeg[i,j]

    tmp = np.full((4), 0, dtype=np.float32)
    new = np.full((4), 0, dtype=np.float32)
    new_arg= np.full((4), 0, dtype=np.int16)

    prev = np.full((4), 0.25, dtype=np.float32)

    for i in range(0, nLoci):
        # create the transition function
        e = transmission[i - 1]
        e2 = e**2
        e1e = e * (1 - e)
        e2i = (1.0 - e) ** 2
        transition=np.array([[e2i,e1e,e1e,e2],
                            [e1e,e2i,e2,e1e],
                            [e1e,e2,e2i,e1e,],
                            [e2,e1e,e1e,e2i],])
        # if there is first locus,regard [0.25,0.25,0.25,0.25] as the initial state
        if i!=0:
            for j in range(4):
                tmp[j] = prev[j] * pointSeg[i - 1,j]
        else:
            for j in range(4):
                tmp[j] = prev[j] * 0.25

        # normalize
        sum_j = 0
        for j in range(4):
            sum_j += tmp[j]
        if sum_j==0:
            sum_j=1
        for j in range(4):
            tmp[j] = tmp[j] / sum_j

        # !                  fm  fm  fm  fm
        # !segregationOrder: pp, pm, mp, mm
        # forward
        for j in range(4):
            new[j] = np.max(tmp*transition[j]*seg[i,j])
            new_arg[j] = np.argmax(tmp*transition[j]*seg[i,j])

        for j in range(4):
            seg_arg[i,j] = new_arg[j]
        prev = new

    # there are four ways we can track, use the most likely state for the final locus (results from the segregation probability )
    prev_index=np.argmax(pointSeg[-1])

    # back track
    track_rec=np.zeros(seg_arg.shape[0]-1,dtype=np.int16)
    a=np.zeros(seg_arg.shape[0],dtype=np.int16)
    for i in range(seg_arg.shape[0]-1,-1,-1):
        prev_index=seg_arg[i][prev_index]
        a[i]=prev_index

    # find the breakpoint
    for i in range(seg_arg.shape[0]-1):
        if a[i]!=a[i+1]:
            track_rec[i]=1
    return track_rec
# run every individuals
seg_a=np.zeros((1000,1999),dtype=np.int16)
for individual in range(seg_a.shape[0]):
    track_rec = Viterbi(seg_prob_array[individual],transmission)
    seg_a[individual]+=track_rec

@gregorgorjanc and @XingerTang , There is a good news and bad news.
The good one is that Naive-converted have better performance than I expected.
Basically, the results of Viterbi algorithm is equal to that of Naive-converted, but more running time.

Algorithm
Run time
Accurancy of recombination probability

Original
5.06s
0.9706

Naive-convert
1.53s+5.01s
0.9982

Viterbi-convert
53.48s
0.9981

The details for every generation:

Generation
Original
Naive-convert
Viterbi-convert
one of individuals

1
1.0
1.0
1.0

2
0.9280
0.9970
0.9969

3
0.9739
0.9978
0.9977

4
0.9777
0.9982
0.9980

5
0.9734
0.9982
0.9981

@gregorgorjanc and @XingerTang , There is a good news and bad news. The good one is that Naive-converted have better performance than I expected. Basically, the results of Viterbi algorithm is equal to that of Naive-converted, but more running time.
Algorithm	Run time	Accurancy of recombination probability
Original	5.06s	0.9706
Naive-convert	1.53s+5.01s	0.9982
Viterbi-convert	53.48s	0.9981
The details for every generation:
Generation	Original	Naive-convert	Viterbi-convert	one of individuals
1	1.0	1.0	1.0
2	0.9280	0.9970	0.9969
3	0.9739	0.9978	0.9977
4	0.9777	0.9982	0.9980
5	0.9734	0.9982	0.9981

@AprilYUZhang I'm wondering how you measure the recombination probability

@gregorgorjanc and @XingerTang , There is a good news and bad news. The good one is that Naive-converted have better performance than I expected. Basically, the results of Viterbi algorithm is equal to that of Naive-converted, but more running time.
Algorithm	Run time	Accurancy of recombination probability
Original	5.06s	0.9706
Naive-convert	1.53s+5.01s	0.9982
Viterbi-convert	53.48s	0.9981
The details for every generation:
Generation	Original	Naive-convert	Viterbi-convert	one of individuals
1	1.0	1.0	1.0
2	0.9280	0.9970	0.9969
3	0.9739	0.9978	0.9977
4	0.9777	0.9982	0.9980
5	0.9734	0.9982	0.9981

@AprilYUZhang I'm wondering how you measure the accuracy of the recombination probability

Just 1 - difference, maybe not very accurancy.
def cor2(a,b):
    cos_theta=0
    for i in range(0,a.shape[0]):
        for j in range(0,a.shape[1]):
            cos_theta += np.abs(a[i,j]-b[i,j])
    return 1-cos_theta/(a.shape[0]*a.shape[1])

@AprilYUZhang Could you measure the accuracy of the prediction of the segregation statuses for both methods?

@AprilYUZhang Could you measure the accuracy of the prediction of the segregation statuses for both methods?

Viterbi method just uses the Original's segregation probabolities, so I skiped.
Fisrt one is naive-convert, Second one is Original.

I also notice the segregation probabolities and recombination rate have the opposite results. I think it should be attributed to too much noise in the segregation prob.

@AprilYUZhang By calling the segregation status, it definitely would lose some information, which could contribute to the decrease in accuracy. Your Viterbi implementation can be easily modified to record the predicted segregation status (just return the list a). Could you check the result again with the Viterbi predicted segregation statuses to compare the two implementations for calling the segregation status?

@AprilYUZhang By calling the segregation status, it definitely would lose some information, which could contribute to the decrease in accuracy. Your Viterbi implementation can be easily modified to record the predicted segregation status (just return the list a). Could you check the result again with the Viterbi predicted segregation statuses to compare the two implementations for calling the segregation status?

In fact, Viterbi could not output a new segregation probablity, because it is just max-production, I guess it shouldn't be regards a new segregation probablity.

@AprilYUZhang By calling the segregation status, it definitely would lose some information, which could contribute to the decrease in accuracy. Your Viterbi implementation can be easily modified to record the predicted segregation status (just return the list a). Could you check the result again with the Viterbi predicted segregation statuses to compare the two implementations for calling the segregation status?

In fact, Viterbi could not output a new segregation probablity, because it is just max-production, I guess it shouldn't be regards a new segregation probablity.

Isn't the argmax state (segregation status) the most likely state (segregation status) given by the Viterbi?

I don't think we should focus on this because the most likely state for every locus is just based on the former one. If we look at this number alone, it is meaningless.

@AprilYUZhang By calling the segregation status, it definitely would lose some information, which could contribute to the decrease in accuracy. Your Viterbi implementation can be easily modified to record the predicted segregation status (just return the list a). Could you check the result again with the Viterbi predicted segregation statuses to compare the two implementations for calling the segregation status?

In fact, Viterbi could not output a new segregation probablity, because it is just max-production, I guess it shouldn't be regards a new segregation probablity.

Isn't the argmax state (segregation status) the most likely state (segregation status) given by the Viterbi?

I don't think we should focus on this because the most likely state for every locus is just based on the former one. If we look at this number alone, it is meaningless.

It is also based on all the previous loci because the probabilities are passed via each multiplication. The reason why I still insist on checking the segregation status is that sometimes the accuracy of recombination predictions can lie, it may have a recomb, but of the wrong haplotype.

@AprilYUZhang By calling the segregation status, it definitely would lose some information, which could contribute to the decrease in accuracy. Your Viterbi implementation can be easily modified to record the predicted segregation status (just return the list a). Could you check the result again with the Viterbi predicted segregation statuses to compare the two implementations for calling the segregation status?

In fact, Viterbi could not output a new segregation probablity, because it is just max-production, I guess it shouldn't be regards a new segregation probablity.

Isn't the argmax state (segregation status) the most likely state (segregation status) given by the Viterbi?

I don't think we should focus on this because the most likely state for every locus is just based on the former one. If we look at this number alone, it is meaningless.

It is also based on all the previous loci because the probabilities are passed via each multiplication. The reason why I still insist on checking the segregation status is that sometimes the accuracy of recombination predictions can lie, it may have a recomb, but of the wrong haplotype.

@AprilYUZhang By calling the segregation status, it definitely would lose some information, which could contribute to the decrease in accuracy. Your Viterbi implementation can be easily modified to record the predicted segregation status (just return the list a). Could you check the result again with the Viterbi predicted segregation statuses to compare the two implementations for calling the segregation status?

In fact, Viterbi could not output a new segregation probablity, because it is just max-production, I guess it shouldn't be regards a new segregation probablity.

Isn't the argmax state (segregation status) the most likely state (segregation status) given by the Viterbi?

I don't think we should focus on this because the most likely state for every locus is just based on the former one. If we look at this number alone, it is meaningless.

It is also based on all the previous loci because the probabilities are passed via each multiplication. The reason why I still insist on checking the segregation status is that sometimes the accuracy of recombination predictions can lie, it may have a recomb, but of the wrong haplotype.

It seems that the Viterbi implementation preserves much more information than naive converted states, that's good news!

@gregorgorjanc and @XingerTang To fit the precision and recall, I convert the original recombination probability to discrete values by logistic regression. (I didn't split train and test dataset, so there is risk of overfitting.)
This plot shows what they are. The green box includes the purple cherries identified correctly by the classifier, while the oranges identified correctly by the classifier are in the blue box. The yellow box is cherries, but it was incorrectly identified as oranges. The opposite is the oranges in the orange box.

Accuracy is all the correct results divided by the total.The recall rate can be regarded as how many cherries can be identified correctly, and the precision is how many of the results that are considered cherries are correct.
Table 1: Performance of method to estimate recombination events

Method
accuracy
precision
recall

Original+logistic
0.9992
0.8064
0.0153

Naive-Convert
0.9982
0.0948
0.1363

Viterbi-Convert
0.9981
0.0436
0.0623

So we can see that Original+Logistic carefully judges recombination events, leading to high accuracy and precision. But it ignores a large part of the real recombination events, causing a low recall rate . Naive-Convert has better performance on recall rates. According to precision and recall curves, the Naive-convert has the best performance.
Which is a good method to estimate the recombination events?
It depends on what we can sacrifice.
As shown in Table 2, a total of 1636 true recombination events occur. Original+Logitic can detect only 31, far less the true number. But 25 of the 31 recombination events are the same as true, which is the highest proportion. However, it is too small compared to the total numbers. Although this problem can be improved by modifying the parameters of logistic regression, training every dataset is not feasible in practice.
The benefit of discretizing the probability is that the difference between the total number of recombination events and the true value is further reduced, whether it is Naive-converted or Viterbi-converted, especially in the fourth generation, where the difference is the smallest.
To explore the gap between predicted and true locations, I performed an intersection between various methods and the true values. Due to the limitations of these methods, which may lead to inaccurate judgments of the locations where recombination events occurred, I also wonder if the predicted recombination events are in the neighbouring true values. Although the performance of exact prediction is poor, it will improve when we extend the region. For example, Naive-converted just predicts precisely 223 recombination events, while 1056 recombination events happen to true loci or surrounding true loci.
Faced with such a long Markov chain, Naive-converted and Viterbi-converted have limited ability to accurately predict each point. Also, the comparison of Naive-converted and Viterbi-converted shows this point. The intersection of Naive-converted and Viterbi-converted includes only 15, but the rough intersection is more than their own predicted number (Because nearby sites will be counted repeatedly). Apparently, Naive-converted and Viterbi-converted rely on different algorithms but have similar results.
Table 2: The number of recombination events

Whole Pedigree
G1
G2
G3
G4
G5

True
1636
0
392
401
427
416

Original (>0)
937317
0
282966
203289
210453
240609

Original+logistic
31
0
3
14
14
0

Naive-converted
2353
0
907
614
434
398

Viterbi-converted
2337
0
893
611
435
398

True and Original
1616
0
378
396
426
416

True and Naive-converted
223
0
43
70
70
40

True and Naive-converted neighbouring
1056
0
194
287
301
274

True and Viterbi-converted
102
0
14
37
30
21

True and Viterbi-converted neighbouring
1056
0
195
284
302
273

True and Original+logistic
25
0
2
11
12
0

True and Original+logistic neighbouring
26
0
3
11
12
0

Naive-converted and Viterbi-converted
15
0
5
4
5
1

Naive-converted and Viterbi-converted neighbouring
2379
0
916
619
440
404

**Original (>0) is there is a recombination event if recombination probablity is greater than 0. "A and B" means to the number of recombination events of A and B occurring at the same position. "A and B neighbouring" means to the number of recombination events of A and B occurring at the 20 variant window.  *

@AprilYUZhang Could you clarify some terms in your table 2? It is unclear to me what true and original+logistic mean.

@AprilYUZhang Logistic regression assumes the recombination probabilities to be independent, so it is not applicable in this way.
The number of recombination events predicted is not very useful in general, because we could have a lot of false positives or false negatives and for the precision-recall curve you only tried very few thresholds, I don't know what kind of conclusions we can draw from these results.


RFM - Psi+

Psi Plus – Development branch of Psi IM Jabber client. Project Purpose: Collection, refinement and writing new patches for transfer them to Psi upstream developers.
A new maintainer is needed.
https://chocolatey.org/packages/psi-plus/

I think I'll maintain it as long as I can.


Add hydrate to lit-element

does not make shadowRoot if one already exists
detects need to hydrate based on shadowRoot existence at construction time
first update calls hydrate instead of render if need for hydration was detected

@sorvell what would be the expected impact of hydrate addition on the bundle size?
Another thing that I'm interested is whether it would be possible to factor this out to a mixin.
As a developer, I would like to have an option to easily override this by replacing an import, as I previously  requested for shady-render in #909, see possible solution at https://github.com/Polymer/lit-element/issues/909#issuecomment-619294064.

@web-padawan Please consider everything in the hydration branches very early implementations, nothing here is actual proposed API yet.
That said, it is definitely a goal to make SSR/hydration support opt-in and pay-for-play to the greatest extent possible.  The exact mechanics of how we achieve that (mixin, global configuration, build-time, etc. are still a bit TBD).


Improve gitops/README.md to describe the process to setup a cluster using PaC

Let's make sure https://github.com/openshift-pipelines/pipelines-service/pull/109 is merged before this change goes in, as it references the new scripts.

@fgiloux @Roming22  I have worked on all the changes requested by Frederic above. Now that #109 is merged, PTAL at this PR.


[$500] IOS - A blank spot appears after deleting a money request

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

**Version Number:**<IP_ADDRESS>
**Reproducible in staging?:**Y
**Reproducible in production?:**Y
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
**Issue reported by:**Applause - Internal Team
Slack conversation:
Action Performed:

Request money manually form Fab menu
Select user
Add receipt
Select from Gallery
Complete request
Open Request
Select tree dot and select Delete Request

Expected Result:
NO blank spot appears after deleting a money request
Actual Result:
A blank spot appears after deleting a money request
Workaround:
Unknown
Platforms:

Which of our officially supported platforms is this issue occurring on?

[ ] Android: Native
[ ] Android: mWeb Chrome
[x] iOS: Native
[ ] iOS: mWeb Safari
[ ] MacOS: Chrome / Safari
[ ] MacOS: Desktop

Screenshots/Videos
Add any screenshot/video evidence

https://github.com/Expensify/App/assets/78819774/4e867d94-3e76-4094-b958-9b8203406cd8
View all open jobs on GitHub
Upwork Automation - Do Not Edit

Upwork Job URL: https://www.upwork.com/jobs/~013eb8adb4d15a7d21
Upwork Job ID:<PHONE_NUMBER>619288576
Last Price Increase: 2023-11-15

@shubham1206agra proposal for you ^

@tienifr Thanks for the proposal.
The RCA looks right. I have some follow-up questions.
Why won't increasing the height work?
And can you try to come up with an alternative solution? Cause this solution might introduce regressions.

@shubham1206agra bump on this comment!

@tienifr proposal looks good to me. I just need to confirm all scenerios that might break using this logic.

Can someone confirm if its still reproducible in DEV?

I think https://github.com/Expensify/App/pull/26498 changed the value of autoscrollToTopThreshold to 128.
See https://github.com/Expensify/App/pull/26498#pullrequestreview-1727585384.
A similar solution to you was marked as a workaround. https://github.com/Expensify/App/pull/26498#discussion_r1386932481
cc @roryabraham @mountiny as you have more context to this issue.

I think Rory mentioned we could dynamically set the autoscrollToTopThreshold  to the screen height, right? that would work then for most cases.

I have verified @tienifr's proposal. It looks good to me.
🎀 👀 🎀 C+ reviewed

I like this solution as well, hired @tienifr!
thanks @shubham1206agra

I will finish the review this weekend

@shubham1206agra did you get a chance to review?

@NicMendonca Yes, I just needed some minor adjustments, which I requested before approving the PR

BugZero Checklist: The PR fixing this issue has been merged! The following checklist (instructions) will need to be completed before the issue can be closed:

[x]  [@shubham1206agra] The PR that introduced the bug has been identified. Link to the PR: https://github.com/Expensify/App/pull/26498
[x]  [@shubham1206agra] The offending PR has been commented on, pointing out the bug it caused and why, so the author and reviewers can learn from the mistake. Link to comment: https://github.com/Expensify/App/pull/26498/files#r1440636967
[x]  [@shubham1206agra] A discussion in #expensify-bugs has been started about whether any other steps should be taken (e.g. updating the PR review checklist) in order to catch this type of bug sooner. Link to discussion: Not required
[x]  [@shubham1206agra] Determine if we should create a regression test for this bug. Yes
[x]  [@shubham1206agra] If we decide to create a regression test for the bug, please propose the regression test steps to ensure the same bug will not reach production again.

Request money manually form Fab menu with receipt.
Open Request created in previous step.
Select three dot and select Delete Request, and delete the request.

[ ]  [@NicMendonca] Link the GH issue for creating/updating the regression test once above steps have been agreed upon:

@shubham1206agra @tienifr  You've both been paid via Upwork 👍

all set here!


Cross-compiled, now runtime error ‘The OpenSSL library reported an error’ (target x86_64-unknown-linux-musl)

The openssl dependency makes cross-compilation very hard. (Once there is feature parity, I would be in favor of replacing it with webpki.)
Even when cross-compilation succeeds, the letsencrypt-rs fails for me at runtime.
I compiled openssl under Arch Linux, as required by the openssl crate:
sudo pacman -Syu musl
mkdir /opt/openssl/
cd /srv/installers/
curl --tlsv1.2 -O 'https://www.openssl.org/source/openssl-1.1.0e.tar.gz'
tar xf 'openssl-1.1.0e.tar.gz'
cd 'openssl-1.1.0e/'
export CC='musl-gcc'
./Configure no-unit-test no-async no-afalgeng no-ui \
    --prefix=/opt/openssl/ linux-x86_64 -fPIC
make -j"$(nproc)"
sudo make install

Then I compiled letsencrypt-rs:
cd "$HOME/devel/github.com/onur/letsencrypt-rs/letsencrypt-rs/"
env PKG_CONFIG_ALLOW_CROSS=1 OPENSSL_STATIC=1 OPENSSL_DIR=/opt/openssl/ \
    cargo build --release --target=x86_64-unknown-linux-musl

However, when running with some CLI params under Alpine Linux 3.5, letsencrypt-rs exits with status 1 and message:
The OpenSSL library reported an error

How can I solve this?
Could the error message be improved?

TBH I have no idea. I can't even build openssl with musl-gcc on my system (Debian sid), it never worked and I give up on trying.

Alpine Linux now used patched libressl version.

Yes, I just tested with LibreSSL and it is working fine. Just compile LibreSSL with musl-gcc and --disable-shared configuration option. Then you can build acme-client for x86_64-unknown-linux-musl and statically link LibreSSL library. I am closing this now.

@onur https://github.com/intoli/exodus


Run Prow tests on K8s 1.28

As per title.
Should help with #271

/hold
might get done via https://github.com/knative/hack/pull/370


[vue] Update package-lock.json after codechecker-api upgrade

@gyorb This was generated by the npm install command. In the previous commits we remove thrift from the main package.json maybe I forgot to regenerate the package-lock.json.


Optionally provide mint keypair for pumpfun

Allow the mint keypair to be grinded so that it ends with pump
Pull Request Description
Changes Made
This PR adds the following changes:

Added optional providedMintKeypair parameter to launchPumpFunToken

Implementation Details

Parameter is optional and shouldn't cause any issue with existing usage

Checklist

[ ] I have tested these changes locally
[ ] I have updated the documentation
[ ] I have added a transaction link
[ ] I have added the prompt used to test it

hey @slimeonmyhead - can you attach a working ss or video of this?

@thearyanag I can if you need, I'm a little busy atm. It's a minor change that should just work though and not affect any current usage.


Fix multiple repositories example

I setup scala-steward-action for multiple repositories, but I didn't realize that need to checkout.
It's an elementary mistake, but I think it would be more user-friendly to add a checkout step to the example.

Thanks for the contribution @NomadBlacky! This is definitely going to help newcomers! 😸


How to use roc-obj with rocblas-bench

I am trying to benchmark MI250X with rocblas-bench and I see some discrepancy. I want to look at the assembly using roc-obj. How do I enable dumping the assembly for the kernel being launched by rocblas-bench. Here is my command
./rocBLAS/build/release/clients/staging/rocblas-bench -m 8 -k 8 -n 8 -f gemm_ex -r bf16_r --compute_type f32_r -i 1 -j 1 --device 0
I tried adding HIP env variable export GPU_DUMP_CODE_OBJECT=1 before launching rocblas-bench, and I see bunch of object files,

When I open them with command
roc-obj -d _code_object0000.o
I get following error
Error: No kernel section found
error: no executables specified

This issue should be posted at https://github.com/ROCmSoftwarePlatform/rocBLAS
The team should be able to answer any rocblas related queries you have

Thanks, create issue in rocBLAS, https://github.com/ROCmSoftwarePlatform/rocBLAS/issues/1295


URL validator does not accept basic auth

>>> from wtforms import *
>>> class UrlForm(Form):
...     url = StringField(validators=[validators.URL()])
...
>>> form =<EMAIL_ADDRESS>>>> form.validate()
False

Duplicate of #153


'+' not accepted in maven version

The ANCHORED_VERSION_PATTERN in maven's Version class should match 2.1.5+32.
We recently changed our versioning strategy to use the number after the + to represent the build number.  This probably isn't normal but this is keeping us from running dependabot for our internal libraries.

Thanks for this, and for the associated PR. Are you aware of any published packages that use this setup? I'm slightly nervous about including it as there are no details about it in the docs.

I admit that this is slightly unusual.  We are following semantic versioning and including build number in the metadata as specified here: https://semver.org/#spec-item-10 and have found maven to handle it fine.  I don't know if there would be public libraries that use it.  Here's a library that has built handling around metadata https://github.com/zafarkhaja/jsemver#incrementing-versions though.  I was looking more into this with ruby and it looks like RubyGems does not support build metadata currently but can't find the article I saw that.  Nevertheless, in my local tweaking it looks like the PR I made is all that we need for it to work.  Otherwise, our library versions are considered incorrect.
Here's the link to the regex for RubyGems around versioning which doesn't seem to handle build metadata: https://github.com/rubygems/rubygems/blob/master/lib/rubygems/version.rb#L159

@matthewmcgarvey Do you also use the build number when publishing your project/library to your maven repo? Otherwise I would recommend dependabot to omit these versions, especially since adding build numbers usually implies development/unstable builds. Maybe SNAPSHOT builds, but I would also omit these unless specified otherwise.

Yea, I think I will be closing these.  Even after fixing this regex there were too many other problems that I ultimately had to give up


For some reason, spaces are removed after formatting

https://github.com/TinkoffCreditSystems/taiga-ui/pull/1017/files

Why prettier plugin change from tuiMapper: percentMapper:collapsed:computedMax to tuiMapper : percentMapper : collapsed : computedMax

Sorry, invalid issue


docker_postgres_1 exited with code 1 when docker-compose up

Do you want to request a feature or report a bug?
seems to be a bug
What is the current behavior?
postgres in docker-compose container will be killed due to version incompatible.
postgres_1    | 2021-12-02 15:57:02.876 UTC [1] FATAL:  database files are incompatible with server
postgres_1    | 2021-12-02 15:57:02.876 UTC [1] DETAIL:  The data directory was initialized by PostgreSQL version 13, which is not compatible with this version 14.1 (Debian 14.1-1.pgdg110+1).
docker_postgres_1 exited with code 1

terminal logs

$ ./setup.sh
Recreating docker_postgres_1 ... done
Recreating docker_graph-node_1 ... done
Starting graph-node ... done
Host IP: <IP_ADDRESS>
Stopping docker_graph-node_1 ... done
(master)$ git diff
diff --git a/docker/docker-compose.yml b/docker/docker-compose.yml
index 18405edc3..647f9161b 100644
--- a/docker/docker-compose.yml
+++ b/docker/docker-compose.yml
@@ -17,7 +17,7 @@ services:
       postgres_pass: let-me-in
       postgres_db: graph-node
       ipfs: 'ipfs:5001'
-      ethereum: 'mainnet:http://host.docker.internal:8545'
+      ethereum: 'mainnet:http://<IP_ADDRESS>:8545'
       GRAPH_LOG: info
   ipfs:
     image: ipfs/go-ipfs:v0.4.23
$ docker-compose up
Starting docker_postgres_1 ... done
Starting docker_ipfs_1     ... done
Recreating docker_graph-node_1 ... done
Attaching to docker_ipfs_1, docker_postgres_1, docker_graph-node_1
ipfs_1        | Changing user to ipfs
ipfs_1        | ipfs version 0.4.23
ipfs_1        | Found IPFS fs-repo at /data/ipfs
ipfs_1        | Initializing daemon...
ipfs_1        | go-ipfs version: 0.4.23-6ce9a35
ipfs_1        | Repo version: 7
ipfs_1        | System version: amd64/linux
ipfs_1        | Golang version: go1.12.16
postgres_1    |
postgres_1    | PostgreSQL Database directory appears to contain a database; Skipping initialization
postgres_1    |
postgres_1    | 2021-12-02 15:57:02.876 UTC [1] FATAL:  database files are incompatible with server
postgres_1    | 2021-12-02 15:57:02.876 UTC [1] DETAIL:  The data directory was initialized by PostgreSQL version 13, which is not compatible with this version 14.1 (Debian 14.1-1.pgdg110+1).
docker_postgres_1 exited with code 1
ipfs_1        | Swarm listening on /ip4/<IP_ADDRESS>/tcp/4001
ipfs_1        | Swarm listening on /ip4/<IP_ADDRESS>/tcp/4001
ipfs_1        | Swarm listening on /p2p-circuit
ipfs_1        | Swarm announcing /ip4/<IP_ADDRESS>/tcp/4001
ipfs_1        | Swarm announcing /ip4/<IP_ADDRESS>/tcp/4001
ipfs_1        | API server listening on /ip4/<IP_ADDRESS>/tcp/5001
ipfs_1        | WebUI: http://<IP_ADDRESS>:5001/webui
ipfs_1        | Gateway (readonly) server listening on /ip4/<IP_ADDRESS>/tcp/8080
ipfs_1        | Daemon is ready

If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem.
on master branch
cd docker
./setup.sh
docker-compose up

What is the expected behavior?
postgresql doesn't be killed.
Maybe specifying version 13 will work?
https://github.com/graphprotocol/graph-node/blob/590df45316c65291169457b50d62a25e46c25c26/docker/docker-compose.yml#L29

terminal logs (postgresql version 13 specified)

$ ./setup.sh
Recreating docker_postgres_1 ... done
Recreating docker_graph-node_1 ... done
Starting graph-node ... done
Host IP: <IP_ADDRESS>
Stopping docker_graph-node_1 ... done
$ docker-compose up
Starting docker_ipfs_1     ... done
Starting docker_postgres_1 ... done
Starting docker_graph-node_1 ... done
Attaching to docker_ipfs_1, docker_postgres_1, docker_graph-node_1
ipfs_1        | Changing user to ipfs
ipfs_1        | ipfs version 0.4.23
ipfs_1        | Found IPFS fs-repo at /data/ipfs
ipfs_1        | Initializing daemon...
ipfs_1        | go-ipfs version: 0.4.23-6ce9a35
ipfs_1        | Repo version: 7
ipfs_1        | System version: amd64/linux
ipfs_1        | Golang version: go1.12.16
postgres_1    |
postgres_1    | PostgreSQL Database directory appears to contain a database; Skipping initialization
postgres_1    |
postgres_1    | 2021-12-02 16:06:03.815 UTC [1] LOG:  starting PostgreSQL 13.5 (Debian 13.5-1.pgdg110+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 10.2.1-6) 10.2.1 20210110, 64-bit
postgres_1    | 2021-12-02 16:06:03.816 UTC [1] LOG:  listening on IPv4 address "<IP_ADDRESS>", port 5432
postgres_1    | 2021-12-02 16:06:03.816 UTC [1] LOG:  listening on IPv6 address "::", port 5432
postgres_1    | 2021-12-02 16:06:03.823 UTC [1] LOG:  listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
postgres_1    | 2021-12-02 16:06:03.846 UTC [28] LOG:  database system was interrupted; last known up at 2021-12-02 15:55:08 UTC
postgres_1    | 2021-12-02 16:06:05.423 UTC [28] LOG:  database system was not properly shut down; automatic recovery in progress
postgres_1    | 2021-12-02 16:06:05.454 UTC [28] LOG:  redo starts at 0/2FD5358
postgres_1    | 2021-12-02 16:06:05.520 UTC [28] LOG:  invalid record length at 0/301B560: wanted 24, got 0
postgres_1    | 2021-12-02 16:06:05.520 UTC [28] LOG:  redo done at 0/301B528
postgres_1    | 2021-12-02 16:06:05.637 UTC [1] LOG:  database system is ready to accept connections
ipfs_1        | Swarm listening on /ip4/<IP_ADDRESS>/tcp/4001
ipfs_1        | Swarm listening on /ip4/<IP_ADDRESS>/tcp/4001
ipfs_1        | Swarm listening on /p2p-circuit
ipfs_1        | Swarm announcing /ip4/<IP_ADDRESS>/tcp/4001
ipfs_1        | Swarm announcing /ip4/<IP_ADDRESS>/tcp/4001
ipfs_1        | API server listening on /ip4/<IP_ADDRESS>/tcp/5001
ipfs_1        | WebUI: http://<IP_ADDRESS>:5001/webui
ipfs_1        | Gateway (readonly) server listening on /ip4/<IP_ADDRESS>/tcp/8080
ipfs_1        | Daemon is ready
graph-node_1  | Dec 02 16:06:13.285 INFO Graph Node version: 0.25.0 (2021-12-01)
graph-node_1  | Dec 02 16:06:13.286 INFO Generating configuration from command line arguments
graph-node_1  | Dec 02 16:06:13.286 INFO Starting up
graph-node_1  | Dec 02 16:06:13.286 INFO Trying IPFS node at: http://ipfs:5001/
graph-node_1  | Dec 02 16:06:13.297 INFO Creating transport, capabilities: archive, traces, url: http://<IP_ADDRESS>:8545, provider: mainnet-rpc-0
...(snip)...

I’m sorry for taking up your time. It's my mistake.
https://stackoverflow.com/questions/44221938/postgres-container-crashes-with-database-files-are-incompatible-with-server-af


typescript build issue

hi all,
thanks very much for all contributors.
i have a issue:
i Use Nextjs in typescript and when i build i have this error:
./node_modules/@stitches/core/types/index.d.ts:279:6
Type error: Type expected.
$${Extract<keyof Theme[ThemeMap[k]], string | number>}
is this a bug ?

Which version of typescript do you have?

hi @peduarte.
i use typescript 4.3.0

That's odd. Should with with typescript 4.1+
Out curiosity would you mind deleting node_modules and installing again, then building?

hi @peduarte
with typescript 4.1+ solve this issue. 👏👏👏 🙌
thanks.
Stefano


[Qt] fix typo in bitcoingui.cpp

availble -> available

closing and reopening to make the CI aware of the target branch change

closing and reopening to make the CI aware of the target branch change


v3 Memory Leak

Looks like the latest beta has a memory leak. need to look into it, but this might be a blocker

@lelandrichardson Do you have code that reproduces the memory leak or appears to have memory leak symptoms? As a part of my PhD research, I have developed an experimental JavaScript memory leak detector that automatically locates, ranks, and diagnoses memory leaks (publication -- and open sourcing! -- pending :) ). I'd be happy to throw enzyme at it to see what happens! All I need is a full example demonstrating the leak that I can run in a web browser.
On a side topic -- do you know who I could contact with memory leaks (and fixes!) that I've found on the main pages of airbnb.com? Some of them involve third-party services, but others appear to be in your own code. It's leaking about a megabyte each time users switch between certain pages, and continually adds global event listeners, documents, and more. You (or whoever) can drop me a line at<EMAIL_ADDRESS>and I can provide plenty of details on the problems, how to observe them, how to fix them, and the measured impact of the fixes.

@jvilk investigating this further, this doesn't appear to be a regression. It's very possible that enzyme has a memory leak, but it doesn't appear to be new to v3. I'll try to get a minimal repro but i'm not prioritizing this fix anymore.

It doesn't need to be a minimal repro; the tool will see through whatever complexity there is. :) Any repro is totally fine.
(Also, I've sent the other memory leaks along to airbnb already, so no need to help me with a contact on that!)

Nobody's reported this further; going to close.


Update vsphere development readme

This PR adds command to launch cluster in README. Fixes #13
Tested flannel:
Before:
Not able to access dashboard service. Since network requests where not able to reach dashboard pod.
After:
Launched nginx and dashboard pods and services for them. Able to access dashboard and nginx.

LGTM


Update Taks/ Playbook

Any plans to support updating a ceph installation? I think this can be a very complex task juggling many deamons on many machines but it can potentially automated even with zero downtime I guess.

This is supported here: https://github.com/ceph/ceph-ansible/blob/master/rolling_update.yml
Please have a look at it.
Closing this, feel free to reopen :)

Sorry, didn't spot that although I looked trough it :/


Add improved header styling

Before:

After:

Whilst these styling changes do improve readability, we may want to consider adding numeric heading separators too (Numeric, Alphabetical or Roman), which could be auto-generated in ./src/_includes/layouts/handbook.njk where we currently auto-generate the ToC.
So:
# Heading A
Content Content Content

## Heading B
Content Content Content

## Heading C
Content Content Content

would be auto-generated as:

I. Heading A

Content Content Content

I.I Heading B

Content Content Content

I.II Heading C

Content Content Content

This may also make a short term assist for https://github.com/flowforge/website/issues/193 to distinguish between the ToC Headers and overall navigation headers


WebComponent HMR

This might not be the place for this, but it's the only work really out there with Svelte + HMR, so:
Any ideas on how to get the web component output working with HMR? I'm looking at https://open-wc.org/docs/development/hot-module-replacement/ which looks for a hotReplacedCallback on the outputted web component.
Not particularly familiar with HMR, so any pointers here on how I could implement this would be awesome!

Yes, this is the right place.
Unfortunately, I have previously tried to fix support for WC myself, got burnt, gave up...
iirc the first blocker was that Svelte registers successive versions of a web component under the same tag name, which doesn't go well with the browser... I believe I past this one, but then there were more... The code produced by Svelte for WC is very different from normal components.
This is a legitimate request so I'm keeping the issue open, but I have no immediate plan on trying to solve that again, sorry.

A general solution might be tough to implement for WC, but with the @open-wc/dev-server-hmr combined with the @web/dev-server it looks like it should be easier?
I've been playing around with the web dev server for the past bit, so far implemented it to resolve and return compiled files with just adding the file src as a script tag in html - adding hmr would be great

Has there been any progress on this? I started seeing hmr-related errors while using the above, vite-plugin-svelte.

Has there been any progress on this?

No sorry. WebComponent HMR implementation would be very different from what we already have and, to be honest, it is far from the top of my TODO list... There are a few items to complete support and increase stability before it.

Also very interested in this. I created svelte-retag which actually handles Svelte 3 & 4 custom elements and supports Vite HMR (along with proper support of slots in the light DOM and some other features).
Anyway, here's a proof of concept in plain Svelte 4 (if it's helpful)... Init repo:
git clone https://github.com/patricknelson/svelte-v4-custom-elements.git
cd svelte-v4-custom-elements
npm i
npm run dev

... and then a demo of it working with svelte-retag: 🚀
git checkout hmr-via-svelte-retag
npm i

In both cases, if you edit src/lib/ExampleElement.svelte you'll see it in action.

In Svelte 3 the issue was that it got redeclared over and over.
However, in Svelte 4 the issue is that HMR simply doesn't trigger at all. My hunch here is that it's working in svelte-retag because the main Svelte component itself is proxied so that changes are reflected, but for some reason the custom element instance defined at Component.element (the .element property of the component itself, specifically) is not proxied and so it doesn't swap out.

Another hunch... after some research, it seems that if we can maybe have the compiled .svelte component emit the customElements.define(create_custom_element(...)); call after the proxy is setup, then there's some potentially that HMR might work. I think that's probably the reason why it's already working right now in svelte-retag, since this is effectively what my package is already doing. i.e.
Deriving the HTMLElement instance (wrapper) based on the proxied component rather than the original component instance. Essentially, relocating it here (reformatted compiled output):

This may in fact be a Svelte compiler issue but I'm not sure. Maybe the HMR adapter is able to ensure it's proxy is injected above this location?

cc @rixo
we cannot redefine the custom-element  though, thats not how browsers work. so the best we can achieve would be to have the svelte-hmr proxy working for the svelte component that lives inside the wrapper.
As soon as the interface of the custom element changes, you have to do a full reload. (eg adding or removing a prop).

@dominikg are you addressing me?
If so: I understand. 😄 The multiple calls to customElements.define() what would occur as the module is reloaded is separate from the triggers that lead to that reload (i.e. the proxying that I was referring to above). The issue of multiple definitions is easily resolved by just checking to see if the element is already defined. When it is defined, it should point to the HMR proxy that does the heavy lifting of swapping out (“hot reloading”) the actual HTMLElement instance like svelte-hmr already does for the Svelte component.
In fact, that’s how it already works (in svelte-retag). In that case, the HTMLElement wrapper that initializes a Svelte component is actually just pointing to the HMR proxy that’s already being helpfully wrapped by svelte-hmr at dev runtime on the fly in Vite. That’s also why the redundant customElements.define() calls are avoided, coincidentally, because svelteRetag() happens to do this outside of the module that’s getting reloaded by HMR.
So in this case, I’m just addressing the HMR boundary issue (which then cascades to the next issue of multiple definitions, again easily resolved) by just moving the proxy definition up a tad. Does that make sense?

As soon as the interface of the custom element changes, you have to do a full reload. (eg adding or removing a prop).

Also: Presumably this interface never changes (at least during dev runtime). That’s because this is just a wrapper already (both in svelte-retag as well as in the implementation in svelte itself). This HTMLElement wrapper points to the proxy (again, just in dev) which then points to the actual component which does change frequently at dev runtime. While those props do change, it’s behind the proxy which is why it’s fine (and works as intended).
Am I misunderstanding?


fix: set requirements for workshop

Description:
Small change to the workshop readme to add requirements

Pull Request Test Coverage Report for Build<PHONE_NUMBER>1
Warning: This coverage report may be inaccurate.
This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.

For more information on this, see Tracking coverage changes with pull request builds.
To avoid this issue with future PRs, see these Recommended CI Configurations.
For a quick fix, rebase this PR at GitHub. Your next report should be accurate.

Details

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

Totals

Change from base Build<PHONE_NUMBER>4:
0.0%

Covered Lines:
3525

Relevant Lines:
4649

💛  - Coveralls


Exposing fontprovider

Checklist

[ ] If applicable, create follow-up issues for purchases-ios and hybrids

Motivation

It's not possible for us to change the font family in react-native-purchase.
My hope was to expose this font provider methods for the RN Bridge so that we can at least set custom font family.

Description

Exposing fontProviders for PaywallFooterView and PaywallView.
Invalidate views when font provider changes. theme composition local provider should update this autmoatically.

Need to add something like this on the React Native side.
If user did link the font via
<font-family xmlns:app="http://schemas.android.com/apk/res/android">
        <font app:fontStyle="normal" android:fontWeight="200" android:font="@font/montserrat" />
</font-family>

    ReactFontManager.getInstance().addCustomFont(this, "Montserrat", R.font.montserrat);

We could just bring the font family
    @ReactProp(name= "fontFamily")
    fun setFontFamily(view: PaywallFooterView, fontFamily: String?){
        val typeface = ReactFontManager.getInstance()
            .getTypeface(fontFamily /** Montserrat in this case. **/, ReactFontManager.TypefaceStyle.NORMAL, assets)

        view.setFontProvider(CustomFontProvider(FontFamily(typeface)))
    }

@tonidero How do you feel about adding this PR to the purchase-android?
Is there a roadmap for font provider setter? If so, I can wait 😄

Hey @Jjastiny, I've just tested these changes and they work great!
We don't have a timeline yet for supporting custom fonts on the hybrids, but it shouldn't take too long we hope, we are actively working on better support there.
I think this PR can be merged once we apply the same changes to the PaywallView (sorry for the duplication 😢). Do you mind applying the changes there and open a PR against our repo? Then we can get it merged.

@tonidero
I do not mind at all!
If you dont mind, I will create ios and react-native bridge changes too :)

Sure thing! Contributions are more than welcome 😄 thank you!!

Closing. as it was merged to purchases-android.


Single period after a named code block causes error

If I use a single period on the next line after a named code block, like so:
`$255` ←
[address of program name]()
.

See context at https://github.com/Wideshanks/mmix-hw/commit/ea56c340dd9a1e227ba99f0daec7e10f37c8957c
I get build errors:

Any other word, or single character like a letter, comma, dash, or more than one period works successfully.

Fixed. It was a deprecated feature. In the old days, the switch parsers were a ". SWITCH NAME". It was deprecated awhile ago and forgotten, but I have now removed it. Tests pass and this problem is removed. Check out v 0.8.3


Strange slowdown

I'm trying out CNNs now, and experience a strange slowdown: epochs start to take significantly longer after some time, see this log for example:
Epoch 1/100
10016/10000 [==============================] - 570s - loss: 0.6259 - acc: 0.6696 - val_loss: 0.5100 - val_acc: 0.7690
Epoch 2/100
10016/10000 [==============================] - 572s - loss: 0.5227 - acc: 0.6842 - val_loss: 0.4405 - val_acc: 0.7347
Epoch 3/100
 4288/10000 [===========>..................] - ETA: 1280s - loss: 0.4887 - acc: 0.7297

As you see, first two epochs required way less time than the 3rd one. This isn't reproducible for random data, as I understand, so I can't provide a script for everyone to try; but the NN is just a simple CNN for images.
I'm training on CPU, the machine doesn't run any other computations at this time, there is a lot of free RAM, no throttling and so on. Also CPU usage was always high during first two epochs, but then started jumping between high and low at the same time as the process slowed down.
Any ideas how to find the cause of this?

I know that denormal value can cause slow down on the CPU:
https://en.wikipedia.org/wiki/Denormal_number. I saw benchmark that show
10% slow down. I don't know if it can go higher.
I think that with g++ compiler, you can use this Theano flag to remove the
support of denormal value and get some speed up:
gcc.cxxflags=-ffast-math
On Thu, Nov 24, 2016 at 1:38 AM, Alexander<EMAIL_ADDRESS>wrote:

I'm trying out CNNs now, and experience a strange slowdown: epochs start
to take significantly longer after some time, see this log for example:
Epoch 1/100
10016/10000 [==============================] - 570s - loss: 0.6259 - acc: 0.6696 - val_loss: 0.5100 - val_acc: 0.7690
Epoch 2/100
10016/10000 [==============================] - 572s - loss: 0.5227 - acc: 0.6842 - val_loss: 0.4405 - val_acc: 0.7347
Epoch 3/100
4288/10000 [===========>..................] - ETA: 1280s - loss: 0.4887 - acc: 0.7297
As you see, first two epochs required way less time than the 3rd one. This
isn't reproducible for random data, as I understand, so I can't provide a
script for everyone to try; but the NN is just a simple CNN for images.
I'm training on CPU, the machine doesn't run any other computations at
this time, there is a lot of free RAM, no throttling and so on. Also CPU
usage was always high during first two epochs, but then started jumping
between high and low at the same time as the process slowed down.
Any ideas how to find the cause of this?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/fchollet/keras/issues/4494, or mute the thread
https://github.com/notifications/unsubscribe-auth/AALC-3odDSOyEqEj_EznoHi73KZGY01Wks5rBTDrgaJpZM4K7Utb
.


Allow to run 'code -w' and return when vscode is running already

VSCode Version: 1.11.1
OS Version: macOs 10.12.4

Steps to Reproduce:

Ensure that vscode is not running
In a shell, run code -w file
vscode is launched and file is opened
Close the window
code -w file does not return
Quit vscode
code -w file returns

Expected result:
code -w file should have returned at step 5 after the window is closed

https://github.com/Microsoft/vscode/issues/4142


fix: print enclave names even after restart during clean

https://user-images.githubusercontent.com/6670312/224962866-e14a3fc6-5b3c-407c-839d-f9516252d3d6.mov


k8s_resource for "out-of-the-box" services

Hi,
I'd like to start off my Tiltfile with a few base services which my cluster depends on, and I would like to set up port forwarding as well. So far the file is pretty simple, yet it runs into a problem.

# dgraph
k8s_resource('dgraph', './dgraph/single.yaml', port_forwards=[8080, 9080, 8000, 5080, 6080])

# fusionauth
k8s_resource('fusionauth', kustomize('fusionauth-infrastructure/kubernetes'), port_forwards=[9011])

# kill-bill setup
k8s_resource('killbill', kustomize('killbill'), port_forwards=[9090, 8080, 8000, 12345])

The errors reported are:
──┤ Building: dgraph ├──────────────────────────────────────────────
Build Failed: ImageBuildAndDeployer does not support these specs

──┤ Building: fusionauth ├──────────────────────────────────────────────
Build Failed: ImageBuildAndDeployer does not support these specs

──┤ Building: killbill ├──────────────────────────────────────────────
Build Failed: ImageBuildAndDeployer does not support these specs

I also tried running the installs at the beginning via k8s_yaml but then the k8s_resource doesn't find it:
k8s_yaml('./dgraph/single.yaml')
k8s_resource('dgraph', port_forwards=[8080, 9080, 8000, 5080, 6080])

--- results in:
Tiltfile error:
resource "dgraph": no matching resource

Can such "ready-made" services be deployed before my development packages are built?

Hi @nadilas! Sorry you ran into trouble with this. I think there's a bug right now that if you have a k8s_resource without a Dockerfile attached, everything gets confused. @maiamcc do you know if there was already a bug filed about this?
also, any chance that the project with dgraph/single.yaml is an open-source project? It would be helpful to test the fix against a real project so that we know we fixed it.

Nope, no ticket open as far as I know -- will file one now! Thanks for the report @nadilas !

@maiamcc no problem 🙃
@nicks the source code is actually available: https://github.com/dgraph-io/dgraph
Does that help?

Hi @nadilas,
sorry for the radio silence, but wanted to let you know that we've got a PR in flight for this (#1156), and i'll check it against your source code tomorrow morning!

Ah so, the good news is, you CAN declare a k8s_resource with only yaml and portforwards and without an associated docker_build, and it'll spin up:

The bad news is that Tilt currently only supports portforwarding for a single container: right now it's picking up ratel because it's the first, and all of the local ports you specified are connecting to ratel:8000.
Is this functionality still blocking you?
I assume in your original Tiltfile, with port_forwards=[8080, 9080, 8000, 5080, 6080] you intended the first container port (ratel) to forward to 8080, the next two (zero) to forward to 9080 and 8000 respectively, etc.?

Hi @nadilas,
Just following up -- I assume the above is still blocking you? Or have you found a workaround?

Hi @maiamcc,
sorry for going dark. So that is actually good news. Do you have a Tiltfile as an example? Or is it just a one liner:
k8s_resource(‘name’, ‘yaml’, port_forwards=[8080]) after a version update?
The yaml file for dgraph is from there doc, maybe the containers can be decoupled, I have to look into it. But yes, your assumption is correct I wanted the port delegation to happen in that order yes.

Yeah, that one-liner should work! Check out this branch for a tiny example!
"Support pods running multiple containers" is on our radar as a future feature, but for now, let me know if you can split out the containers/get this code running, and when you do I'll close the issue.

@nadilas I'm gonna go ahead and close this issue, but let me know if you run into any trouble getting this running and I can help you debug!

@maiamcc thanks a lot! I’ll get back to you, should anything unforeseen happen :-)

FYI @nadilas we're slowly making progress on this -- still can't port-forward multiple containers, but you can now at least get logs from them! 😅


PowerToys requires certain apps to close before update, but no documentation explains why this is necessary.

I tried to update the PowerToys app today and during the process it asked me to close apps such as Office 365 Suite apps, Slack, Calculator and all my browsers + a lot more apps. There is no documentation I can find that explains the reasoning behind these requirements. And I don't see how the installation would benefit from closing all these other apps, apart from it being tedious and annoying.
📝 Provide a description of requested docs changes
It would be great if someone could shed light on these requirements and maybe explain why it has to be done every time the app is updated (which is quite frequently).

dup of #3534

So, its a bug, not something undocumented?

Yes. This is a bug of which the PT Team can do nothing about.

It would be great if you could close this issue if you think that this is a duplicate of #3534

I couldn't find any apparent issues when pressing "ignore", if this is the case that no real dll issues would occur then maybe it could be beneficial to include some info about this in the documentation?

But these incidents seem to very rare

Well, I guess I'll close it then.

No. don't close it. Wait for triage from PT Team. I was just reasoning when you said:

I couldn't find any apparent issues when pressing "ignore". If this is the case for all apps and no real dll issues would occur, then maybe it could be beneficial to include some info about this in the documentation?

@Swoy I could be wrong


test_up_down_consistency assumes linear history and does not work with branches

As you might see in the readme for that check, I dont see the value in branched histories, although I'm sure it's something we certainly can accommodate in some fashion. In the interim, you can always disable that check.
Can you explain your usecase for branched history? And also, can you explain how you would navigate this check manually with alembic commands, given your history/branches?

We have 5-6 people working on a project and each one of us creates alembic revisions specific to our changes. Usually we create a mergepoint to combine these changes.
For branched histories we can check test_up_down_consistency from each branchpoint to each connected mergepoint.

As a rule, all of our histories are completely linear (which we enforce with i.e. pytest-alembic), so the existing methodology of upgrading by +1 clearly wont work.
I assume we would have to do a kind of bfs traversal of the upgrade graph, inspecting at each node the set of available heads (or tails, going downwards :p) and upgrading each of them in turn.
I'll have to see what the workflow for that looks like in practice, given a graph that maybe branches a couple times and has nonlinear mergepoints or something.


Clauderlys rodriguez

Sprint Done

I want to go back to lambda . I don’t know how to proceed.
On Fri, Oct 1, 2021 at 11:54 AM Brit Hemming @.***>
wrote:

Closed #22
https://github.com/LambdaSchool/web-Sprint-Challenge-User-Interface-and-Git/pull/22
.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/LambdaSchool/web-Sprint-Challenge-User-Interface-and-Git/pull/22#event-5395339527,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ANFIZ2RMULL7AUQVSYK5Q4DUEXKUXANCNFSM4N5WQLKA
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.


Feature/react webpack testing

@pluma  Just for better readability

still WIP, a few things left to do. More information in TODOS:
https://github.com/arangodb/arangodb/pull/8712/commits/75dfa22260313534b04a5bf5402b878965b18d18

Oskar:
and cp -a Documentation/Examples js/apps/system/_admin/aardvark/APP/api-docs.json Documentation/Scripts/allComments.txt ../Documentation
Path needs to be adjusted in:
scripts/buildExamples.fish

@mchacki now finally mergeable :)


Sales Prediction

Describe the project you want to add with tech stack
With the help of an appropriate Machine Learning model, I would like to create a Sales Prediction Model for a retail Supermart, or any shop.
Expected behavior
So for a specific dataset, the first step would be finding out the best model (that gives the best accuracy) followed by training and testing the model on that selected model and then predicting the values.

can u assign me this isssue


get puente working with python 3.3, 3.4 and 3.5

Need to add tox environments for python 3.3, 3.4 and 3.5 and then test Puente out with them all and fix the issues.

We're going to push this off until someone needs it.
Why? Because it's not clear whether this project is in it for the long haul or whether it's just a stopgap fix that will be phased out in the next year.

Turned out to be pretty easy to do. Pretty sure the result is good--it passes all the tests.


Odd effects with transformOrigin property

When animating some basic div shape, modifying the transformOrigin property in anime.js causes a different animation than animating the transform-origin property in the CSS file.
To observe the issue:

Watch the animation in the codepen
Uncomment line 3 in the javascript and watch the animation
Recomment the javascript line and uncomment the transform-origin property in the CSS, observe correct animation

https://codepen.io/supermandrew/pen/pWxyBJ
Any ideas why they're different?
EDIT: Additionally, it appears that words such as 'left', 'center', etc are not supported in anime.js transformOrigin.  For instance, using this for line 3 causes the animation to stop:
transformOrigin: 'left center',

Okay, after a bit more testing, it seems like animejs 2.0.0 (included in the codepen) has the weird effect with transformOrigin, and animejs 2.2.0 has no effect with transformOrigin.
However, I'm assuming animejs should still be able to modify transformOrigin correctly, no?

@supermandrew You probably cant animate keywords. Convert those to numerical units like 50% 50% instead of center center or whatever.

You need to give the three-value syntax:
{ transformOrigin: "50px 50px 0"}

Both @HauntedSmores and @cedeber are right, you can't use 'center center',
and if no initial values are specified, I recommend using the full three-value syntax '50px 50px 0px'.

I still think I'm missing something here.  I've modified the codepen to instead of using %'s, to use px, but the issue still persists.
Using: transform-origin: 0px 50px; in CSS causes a different behavior than transformOrigin: '0px 50px', in animejs.
I've also tried with using the full three-value syntax, and still having no luck (seems to work in CSS, not animejs though).

It's because you're animating the transformOrigin property.
From the default value to '0px 50px'.
If you want to define a property, but not animating it, you should simple set it in CSS.
But if you really want to use anime() to set the transformOrigin property you can define the initial and end value to be the same, like this:
transformOrigin: ['0px 50px', '0px 50px']

Totally didn't realize that, you're absolutely correct.  Thanks for the help!


Avoid torch/extension.h in cu file

Fix #115 the compiling failure of the custom ops on windows.

@vivid-k has verified that the issue has been fixed.


Segmentation fault - Return float from a Lua script

Hi,
To reproduce the bug :
Create a simple Lua script that return a float, for example (defined in my_module.lua) :
function example(topRec)     return 10.51 end
Then call this function from your PHP script :
$client->apply($key, 'my_module', 'example', [], $result);
You will have a Segmentation fault (11)
Env :
Server : Apache 2 with MAMP
PHP : 7.0.12
Aerospike PHP Client :  3.4.14
Aerospike Server : Aerospike Community Edition build <IP_ADDRESS>
BOUDAOUI Mohamed.

Thank you for reporting the issue.
We'll look into the issue and let you know when it has been fixed.


Mediapipe has a slow performance on android

Hi. I have a problem with the mediapipe performance on android. I really got stuck with that and do need help please!

It seems like fps rate is around 10 or maybe even low.

I've built hands solution app by the documentational tutorial using android studio.
I think, I've investigated all the official code and haven't found the way to increase to the certain 30 fps. That's exactly what I need because the following step in my apk is to collect information about landmarks'  coordinates for further sign language recognition (my tensorflow model, of course converted to the tflite, has been trained on 30fps).
Maybe is there a problem in my device? I use

HUAWEI AUM-L41
APL 26
Android 8.0

If it needs, I can provide any additional information.

The mediapipe class CameraInput is being used, in which then CameraXPreviewHelper.class is being imported:
MainActivity.java
import com.google.mediapipe.solutioncore.CameraInput;

CameraInput.class
import com.google.mediapipe.components.CameraXPreviewHelper;

So I had an idea to edit CameraXPreviewHelper.class. There is a class ImageCapture.Builder.
CameraXPreviewHelper.class
import androidx.camera.core.ImageCapture.Builder;
...
public class CameraXPreviewHelper extends CameraHelper {
  ...
  private Builder imageCaptureBuilder;
  ...
  public void startCamera(Activity activity, @Nonnull Builder imageCaptureBuilder,
  CameraFacing cameraFacing, @Nullable Size targetSize) {
        this.imageCaptureBuilder = imageCaptureBuilder;
        this.startCamera((Context)activity, (LifecycleOwner)((LifecycleOwner)activity),
        (CameraFacing)cameraFacing, targetSize);
  }
  ...
}

And I thought it would work to add a Camera2Interop option as I saw it had worked with ImageAnalysis from this issue's second answer. Something like that:
CameraXPreviewHelper.class
import androidx.camera.core.ImageCapture.Builder;
\\\add imports
import androidx.camera.camera2.interop.Camera2Interop;
import android.hardware.camera2.CaptureRequest;
...
public class CameraXPreviewHelper extends CameraHelper {
  ...
  private Builder imageCaptureBuilder;
  ...
  public void startCamera(Activity activity, @Nonnull Builder imageCaptureBuilder,
  CameraFacing cameraFacing, @Nullable Size targetSize) {
        this.imageCaptureBuilder = imageCaptureBuilder;
        \\\and this
        Camera2Interop.Extender ext = new Camera2Interop.Extender<>
        (this.imageCaptureBuilder);
        ext.setCaptureRequestOption(CaptureRequest.CONTROL_AE_TARGET_FPS_RANGE, new
        Range<Integer>(30, 30));
        \\\
        this.startCamera((Context)activity, (LifecycleOwner)((LifecycleOwner)activity),
        (CameraFacing)cameraFacing, targetSize);
  }
  ...
}

But I still have a doubt because here ImageCapture is been used. Moreover, after I'd decompiled class, edited code and tried to compile that again to .class I received a bunch of errors.

Hi @KornilovaK ,
Could you check this closed issue https://github.com/google/mediapipe/issues/460 , please check and revert back if you have still further queries.


Add localisation/formatting capabilities to SpriteText

This is an example implementation of 'native' localisation in text sprites to get some feedback on the idea.
Just take a look at the test case to see how this could be used in code.
Note: Sprite text instantiation can usually be done in the constructor. It's necessary to put it inside load() in  the test case since we need local dependencies.
I am also not sure if this should be moved to a new LocalisableSpriteText class.
I know that it's missing comments and that it breaks existing SpriteText implementations.

Listening to changes on the LocalisableString introduces two problems:

Lingering object references
Re-calculating all the localisation on every property update (as in: if we change Text, Type, Args, the localisation will be re-done three times).

Both of these can most likely be fixed, but is it really worth doing that over a manual UpdateLocalisation() call or something similar?
Pinging @peppy, @smoogipoo for opinions

If you wanted to update all three, why not just create a new LocalisableString?
Manual methods are never going to be a thing.
Don't need to ping; we read everything anyway.

Can you explain the "lingering references" thing in more detail? Where are you seeing this?

I know that creating a new LocalisableString makes more sense than changing 2+ values in an existing one, but I thought it might not be obvious to someone else using it.
But if that is preferred over a manual method call, that's fine. I can probably add that as an XMLdoc to the LocalisableText property.
What I mean with "lingering object references" is this:

I haven't tested this to be honest, but I think that this prevents bindable from being GC'd, doesn't it?

Those are all outwards references, so should not affect GC.

I guess I was brought in here over a minute detail, but I'm gonna comment on the full thing anyways.
Localisation, as is done in this PR, is basically useless to me.
Most the relevant text I have is sitting nice and comfortably in a TextFlowContainer, which does not make use of any localisation features and does not expose APIs to use them itself, either.
The only thing this PR offers over doing dumb hand-localisation as in spriteText.Text = MyLocalizer.Money(123.45); is that it will correctly auto-update all SpriteText instances (except those in TFCs I guess, but lets assume TFCs had new API surface similar to whats been done for SpriteText in this PR) without needing to re-launch my application. Since it is indeed very unlikely that my users are going to change their language setting at all, ever (since I can just pick OS default as display language and 99% of users will never care to choose anything else) I don't think I gain much by asking my users to restart if they wanna change the language.
In terms of effort required to ensure everything I want to be localised is localised, using this API over the manual approach (MyLocalizer class with a bunch of methods/properties for rendering out text) is actually more work and probably requires both more memory and CPU time (not sure the diff is big enough to write home about, but ya know).
So overall, using this approach I get a negligible benefit (ie solving a problem that I don't think is relevant to me or my users at all) for a bunch of extra effort and a slight memory use and probably a slight perf degradation.
The other thing that rubs me the wrong way is pretending (via names in the API) that SpriteText et al actually support Unicode. They don't. The moment you throw RTL-Overrides or Surrogate-Pairs at them they will not display the correct thing. They also do not support combining diacritics at all. At best, it supports everything that fits into a UTF-16 unicode code point, but everything that goes beyond that, and almost all control characters are essentially ignored. I'm not arguing to implement full unicode here, I'm just saying we shouldn't write APIs that could get people to believe that SpriteText actually supports arbitrary unicode.
Sorry for the harsh judgement, but overall I don't see a solid reason to call this API useful, it seems clumsy to use for only a small benefit and does not (yet) cover important use-cases (TextFlowContainer et al).

This is sort of restating a point, but my main reason for not wanting to use this API and instead wanting to hand-localise things is not performance, it's that using this API is actually more effort (since I have to manage three properties per localised text and do some infrastructure plumbing to get the framework integration) than hand-localisation.
If you can get the usage of this API to be as or more convenient than hand-localisation I honestly wouldn't mind sacrificing a bit of perf/memory for its neatness, although it'd of course be great if that overhead would be kept to a minimum.

Thanks for the clarification on that, I actually didn't quite catch that in your first post.
I agree that the API could be more convenient (e.g. just inputting a string will localise it as a default option), although I'll have to try and find a way to still include all functionality without making the API convoluted.
I'll think about a good way of doing this and then probably start over in a fresh PR. I'll leave this one open for now though.

Could you explain what hand-localisation is?

Hand-localisation is what he meant by spriteText.Text = MyLocalizer.Money(123.45);. I.e. localise explicitly whenever a text is assigned. His argument is that it's not that bad in terms of UX to require a restart for localisation changes to occur since

Localisation changes are rare (they likely occur at most once and then never again)
Most of the time, using the system default will do the right thing and the user never has to change language in the first place

Aha. I don't think that's not gonna float for osu! (or my own goals for framework localisation support). But we definitely should still allow users to do that – ie. localisation additions should not cripple the basic Text setters in SpriteText and FlowTextContainer in usability or performance.

That is not sufficient for fe Tooltips where you would be forced to always use IHasCustomTooltip to be able to use localisation since the IHasTooltip API simply sets a string value to the tooltip - which if the tooltip forwards it to a SpriteText will still not be localised. Other APIs may have similar issues.
I also cannot see a good reason for why I should be forced to override a SpriteText if all I want is localisation - after all most APIs already expose ways to set the Text property from the outside.
Personally I believe myButton.Text = MyLocalizer.Confirm; beats
public class MyButton : Button
{
    public new LocalisableString Text
    {
        set => SpriteText.LocalisableText = value;
    }
}

To me, that solution is far from clean or desirable, exposed SpriteText or not.

public class OsuTooltipContainer : TooltipContainer
    {
        protected override ITooltip CreateTooltip() => new OsuTooltip();
        ...

And how exactly is OsuTooltip going to acquire a LocalisableString when IHasTooltip always returns a regular string?

If we're going down the path of assigning to Text manually, for osu! this means creating callback methods per text assignment everywhere across the project, so this will not work for us.
If we don't implement the bindable solution at a framework level (which I think is the correct place) we are going to be doing the same thing at the osu! end.
Since you personally aren't interested in using this solution, I think it's fair if we do it at the framework side and – as I said above – avoiding changing the workflow for normal Text setting.

In the case of tooltips, we would need to make a IHasLocalisableTooltip, or modify the IHasTooltip interface.

@peppy Yes, things like that have to be done. That is what I was getting at in my original comment - that APIs such as Tooltips, Buttons etc. probably should be revisited too since they expose ways to set SpriteText.Text but not ways to do so in a localised way, and trying to work that in from subclasses gets messy quickly, so overriding SpriteText is not a sufficient solution.

Before I change the API, something about functionality (really unsure about this):
So.. currently (in this PR), the localisation engine supports any combination of the following in a LocalisableString:

Switching between a unicode and non-unicode string
localisation
formatting

This was intentional, but I'm not sure if this functionality is actually needed (and it complicates the current API a lot). How about the following instead:

Have LocalisableString handle localisation and formatting (again, any combination of the two, including none). This will allow something similar to osu-web's current localisation engine, where we could have "last_played": "Last played on {0}" in a translation file.
Have the "unicode preference" thing separated from the two, since (to my knowledge) this was only implemented for e.g. song titles which have names in e.g. kanji, and can be romanised instead (and don't need any kind of localisation).

This now works like this:
// unlocalised
sprite.Text = "Hello world!";
// localised
sprite.LocalisableText = "Hallo Welt!";
// LocalisationType.Localised is the default type now. same as line above
sprite.LocalisableText = new LocalisableString("Hallo Welt!") ;

I changed the implicit cast from string to be localised by default for convenience. For unlocalised text, the Text property still exists. I think it's okay to demand that the object implementing this creates a property to easily input unlocalised text.
I'd still like some kind of global "switch" though, where framework-side localisation can be disabled completely. Maybe a DummyLocalisationEngine.

Test cases need fixing

@peppy / @ekrctb I consider this PR to be complete now.
SpriteText.Text is now a LocalisableString. This is a type that has implicit operators to support:
text.Text = "hello world!" // Maintains backwards compatibility
text.Text = new LocalisableString("hello world!") // Provides formatting args/localisable toggle.

There are 0 heap allocations beyond the initial bindable for each spritetext.

Upon further discussion, LocalisedString handles unicode too:
new LocalisedString((original, fallback), arg1); // Unicode + fallback + args
new LocalisedString(original, arg1); // No fallback + args


Should awaiting a non-Promise value be an error?

TypeScript Version:
1.9.0-dev.20160426
Code
var x = await 5;

Currently this compiles just fine and behaves correctly at runtime. But is there a situation where the user would want to deliberately await a non-Promise? Or should it be a compiler error?

I thought of:

Normalizing a sync-or-async value:
declare function mayReturnSyncOrAsyncResult(): number | Promise<number>;

var result = await mayReturnSyncOrAsyncResult(); // number

Either await could still be allowed for unions that contain Promise, or the user could be required to use await Promise.resolve instead of just await.

Extracting the value of a thenable:
declare function foo(): bluebird.Promise<number>;

var result = await foo(); // number

Again await could still be allowed, or the user could be required to use await Promise.resolve

Deliberately introducing a yield point to make the rest of the function be a separate async continuation. I'm not sure if such a use actually exists in the wild. If it does exist, it too can be handled by await Promise.resolve

The downside of await Promise.resolve is that it introduces one extra Promise, since await will wrap the awaited value in one anyway.
I'm not completely convinced one way or the other. Opening this issue to get TS team's and other people's thoughts.

Alternatively I suppose we can make a tslint rule for "stricter awaits" or something.

But is there a situation where the user would want to deliberately await a non-Promise? Or should it be a compiler error?

Yes. When the API consumer wants a promise but the API provider doesn't need to be async. The provider code can then just await :rose:

instead of
function foo(){
      return Promise.resolve(3);
}

you get to
async function foo(){
      return await 3;
}

@basarat That should be return 3

That should be return 3

Indeed. Sorry. I know I should have been sleeping at that time :rose:

// CC @bterlson
I believe it is not an error to await a non-thenbale non-promise object. awaiting a literal as in the example should be equivalent to await Promise.resolve(3). @bterlson can point to the spec details.
one thing to note, var x = await 5; is not the same as var x = 5;; var x = await 5; will assign x 5 in the next tern, where as var x = 5; will evaluate immediately.

Yes, I said all that in the OP.

But is there a situation where the user would want to deliberately await a non-Promise

This is the heart of the question by @Arnavion ^.
Me : I can't think of a good reason. The only use case (next tern) is not one the user should be depending upon. There might be some obscure debounce style stuff that one can cook up :rose:

@bterlson, can you shed some light on the rational/motivating use cases for the current design?

Just some anecdotal info: I got unwanted behavior when writing my first TypeScript program, since in many libs the TS version uses *Async names for the Promise-returning version of the function.
So since the callback was optional, I "awaited" on void and then the program would continue too early...
So if there no real reason to keep this behavior, I can assure you that this has already created some bug (even though luckily only during development).

The goal of the current semantics isn't to allow uselessly awaiting known synchronous values but instead to allow awaiting maybe-promises and to align with the semantics of various existing promise utilities including Promise.resolve (promises and thenables unwrapped, values passed through) and then handlers (returned promises and thenables unwrapped, values passed through).

Thinking about this more, this could be enforced under a flag, by default if the compiler can attest that the type of await expression can not be a promise, then it should report an error, if the flag is set, the error reporting is skipped.

Main points from discussion:

Not necessarily clear this an error (maybe you intend to effectively yield)
What if the awaited expression is a type parameter? Not clear how to determine if that's an error or not
We clearly want to allow await T | Promise<T> (for reasons @bterlson mentioned above) but then it's weird to allow await Promise<T> but disallow await T since we're effectively saying either might happen

We can't tell that you definitely meant to not await any arbitrary value, so disallowing it isn't something we can do for certain.

but then it's weird to allow await Promise<T> but disallow await T since we're effectively saying either might happen

I dunno, atleast to me it doesn't seem weird.

Would be great if there was a flag for raising an error.

Rumor has it tslint is getting type-based rules in the near future thanks to some work from the Angular team, so that might be a good place to go.

Rumor has it tslint is getting type-based rules

Indeed it is. The reason why I've dropped my usage of ntypescript (which could support ts extension) and moved to a simpler automation of bring your own typescript : https://github.com/basarat/byots (as the extension can now be done using tslint) and also working on first class integration into alm : https://github.com/alm-tools/alm/issues/155 :rose:


Timezone oddities

Hi Christian,
I am not 100% sure where the issue lies. Basically Zimbra shows me a calendar entry at 15:00,
whereas khal shows it at 14:00. This is the ics entry (attendees stripped out):
BEGIN:VCALENDAR
VERSION:2.0
PRODID:Zimbra-Calendar-Provider
BEGIN:VTIMEZONE
TZID:GMT/+01.00
BEGIN:STANDARD
DTSTART:16010101T010000
TZOFFSETTO:-0000
TZOFFSETFROM:+0100
RRULE:FREQ=YEARLY;INTERVAL=1;BYMONTH=10;BYDAY=-1SU;WKST=MO
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:16010101T020000
TZOFFSETTO:+0100
TZOFFSETFROM:-0000
RRULE:FREQ=YEARLY;INTERVAL=1;BYMONTH=3;BYDAY=-1SU;WKST=MO
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
UID:bfcf13fe-3dc5-48ec-9fa0-b30bff5789dd
RRULE:FREQ=WEEKLY;INTERVAL=2;BYDAY=FR
SUMMARY:Call
DESCRIPTION:Call
ORGANIZER;CN=Michele<EMAIL_ADDRESS>DTSTART;TZID="GMT/+01.00":20150227T140000
DTEND;TZID="GMT/+01.00":20150227T143000
STATUS:CONFIRMED
CLASS:PUBLIC
TRANSP:OPAQUE
LAST-MODIFIED:20150217T071347Z
DTSTAMP:20150217T071347Z
SEQUENCE:5
BEGIN:VALARM
ACTION:DISPLAY
TRIGGER;RELATED=START:-PT5M
DESCRIPTION:Reminder
END:VALARM
END:VEVENT
END:VCALENDAR

In my config I do have:
[locale]
local_timezone= Europe/Berlin
default_timezone= Europe/Berlin

Am I missing something completely obvious here or is this another case of Zimbra funkiness?
Thanks and regards,
Michele

The above defined timezone is not equivalent to Europe/Berlin as it has an offset off zero or one hours to GMT (depending if it is daylight saving time), but Europe/Berlin has one or two hours offset.
Here is a valid Europe/Berlin example: http://tzurl.org/zoneinfo/Europe/Berlin.ics

Is this a cockup on my part or is it Zimbra being dense again? In my preferences on Zimbra I have timezone "GMT +1:00 Amsterdan, Berlin, Bern, Rome, ..." selected. Am I supposed to change it to something else or is this issue related to the fact ths this ics has non Olson DB Timezone?

to me it looks like a proper bug on zimbra's side. I can look into it next week.

Do you know which version of zimbra this was created with?

So the version I currently have is: Zimbra 8.0.6_GA_5922 (build<PHONE_NUMBER>3753)
It could be that the above calendar entry was created with an older version (of that I am not sure and have no means of verifying)

It looks like current versions of Zimbra produce valid VTIMEZONE components and I actually cannot find any hint that they were once broken.
The good news is, if you update icalendar, khal will (in)correctly show this event starting at 15:00.

Thanks so much! I confirm that updating to 3.9.0 fixes this and I see the event at 15:00 instead of 14:00


changed the styling of the div's on the homepage

Fixes #819
changed the styling of the div's on the homepage, now they look much more attractive
before

after

@khushi-joshi-05  check it out


v4.1.0-SNAPSHOT

This issue will be used to track changes between v4.0.0-SNAPSHOT and v4.1.0-SNAPSHOT. Once v4.1.0 is ready these changes will be posted as patch notes to the community.
Changes
Fixed

Vote link in /vote now works properly
/wild will now run asynchronously to reduce server lag on use
Legacy color codes will now work properly in chat/nicknames
Staff playtime should now be correct
Fixed hard coded height limit for things like teleportation and claims
Media rank can now only fly in claims they own or have access trust in
/homes now works when the player has no homes

Added

Added advancements in-game showing in discord #in-game
Added ability to use MiniMessage codes where you use other codes, ex. signs, chat, nicknames
/home <home> will now accept partial home names
Added the ability to trust a player on all your claims with /trust <player> all
Added /stack hotbar
Added a new in-chat emote: :tm: → ™
Chat formatting can now be used in /msg
When a player returns from AFK, they will receive a "While you were gone..." message with various events that happened when they were afk
Added /homes custom sorting, with /homes sort [sort-type]
Added a message on /movhome that shows the previous location of the home.
Added /bright command to media rank that gives night vision

Removed

Removed /top playtime no-staff, since staff playtime was reset with players
Removed /vanish command from media rank
Removed stacking of unstackable items within inventory (caused more bugs than worth it)

Backend

Switched from Gson to Moshi
Switched from NMS NBT to adventure-nbt
Converted TextUtils to adventure components and MiniMessage
Converted storage of custom items from JSON to NBT
Created new Pagination class for paginated components
Converted GUIs to use components

We're probably good to release these once #13 is merged and perhaps we add some more requirements.

I think this can probably be closed now...


add environment to current run config doesn't work for maven

The add environment is generic for all IDEs, the code is in the main module, but
Its not possible to use Maven plugin classes in modules other then the jvm module because rider does not include maven or gradle plugins.
to sole this issue we need a separation of the classes that use maven/gradle plugins to a dedicated service that will be installed only if these plugins exist.
this issue is related:
https://github.com/digma-ai/digma-intellij-plugin/issues/1616


feat: add mul_min and min_mul

The PR builds, but I keep getting the error "Post PR summary comment".
I tried to follow the suggestion in this Zulip thread to merge master, but it didn't fix the error.
It seems that others are having the same problem (e.g. #19017).
Anybody knows how to fix this?


please add mermaid support

VSCode Version: Code 1.19.0 (816be6780ca8bd0ab80314e11478c48c70d09383, 2017-12-14T12:06:43.492Z)
OS Version: Windows_NT x64 6.1.7601

Extension
Author (truncated)
Version

markdown-all-in-one
yzh
0.11.2

mermaid is used to wirte within markdown for graphic info. But I find this plugin does not support it. please add it.

I think Markdown Preview Mermaid Support might meet your need.
But in my view, mermaid is not too widely used is common Markdown context, I would like not to add it to this extension recently.

ok.
I love using markdown to write code document, but markdown is lack of tools in visual info. So I use mermaid.
Maybe Jupter Notebook is better.

Please see v3.0.0


build/170/update packages with vulnerabilities

What does this PR do?
UIpdate packages with vulnerabilities

Where should the reviewer start?
Since dependabot found some vulnerabilities here

How should this be manually tested?
Check the package.json

Any background context you want to provide?
https://github.com/wizeline/remix-project-lab/security/dependabot
Also this change will affect the current test we have

What are the relevant tickets?
#170

Screenshots

Questions

Checklist

[ ] I added the necessary documentation, if appropriate.
[ ] I added tests to prove that my fix is effective or my feature works.
[ ] I reviewed existing Pull Requests before submitting mine.

hahahaha, but why do we need to comment our tests? Is it mainly the cypress tests, right? But they were supposed to be working, no? @LuisTejedaS

hahahaha, but why do we need to comment our tests? Is it mainly the cypress tests, right? But they were supposed to be working, no? @LuisTejedaS

Hi @jackbravo, welcome back!
The tests are currently broken due to the last change done in the managers section haha. It was a huge change, so @martinrobled0 finished those changes and I am currently working on updating the tests to fit the current components

So i guess we are fine @juanan150 lets fix them as soon as we can

So, Can I merge this? @LuisTejedaS @juanan150


lucius: use a darker background for inactive statusline

This also provides more contrast to the tabline plugin, by better highlighting
the currently selected tab.

Does this fix #16? Also can you please add a screenshot, to show the effect?

Yes, this should fix #16.  Here are the screenshots, pay special attention to the tabline and the inactive status lines.
Lucius light, before patch:

Lucius light, after patch:

Lucius dark, before patch:

Lucius dark, after patch:

okay thanks. Merging then.


[Feature] User interface for Multi-cloud Block Service

Issue/Feature Description:
Create a user interface to support the Multi-cloud Block Device Management Service.
The Cloud Block Device should support:

AWS EBS
Azure Disk Storage
Google Cloud Storage

Multi-cloud block device management will provide:

Block Device creation/deletion/update
Block Device attach/detach to the compute
Snapshots of the block device for Lifecycle and data migration

Why this issue to fixed / feature is needed(give scenarios or use cases):
The basic idea behind adding block support is to create a Distributed Data Store(DDS) going ahead. Distributed across on-premise and cloud.  This block device support in multi-cloud is a step forward to achieve the DDS.
How to reproduce, in case of a bug:
Other Notes /  Environment Information: (Please give the env information, log link or any useful information for this issue)

This feature can be added in the next release of SODA.
@kumarashit @skdwriting


Update Sidebar to include the contributing guide for API

Description
Describe the changes that were made in this pull request. When possible start with the motivations behind the change. Be sure to also include the following information:

Motivation for change? doc-a-thon!
What was changed? Updated Sidebar to include the correct link for API contributing guide

Checklist

[X ] Conventional commits were used
[X] New links to files and images were verified
[ ] For fixes/refactors: all existing references were identified and replaced
[ ] Style guide was reviewed and applied
[ ] Clear code samples were provided
[X ] People were tagged for review

@saralab the files changed tab shows 0 changes in this PR 🤔 Have the commits already been merged in main?


New rule - "Use single quotes unless you need double quotes to enclose expressions or variables"

A warning should appear for strings that have double quotes with no expressions or variables.

Hi Zuldan.
We are focusing on adding functionality based rules to ScriptAnalyzer.
"Style" rules (such as using specific casing, syntax, quotes) need to be part of the community driven Style Rules, which can ship outside our core set of rules.

I would support this new rule!

I had the same thought and I like to support this rule as well especially it is not just a "style" rule, according to this site: Powershell and Single vs Double Quotes there is a performance difference. Quote:

double quotes is just over double the execution time of single quotes

In fact, if the string itself does not contain special characters like the space, dollar, backtick or single/double quotes then there is no need for a single quotes at all. The PowerShell parser was designed to not require quotes at all.
I agree that a rule against double quoted strings that are not necessary would be useful.

Good point!

@raghushantha I don't think this is a style-based rule, but one based on functionality.

@iRon7 (as discussed on Stack Overflow), while it makes good sense to use double quotes only when expansion is needed - for conceptual clarity and to avoid unwanted expansion -  there is virtually no performance difference; the test methodology of the linked blog post is flawed.

@bergmeister, warning against potentially unnecessary quotes (in argument mode) can get tricky, because the quotes may be needed in order to pass a "number-like thing" deliberately as a string; e.g., foo '42' passes a string, whereas foo 42 passes a number.
To avoid false positives, you'd have to analyze each quoted argument to see if PowerShell would not parse it as a number, and only then warn if the quotes make no difference.


Markdown & swagger generator are not in release packages

We are generating our documents using rdl. However, markdown and swagger generator plugin are not in release packages. There's only rdl itself in the packages.
It would be nice if you can help us putting them into release packages. We really need them.
Thank you.

Fixed in Release 1.4.11.