dns record removal

it worth mention that after the domain has been validated in the portal, the record can be removed from the dns

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 27249e0c-e601-b849-8404-ce0bb8155fce
Version Independent ID: a308f156-998b-8ea9-5668-7a59e549cd10
Content: Gather the information you need to create Office 365 DNS records
Content Source: Office365-Admin/get-help-with-domains/information-for-dns-records.md
Service: o365-administration
GitHub Login: @pebaum
Microsoft Alias: pebaum

@officedocsbot assign @mypil

@francescopoli - Thank you for submitting feedback.
I will get this issue over to the O365ITPro writing team for investigation.
Thank you for reporting and making the docs better. Much appreciated.
I made a note to request the team to update this when the work is complete.

@francescopoli Thank you for your feedback. We have added a step to remove the DNS records after they are verified in o365. This can be tracked under PR https://github.com/MicrosoftDocs/OfficeDocs-O365ITPro/pull/496
Regards
Sriraman MS

@francescopoli - From our understanding, the issue has been resolved but it may take a few days for the merged content to appear in the article. If you feel it hasn't been resolved, please re-open this issue.
Thank you for your contribution to make the docs better! Much appreciated!

@officedocsbot close


decoder fuzzer takes a long time

This is similar to https://github.com/openssl/openssl/issues/21645 but now the decoder is affected.
It takes sometimes here longer than 2 sec:
for i in $(ls ./default/{crashes,hangs}/* 2>/dev/null); do time ./*-test $i; echo; done
# ./default/hangs/id:000000,src:002573,time:242891731,execs:1156316028,op:havoc,rep:6

real    0m2.885s
user    0m2.858s
sys     0m0.008s

# ./default/hangs/id:000001,src:002573,time:243145483,execs:1157808208,op:havoc,rep:6

real    0m2.302s
user    0m2.271s
sys     0m0.011s

# ./default/hangs/id:000002,src:002573,time:252049047,execs:1199800434,op:havoc,rep:2

real    0m2.605s
user    0m2.564s
sys     0m0.008s

2 seconds is definitely fine. Otherwise we would have to limit the sizes of the decoded data in the fuzzer extremely.

ah - ok, so I'll increase the default here.
Thx.


Fix CI for missing py38 dependency

https://pypi.org/project/tensorflow-io-gcs-filesystem/0.35.0/#files


String.Empty is reported as not-initialized

From an internal email:
Do you know if there are known issues around the static field String.Empty? I have noticed both CLRMD and SOS seems to think it is uninitialized, but it definitely should be initialized afaik (i.e. looking in the heap there are literally millions of objects that reference it).
From a random dump I am looking at:
0:000> !DumpClass /d 729f4a50
Class Name:      System.String
mdToken:         02000073
File:            C:\WINDOWS\Microsoft.Net\assembly\GAC_32\mscorlib\v4.0_<IP_ADDRESS>__b77a5c561934e089\mscorlib.dll
Parent Class:    729715b0
Module:          72971000
Method Table:    72e1d6d8
Vtable Slots:    1b
Total Method Slots:  1d
Class Attributes:    102101
Transparency:        Transparent
NumInstanceFields:   2
NumStaticFields:     1
MT    Field   Offset                 Type VT     Attr    Value Name
72e1f52c  4000275        4         System.Int32  1 instance           m_stringLength
72e1e120  4000276        8          System.Char  1 instance           m_firstChar
72e1d6d8  400027a       54        System.String  0   shared   static Empty
>> Domain:Value  034ffd08:NotInit  <<
CLRMD also claims it is not initialized
However if I look at the backing CLR string object (which I suspect to refer to String.Empty)
class StringObject * 0x06201228
+0x000 m_pMethTab       : 0x72e1d6d8 MethodTable
+0x004 m_StringLength   : 0
+0x008 m_Characters     : [0]  ""
=74493300 EmptyStringRefPtr : 0x07202300  -> 0x06201228 StringObject
I am seeing the value referred to by EmptyStringRefptr EVERYWHERE (i.e. tons of objects that have internal string references have a string reference whose address is 0x06201228, so presumably they have had String.Empty assigned to that field. Is there something wacky/special that goes on with String.Empty where it can be assigned but the domain value is not initialized?

My reply:
It looks like SOS and ClrMD do not handle static variables that are in the shared domain.  This is an odd corner case in CLR.

@ryanmolden Added a test case for this issue, it's not fixed though.  This seems to be a problem in mscordacwks.dll.  I plan to do some work in .Net Core 5 to fix various issues, including this one.  Not sure if it'll be backported or not.

Duplicate of https://github.com/dotnet/diagnostics/issues/280, looks like it was fixed already.  Will resolve this issue.


Promote k3d status

Promote k3d status from In Development to Available.

@alefesta I had just noticed the conversation on the other issue. Apologies.

Great job @burntcarrot !!!


Test telemetry is only being sent for smoke and perf tests

All test logs that run in CI on main have "sending telemetry" logs, but the events in ADE only include the smoke and perf tests, so integration tests are not actually sending telemetry for some reason.
Integration test telemetry has a subset of the dimensions that perf tests have.
Perf test:
Sending telemetry event DS_INTERNAL.RUNTEST with dimensions {"testName":"Initial Notebook Cell Execution Perf Test","testResult":"passed","timedCheckpoints":"{\"0_pythonExtensionActivation\":879,\"1_jupyterExtensionActivation\":16183,\"2_notebookCreated\":31751,\"3_cellExecuted\":34491,\"totalTime\":34498}","commitHash":"ddcde9d29f8f8c391b46347b7dff6aed167a4e57"}
Integration test:
Sending telemetry event DS_INTERNAL.RUNTEST with dimensions {"testName":"List kernel specs", "testResult":"passed", "commitHash":"ddcde9d29f8f8c391b46347b7dff6aed167a4e57"}

The first event sent in a test run has a dynamic import error from within the vscode telemetry package, and could be caused by an issue with mocha https://stackoverflow.com/questions/64261239/mocha-tests-with-esm-support-for-native-es6-modules
I haven't been able to fix this with the solutions from that post, but we could look into alternatives with downloading test results artifacts from the github actions run.

@amunger
Please could you let me know what is required here?

Do we just need telemetry in our integration tests?
Do we just need LOGGING of telemetry in our integration tests and not have them sent?
Or is the issue the fact that we do have telemetry working, but are missing some additional information that we have in perf & smoke tests?

The telemetry being sent for each test result in the testHooks file is not actually making it off the box. I worked with Logan and Rick to get it working and wasn't able to, so I planned to just collect test run data from the CI artifacts instead.


Will it be published soon a new release for issue #28?

Good afternoon,
Will it be published soon an 'official' release fixing the issue #28? Are you waiting for other changes?
Thanks for your answers

Yes today or tomorrow.


prow.sh: only run alpha tests for latest Kubernetes release

Commit 7bcee13d79012 added alpha feature gates for Kubernetes 1.19 in
the CSI_PROW_E2E_ALPHA_GATES_LATEST variable based on the comment in
https://github.com/kubernetes-csi/external-provisioner/pull/493#discussion_r502663402
that alpha testing only runs for the latest Kubernetes.
But some components (like external-health-monitor) are configured with
a single Prow job which runs the default set of tests on a stable
Kubernetes release (currently 1.17). Those tests used to include alpha
testing which then broke during Kind cluster startup because the
Kubernetes 1.19 feature gates weren't recognized by 1.17.
The solution is to disable alpha testing for Kubernetes != latest in
the default set of tests.

/assign @msau42

Tested in https://prow.k8s.io/view/gs/kubernetes-jenkins/pr-logs/pull/kubernetes-csi_external-health-monitor/40/pull-kubernetes-csi-external-health-monitor/1321020191001284608

/release-note-none

/lgtm


Floatbar fixes and windows support

Allow more fine grained settings for X11 floatbar
Integrate old pr #3419 and extend with new command line settings
unify cmdline.c string to integer conversions and error checks

@freerdp-bot test

Tested the wfreerdp and xfreerdp parts. Both work. Windows has some (unrelated) problems though.

@hardening any objections?


Complete the XmlMapping tests for XSD validation in #6728

Fix the DDC889 tests which were failing after the removal of the related XML mapping files.
This commit restores them and also adds more mapping files to test.
Furthermore, a new test is added to check the invalid use cases with DOMDocument.

Thanks! I'll try to take a closer look tonight!


Uncaught TypeError: Cannot read property 'match' of undefined

Hi, is someone know how to fix this bug https://jsfiddle.net/ouwde3wd/ ?
It's show self if list contain a lot of identical strings (more than 50 or 100 or something like);
update 1.0: Last version of list.js fixed this error, but there is another problem, for now list not filter all list, just one string without 5 goes on top wher sort button is pressed.
p.s.s.  Thank you Jonny for this great extension!

@Hellek the problem is solved

Yeah, if you toggle asc/desc on a list with multiple occurrences of the same string it won't flip the sorting order completely, I'm sorry but that is not a prioritised issue right now and I don't have a clear ide exactly how to solve it in a nice way.
But I'm glad that you like List.js anyways! :D

I have solved it! Just cannot merge for now. Would you have interest in the
solution?
4 февр. 2017 г. 5:33 PM пользователь "Jonny Strömberg" <
<EMAIL_ADDRESS>написал:

Yeah, if you toggle asc/desc on a list with multiple occurrences of the
same string it won't flip the sorting order completely, I'm sorry but that
is not a prioritised issue right now and I don't have a clear ide exactly
how to solve it in a nice way.
But I'm glad that you like List.js anyways! :D
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/javve/list.js/issues/433#issuecomment-277449607, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AF9QT_0M_0ZNtY82feBIWLdHdBls23BMks5rZIxOgaJpZM4JPPnK
.

@EugeneTM The problem not actual. I forget how i solve it, i can suggest that i update list.js to latest version. Anyway if my suggestion is wrong it would be a great if you share your solution with community))

Is it fixed in current version? I have this problem and don't know how to fix it, if anyone has a idea... Thanks


⚠ ClamAV has degraded performance

In e8f35a9, ClamAV (https://spamassassin.apache.org/) experienced degraded performance:

HTTP code: 200
Response time: 584 ms

Resolved: ClamAV performance has improved in 4cd1ca1.


dependabot for github-actions

Pull Request Test Coverage Report for Build<PHONE_NUMBER>2
Details

5 of 5 (100.0%)  changed or added relevant lines in 3 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 91.875%

Totals

Change from base Build<PHONE_NUMBER>3:
0.0%

Covered Lines:
1357

Relevant Lines:
1477

💛  - Coveralls


ENH: stats: add noncentral hypergeometric distributions (Fisher's and Wallenius')

Reference issue

gh-12288
and mailing list discussions
What does this implement/fix?

This adds Fisher's noncentral hypergeometric distribution. It will be useful in gh-13340.
It also adds Wallenius' non-central hypergeometric distribution, which was requested on the mailing list.
Additional information
The implementations are from the BiasedUrn package, which is usually distributed under the GPL license, but we have written permission from the author, Agner Fog, to distribute this version of the software under SciPy's license. Thanks @mckib2 for the wrapper!

biasedurn.cxx is a generated file, should probably be removed and ignored

biasedurn.cxx is a generated file, should probably be removed and ignored

Interesting error:
Error compiling Cython file:
------------------------------------------------------------
...
from numpy.random cimport bitgen_t
^
------------------------------------------------------------

biasedurn.pxd:1:0: 'numpy/random.pxd' not found

numpy.get_includes() is added in the include_dirs, I wonder why it's not available when the CI tries to build it.

Interesting error:
Error compiling Cython file:
------------------------------------------------------------
...
from numpy.random cimport bitgen_t
^
------------------------------------------------------------

biasedurn.pxd:1:0: 'numpy/random.pxd' not found

numpy.get_includes() is added in the include_dirs, I wonder why it's not available when the CI tries to build it.

@mckib2 Any ideas about the new failure on macOS?

@mckib2 Any ideas about the new failure on macOS?

@mckib2 Any ideas about the new failure on macOS?

Yep, I can see what the error is and it makes sense, but I'm confused why we weren't getting it before. I'll have to dig more into this tomorrow

@mckib2 Any ideas about the new failure on macOS?

Yep, I can see what the error is and it makes sense, but I'm confused why we weren't getting it before. I'll have to dig more into this tomorrow

@mckib2

biasedurn.pxd:1:0: 'numpy/random.pxd' not found

Does this happen with Numpy 1.17? I had the same problem some time ago and Matti Picus replied to my question on the mailing list (SciPy-Dev Digest, Vol 195, Issue 13): The new random c-api was broken in NumPy 1.17. Please try with NumPy 1.18.
In my PR #11954, I just skip the test if the numpy version is < 1.18.

@mckib2

biasedurn.pxd:1:0: 'numpy/random.pxd' not found

Does this happen with Numpy 1.17? I had the same problem some time ago and Matti Picus replied to my question on the mailing list (SciPy-Dev Digest, Vol 195, Issue 13): The new random c-api was broken in NumPy 1.17. Please try with NumPy 1.18.
In my PR #11954, I just skip the test if the numpy version is < 1.18.

@chrisb83 This is probably what's going on.  Probably the easiest thing to do here is follow @rkern 's advice and vendor the bitgen_t definition until numpy 1.17 is deprecated.  @mdhaber  I would suggest creating a new random.pxd file with the following:
# vendored from https://github.com/numpy/numpy/blob/master/numpy/random/__init__.pxd
# Please use `from numpy.random cimport bitgen_t` after numpy 1.17 is deprecated
from libc.stdint cimport uint32_t, uint64_t

cdef extern from "numpy/random/bitgen.h":
    struct bitgen:
        void *state
        uint64_t (*next_uint64)(void *st) nogil
        uint32_t (*next_uint32)(void *st) nogil
        double (*next_double)(void *st) nogil
        uint64_t (*next_raw)(void *st) nogil

    ctypedef bitgen bitgen_t

Then replace all instances of from numpy.random cimport bitgen_t in biasedurn.pyx and biasedurn.pxd with from random cimport bitgen_t.  Let me know if you run into any trouble and I can see if I can get it to work.

@chrisb83 This is probably what's going on.  Probably the easiest thing to do here is follow @rkern 's advice and vendor the bitgen_t definition until numpy 1.17 is deprecated.  @mdhaber  I would suggest creating a new random.pxd file with the following:
# vendored from https://github.com/numpy/numpy/blob/master/numpy/random/__init__.pxd
# Please use `from numpy.random cimport bitgen_t` after numpy 1.17 is deprecated
from libc.stdint cimport uint32_t, uint64_t

cdef extern from "numpy/random/bitgen.h":
    struct bitgen:
        void *state
        uint64_t (*next_uint64)(void *st) nogil
        uint32_t (*next_uint32)(void *st) nogil
        double (*next_double)(void *st) nogil
        uint64_t (*next_raw)(void *st) nogil

    ctypedef bitgen bitgen_t

Then replace all instances of from numpy.random cimport bitgen_t in biasedurn.pyx and biasedurn.pxd with from random cimport bitgen_t.  Let me know if you run into any trouble and I can see if I can get it to work.

Thanks @chrisb83 @mckib2 I'll try that!

Thanks @chrisb83 @mckib2 I'll try that!

Let me know if you run into any trouble...

I'm getting
Error compiling Cython file:
------------------------------------------------------------
...
from random cimport bitgen_t
^
------------------------------------------------------------

biasedurn.pxd:1:0: 'random.pxd' not found
...

Probably easy for you... : )

Let me know if you run into any trouble...

I'm getting
Error compiling Cython file:
------------------------------------------------------------
...
from random cimport bitgen_t
^
------------------------------------------------------------

biasedurn.pxd:1:0: 'random.pxd' not found
...

Probably easy for you... : )

Probably easy for you...
We'll see...  I'd try two things in this order:

make it a relative import, i.e. from .random cimport bitgen_t
add the current directory to the include_dirs in setup.py

Probably easy for you...
We'll see...  I'd try two things in this order:

make it a relative import, i.e. from .random cimport bitgen_t
add the current directory to the include_dirs in setup.py

Thanks! Fingers crossed!

Thanks! Fingers crossed!

Still have a similar numpy/random/bitgen.h issues.  numpy version in this case is 1.16.5, so this header must not exist <18.  I'm looking at a solution now and will make PR into your branch if I find a solution @mdhaber

Still have a similar numpy/random/bitgen.h issues.  numpy version in this case is 1.16.5, so this header must not exist <18.  I'm looking at a solution now and will make PR into your branch if I find a solution @mdhaber

I'm going to do a clean build with numpy==1.16.5 to see if I can reproduce the crashes.

I'm going to do a clean build with numpy==1.16.5 to see if I can reproduce the crashes.

Thank you!

Thank you!

I think we're getting closer -- a lot of the CI errors will be solved by my review comments above.  There are still some crashes though that I'm not able to reproduce on my machine.  I'll have to look at this more tomorrow evening

I think we're getting closer -- a lot of the CI errors will be solved by my review comments above.  There are still some crashes though that I'm not able to reproduce on my machine.  I'll have to look at this more tomorrow evening

In addition to using the naive Wallenius implementation in the tests (which sounds like it is not completely reliable), we can precompute Wallenius data using mpmath, e.g.:
import mpmath

def support(M, n, N):
    return range(max(0, N - (M - n)), min(N, n) + 1)

def wallenius_pmf(k, M, n, N, nc):
    with mpmath.extradps(5):
        nc = mpmath.mpf(nc)
        c1 = mpmath.binomial(n, k)
        c2 = mpmath.binomial(M - n, N - k)
        D = mpmath.mpf(nc*(n - k) + (M - n - (N - k)))
        c3 = mpmath.quad(lambda t: (mpmath.power(1 - mpmath.power(t, nc/D), k)
                                    * mpmath.power(1 - mpmath.power(t, 1/D), N - k)),
                         [0, 1])
        return c1 * c2 * c3

def wallenius_mean_var(M, n, N, nc):
    sup = support(M, n, N)
    pmf = [wallenius_pmf(k, M, n, N, nc) for k in sup]
    mean = mpmath.fsum(p*k for (p, k) in zip(pmf, sup))
    var = mpmath.fsum(p*k**2 for (p, k) in zip(pmf, sup)) - mean**2
    return mean, var

We can use those functions to compute some Wallenius distribution data to full 64 bit precision, e.g.
In [285]: import mpmath

In [286]: mpmath.mp.dps = 100

In [287]: M = 50
In [288]: n = 30
In [289]: N = 20
In [290]: odds = 2.25

In [291]: sup = support(M, n, N)

In [292]: sup
Out[292]: range(0, 21)

In [293]: [float(wallenius_pmf(k, M, n, N, odds)) for k in sup]
Out[293]:
[3.699003068656875e-20,
 5.89398584245431e-17,
 2.1594437742911123e-14,
 3.221458044649955e-12,
 2.4658279241205077e-10,
 1.0965862603981212e-08,
 3.057890479665704e-07,
 5.622818831643761e-06,
 7.056482841531681e-05,
 0.000618899425358671,
 0.003854172932571669,
 0.01720592676256026,
 0.05528844897093792,
 0.12772363313574242,
 0.21065898367825722,
 0.24465958845359234,
 0.1955114898110033,
 0.10355390084949237,
 0.03414490375225675,
 0.006231989845775931,
 0.0004715577304677075]

In [294]: [float(stat) for stat in wallenius_mean_var(M, n, N, odds)]
Out[294]: [14.808018384813426, 2.6085975877923717]

Then put that data into a test:
def test_wallenius_against_mp():
    M = 50
    n = 30
    N = 20
    odds = 2.25
    # Expected results, computed with mpmath.
    sup = np.arange(21)
    pmf = np.array([3.699003068656875e-20,
                    5.89398584245431e-17,
                    2.1594437742911123e-14,
                    3.221458044649955e-12,
                    2.4658279241205077e-10,
                    1.0965862603981212e-08,
                    3.057890479665704e-07,
                    5.622818831643761e-06,
                    7.056482841531681e-05,
                    0.000618899425358671,
                    0.003854172932571669,
                    0.01720592676256026,
                    0.05528844897093792,
                    0.12772363313574242,
                    0.21065898367825722,
                    0.24465958845359234,
                    0.1955114898110033,
                    0.10355390084949237,
                    0.03414490375225675,
                    0.006231989845775931,
                    0.0004715577304677075])
    mean = 14.808018384813426
    var = 2.6085975877923717

    # wnch.pmf returns 0 for pmf(0) and pmf(1), and pmf(2)
    # has only three digits of accuracy (~ 2.1511e-14).
    assert_allclose(wnch.pmf(sup, M, n, N, odds), pmf,
                    rtol=1e-13, atol=1e-13)
    assert_allclose(wnch.mean(M, n, N, odds), mean, rtol=1e-13)
    assert_allclose(wnch.var(M, n, N, odds), var, rtol=1e-11)

In addition to using the naive Wallenius implementation in the tests (which sounds like it is not completely reliable), we can precompute Wallenius data using mpmath, e.g.:
import mpmath

def support(M, n, N):
    return range(max(0, N - (M - n)), min(N, n) + 1)

def wallenius_pmf(k, M, n, N, nc):
    with mpmath.extradps(5):
        nc = mpmath.mpf(nc)
        c1 = mpmath.binomial(n, k)
        c2 = mpmath.binomial(M - n, N - k)
        D = mpmath.mpf(nc*(n - k) + (M - n - (N - k)))
        c3 = mpmath.quad(lambda t: (mpmath.power(1 - mpmath.power(t, nc/D), k)
                                    * mpmath.power(1 - mpmath.power(t, 1/D), N - k)),
                         [0, 1])
        return c1 * c2 * c3

def wallenius_mean_var(M, n, N, nc):
    sup = support(M, n, N)
    pmf = [wallenius_pmf(k, M, n, N, nc) for k in sup]
    mean = mpmath.fsum(p*k for (p, k) in zip(pmf, sup))
    var = mpmath.fsum(p*k**2 for (p, k) in zip(pmf, sup)) - mean**2
    return mean, var

We can use those functions to compute some Wallenius distribution data to full 64 bit precision, e.g.
In [285]: import mpmath

In [286]: mpmath.mp.dps = 100

In [287]: M = 50
In [288]: n = 30
In [289]: N = 20
In [290]: odds = 2.25

In [291]: sup = support(M, n, N)

In [292]: sup
Out[292]: range(0, 21)

In [293]: [float(wallenius_pmf(k, M, n, N, odds)) for k in sup]
Out[293]:
[3.699003068656875e-20,
 5.89398584245431e-17,
 2.1594437742911123e-14,
 3.221458044649955e-12,
 2.4658279241205077e-10,
 1.0965862603981212e-08,
 3.057890479665704e-07,
 5.622818831643761e-06,
 7.056482841531681e-05,
 0.000618899425358671,
 0.003854172932571669,
 0.01720592676256026,
 0.05528844897093792,
 0.12772363313574242,
 0.21065898367825722,
 0.24465958845359234,
 0.1955114898110033,
 0.10355390084949237,
 0.03414490375225675,
 0.006231989845775931,
 0.0004715577304677075]

In [294]: [float(stat) for stat in wallenius_mean_var(M, n, N, odds)]
Out[294]: [14.808018384813426, 2.6085975877923717]

Then put that data into a test:
def test_wallenius_against_mp():
    M = 50
    n = 30
    N = 20
    odds = 2.25
    # Expected results, computed with mpmath.
    sup = np.arange(21)
    pmf = np.array([3.699003068656875e-20,
                    5.89398584245431e-17,
                    2.1594437742911123e-14,
                    3.221458044649955e-12,
                    2.4658279241205077e-10,
                    1.0965862603981212e-08,
                    3.057890479665704e-07,
                    5.622818831643761e-06,
                    7.056482841531681e-05,
                    0.000618899425358671,
                    0.003854172932571669,
                    0.01720592676256026,
                    0.05528844897093792,
                    0.12772363313574242,
                    0.21065898367825722,
                    0.24465958845359234,
                    0.1955114898110033,
                    0.10355390084949237,
                    0.03414490375225675,
                    0.006231989845775931,
                    0.0004715577304677075])
    mean = 14.808018384813426
    var = 2.6085975877923717

    # wnch.pmf returns 0 for pmf(0) and pmf(1), and pmf(2)
    # has only three digits of accuracy (~ 2.1511e-14).
    assert_allclose(wnch.pmf(sup, M, n, N, odds), pmf,
                    rtol=1e-13, atol=1e-13)
    assert_allclose(wnch.mean(M, n, N, odds), mean, rtol=1e-13)
    assert_allclose(wnch.var(M, n, N, odds), var, rtol=1e-11)

This generates the wrapper for biasedurn based on the version of numpy that is installed when scipy is built.  How will this work when a user installs scipy from a binary wheel, and we don't know which version of numpy will be installed?  (Sorry if I missed something, I'm still looking into the wrapper generator code.)

This generates the wrapper for biasedurn based on the version of numpy that is installed when scipy is built.  How will this work when a user installs scipy from a binary wheel, and we don't know which version of numpy will be installed?  (Sorry if I missed something, I'm still looking into the wrapper generator code.)

This generates the wrapper for biasedurn based on the version of numpy that is installed when scipy is built. How will this work when a user installs scipy from a binary wheel, and we don't know which version of numpy will be installed?

Yes, I hadn't considered this.  Probably the safest option is to build wheels with the lowest guaranteed (currently numpy==1.16.5) and then switch over to the new random C API when numpy==1.18 is guaranteed.  We'd also need to conditionally implement np.random.Generator for the "old numpy" code. I'm unhappy that we'd have to give users of latest numpy an inferior implementation, but I don't see a way around it.
Do you know off the top of your head if there's an API to get the lowest required numpy for scipy?

This generates the wrapper for biasedurn based on the version of numpy that is installed when scipy is built. How will this work when a user installs scipy from a binary wheel, and we don't know which version of numpy will be installed?

Yes, I hadn't considered this.  Probably the safest option is to build wheels with the lowest guaranteed (currently numpy==1.16.5) and then switch over to the new random C API when numpy==1.18 is guaranteed.  We'd also need to conditionally implement np.random.Generator for the "old numpy" code. I'm unhappy that we'd have to give users of latest numpy an inferior implementation, but I don't see a way around it.
Do you know off the top of your head if there's an API to get the lowest required numpy for scipy?

An API for the lowest numpy?  Not that I know of.

An API for the lowest numpy?  Not that I know of.

@WarrenWeckesser According to release docs wheels are always built with the lowest version of numpy supported, so as long as that is actually the case (which I think it is) then compatibility should not be a problem.  Those who build from source with a more recent version of numpy installed get a better implementation while wheels remain unbroken for any supported version of numpy.

@WarrenWeckesser According to release docs wheels are always built with the lowest version of numpy supported, so as long as that is actually the case (which I think it is) then compatibility should not be a problem.  Those who build from source with a more recent version of numpy installed get a better implementation while wheels remain unbroken for any supported version of numpy.

@mckib2, to be honest, I'm not sure how much of a problem the current approach is.  For example, I don't know if a Linux distribution might build its scipy package with a newer version of numpy and still expect it to work with older (but still supported by scipy) numpy versions.  Perhaps @rgommers or @tylerjereddy can chime in: what problems, if any, will we run into if the wrapper of the biasedurn code is based on the version of numpy that is installed when scipy is built?  Can we expect any binary scipy package (that is released for distribution somehow) to have been built with the oldest supported numpy?  If not, are there users who will end up trying to run a scipy built with a newer numpy on a system with an older numpy?

@mckib2, to be honest, I'm not sure how much of a problem the current approach is.  For example, I don't know if a Linux distribution might build its scipy package with a newer version of numpy and still expect it to work with older (but still supported by scipy) numpy versions.  Perhaps @rgommers or @tylerjereddy can chime in: what problems, if any, will we run into if the wrapper of the biasedurn code is based on the version of numpy that is installed when scipy is built?  Can we expect any binary scipy package (that is released for distribution somehow) to have been built with the oldest supported numpy?  If not, are there users who will end up trying to run a scipy built with a newer numpy on a system with an older numpy?

@mckib2, to be honest, I'm not sure how much of a problem the current approach is. For example, I don't know if a Linux distribution might build its scipy package with a newer version of numpy and still expect it to work with older (but still supported by scipy) numpy versions.

That won't work. @mckib2 is correct here, we always build against the lowest supported NumPy version, and then those wheels will work with any later version.

@mckib2, to be honest, I'm not sure how much of a problem the current approach is. For example, I don't know if a Linux distribution might build its scipy package with a newer version of numpy and still expect it to work with older (but still supported by scipy) numpy versions.

That won't work. @mckib2 is correct here, we always build against the lowest supported NumPy version, and then those wheels will work with any later version.

Thanks Ralf.  I understood that our wheels are built with the oldest supported numpy, but I wasn't sure if anyone out in the wild would expect a binary scipy package that was built with a newer numpy would still work with an older (but supported) version of numpy.  If that is not something that any scipy packagers should expect, then it looks like approach taken here is fine.

Thanks Ralf.  I understood that our wheels are built with the oldest supported numpy, but I wasn't sure if anyone out in the wild would expect a binary scipy package that was built with a newer numpy would still work with an older (but supported) version of numpy.  If that is not something that any scipy packagers should expect, then it looks like approach taken here is fine.

From a quick look at this, I think it's perfectly fine build-wise.
One question: won't users see a behaviour change at the point where our minimum numpy version becomes high enough that we build wheels with the new C API, even if they give an explicit seed? That is actually fine imho, the new numpy.random API explicitly doesn't guarantee reproducibility between releases - but it's different from all of the other stats distributions we have, so it would be good to document that in the Notes section of the relevant docstring.

From a quick look at this, I think it's perfectly fine build-wise.
One question: won't users see a behaviour change at the point where our minimum numpy version becomes high enough that we build wheels with the new C API, even if they give an explicit seed? That is actually fine imho, the new numpy.random API explicitly doesn't guarantee reproducibility between releases - but it's different from all of the other stats distributions we have, so it would be good to document that in the Notes section of the relevant docstring.

Thanks Ralf. I understood that our wheels are built with the oldest supported numpy, but I wasn't sure if anyone out in the wild would expect a binary scipy package that was built with a newer numpy would still work with an older (but supported) version of numpy. If that is not something that any scipy packagers should expect, then it looks like the approach taken here is fine.

No that won't work, numpy does a check on API version on import, and it will give an exception if a user happens to try this.

Thanks Ralf. I understood that our wheels are built with the oldest supported numpy, but I wasn't sure if anyone out in the wild would expect a binary scipy package that was built with a newer numpy would still work with an older (but supported) version of numpy. If that is not something that any scipy packagers should expect, then it looks like the approach taken here is fine.

No that won't work, numpy does a check on API version on import, and it will give an exception if a user happens to try this.

Is there a reason why this shouldn't work?
gausshyper.rvs(3, 3, [[.1], [100], [1000]], 1, size=(5))

?
I would think that the parameters would be broadcast to shape (3, 1). This should be broadcastable with size (5). I would expect the output to have shape (3, 5).

Is there a reason why this shouldn't work?
gausshyper.rvs(3, 3, [[.1], [100], [1000]], 1, size=(5))

?
I would think that the parameters would be broadcast to shape (3, 1). This should be broadcastable with size (5). I would expect the output to have shape (3, 5).

If that worked, you would get an output that is larger than the requested size.  I think the intent of the API (inherited from the numpy random variate generators) is that size, if given explicitly, is the exact output size desired, and the function shouldn't return something bigger.

If that worked, you would get an output that is larger than the requested size.  I think the intent of the API (inherited from the numpy random variate generators) is that size, if given explicitly, is the exact output size desired, and the function shouldn't return something bigger.

Yeah I was just looking at the comments:
The rule is that, if size
is given, it determines the shape of the output.  Broadcasting
can't change the output size.

Yeah I was just looking at the comments:
The rule is that, if size
is given, it determines the shape of the output.  Broadcasting
can't change the output size.

@mckib2 can you help me with:

[ ] Replacing c_fnch with c_wnch
[ ] RuntimeError: No normal generator found!
[ ] The logic for NPY_OLD

I think the rest have been addressed.

@mckib2 can you help me with:

[ ] Replacing c_fnch with c_wnch
[ ] RuntimeError: No normal generator found!
[ ] The logic for NPY_OLD

I think the rest have been addressed.

@mdhaber Yes, I can take a look at these later this evening or tomorrow.  I wasn't aware that the normal generator should ever be called, so it was left unimplemented -- but shouldn't be too much trouble to add

@mdhaber Yes, I can take a look at these later this evening or tomorrow.  I wasn't aware that the normal generator should ever be called, so it was left unimplemented -- but shouldn't be too much trouble to add

Thanks @mckib2!
@WarrenWeckesser i think we've addressed your comments.

@WarrenWeckesser Done!

Thanks @mdhaber.
If there are no additional changes requested by then, I'll merge this on Monday.

I'm not opposed to a different public names for these (assuming it's ok to leave the private names alone. I actually think nchypergeom_f and nchypergeom_w would be more consistent with existing naming conventions (e.g. nc + t/f, gumbel + _l/_r). If you think this is something that should be opened up to the mailing list, please go ahead.

The current names, fnch and wnch, are at the extreme end of the brevity scale.  At the other extreme--if you're not into the whole brevity thing--we might have fisher_noncentral_hypergeometric and wallenius_noncentral_hypergeometric.  I agree that it is reasonable to use nc for "noncentral".  The hypergeometric and negative hypergeometric distributions are hypergeom and nhypergeom, resp., so there is precedent for truncating hypergeometric to hypergeom.  So we might consider fisher_nchypergeom and wallenius_nchypergeom, or  nchypergeom_f and nchypergeom_w (as @mdhaber suggested above), or nchypergeom_fisher and nchypergeom_wallenius.  (FWIW, the advantage of putting nchypergeom first is that the distributions will show up next to each other in an alphabetical list.)  I don't have a strong preference.  Anyone else care to comment?

or nchypergeom_fisher and nchypergeom_wallenius.

These seem reasonable, and there's other nc* functions.
Most other ones are okay too, except for fnch/wnch - that's way too cryptic.

On Feb 16, 2021, at 12:25 PM, Ralf Gommers<EMAIL_ADDRESS>wrote:

or nchypergeom_fisher and nchypergeom_wallenius.

These would have my vote, towards the longer end of my preference but seems necessary to disambiguate. I agree on the ‘nc*’ part too, we’ve got “nct” already.

These seem reasonable, and there's other nc* functions.
Most other ones are okay too, except for fnch/wnch - that's way too cryptic.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

@WarrenWeckesser names changed.

I forget why the r was added at some point. I think I was trying to debug something and that was an incorrect guess that didn't go away.

We just need to add invalid parameters to the invdiscrete list. I can do it later tonight, and I'll make a note in the "adding a distribution" guide about it.

That should do it @WarrenWeckesser.

Merged 🎉 .  Thanks @mdhaber and @mckib2!

I added a brief note to the SciPy 1.7.0 release notes.  Feel free to copy-edit and say more if you think it needs it.

Stubs are fine for now. We'll have a lot to report in the 1.7 notes so we can unify and polish as release approaches. Thanks @WarrenWeckesser!

Is there any plan of adding a wrapper for multivariate cases of the two distributions added it this PR? AFAIU most of the code for them is already here.

It looks like it would be pretty easy, but I don't plan on it any time soon. PR would be welcome, I think. You might email the mailing list about it to see if you can get other interest and find someone who can review.


DE - Received results with invalid Specimen Type - 10/5/23

Problem Statement
We received a request in the ReportStream inbox to investigate some results received by the Delaware Division of Public Health today that contained improper specimen types for the selected device.
What you need to know
Initial message received:

The Delaware Division of Public Health received two (2) laboratory records and would like to confirm the specimen source and test type (Antigen/Antibody):
Reporting Lab: PRIME
Requesting Org: Any Facility USA
Ordering Practitioner: Moshe Smith
Date Reported: 10/05/2023
Note: The specimen source for the reported records is “Dried blood spot specimen” with “Antigen” as test type. Typically, when a blood is the specimen source of a sample, the test type is “Antibody”.
Would you please advise?

Following exhaustive research with the assistance of Tanea and Sharon, we were unable to determine the cause of the issue or even find the message in question with the provided details. I requested additional information and received:

Message ID:
275782***20231005085945

This did not provide any results, regardless of where we searched (ReportStream, SimpleReport, Metabase for each), and we are unable to determine the source of the results or the source of the message they received. They provided this information when asked to confirm that the data was coming from ReportStream:

It is being sent through PRIME.
MSH below:
Any lab USA^24D5417759^CLIA-CDC PRIME - Atlanta,^2.16.840.1.114<IP_ADDRESS>821^ISO

Although this is a malformed MSH segment, I did try looking up the CLIA number and did not get any results from our systems or the CDC CLIA Search tool.
Acceptance Criteria

Identify the source of the message received by DE and resolve the cause of invalid specimen types being transmitted.

To Do

Confirm the message came from ReportStream and locate that file
Review the file's history and determine where the issue occurred

Additional Comments
Sharon, Tanea, and I performed an extensive investigation into this request and were unable to find the results they received from us with this issue. If you need any additional information regarding our troubleshooting steps prior to escalation, please let me know and I would be happy to provide as much detail as possible.

Christopher,
I am trying to look for the message with message ID below.  I can't find any in our database.
Message ID:
275782***20231005085945
Would you please give exact MessageID/MSH-10?
Very respectfully
-Ott Sathngam
CDC ReportStream Engineer

I am looking at the following information provided.  It seems like those two messages are not production messages.  They are sample/fake messages that are used for testing.
Reporting Lab: PRIME
Requesting Org: Any Facility USA   <---- This is from our test message template
Ordering Practitioner: Moshe Smith
Date Reported: 10/05/2023


Consider updating README with links to your examples

I've been reading through the paper and got sucked into reading the peer review content as well 😅. What a journey, and nice work!
https://github.com/b-shields/edbo/blob/master/examples/deoxyfluorination_optimization/optimization.ipynb
https://github.com/b-shields/edbo/blob/master/examples/mitsunobu_optimization/optimization.ipynb
I think including links to above in the README would help with visibility

Some basic usage instructions on the README (or the docs) using a toy example / dummy data showing class instantiation and fitting might also be worth considering.


Implement AssignE

We will need to create a Project model first. Currently the design is bad. Project is being represented as an attribute of the Employee model. What if you intend to add attributes to a project, such as deadline which we discussed. It would not be proper to add a deadline attribute under the Employee model, as that violates the SoC principle. The only way to achieve that requirement is to first create a Project model and then add a deadline attribute under it. The more features we add before implementing the Project model, the harder it will be to implement later on (will lead to extra time and effort required). With that being said, I am disinclined to approve this PR.

Currently Employee stores an empty Project that only has a name just for ease of UI purposes, and we can directly add deadline attribute to the Project class. Perhaps it was misleading that Project and UniqueProjectList are under the employee folder. I'll move them to a separate folder instead.


Failed to load class Google\Cloud\Firestore\FirestoreClient used by typed property Kreait\Firebase\Firestore::$client during preloading

Describe the issue you are experiencing
Hi there,
I'm getting this error, when i apply  composer dump-autoload -o --no-dev or  composer dump-autoload --classmap-authoritative --no-dev during the build of my container and i run it but when i apply composer dump-autoload -o  it works perfectly.
I only use cloud messaging service.
Thanks.
Installed packages

kreait/firebase-bundle 2.4

PHP version and extensions

PHP 8.0
API Platform
Docker

Error message/Stack trace
NOTICE: PHP message: PHP Fatal error:  Failed to load class Google\Cloud\Firestore\FirestoreClient used by typed property Kreait\Firebase\Firestore::$client during preloading in Unknown on line 0

It's solved, it was a symfony environment problem.

@blt909 Thanks, I think I'm encountering a different issue then, because the env is built and warmed up in my case, and the error appears only when using opcache.preload=/app/config/preload.php in php-fpm. My current workaround is to not use preloading at all, which isn't ideal.
I will debug some more to find what is my issue.

I found a workaround by configuring public: false inside firebase.yaml.
This way Symfony did not include anymore the unused Kreait\Firebase\Firestore class in the preload script.
I suppose it would be nice to avoid this issue, by having public: false by default, or have an option to enable each service separately?


Add in select command to in.txt

The in.txt associated with release 0.5 includes:
select
select junk
select radius
select catalog
select table
In order to improve code coverage with the Piston-Cylinder problem, it will likely be necessary to build standard size tables and catalogs.  Also, it may be necessary to build new command syntax in order to avoid prompting within select.js.
Defer ?

After discussion, we have decided to defer further activity on this issue until the spring design problem is available.


GraphQL language server has stopped

I'd like to provide some more information or troubleshoot but I'm not sure how to. I found no way of debugging externally installed plugins.
I'd be glad for any directions investigating this, thanks.
@playlyfe/gql: 2.3.2
vscode: 1.16.0

Trying to setup this plugin locally the server errors out:
> tsc -p src/server

src/server/server.ts(57,25): error TS2345: Argument of type '(params: InitializeParams) => Thenable<InitializeResult | ResponseError<InitializeError>>' is not assignable to parameter of type 'RequestHandler<InitializeParams, InitializeResult, InitializeError>'.
  Type 'Thenable<InitializeResult | ResponseError<InitializeError>>' is not assignable to type 'HandlerResult<InitializeResult, InitializeError>'.
    Type 'Thenable<InitializeResult | ResponseError<InitializeError>>' is not assignable to type 'Thenable<ResponseError<InitializeError>>'.
      Type 'InitializeResult | ResponseError<InitializeError>' is not assignable to type 'ResponseError<InitializeError>'.
        Type 'InitializeResult' is not assignable to type 'ResponseError<InitializeError>'.
          Property 'code' is missing in type 'InitializeResult'.

when trying to only compile the client I get this:
node_modules/vscode-languageclient/lib/client.d.ts(4,139): error TS2305: Module '"/Users/krokofant/GitHub/graphql-for-vscode/node_modules/vscode/vscode"' has no exported member 'ProviderResult'.
node_modules/vscode-languageclient/lib/client.d.ts(4,706): error TS2305: Module '"/Users/krokofant/GitHub/graphql-for-vscode/node_modules/vscode/vscode"' has no exported member 'WorkspaceFolder'.
node_modules/vscode-languageclient/lib/workspaceFolders.proposed.d.ts(1,10): error TS2305: Module '"/Users/krokofant/GitHub/graphql-for-vscode/node_modules/vscode/vscode"' has no exported member 'WorkspaceFoldersChangeEvent'.

@krokofant what is your tsc version? Make sure you have atleast 1.5.3+.
After pulling this repo, run yarn install, followed by yarn run compile-server and yarn run compile for front-end and backend respectively.


Limit how far you can future date itemizables (i.e. donations, purchases, distributions)

Summary
Limit how far in the future you can date donations, purchases, distributions
Why
If you accidentally enter a far future date (say 20204), the system accepts it, but you can't see the activity you entered.
Details
On each of purchases, donations, and distributions, there is a date the user enters, which is the effective date of the activity (as opposed to the date entered).
This date is used in filters of the activities.
Limit that date to be no more than 1 year beyond today's date.
Note:  in a separate issue we are going to make the current "all time" date filter shortcut go to 1 year beyond today.
Criteria for completion

[ ] the entered dates on each of donations, purchases, and distributions are limited to 1 year in the future.
[ ] automated tests to support that behaviour.

👋 I'd like to pick this up!

Yep!  Thank you!


Warrior nitrogen8m

Some changes needed for the current warrior branch on the nitrogen8m platform.
This goes with https://github.com/boundarydevices/meta-boundary/pull/12
@texierp can you take a look?

Sure @drewmoseley ;), I will check

I removed one patch which wasn't supposed to be here.  This is better now.

And FWIW the required PR in meta-boundary has been merged.

@drewmoseley
The build is ok on my side, but I have an issue when I want to upgrade U-Boot (run upgradeu). See after:
MMC read: dev # 0, block # 66, count 2254 ... 2254 blocks read: OK
byte at 0x000000004200208f (0xa3) != byte at 0x000000004240208f (0xad)
Total of 7311 byte(s) were the same
Need U-Boot upgrade
Program in 5 seconds
5
4
3
2
1

MMC write: dev # 0, block # 66, count 2254 ... 2254 blocks written: OK
switch to partitions #0, OK
mmc0(part 0) is current device
---- U-Boot upgraded. The board will now reset.
resetting ...

U-Boot SPL 2018.07 (Jun 29 2020 - 19:04:58 +0000)
Setting voltages
config to do 3200 1d training.
config to do 667 1d training.
config to do 3200 2d training.
Normal Boot
Trying to boot from MMC1
No matching DT out of these options:
   Configuration to load ATF before U-Boot
No matching DT out of these options:
   Configuration to load ATF before U-Boot
mmc_load_image_raw_sector: mmc block read error
SPL: failed to boot from all boot devices
### ERROR ### Please RESET the board ###

have you had that issue  on your side?
Here is my configuration:
Build Configuration:
BB_VERSION           = "1.42.0"
BUILD_SYS            = "x86_64-linux"
NATIVELSBSTRING      = "universal"
TARGET_SYS           = "aarch64-poky-linux"
MACHINE              = "nitrogen8m"
DISTRO               = "poky"
DISTRO_VERSION       = "2.7.4"
TUNE_FEATURES        = "aarch64"
TARGET_FPU           = ""
meta
meta-poky
meta-yocto-bsp       = "HEAD:f65b24e9ca0918a4ede70ea48ed8b7cc4620f07f"
meta-mender-core
meta-mender-demo     = "HEAD:5621ca878bacdf654cc63011f215192026dba7be"
meta-mender-nxp      = "warrior-nitrogen8m:498e4537002c6301ad1ca5db29eb248dad633dfd"
meta-freescale       = "HEAD:dde79e0e441cf0dae95ba42acdb9d81a384541c4"
meta-freescale-3rdparty = "HEAD:1e374913b737ae24934f799cc3592a05247a3c29"
meta-freescale-distro = "HEAD:d4e77ea682fa10d0d54a723b3d3099c44fc5e95c"
meta-oe              = "HEAD:a24acf94d48d635eca668ea34598c6e5c857e3f8"
meta-boundary        = "warrior:0beba0ebbda86342e77659ccb9efeef0094b434c"

Thanks !

Hi @texierp I did not see that issue but I was not running on a stock nitrogen8m board so it's possible there is an issue with that platform.  Did you reset the environment to default after running upgradeu?

Did you reset the environment to default after running upgradeu

Yes ;)
I will investigate further

Hi @texierp any progress here?

Ping @texierp @drewmoseley

I don't have the ability to test this any more but I think it's a valid fix.  Waiting on @texierp

@drewmoseley @mirzak sorry for the delay, I was very busy :/
I will check this week ;)

@mirzak @drewmoseley, FYI, I will update the nitrogen8m for Zeus branch.

Readme updated.  Thanks for reviewing and testing.

Thanks to you @drewmoseley ;)


fix: resolve error when setup on second attempt

Description
This PR fixes a bug where the setup process was stuck if any error occurred after the first setup.
Instead of just checking if an admin user exists in database, this PR will also check if the settings are properly set up, and if so edit the admin user according to the new settings provided during the 2nd setup.
Steps to reproduce:

Do the whole setup process
Stop Jellyseerr
Delete settings.json
The setup page appears again but you can't setup Jellyseerr anymore.

Screenshot (if UI-related)
To-Dos

[x] Successful build pnpm build
[ ] Translation keys pnpm i18n:extract
[ ] Database migration (if required)

Issues Fixed or Closed

Fixes #XXXX

Please add more details of what this PR achieves to solve

Done

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

v2.1.0
GitHub release

Your semantic-release bot :package::rocket:


value.split is not a function

Steps to Reproduce

Navigate to the Emissions Management Swaggar page
Craft a request that has two year parameters/two repeated parameters. EX:
https://api.epa.gov/easey/dev/streaming-services/emissions/apportioned/quarterly?year=2020&year-2021&quarter=1&exclude=countOpTime
System returns a 500 response code

Needs to be revalidated before proceeding with developement

Navigate to CAMD dev environment HOME.
Private Zenhub Image
Scroll down and click on " Start your data query"
Private Zenhub Image
Set data type to EMISSIONS and sub data type to QUARTERLY EMISSIONS then click apply
Private Zenhub Image
Click on TIME PERIOD and enter 2020 then select Q1 and click "apply filter"
Private Zenhub Image
Click "preview data"
Private Zenhub Image
Click the 3 dots edit button next to OPERATING COUNT then click on customize columns scroll down and uncheck OPERATING TIME COUNT then click on APPLY.
Private Zenhub Image
Click on Download. This should download without any errors.
Private Zenhub Image

this also looks good in the campd ui and when i try the api directly. however, same issue with dev swagger page freezing. @bchofor

this also looks good in the campd ui and when i try the api directly. however, same issue with dev swagger page freezing. @bchofor

@tlageman-epa I've fixed the issue in this repo you can test it now
US-EPA-CAMD/easey-streaming-services#97

looks good in staging re: api call, but same swagger page issue i mentioned in dev. See email comments


Missing onPressIn and onPressOut properties on Text page

Description
The Text page of the documentation doesn't explain that the components embarks also the onPressIn and onPressOut props.
Documentation version
0.71

Related to this PR: #3564

closing issue as PR merged


there is a error when running

input command:
pyftsubset SourceHanSans-VF.otf --text-file=reserve.txt --output-file=target.otf
SourceHanSans-VF.otf : https://github.com/adobe-fonts/source-han-sans/blob/release/Variable/OTF/SourceHanSans-VF.otf
reserve.txt
ERROR:
Traceback (most recent call last):
File "/usr/bin/pyftsubset", line 11, in
load_entry_point('fonttools==3.21.2', 'console_scripts', 'pyftsubset')()
File "/usr/lib/python3/dist-packages/fontTools/misc/loggingTools.py", line 372, in wrapper
return func(*args, **kwds)
File "/usr/lib/python3/dist-packages/fontTools/subset/init.py", line 3119, in main
subsetter.subset(font)
File "/usr/lib/python3/dist-packages/fontTools/subset/init.py", line 2930, in subset
self._prune_pre_subset(font)
File "/usr/lib/python3/dist-packages/fontTools/subset/init.py", line 2759, in _prune_pre_subset
retain = table.prune_pre_subset(font, self.options)
File "/usr/lib/python3/dist-packages/fontTools/subset/init.py", line 1977, in prune_pre_subset
dfltWdX = private.defaultWidthX
File "/usr/lib/python3/dist-packages/fontTools/cffLib/init.py", line 2242, in getattr
raise AttributeError(name)
AttributeError: defaultWidthX

I cannot reproduce this. Please try with latest version of fonttools.

I cannot reproduce this. Please try with latest version of fonttools.

Thank you for your replying. The problem has been solved when you update the installation and require Python 3.8.

fonttools 4.38.0 still supports 3.7, though.


Consider Fixing NuSpecs to Match NuGet 3.0

As stated here, NuGet 3.0 no longer allows packages to add libraries to the lib root directory.
This isn't an issue for Duality itself, but it might be when someone chooses to install Duality packages in a regular VS solution. While unlikely for plugins, this is a likely use case for plugin developers to obtain the Duality core binaries in a plugin solution.
Test whether the Duality Package Manager can handle libraries inside a lib/target folder and consider updating all nuspecs according to this. Do so in the course of creating the v2.0 packages.

What's the NuGet target platform for PCL Profile 111? According to this list, it's

portable-net45+netcore45+wpa81

but I'm not sure whether that's still up-to-date, with Xamarin and Mono support. Any insight appreciated.

Superseded by #574. Closing this.


Is it postgres_set works?

I had tried this configuratio for my project:
postgres_pass database;
postgres_query "SELECT id FROM articles WHERE slug='$slug' LIMIT 1";
postgres_set $id 0 0;
postgres_output none;
When i try to use $id for rewrite operator it returns nothing:
rewrite  ^/(.*)$  /$id  permanent; => redirects to "/" but not /$id
When i try echo it, it returns nothing:
echo "id = '$id'"; => id=''
But when i try example from your tests with header, it works:
add_header "X-ID" $id;
Why it is? Why i can`t get variable value?

I was able to get this working with the following stack:
nginx-eval-module-2016.06.10
openssl-1.0.2l
echo-nginx-module-0.61
ngx_devel_kit-0.3.0
pcre-8.41
zlib-1.2.11
nginx-1.13.6
ngx_postgres-1.0rc7
set-misc-nginx-module-0.31

Url trigger `somehost.com?subentity_slug=foo&entity_id=bar
  location /subentity {
    eval_subrequest_in_memory off;

    eval $subentity_id {
      postgres_pass pg_backend;
      postgres_query  "SELECT subentity_id from entity_routing where slug = '$arg_subentity_slug' and entity_id = '$arg_entity_id'";
      postgres_output value;
    }

    if ($subentity_id = "") {
      return 404;
    }

    if ($subentity_id != "") {
      return 301 http://someotherbiz.com/?entity_id=$arg_entity_id&subentity_id=$subentity_id;
    }
  }


Remove last remaining traces of modelMetricsNamespace flag

Description

Removes a few orphaned references to the removed modelMetricsNamespace flag.
How Has This Been Tested?

Test Impact

Request review criteria:

Self checklist (all need to be checked):

[ ] The developer has manually tested the changes and verified that the changes work
[ ] Commits have been squashed into descriptive, self-contained units of work (e.g. 'WIP' and 'Implements feedback' style messages have been removed)
[ ] Testing instructions have been added in the PR body (for PRs involving changes that are not immediately obvious).
[ ] The developer has added tests or explained why testing cannot be added (unit tests & storybook for related changes)

If you have UI changes:

[ ] Included any necessary screenshots or gifs if it was a UI change.
[ ] Included tags to the UX team if it was a UI/UX change (find relevant UX in the SMEs section).

After the PR is posted & before it merges:

[ ] The developer has tested their solution on a cluster by using the image produced by the PR to main

Oh, you broke tests... no approval for you 🙂

@alexcreasy should we merge this? it's been open for a couple of months

/retest

Okay, GitHub allowed a rebase -- the test info was lost and seemed to not want me to retest it -- so I figured this way we can try to merge this if the tests pass.


Why numeric columns can be string or number?

I have a column in my database defined as a numeric. Is there any particular reason why the generated type can be a string or number?
I currently have to use Number(valueFromDatabase) to make sure the typescript knows the value is a number.

Upvote & Fund

We're using Polar.sh so you can upvote and help fund this issue.
We receive the funding once the issue is completed & confirmed by you.
Thank you in advance for helping prioritize & fund our backlog.

Bigint an numberic types can hold values that are larger than the maximum integer the javascript number can express (2^53-1). That's why most db drivers like pg return those types as strings by default.
If you're sure your numbers never exceed that value, you can configure the driver to return numbers. See this recipe.
I don't know how to tell that to kysely-codegen though. There should be a way. @RobinBlomberg can probably elaborate on this.

Has any work been done in this direction?

This will be released in<EMAIL_ADDRESS>soon!

Should be released in<EMAIL_ADDRESS>🚀


mup deploy succeeds but application cannot be accessed

Hi,
I have deployed my application with mup, and am getting a success message after running "mup deploy"
here is the logs on the development server
Building App Bundle Locally

Started TaskList: Pushing Meteor
[REDACTED IP] - Pushing Meteor App Bundle to The Server
[REDACTED IP] - Pushing Meteor App Bundle to The Server: SUCCESS
[REDACTED IP] - Pushing the Startup Script
[REDACTED IP] - Pushing the Startup Script: SUCCESS

Started TaskList: Configuring  Meteor Environment Variables
[REDACTED IP] - Sending Environment Variables
[REDACTED IP] - Sending Environment Variables: SUCCESS

Started TaskList: Start Meteor
[REDACTED IP] - Start Meteor
[REDACTED IP] - Start Meteor: SUCCESS
[REDACTED IP] - Verifying Deployment
[REDACTED IP] - Verifying Deployment: SUCCESS

I am deploying to a fresh Ubuntu 14.04 install on a digital ocean droplet
once I have deployed it seems I can only access the server via the in-browser terminal on digitalocean
I checked what's running on port 80  and got this response
(spacing is wrong as I cannot seem to copy text from the in-browser terminal)
netstat -tulpn | grep :80
tcp6    0    0  :: :80           :::*         LISTEN      29348/docker-proxy

If I watch the production server while running mup setup I see several warnings

>>>WARNING<<< Wrong ufstype may corrupt your filesystem, default is ufstype=old
ufs: ufs_fill_super(): bad magic number
qnx: no qnx4 filesystem (no root dir).
ext4-fs (vda15): VFS Can't find ext4 filsystem
ext4-fs (vda15): VFS Can't find ext4 filsystem
ext4-fs (vda15): VFS Can't find ext4 filsystem
squashfs: SQUASHFS error: Can't find a SQUASHFS superblock on vda15
FAT-fs (vda15): invalid media value (0x7d)
FAT-fs (vda15): invalid media value (0x7d)
ufs: You didn't specify the type of your ufs filesystem

mount -t ufs -o ufstype=sun|sunx86|44bsd|ufs2|5xbsd|old|hp|nextstep|nextstep-cd|openstep ...

>>>WARNING<<< Wrong ufstype may corrupt your filesystem, default is ufstype=old
ufs: ufs_fill_super(): bad magic number
qnx: no qnx4 filesystem (no root dir).
ext4-fs (vda15): VFS Can't find ext4 filsystem
ext4-fs (vda15): VFS Can't find ext4 filsystem
ext4-fs (vda15): VFS Can't find ext4 filsystem
squashfs: SQUASHFS error: Can't find a SQUASHFS superblock on vda15
FAT-fs (vda15): invalid media value (0x7d)
FAT-fs (vda15): invalid media value (0x7d)
ufs: You didn't specify the type of your ufs filesystem

mount -t ufs -o ufstype=sun|sunx86|44bsd|ufs2|5xbsd|old|hp|nextstep|nextstep-cd|openstep ...

>>>WARNING<<< Wrong ufstype may corrupt your filesystem, default is ufstype=old
ufs: ufs_fill_super(): bad magic number
qnx: no qnx4 filesystem (no root dir).

(may contain typos due to aforementioned inability to copy text)


HashMap in Python

Introduction to HashMap
Complexity Analysis of Worst-Case + Best Case
Code for Insertion Operation in HashMap
Explanation of Code Example

Hii!! Can you assign me this issue?

I want to work on this issue. Please assign me


Remove MP and QA UI Reports

Remove the following Reports from the UI:
Global-view:

Monitoring Plan Module:

View Printout Report

QA Test Data Module:

Test Data Report
Test History Report

QA Cert Events and TEE Data Module:

Test Data Report
Test History Report

Workspace:

Monitoring Plan Module:

View Printout Report

QA Test Data Module:

Test Data Report
Test History Report
Evaluation

QA Cert Events and TEE Data Module:

Test Data Report
Test History Report
Evaluation

Global View:
Global View - View Printout Report

Global View - QA Test Data Module

Global View - QA Cert Events and TEE Data Module

Global View:
Workspace - View Printout Report

Workspace - QA Test Data Module

Workspace - QA Cert Events and TEE Data Module

MP and QA UI Reports have been removed.


Automated pseudonymisation

A robust and configurable pseudonymisation process is required. Feature metadata should specify whether a pseudonymised version of a feature is required. Pseudonymised versions should be generated automatically. Ideally, queries to the feature store should transparently return pseudonymised versions of PII features depending on RBAC.

[ ] Data transformation pipeline sample to pseudonymise structured data
[ ] Data transformation pipeline sample to pseudonymise unstructured data

This will likely take the form of a sample transform pipeline (a Data Pot)

Merseyside work hopefully will be able to share this work back into flowEHR with sample repo that has example for bootstrapping.

Lots of the work de-identification of notes data, happy to share if it works. Using presidio
Have had rule-based pseudonymisation based on data types (e.g. dates). Databricks configuration

Consider breaking out into two separate issues nearer to the time of sharing back into flowEHR. Will demo at next standup


Update in kepler documentation for this repo usage

Update in kepler documentation for this repo usage
for example update patch locally

fixed by https://github.com/sustainable-computing-io/kepler/pull/729


(Inverted) Toggle Gear sound not directional clientside

Describe the bug
The sound of a toggle gear being toggled, on a client, isn't coming from the gear but from "everywhere", as if it was centered on the player, all the way up until a distance, where the sound disappears completely.
Tested on a LAN server, the host doesn't have this issue.
To Reproduce [Optional]
A setup with a toggle gear and an inverted toggle in the same block used to switch the direction of a centrifuge will have this issue.

I've tested this, and it's working fine for me.
However, issue #149 also reports issues with the sound from toggle gears (a different issue, but still), and I can't reproduce that one either.
Either there is something very intermittent with the toggle gear sounds, or there's something about the sound that makes people think they can't hear it properly.

Closing the issue for inactivity as it's not been reproduced.


[Feature Request] Can you please add responsiveness to the components

Existing Component
No
Component Name
Whole Library
Description
it would be nice to have the components responsive, please?

pr welcome


After some time unit returns "Error connecting to Loki"

Bug Description
We deployed loki under latest/edge (needed a fix for https://github.com/canonical/loki-k8s-operator/issues/338) and the initial deployment goes fine, but after some time loki goes into a blocked state with:
loki/0*                             blocked   idle   <IP_ADDRESS>          Error connecting to Loki. Check juju debug-log
It seems that the connection is there though:
root@loki-0:~# curl -k [https://<IP_ADDRESS>:16443/loki/api/v1/push](https://<IP_ADDRESS>:16443/loki/api/v1/push) { "kind": "Status", "apiVersion": "v1", "metadata": {}, "status": "Failure", "message": "Unauthorized", "reason": "Unauthorized", "code": 401
Juju debug-log does not provide anything valuable for this problem, I attached it bellow
To Reproduce
COS bundle:
07-03-cos-bundle.txt
Environment
Loki latest/edge: juju status:
 juju status --relations | grep loki loki                             2.9.4    waiting      1  loki-k8s                      latest/edge    123  <IP_ADDRESS>  no       waiting for units to settle down loki/0*                             blocked   idle   <IP_ADDRESS>          Error connecting to Loki. Check juju debug-log loki                             loki                             loki-k8s                      123  4/4        logging                   loki_push_api            provider alertmanager:alerting                             loki:alertmanager            alertmanager_dispatch  regular ca:certificates                                   loki:certificates            tls-certificates       regular loki:grafana-dashboard                            grafana:grafana-dashboard    grafana_dashboard      regular loki:grafana-source                               grafana:grafana-source       grafana_datasource     regular loki:metrics-endpoint                             prometheus:metrics-endpoint  prometheus_scrape      regular loki:replicas                                     loki:replicas                loki_replica           peer traefik:ingress-per-unit                          loki:ingress                 ingress_per_unit       regular
Relevant log output
juju debug-log --include loki |grep loki
unit-loki-0: 08:37:20 DEBUG juju.worker.uniter.relation unit "remote-5b5faaa50bbc45628410ed84955e906f/53" already joined relation 58
unit-loki-0: 08:37:20 DEBUG juju.worker.uniter.relation unit "remote-5b5faaa50bbc45628410ed84955e906f/54" already joined relation 58
unit-loki-0: 08:37:20 DEBUG juju.worker.uniter.relation unit "remote-5b5faaa50bbc45628410ed84955e906f/55" already joined relation 58
unit-loki-0: 08:37:20 DEBUG juju.worker.uniter.relation unit "remote-5b5faaa50bbc45628410ed84955e906f/56" already joined relation 58
unit-loki-0: 08:37:20 DEBUG juju.worker.uniter.relation unit "remote-5b5faaa50bbc45628410ed84955e906f/58" already joined relation 58
unit-loki-0: 08:37:20 DEBUG juju.worker.uniter.relation unit "remote-5b5faaa50bbc45628410ed84955e906f/6" already joined relation 58
unit-loki-0: 08:37:20 DEBUG juju.worker.uniter.relation unit "remote-5b5faaa50bbc45628410ed84955e906f/7" already joined relation 58
unit-loki-0: 08:37:20 DEBUG juju.worker.uniter.relation unit "remote-5b5faaa50bbc45628410ed84955e906f/8" already joined relation 58
unit-loki-0: 08:37:20 DEBUG juju.worker.uniter.relation unit "remote-5b5faaa50bbc45628410ed84955e906f/9" already joined relation 58
unit-loki-0: 08:37:20 DEBUG juju.worker.uniter.relation unit "grafana/0" already joined relation 20

More debug-log:
debug-log.txt
Additional context
No response

@natalytvinova could we also get the full juju status --relations without grepping on loki?

@mmkay here you go
07-03-juju-status.txt

I copy the juju status output here, so we do not need to download and open the file in a text editor
juju status --relations
Model  Controller           Cloud/Region                      Version  SLA          Timestamp
cos    microk8s-controller  snapped-microk8s_cloud/localhost  3.3.1    unsupported  11:12:41Z

App                              Version  Status   Scale  Charm                         Channel        Rev  Address         Exposed  Message
alertmanager                     0.25.0   active       1  alertmanager-k8s              stable          96  <IP_ADDRESS>  no
ca                                        active       1  self-signed-certificates      edge            80  <IP_ADDRESS>  no
catalogue                                 active       1  catalogue-k8s                 stable          33  <IP_ADDRESS>   no
external-ca                               active       1  self-signed-certificates      edge            80  <IP_ADDRESS>   no
grafana                          9.2.1    active       1  grafana-k8s                   stable          93  <IP_ADDRESS>  no
loki                             2.9.4    waiting      1  loki-k8s                      latest/edge    123  <IP_ADDRESS>  no       waiting for units to settle down
prometheus                       2.48.0   active       1  prometheus-k8s                latest/stable  165  <IP_ADDRESS>   no
scrape-interval-config-metrics   n/a      active       1  prometheus-scrape-config-k8s  stable          44  <IP_ADDRESS>  no
scrape-interval-config-monitors  n/a      active       1  prometheus-scrape-config-k8s  stable          44  <IP_ADDRESS>  no
traefik                          2.10.4   active       1  traefik-k8s                   stable         166  <IP_ADDRESS>     no

Unit                                Workload  Agent  Address       Ports  Message
alertmanager/0*                     active    idle   <IP_ADDRESS>
ca/0*                               active    idle   <IP_ADDRESS>
catalogue/0*                        active    idle   <IP_ADDRESS>
external-ca/0*                      active    idle   <IP_ADDRESS>
grafana/0*                          active    idle   <IP_ADDRESS>
loki/0*                             blocked   idle   <IP_ADDRESS>          Error connecting to Loki.


APA102 support is very inconsistent

The example here works fine as long as the brightness is high enough. 31 (the max) doesn't seem to pose any problems, but as soon as you get to 15 or lower, problems consistently arise.  Problems such as LEDs being off or being the wrong color.
I've tested this APA102 strip and the same power source with a Photon microcontroller and it works fine at very low brightness, so the only other variable is the Intel Edison hardware or software.
I've seen a lot of mentions that the Edison has poor support for SPI (it's emulated), so maybe it's related to that?

Hi @solidcell, the SPI driver on the Edison has actually improved quite a bit with the new image, but there are still a few things you sometimes need to tweak based on device. For instance, PM used to cause problems if it's on when hooking up displays, you can read more about it here. I don't recall if it's relevant for the LED strips but can be tried.
Then, make sure your SPI bus shares a common ground with the power supply. The issue you're describing is actually caused by the different characteristics of the SPI lines on the two boards. The number of LEDs on the strip also matters.
You have two options to fix that from the APA102 driver itself:

The first one and likely to make the biggest impact is batchMode. Set it to true in the constructor call, draw your frame and then push it over the bus with a call to pushState() at the end.
The second is to lower the SPI bus speed with the setBusSpeed(int hz) function. This will directly affect the length of the strip you can drive, and will likely need to be significantly lower when not using batch mode.

Let me know what works for you. Good luck!


grt: clang-format

Signed-off-by: Eder Monteiro<EMAIL_ADDRESS>

I'll approve on the idea that you are just formatting but you need to address the build issue.

The issue was with the GlobalRouter.i file. clang-formating leads to the build issue, but my latest commit should fix it.

@maliberty I don't get this error on the macOS build:
/Users/openroad/github-action-runners/actions-runner-0/_work/OpenROAD/OpenROAD/src/odb/src/lef/lef/lefrReader.cpp:319:14: error: use of undeclared identifier 'lefyyparse'
cd /Users/openroad/github-action-runners/actions-runner-0/_work/OpenROAD/OpenROAD/build/third-party/abc && /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++  -I/Users/openroad/github-action-runners/actions-runner-0/_work/OpenROAD/OpenROAD/third-party/abc/src -O3 -DNDEBUG -arch arm64 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.1.sdk -Wall -Wno-array-bounds -Wno-nonnull -Wno-unused-variable -Wno-unused-function -Wno-write-strings -Wno-sign-compare -Wno-deprecated -Wno-c++11-narrowing -Wno-register -Wno-format -Wno-reserved-user-defined-literal -DABC_USE_STDINT_H=1 -DABC_MEMALIGN=4 -DABC_NAMESPACE=abc -fpermissive -DABC_USE_CUDD=1 -DABC_USE_PTHREADS -std=c++17 -MD -MT third-party/abc/CMakeFiles/libabc.dir/src/base/abci/abcBidec.c.o -MF CMakeFiles/libabc.dir/src/base/abci/abcBidec.c.o.d -o CMakeFiles/libabc.dir/src/base/abci/abcBidec.c.o -c /Users/openroad/github-action-runners/actions-runner-0/_work/OpenROAD/OpenROAD/third-party/abc/src/base/abci/abcBidec.c
    status = lefyyparse();
             ^
1 error generated.
make[2]: *** [src/odb/src/lef/CMakeFiles/lef.dir/lef/lefrReader.cpp.o] Error 1
make[2]: *** Waiting for unfinished jobs....

I don't see this error on my mac. Did you see something like this before?

You should not use clang-format on the .i file as it isn't really c++

@maliberty I don't get this error on the macOS build:
/Users/openroad/github-action-runners/actions-runner-0/_work/OpenROAD/OpenROAD/src/odb/src/lef/lef/lefrReader.cpp:319:14: error: use of undeclared identifier 'lefyyparse'
cd /Users/openroad/github-action-runners/actions-runner-0/_work/OpenROAD/OpenROAD/build/third-party/abc && /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++  -I/Users/openroad/github-action-runners/actions-runner-0/_work/OpenROAD/OpenROAD/third-party/abc/src -O3 -DNDEBUG -arch arm64 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.1.sdk -Wall -Wno-array-bounds -Wno-nonnull -Wno-unused-variable -Wno-unused-function -Wno-write-strings -Wno-sign-compare -Wno-deprecated -Wno-c++11-narrowing -Wno-register -Wno-format -Wno-reserved-user-defined-literal -DABC_USE_STDINT_H=1 -DABC_MEMALIGN=4 -DABC_NAMESPACE=abc -fpermissive -DABC_USE_CUDD=1 -DABC_USE_PTHREADS -std=c++17 -MD -MT third-party/abc/CMakeFiles/libabc.dir/src/base/abci/abcBidec.c.o -MF CMakeFiles/libabc.dir/src/base/abci/abcBidec.c.o.d -o CMakeFiles/libabc.dir/src/base/abci/abcBidec.c.o -c /Users/openroad/github-action-runners/actions-runner-0/_work/OpenROAD/OpenROAD/third-party/abc/src/base/abci/abcBidec.c
    status = lefyyparse();
             ^
1 error generated.
make[2]: *** [src/odb/src/lef/CMakeFiles/lef.dir/lef/lefrReader.cpp.o] Error 1
make[2]: *** Waiting for unfinished jobs....

I don't see this error on my mac. Did you see something like this before?

I'm guessing there is more error message somewhere above as that seems incomplete.

I don't see that message in https://github.com/The-OpenROAD-Project/OpenROAD/actions/runs/3441135922/jobs/5740427304 - where did you copy it from?

status = lefyyparse();

It is from this link, around line 402.

I found it
2022-11-10T23:19:26.9047440Z /Users/openroad/github-action-runners/actions-runner-0/_work/OpenROAD/OpenROAD/src/odb/src/lef/lef/lefrReader.cpp:319:14: error: use of undeclared identifier 'lefyyparse'

I don't see how grt could affect odb so it is mysterious.  I've restarted the action but perhaps @vvbandeira has some ideas.

@vvbandeira something has changed on the mac build.  I looked at https://github.com/The-OpenROAD-Project/OpenROAD/pull/2481 from two days ago and I see in https://pipelines.actions.githubusercontent.com/serviceHosts/0e85c22b-57c2-4209-9b54-a3eaf4fc9b50/_apis/pipelines/1/runs/93537/signedlogcontent/2?urlExpires=2022-11-11T00%3A13%3A13.2393551Z&urlSigningMethod=HMACV1&urlSignature=CWN6IbeHY6DJzcXInLIb33UE234ykp1O4SdZBIRK3Z4%3D
Found BISON: /opt/homebrew/Cellar/bison/3.8.2/bin/bison (found version "3.8.2")
Found FLEX: /opt/homebrew/Cellar/flex/2.6.4_2/bin/flex (found version "2.6.4")

but in this PR https://pipelines.actions.githubusercontent.com/serviceHosts/0e85c22b-57c2-4209-9b54-a3eaf4fc9b50/_apis/pipelines/1/runs/93710/signedlogcontent/2?urlExpires=2022-11-11T00%3A12%3A21.9197907Z&urlSigningMethod=HMACV1&urlSignature=lQPsFZmUwOptleYdPUtyK%2BhHMQfzDzKaBXQ%2BiSQP%2Fkw%3D
Found BISON: /usr/bin/bison (found version "2.3")
Found FLEX: /usr/bin/flex (found version "2.6.4")

Yes, I have run into this error several times and it comes from accidentally using the MacOS system version of bison instead of the one installed by homebrew.

@maliberty fixed, env of the runner was misconfigured as @rovinski suggested


openpgp: ignore unsupported critical packets on cross-signed WoT sigs

Fixes keybase id sneak

r? @oconnor663

lgtm

Has it been submitted upstream?


the done might be called twice when err occurred.

https://github.com/senecajs/ramanujan/blob/master/fanout/fanout-logic.js#L9-L15
 seneca.add('fanout:entry', function(msg, done) {
    ...
    done()
    ...
    this.act('follow:list,kind:followers',{user:entry.user},function(err,userlist){
      if(err) return done(err) // done has been called before

Good catch, thanks


Public Cloud eMOU Form - EA signing process

OCIO and (TEAM NAME)- AWS (1).docx

The team name is fixed. All the text issues correspond to the example document, provided above.
The AWS instead of MS Azure will be tackled in corresponding later task.


Null argument exception for parameter operationStatusLink when calling some Automation SDK methods

Library name and version
Azure.Automation
Describe the bug
When calling some Azure.Automation methods we are observing a null argument exception that references the operationStatusLink property. We have so far observed this with the RunbookDraft.UpdateGraphAsync and RunbookDraft.UpdateAsync methods, but it may also affect others as well. We are mostly observing this issue when uploading a new runbook draft and it seems like a new issue, as we only started observing this recently.
Expected behavior
Should be able to create and upload a new runbook draft without any exceptions.
Actual behavior
Receiving a null argument exception that references the operationStatusLink parameter.
Stack trace:
	at Microsoft.Azure.Management.Automation.AutomationManagementClient.<GetOperationResultStatusAsync>d__110.MoveNext()\r\n
	at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()\r\n   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)\r\n
	at Microsoft.Azure.Management.Automation.RunbookDraftOperations.<UpdateGraphAsync>d__12.MoveNext()\r\n   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()\r\n
	at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)\r\n   at System.Runtime.CompilerServices.ConfiguredTaskAwaitable`1.ConfiguredTaskAwaiter.GetResult()\r\n
	at Kelverion.RunbookStudio.Cloud.Extensions.RunbookDraftOperationsMixins.<UpdateGraphAsync>d__4.MoveNext() in C:\\Users\\DavidCader\\source\\repos\\app-automation-console\\Src\\Kelverion.RunbookStudio.Cloud\\Extensions\\RunbookDraftOperationsMixins.cs:line 65\r\n
	at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()\r\n   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)\r\n   at System.Runtime.CompilerServices.ConfiguredTaskAwaitable.ConfiguredTaskAwaiter.GetResult()\r\n
	at Kelverion.RunbookStudio.Cloud.RunbookAssetClient.<CreateOrUpdateAsync>d__4.MoveNext() in C:\\Users\\DavidCader\\source\\repos\\app-automation-console\\Src\\Kelverion.RunbookStudio.Cloud\\RunbookAssetClient.cs:line 123\r\n
	at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()\r\n   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)\r\n
	at System.Runtime.CompilerServices.ConfiguredTaskAwaitable`1.ConfiguredTaskAwaiter.GetResult()\r\n
	at Kelverion.RunbookStudio.Cloud.RunbookAssetClient.<Kelverion-RunbookStudio-Cloud-ICloudResourceClient-CreateOrUpdateAsync>d__1.MoveNext() in C:\\Users\\DavidCader\\source\\repos\\app-automation-console\\Src\\Kelverion.RunbookStudio.Cloud\\RunbookAssetClient.cs:line 79\r\n
	at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()\r\n   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)\r\n
	at System.Runtime.CompilerServices.TaskAwaiter`1.GetResult()\r\n
	at Kelverion.RunbookStudio.Services.AzureService.<UploadToCloudAsync>d__65.MoveNext() in C:\\Users\\DavidCader\\source\\repos\\app-automation-console\\Src\\Kelverion.RunbookStudio.Services\\AzureService.cs:line 420\r\n
	at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()\r\n   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)\r\n   at System.Runtime.CompilerServices.TaskAwaiter`1.GetResult()\r\n
	at Kelverion.RunbookStudio.ViewModels.Documents.RunbookViewModelBase.<OnUploadRunbookDraft>d__164.MoveNext() in C:\\Users\\DavidCader\\source\\repos\\app-automation-console\\Src\\Kelverion.RunbookStudio\\ViewModels\\Documents\\RunbookViewModelBase.cs:line 512"	string

Reproduction Steps

Create a new graphical runbook using the Runbooks.CreateOrUpdateWithDraftAsync method
Upload the runbook draft by calling RunbookDraft.UpdateGraphAsync
A null argument exception is generated

Environment
.NET 4.8
Visual Studio 2022
Windows 10 Pro

Label prediction was below confidence level 0.6 for Model:ServiceLabels: 'Automation:0.24145123,Azure.Core:0.14916874,Service Bus:0.12326955'

Using release 2.07 and not one of the preview releases.

Thank you for your feedback.  Tagging and routing to the team member best able to assist.

I have this same issue when saving draft runbooks to Azure Automation.

Thank you for using Azure SDK for .NET.
We are looking in to this issue now.

This issue is a service issue, the swagger file does not define this parameter operationStatusLink, but the API requires it.
Right now we don't have any plan to release any Track1 SDK (Microsoft.Azure.Management), please use the latest SDK version: 3.8.3-preview, or wait for Track2 SDK.

Hello  Chengming
Thank you for investigating this and your suggestions, but migrating to the preview SDK is not a viable option for our team now due to the many breaking changes starting with version 3. We make extensive use of the Automation API, and would have to address literally hundreds of breaking changes followed by weeks of testing to have a new build that runs on the latest SDK version.
David Cader
From: Chengming Ruan @.>
Sent: June 28, 2022 10:21 PM
To: Azure/azure-sdk-for-net @.>
Cc: David Cader @.>; Author @.>
Subject: Re: [Azure/azure-sdk-for-net] Null argument exception for parameter operationStatusLink when calling some Automation SDK methods (Issue #29368)
This issue is a service issue, the swagger file https://github.com/Azure/azure-rest-api-specs/blob/main/specification/automation/resource-manager/Microsoft.Automation/stable/2018-06-30/runbook.json#L110  does not define this parameter operationStatusLink, but the API requires it.
Right now we don't have any plan to release any Track1 SDK (Microsoft.Azure.Management), please use the latest SDK version: 3.8.3-preview, or wait for Track2 SDK.
—
Reply to this email directly, view it on GitHub https://github.com/Azure/azure-sdk-for-net/issues/29368#issuecomment-1169461657 , or unsubscribe https://github.com/notifications/unsubscribe-auth/ACOP4E2CEXE3QEXVIHBJRDTVROXJPANCNFSM5ZJSUQMQ .
You are receiving this because you authored the thread.  https://github.com/notifications/beacon/ACOP4E6AGWD4OIPQL6FTFM3VROXJPA5CNFSM5ZJSUQM2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOIW2JDGI.gif Message ID: @.*** @.***> >


Set up Pocketbase in Swift

Integrate Pocketbase into Swift:

[ ] Add the pocketbase swift client to project
[ ] Set up login component

Closing because we will no longer be using swift


Changing password 'pad block corrupted'

Bug changing password: see image.

Proposed fix in #470 so marking as awaiting issue

Change password verified working. Test included a new style paymentrequest.aes which was correctly updated.
@hughht5 needs to verify this on his machine using a 0.0.0 installer so marking as "installer" pending close.

I have uploaded a test installer for @hughht5 to test here:
https://beta.multibit.org/releases/multibit-hd/multibit-hd-0.0.0/
It won't fix the existing wallet but if you create a new wallet you should be able to change password etc ok.
Awaiting review and closing

I have tried the 'change password' on both MacOS and Windows 8 installs using this code successfully. I didn't actually see the OPs problem so it is not a 100% test but shows no regression.

I've closed this as neither @gary-rowe or I are seeing this problem.
@hughht5 if when you retest it it's still a problem open it again.


Add Config Values for Enable SHA-1 Hashing Algorithm

Purpose
With [1], the default algorithm used for certificate hashing was changed to SHA-256. But a config was provided to use SHA-1 algorithm as well. This PR adds the config values to the default.json and the deployment.toml
[1] https://github.com/wso2/carbon-apimgt/pull/12365

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


BigQuery: LoadJobConfiguration to support schemaUpdateOptions

configuration.load.schemaUpdateOptions is documented in the REST API docs, but LoadJobConfiguration doesn't have a way to set it. Actually the protobuf model class seems to have a setter.
It's not clear in the documentation whether schemaUpdateOptions are valid also for partitioned tables or not. Would be nice to get a clarification for that.

Doc issue reported as b/62535154.


WIP to move to a leaner CLI

The previous CLI was using thor and had some issues with bundler, and we needed to switch to parse the Gemfile.lock
This is just shy of a total rewrite, but not 100%. I maintained most of gems.rb, and after switching to parsing the Gemfile.lock, now I'm seeing the transitive deps come back for the project.
This does:

Renames to chelsea completely
Maintains mostly the same usage as before
Trims the deps down BIG TIME
Adds CircleCI config to have commits run through CI
Saves Test Results in a format that CircleCI can show us
Adds LICENSE (set to MIT for now, probs want to switch to Apache long term)

Local run:
$ ./chelsea --file Gemfile.lock
 _____  _            _
/  __ \| |          | |
| /  \/| |__    ___ | | ___   ___   __ _
| |    | '_ \  / _ \| |/ __| / _ \ / _` |
| \__/\| | | ||  __/| |\__ \|  __/| (_| |
 \____/|_| |_| \___||_||___/ \___| \__,_|

Version: 0.0.1

[+] Parsing dependencies ...done. Parsed 23 dependencies.
[+] Parsing versions ...done.
[+] Making request to OSS Index server ...done.

Audit Results
=============
[1/23] -<EMAIL_ADDRESS>No vulnerabilities found!
[2/23] -<EMAIL_ADDRESS>No vulnerabilities found!
[3/23] -<EMAIL_ADDRESS>No vulnerabilities found!
[4/23] -<EMAIL_ADDRESS>No vulnerabilities found!
[5/23] -<EMAIL_ADDRESS>No vulnerabilities found!
[6/23] -<EMAIL_ADDRESS>No vulnerabilities found!
[7/23] -<EMAIL_ADDRESS>No vulnerabilities found!
[8/23] -<EMAIL_ADDRESS>No vulnerabilities found!
[9/23] -<EMAIL_ADDRESS>No vulnerabilities found!
[10/23] -<EMAIL_ADDRESS>No vulnerabilities found!
[11/23] -<EMAIL_ADDRESS>No vulnerabilities found!
[12/23] -<EMAIL_ADDRESS>No vulnerabilities found!
[13/23] -<EMAIL_ADDRESS>No vulnerabilities found!
[14/23] -<EMAIL_ADDRESS>No vulnerabilities found!
[15/23] -<EMAIL_ADDRESS>No vulnerabilities found!
[16/23] -<EMAIL_ADDRESS>No vulnerabilities found!
[17/23] -<EMAIL_ADDRESS>No vulnerabilities found!
[18/23] -<EMAIL_ADDRESS>No vulnerabilities found!
[19/23] -<EMAIL_ADDRESS>No vulnerabilities found!
[20/23] -<EMAIL_ADDRESS>No vulnerabilities found!
[21/23] -<EMAIL_ADDRESS>No vulnerabilities found!
[22/23] -<EMAIL_ADDRESS>No vulnerabilities found!
[23/23] -<EMAIL_ADDRESS>No vulnerabilities found!

There's more we could do but this is functional and probably a good stopping point to get this merged into master

Got an informal blessing of this from @ken-duck , pushing to master

@allisterb I need to update the README, but now we are parsing Gemfile.lock, as that has the authoritative list of what was installed, etc...
Give that a twirl!

@DarthHater Ohh I see :) sorry didn't fully understand. Tried it on the lock file on Window and everything looks ok.

Coolio! Yeah that was the big change. I ended up using bundler's utilities to parse it, which made it kinda fun and easy.


meta-lxatac-software: rkdeveloptool: Add recipe for version 1.32

The rkdeveloptool enables communication with the Boot ROM of various
Rockchip SoCs.
It allows uploading software, writing/reading memory and resetting the CPU/running code.
This could be a replacement for #210, which enables using rkdeveloptool installed into a Debian container.

Hi @a3f,
I've created a bit of a backlog on the server we run the build job on.
But once that unclogs it will generate a RAUC bundle that should contain rkdeveloptool it would be very cool if you could test that with your board.

Nice! I still think #210 is appropriate, because it makes the Debian containers more useful in general. I can give this a test when a bundle is available.

Hi @a3f,
the build queue has unclogged now, so if you like you can try installing the bundle generated by this PR's build now:
root@lxatac-00011:~# rauc-enable-cert devel.cert.pem
root@lxatac-00011:~# rauc install https://github-runner.pengutronix.de/artifacts/forrest-build-qIluyrHbqEVZRlAC/lxatac-core-bundle-base-lxatac.raucb

We should still wait for a successful test report from @a3f.


Stubs generator - hide internal method(s)

refs https://github.com/owl-framework/owl/commit/c98fa7da22a0e047854e911465c9e24b00f762cd

ping @andresgutierrez


How to join the PS Prerelease

The Photoshop prerelease is invisible to end users, so linking to adobeprerelease.com is misleading...

Description

Related Issue

Motivation and Context

How Has This Been Tested?

Screenshots (if appropriate):
Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

[ x ] I have signed the Adobe Open Source CLA.
[ ] My code follows the code style of this project.
[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[ ] I have read the CONTRIBUTING document.
[ ] I have added tests to cover my changes.
[ ] All new and existing tests passed.

Closing, as another PR will be removing this section. A 3rd party developer can readily access Photoshop (Beta) which will provide just as regular of updates to the software.


Add develop command to frontend_addon

I propose we add a develop command here
https://github.com/plone/cookieplone-templates/blob/main/frontend_addon/{{ cookiecutter.__folder_name }}/package.json#L15
"develop": "missdev --no-config  --fetch-https",
This allows me to develop any new add-ons I set in mrsdeveloper
ex:
{
"core": {
"output": "./",
"package": "@plone/volto",
"url": "git@github.com:plone/volto.git",
"https": "https://github.com/plone/volto.git"
},
"volto-slate-glossary": {
"output": "packages",
"url": "git@github.com:rohberg/volto-slate-glossary.git",
"https": "https://github.com/rohberg/volto-slate-glossary.git",
"package": "@rohberg/volto-slate-glossary",
"branch": "only-first-occurence---use-wrapped-view",
"path": "src"
}
}
Would be cool if we could make it easy with another command to add an add-on within volto-config addons key but for now I want to know what is the current feeling regarding this proposal.

@ericof @davisagli @sneridagh what do you guys think about my proposal?
If you don't agree what would you propose instead if someone wants to have an easy add-on developing and registration in this new monorepo way?

@ichim-david This is already included when you run make install:
https://github.com/plone/cookieplone-templates/blob/main/frontend_addon/{{ cookiecutter.__folder_name }}/Makefile#L41
Is there a use case for running your develop command without running the other commands that are part of make install?

@ichim-david I might be missing the point, but why would you want to check out things without installing them so that you can use them?

@ichim-david I might be missing the point, but why would you want to check out things without installing them so that you can use them?

@davisagli I'm not saying that I want todo that but up to this point we have the documentation on how to add addons using mrs developer using make develop
https://6.docs.plone.org/volto/addons/index.html#use-mrs-developer-to-manage-the-development-cycle
This has now been basically merged into make install. We are sort of loosing that gained knowledge because now things are done differently.
Again not a major deal if it's documented as make install is now the equivalent of make develop and make install from previous system.

Closing as I got my feedback that make install does what I needed as part of the "develop" command that I wanted with the package.json scripts section.

@ichim-david I think we've had different habits for how to do this. make install has included running missdev since the time I started using volto, so I always have just run make install.
(I think part of what happened is that yarn install used to run the develop command via a preinstall script, so it all happened automatically with configuration in package.json. But pnpm didn't support this feature, so we had to switch to a make command to do it all together.)


npm install

Hi,
Would be awesome to publish simhash-js in npm.
Thanks

And if you can put it into a node module, that would be perfect ;)

@xblanc33 thanks! I wanted to add this as an npm module when I first wrote it in Node 0.8 version. But I wasn't satisfied it was prod ready and kept postponing ;) If you are interested or have the time please feel free to add and push as an npm module.

I forked it.
Can you try : https://github.com/xblanc33/simhash-js
Then you can easily import (I can manage a pull-request if you want).
then npm publish ;)
tell me

Xavier, That was an incredible effort! I've merged your pull request and published to npm: https://www.npmjs.com/package/simhash-js
Hope all is good. Thank you!!

Thanks,
It’s good J
De : Vijay Kandy<EMAIL_ADDRESS>Envoyé : jeudi 29 juin 2017 23:39
À : vkandy/simhash-js<EMAIL_ADDRESS>Cc : Xavier Blanc<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Objet : Re: [vkandy/simhash-js] npm install (#5)
Xavier, That was an incredible effort! I've merged your pull request and published to npm: https://www.npmjs.com/package/simhash-js
Hope all is good. Thank you!!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/vkandy/simhash-js/issues/5#issuecomment-312116125 , or mute the thread https://github.com/notifications/unsubscribe-auth/AJ2niexvnfeYUCze_1zsU8QH9JT9Al1Vks5sJBl7gaJpZM4OGXRH .  https://github.com/notifications/beacon/AJ2niT37XAxF0S9GGGL_Hk2La3l9ncC3ks5sJBl7gaJpZM4OGXRH.gif


StaticDateRangePicker Error

Hello
i was checking the library and i found this https://v4-0-0-alpha-5.material-ui-pickers.dev/demo/daterangepicker#static-mode
i was wondering why this is written in TypeScript?
if its in alpha version it needs to be used as simply as possible with pure react,  right now i cant convert it to pure react and im keep getting this error in my console
Uncaught TypeError: Cannot read property 'keyboardDate' of undefinedblah blah blah

The above error occurred in the <RangePickerWithStateAndWrapper> component:
blah blah blah

Uncaught (in promise) TypeError: Cannot read property 'keyboardDate' of undefined
blah blah blah

please provide a gist of pure javascript for this 😭
and try to show it in pure javascript file not shitty type script 😭 to know how it works in react and then we check that in typescript!

Please provide more information and reproduction using codesandbox.

please provide a gist of pure javascript for this

@a-m-dev This will be resolved with https://github.com/mui-org/material-ui/issues/19706.


Fix unreliable test

Seek the whole log file and wait for the event to be logged.
The test I added fails randomly: https://travis-ci.org/pallets/werkzeug/jobs/322728286 https://travis-ci.org/pallets/werkzeug/jobs/322696785

Thanks a bunch.