snap post refresh hook not work

@Lin-Buo-Ren:
I try to add udev rule in post refresh hook. but it doesn't work.
Can you help check?

As far as I can tell currently it is not possible to modify udev rules from with-in the snap, the root filesystem (/) from the snapped applications' perspective is actually a Ubuntu filesystem provided by the core* snap instead of the actual host filesystem thus placing udev drop-in rules under /etc/udev/rules.d will not have any intended effect.
For hardware integration support one must rely on the facilities snapd provided, which is currently limited to the usage of USB serial interface devices under Ubuntu Core (not classic) systems, refer the following references for more info:

Hotplug support | Snapcraft documentation
The serial-port interface | Snapcraft documentation
Developing hotplug interfaces | Snapcraft documentation
How to add or workaround a udev rule - snapd - snapcraft.io
The Device access section in Multiple users and groups in snaps - snapd - snapcraft.io

Currently the only way to achieve UUU's typical usage(connecting & flashing USB devices) is to run it as root and thus have the permission to write to the devices (via the already granted raw-usb interface, it is snapd's limitation yet to be lifted.

Another possibility is to instruct the user to place udev rules themselves in the host system's /etc/udev/rules.d, which is already done by UUU's -udev command-line option IIRC.


In-memory engine: evict range should consider loading range

What is changed and how it works?

Issue Number: Close #17153

What's Changed:
evict range should consider loading range

Related changes

[ ] PR to update pingcap/docs/pingcap/docs-cn:
[ ] Need to cherry-pick to the release branch

Check List
Tests

[x] Unit test
[ ] Integration test
[ ] Manual test (add detailed scripts or steps below)
[ ] No code

Side effects

[ ] Performance regression: Consumes more CPU
[ ] Performance regression: Consumes more Memory
[ ] Breaking backward compatibility

Release note

None

/retest-required

/merge

/approve

/merge


[question] Publish Test Results task: Could not publish build level data. Object reference not set to an instance of an object.

I have two pipeline jobs, one for macOS and one for Windows. Both jobs invoke the same template file which contains the followings:
- script: myFolder/gradlew -p ./myFolder/ clean build -PignoreTestFailures=true --refresh-dependencies --continue
  displayName: 'Gradle - Build'
- task: PublishTestResults@2
  inputs:
    testResultsFormat: 'JUnit'
    testResultsFiles: '**/build/test-results/test/*.xml'
    mergeTestResults: true
    testRunTitle: 'Tests'
  displayName: 'Publish - Test Results'

The macOS build runs first, no warnings. Then I can see the following warning in the Windows log:
##[warning]Could not publish build level data. Object reference not set to an instance of an object.

Question: What does it mean? What is the problem?
Note: I am not using any Gradle Tools task.
Thank you!

@nigurr for test question.

Update: I can see the same warning in the Windows build even if it runs before the macOS one. The macOS build does not log this warning.

@kittaakos we identified the bug and committed the fix. Due to holiday season, the fix is not rolled out yet.
This will be addressed as soon as possible.

@nigurr, does that mean I can ignore this warning for now?

@kittaakos yes. This warning can be ignored and don't cause any breaks in pipeline experience.

@nigurr is this fixed?

Yes. This fix is rolled out. Closing this issue


absent count field should be added in scan history page .

absent count field is visible in scan history page successfully .


Overloads do not emit JSDoc on non-implementation signatures

TypeScript Version:  3.2.0-dev.201xxxxx

Search Terms:
Code

.ts file

/**
 * this will lost
 */
function a()
function a() { }

/**
 * this will keep
 */
function b() { }

function c()
/**
 * this will keep, but i don't think this is good way
 */
function c() { }

Expected behavior:
all will keep
/**
 * this will lost
 */
function a() { }
/**
 * this will keep
 */
function b() { }
/**
 * this will keep, but i don't think this is good way
 */
function c() { }

Actual behavior:
a is lost

output .js file

function a() { }
/**
 * this will keep
 */
function b() { }
/**
 * this will keep, but i don't think this is good way
 */
function c() { }

and when it at .d.ts

a will keep
b will keep too
but c will lost

Playground Link:
http://www.typescriptlang.org/play/index.html#src=%2F**
 * this will lost
 *%2F
function a()
function a() { }

%2F**
 * this will keep
 *%2F
function b() { }

function c()
%2F**
 * this will keep%2C but i don't think this is good way
 *%2F
function c() { }
Related Issues:

@sandersn How do you feel about emitting all JS doc comments attached to the first signature + the implementation signature, eliding all intermediates? That should eliminate duplicates without breaking existing emit too badly.

@bterlson probably has opinions since he was thinking about how to write jsdoc for overloads.

Expected behavior:
ts
/**
 * this will keep, because all other overloads didn't have jsdoc
 */
function a()
function a()
function a() { }

function b()
function b()
/**
 * this will keep, because all other overloads didn't have jsdoc
 */
function b() { }

/**
 * desc
 */
function c()
function c()
/**
 * this will lost, because one of overloads have jsdoc
 */
function c() { }

=>
/**
 * this will keep, because all other overloads didn't have jsdoc
 */
declare function a(): any;
/**
 * this will keep, because all other overloads didn't have jsdoc
 */
declare function a(): any;
/**
 * this will keep, because all other overloads didn't have jsdoc
 */
declare function b(): any;
/**
 * this will keep, because all other overloads didn't have jsdoc
 */
declare function b(): any;
/**
 * desc
 */
declare function c(): any;
declare function c(): any;


Export of public EC key fails with PKCS#11 back-end on NXP Layerscape

Summary
If you create an elliptic curve key and try to export the public part, you get an error when using the PKCS#11 back-end with the secure objects library in the NXP Layerscape platform. The same operation works correctly on other PKCS#11 systems, so this might be a spec compliance issue in the Layerscape stack.
Affected Versions
Parsec service 1.0.0
Repro
Requires suitable NXP Layerscape device such as LS1046a, imaged with LSDK firmware and userland including OPTEE, libsecure_obj and libpkcs11 components.

Configure Parsec with PKCS#11 back-end with the library_path parameter set to /usr/local/lib/libpkcs11.so and slot_number set to 0. (user_pin is not required and can remain commented out). Also set software_public_operations to true.
Disable any other provider back-ends (eg. Mbed, TPM) by commenting them out.
Start Parsec service. Service should start successfully.
Build or install the parsec-tool (version 0.5.2 is suitable)
Run the parsec-tool list-providers command to ensure that only the core provider and the PKCS#11 provider are active in the service. This is important, otherwise the following commands may use the wrong provider and fail to show the issue or confirm the fix.
Create a default ECC key with parsec-tool create-ecc-key --key-name ecctest1
Attempt to export the public key with parsec-tool export-public-key --key-name ecctest1
Expected: public key is written to the console as a PEM object
Observed: an error message of type PsaErrorGenericError is displayed and the key is not written

Root Cause
Under investigation, but seems likely that this is a spec compliance issue in the LSDK libpkcs11.so component. The Parsec PKCS#11 provider expects the public key to be contained within the PKCS#11 CKA_EC_POINT attribute, and that it will be encoded as an ASN.1 octet string. This is correct, because it is what the PKCS#11 spec mandates. However, it seems that some implementations do not work this way, and they just return the raw data without wrapping it in the ASN.1 octet string. Parsec cannot cope with this, which may be the cause of the error.
Suggested Fix
If the above RCA is confirmed, then the correct fix would probably be for the LSDK to comply with the spec, in which case no changes would be required in Parsec. However, it may be more expedient to make Parsec more lenient to work around this issue, because research suggests that this is not the only PKCS#11 library that suffers from the problem. A similar situation was encountered here in OpenSC, and they decided to work around it. Fixing Parsec will improve its ability to interoperate both with LSDK and also other non-compliant implementations.

I can confirm that the key exports correctly (and provides the right data) if the ASN.1 wrapper parsing is skipped and the raw data used instead. I can prepare a PR for this.


Passkey>codeskey>passcodekeyHACKING***%updating @**%downloading© update ®™

Describe the issue
Opening file medical term IT DATA SCIENCE
<EMAIL_ADDRESS>syafiqsteven000<EMAIL_ADDRESS><EMAIL_ADDRESS>https://syafiqsteven999.atlassian.net
Code of Conduct

[X] I agree to follow the IETF's Code of Conduct

@martinthomson ### ****https://net//com//my//<>%%®™%~=×

[ ] Symbol key locking system updated all file hacking ID keys
Numbering system saving update software Secure syetem hackingkey
Number A-line>a-frame opening download and updated all file output-inload software Backers-H-key+ddd%©%®%™<>


Disable warning notification on dismissing the action

This popover is really annoying when you want to make a new file but then change your mind.

Please allow users to remove it. Thank you.

Sorry this has been fixed already by @Telokis in #33 but I haven't had the time to push an update. If you update your extension this should be fixed now.
Cheers,
Dominik


Race condition when deploying scheduler and deployment group

If the scheduler inits before the deployment group is created, it fails to load because it activates the execution path leading to "Deployment pending, deferring service start".
This is a tough one because the simple solution would yield a circular dependency between CFN resources (CodeDeploy group, Launch Configuration, CFN Init metadata)

The easiest solution is to just consider that the HAS_DEPLOYMENT variable is going to sometimes be empty for new stack deployments and allow that to init the service.

Even easier is to drop this attempt of deferring the service start.
Deployments scripts should take care of this.
Removed on branch develop


Dashboard Query of Index Shards Datasource errors on Last Commit

If I run a query on Index Shards datasource where Last Commit  <  2023-10-05T00:00:00.000Z
I get an WARN triangle stating
For input string "2023-10-05T00:00:00.000Z"

Fixed in > 7.2.20


Performance

Hi @dsietz ,
Hope you don't mind but I took the liberty of doing a quick pass at improving performance.
I squeezed about 10% better performance from my testing with these tweaks.
BTW, I noticed that you do multi-threading in the library, is that something that can be exposed to the Data Sample Parser? Several qsv commands support multi-threading and have CLI options for it to take advantage of additional processors.
If so, let me know so I can create an enhancement issue for it.
Thanks again!

@jqnatividad Thank you very much for the performance improvements and sharing your code. I'm always open to code contributions and feedback. Your changes make sense and are more eloquent than what I had. Going forward, please make sure to create Pull Requests onto the Development branch so that I can integrate it with my own changes before pushing it up to Master.
Unfortunately, I don't have the time necessary to support continued development (enhancements) on this package, however if you'd like to join as a contributor of this package, you are more than welcome. Just let me know.

Hi @dsietz,
Thanks for your prompt reply and merging my enhancements.
And yes, I'd be more than happy to help maintain and enhance test-data-generation!
It fills an underserved need, and I can imagine several enhancements already.


Error: can not process numeric item "color_temp_startup"

Issue description
I am getting this error on every start of z2m ( can not process numeric item "color_temp_startup" ) in domoticz on this devices:
IKEA | LED1903C5/LED1835C6
IKEA | LED1732G11
IKEA | LED1537R6/LED1739R5
Xiaomi | ZNLDP12LM
Additional information
Zigbee2MQTT version 1.17.1-dev commit: 1bcc5f1
Coordinator type zStack3x0
Coordinator revision 20210120
Frontend version 0.3.42
Python: 3.7.3
Domoticz 2020.2 build 12913

Could you please enable debug mode in the plugin and provide what you have in the log (there should be additional feature details under the error message).

2021-02-10 10:21:34.373  Python Plugin System: (Zigbee) {"access": 7, "description": "Color temperature after cold power on of this light", "name": "color_temp_startup", "presets": [{"description": "Coolest temperature supported", "name": "coolest", "value": 250}, {"description": "Cool temperature (250 mireds / 4000 Kelvin)", "name": "cool", "value": 250}, {"description": "Neutral temperature (370 mireds / 2700 Kelvin)", "name": "neutral", "value": 370}, {"description": "Warm temperature (454 mireds / 2200 Kelvin)", "name": "warm", "value": 454}, {"description": "Warmest temperature supported", "name": "warmest", "value": 454}, {"description": "Restore previous color_temp on cold power on", "name": "previous", "value": 65535}], "property": "color_temp_startup", "type": "numeric", "unit": "mired", "value_max": 454, "value_min": 250}
2021-02-10 10:21:34.374  Python Plugin System: (Zigbee) {"access": 3, "description": "Offset to be used in the local_temperature", "name": "local_temperature_calibration", "property": "local_temperature_calibration", "type": "numeric", "unit": "\u00b0C"}
The last logitem is also not processed, and gives the error: can not process numeric item "local_temperature_calibration"
That is about https://www.zigbee2mqtt.io/devices/SEA801-Zigbee_SEA802-Zigbee.html#saswell-sea801-zigbee%252Fsea802-zigbee

Thanks, I'm not sure what device type should be used to handle that if any at all. Could you please suggest?

To me it seems to have only a few default setting, like coolest, cool, neutral, warm and warmest.
That could be solved with a selector-switch with the above level names.
This way there is an easy setting to set all bulbs to the same color temperature.
For the 'local_temperature_calibration' it should be part of the device temperature device. In a temperature device there is a setting "Adjustment", because the unit is \u00b0C, which is degrees Celsius.

Lust to show what is exposed by these kind of bulbs.

For now I have added below code to the adapters.py at line 301 to avoid the ' can not process numeric item "color_temp_startup" ' error...
        if (feature['name'] == 'color_temp_startup' and state_access):
            return

That's not a solution, but a workaround. I think it should be a selector device.

Like I mentioned, its a solution to the errors...

Por ahora, he agregado el siguiente código a adapters.py en la línea 301 para evitar el error ' no se puede procesar el elemento numérico "color_temp_startup" ' ...
        if (feature['name'] == 'color_temp_startup' and state_access):
            return

dear @stas-demydiuk , I have added this code to adapters.py but in my case with domoticz the problem is not solved:
2021-04-26 11:06:52.145 Error: zigbe2mqtt: (zigbe2mqtt) Philips hue1: can not process feature type "composite"
2021-04-26 11:06:52.146 Error: zigbe2mqtt: (zigbe2mqtt) Philips hue2: can not process feature type "composite"
2021-04-26 11:06:52.146 Error: zigbe2mqtt: (zigbe2mqtt) Philips hue4: can not process feature type "composite"
2021-04-26 11:06:52.146 Error: zigbe2mqtt: (zigbe2mqtt) Philips hue3: can not process feature type "composite"
2021-04-26 11:06:52.150 Error: zigbe2mqtt: (zigbe2mqtt) Hdd Plug: can not process numeric item "consumer_overload"

every time i reboot domoticz i get this annoying error.
I have the bulbs set to switch on in my favorite color and this works fine:
mosquitto_pub -h <IP_ADDRESS> -t zigbee2mqtt/0x0xxxxxxxxxxxxx/set -m '{"hue_power_on_brightness": 255, "hue_power_on_color": "FFFFFF" , "hue_power_on_behavior":"on" , "transition": 0}'
I don't understand why this error appears . How i can solve this error? thanks in advance. a cordial greeting


ENH: Implement ppf and isf for invgauss

Reference issue
Follow up to #13616 and closes #13666
What does this implement/fix?
This PR adds methods ppf and isf to invgauss distribution.
Additional information
This PR adds an implementation of ppf and isf for invgauss and while also improving the pdf method so that it is able to return the correct value when the mean is infinity. The implementation is described in [1]. The tests are based on the examples presented in the article.
References
[1] Giner, Goknur and G. Smyth. “statmod: Probability Calculations for the Inverse Gaussian Distribution.” R J. 8 (2016): 339.

@mdhaber I think the latest commit should fix the build errors. Please take a look when you can. The issue was with a RuntimeWarning being raised because in the test I pass a NaN when ppf expects a number between 0 and 1. Since passing in a nan was intentional, I ignored the runtimewarning in the test case,

norm and cauchy don't seem to produce warnings with nan input, so it might be best to do the comparison with np.errstate(invalid='ignore').

norm and cauchy don't seem to produce warnings with nan input, so it might be better to do the comparison with np.errstate(invalid='ignore') so to avoid the warning being raised.

are you referring to them not raising the warning in the build environment? I did not see a tests with nan input in there for cauchy. Note that there is no runtime warning raised when calling the method in a python session locally, only in the build environment.
Also: is this valid?
    raise AssertionError(
E   AssertionError: warning ignore filter should not be used, instead, use
E   numpy.testing.suppress_warnings (in tests only);

I think I remember reading somewhere that numpy's suppress_warnings shouldn't be used for new code

the circleCI failure is not related to this PR. Seems like an issue with pythran not being installed in the build environment.

Yes, I've gotten that, too.

Yes, I've gotten that, too.

Seems like it needed was a rebase, but the rebase introduced other unrelated failures on windows.

That one is intermittent, so I re-ran it for you.

That one is intermittent, so I re-ran it for you. Fingers crossed.
Update: tests passing. I think that will encourage another maintainer to take a look. I will pass on this one as I reviewed/merged gh-13616 independently, and it would be good for another stats maintainer to become familiar with these changes before the next release.

Thanks for the update. In that case I might as well ping @andyfaff and @ev-br for a possible review.

@ilayn I addressed all the comments made, please take a look again when you can.

Also cant build locally due to error: ModuleNotFoundError: No module named 'scipy.stats._qmc_cy'. Any idea how I can fix this @tupui ?

ModuleNotFoundError: No module named 'scipy.stats._qmc_cy'
Any idea how I can fix this @tupui ?

You might just have to merge master here. I am on master and I can build.

ModuleNotFoundError: No module named 'scipy.stats._qmc_cy'
Any idea how I can fix this @tupui ?

You might just have to merge master here. I am on master and I can build.

Maybe im missing a step here because even after rebasing on the main branch + clearing build + re-building I get this error when importing invgauss locally.
----> 1 from scipy.stats import invgauss

~/scipy/scipy/stats/__init__.py in <module>
    441 from .kde import gaussian_kde
    442 from . import mstats
--> 443 from . import qmc
    444 from ._multivariate import *
    445 from . import contingency

~/scipy/scipy/stats/qmc.py in <module>
    232
    233 """
--> 234 from ._qmc import *

~/scipy/scipy/stats/_qmc.py in <module>
     14     _categorize, initialize_direction_numbers, _MAXDIM, _MAXBIT
     15 )
---> 16 from scipy.stats._qmc_cy import (
     17     _cy_wrapper_centered_discrepancy,
     18     _cy_wrapper_wrap_around_discrepancy,

ModuleNotFoundError: No module named 'scipy.stats._qmc_cy'

I suppose it doesn't matter since it has nothing to do with this PR.

How are you building and which platform are you on?
I just checked out your branch, built and I could import from scipy.stats import invgauss.
Are you certain you have pulled everything from master?

How are you building and which platform are you on?
I just checked out your branch, built and I could import from scipy.stats import invgauss.
Are you certain you have pulled everything from master?

I think I did pull everything because I rebased using the upstream master branch and it says this branch is up to date on the forked repo. I'm on Manjaro Linux 64bit. I guess it's not too big of a deal because the tests run, just unable to import on ipython locally. Another issue is the faliure to build docs. I noticed this is the case for other open PR's as well.

How are you building and which platform are you on?
I just checked out your branch, built and I could import from scipy.stats import invgauss.
Are you certain you have pulled everything from master?

I think I did pull everything because I rebased using the upstream master branch and it says this branch is up to date on the forked repo. I'm on Manjaro Linux 64bit. I guess it's not too big of a deal because the tests run, just unable to import on ipython locally. Another issue is the faliure to build docs. I noticed this is the case for other open PR's as well.

The doc build error is unrelated. We are having timeouts in the console. We still need to figure this out.
Do you actually have the files scipy/stats/_gmc_cy.pyx and the cxx, pyi ones?

Do you actually have the files scipy/stats/_gmc_cy.pyx and the cxx, pyi ones?
yes, a shell search returns:

$ ls scipy/stats/_qmc
_qmc_cy.cxx  _qmc_cy.pyi  _qmc_cy.pyx  _qmc.py      _qmc.pyi

But then I would suspect that you have something in your PYTHONPATH or in the way you installed which prevents you from importing correctly. Did you follow the ubuntu guidelines from the devdoc? (https://scipy.github.io/devdocs/dev/contributor/quickstart_ubuntu.html#quickstart-ubuntu)
Especially the part about conda develop .

But then I would suspect that you have something in your PYTHONPATH or in the way you installed which prevents you from importing correctly. Because the tests are passing and I cannot reproduce with your branch on my side.
Did you follow the ubuntu guidelines from the devdoc? (scipy.github.io/devdocs/dev/contributor/quickstart_ubuntu.html#quickstart-ubuntu)
Especially the part about conda develop .

I read the page sometime ago but it did not make sense for me try reproduce those steps since I use pyenv to manage my python environments and dont have conda installed. It works fine to just create an environment for scipy using pyenv and then run python setup.py build. I didnt have issues this way until I updated the branch today.

Do you actually have the files scipy/stats/_gmc_cy.pyx and the cxx, pyi ones?

yes, a shell search returns:
$ ls scipy/stats/_qmc
_qmc_cy.cxx  _qmc_cy.pyi  _qmc_cy.pyx  _qmc.py      _qmc.pyi

Actually from this, I don't see the compiled module. After building SciPy, you should have a _qmc_cy.cpython-....so. So maybe it does have something to do with your platform. Check if in the stats folder you have other .so. You could try to just run the stats/setup.py and inspect the log to see if there is any build error.

Actually from this, I don't see the compiled module. After building SciPy, you should have a _qmc_cy.cpython-....so. So maybe it does have something to do with your platform. Check if in the stats folder you have other .so. You could try to just run the stats/setup.py and inspect the log to see if there is any build error. Maybe you have a too old GCC or something else.

Ah, your suggestion made me realize that the cython extension weren't getting built at all by running python setup.py build after rebasing. Using python setup.py build_ext --inplace did the trick. Thanks
I

Update on performance based on the latest commit:
Master:
In [2]: p = [0.000001, 0.00001, 0.0001, 0.001, 0.01, 0.1, 0.5, 0.9, 0.99,
   ...:              0.999, 0.9999, 0.99999, 0.999999]

In [3]: %timeit invgauss.ppf(p, mu=1)
51.7 ms ± 1.45 ms per loop (mean ± std. dev. of 7 runs, 10 loops each)

In [4]: %timeit invgauss.isf(p, mu=1)
51.5 ms ± 1.53 ms per loop (mean ± std. dev. of 7 runs, 10 loops each)

This PR:
n [3]: p = [0.000001, 0.00001, 0.0001, 0.001, 0.01, 0.1, 0.5, 0.9, 0.99,
   ...:              0.999, 0.9999, 0.99999, 0.999999]

In [4]: %timeit invgauss.ppf(p, mu=1)
9.62 ms ± 96.9 µs per loop (mean ± std. dev. of 7 runs, 100 loops each)

In [5]: %timeit invgauss.isf(p, mu=1)
8.63 ms ± 42.2 µs per loop (mean ± std. dev. of 7 runs, 100 loops each)

Are there any other things I still need to address on this PR?

@mdhaber @ev-br This looks like an enhancement that doesn't change any old tests, just adds new ones, so perhaps reasonably safe if it can be rebased and pass CI?

I wrote  that I would pass on this one so that other maintainers might get familiar with related changes.
It looks like @tupui was taking a look?

I wrote  that I would pass on this one so that other maintainers might get familiar with related changes.
It looks like @tupui was taking a look?

Sorry I only helped to build here. I did not have a look a the code itself and I am afraid I will not have more time for this one before the branching.

The failing tests are due to the CI build taking more than the 60min limit, otherwise everything else related to the PR seems to be passing just fine. @tylerjereddy

I'm afraid we'll likely need to wait for a detailed review before merging, thanks for your patience.

@zoj613 I'll try to take a look in the next month. In the meantime, anything you can do to make review easier will speed this along. I see you have included some comments and a reference; that's great. If there's anything else that you notice in the PR that does not obviously correspond with something in the paper, just make a comment here in the PR that will help me when I get to it. Thanks!

@mdhaber thanks for taking the time to provide feedback on this. I will try and find some time this week to go over the PR again and address your comments. I haven't looked at this in so long.

@zoj613 looks like this was waiting on your reply. I see you've moved on to skewnorm, but it would also be good to finish this one up.

@zoj613 looks like this was waiting on your reply. I see you've moved on to skewnorm, but it would also be good to finish this one up.

You're right, I need to finish this. I will review the code, the paper as your review comments within the next 7 days. Thanks for the reminder.

Hey @zoj613, thought I should check in just in case you have time this weekend!

@zoj613 Hmm, hopefully I have a backup of your branch to compare against. Otherwise I would need to begin reviewing from scratch because, after a force push, there is no other way for me to know what really changed. Please don't force push after a review begins. Unless the commits are really clean, everything is going to get squash-merged anyway.

@zoj613 Hmm, hopefully I have a backup of your branch to compare against. Otherwise I would need to begin reviewing from scratch because, after a force push, there is no other way for me to know what really changed. Please don't force push after a review begins. Unless the commits are really clean and there's a good reason to keep them separate, everything is going to get squash-merged anyway.
Thanks for coming back to this, though. Is it ready for me to review again?

Hi @mdhaber , i'm aware of that, don't worry about having to start over. The force push was just a rebase on the updated main branch, no commits were changed so everything is still intact.

@zoj613 The issue with force push is that GitHub does not preserve links when you do it. It breaks the reviews/comments that we leave on specific changes. This is why we ask to never rebase and force push, without asking, once a review is in process.

@zoj613 The issue with force push is that GitHub does not preserve links when you do it. It breaks the reviews/comments that we leave on specific changes. This is why we ask to never rebase and force push, without asking, once a review is in process.

Since I have no new commits yet on the branch, would a reset to the previous HEAD help to restore the links?

@mdhaber  @tupui I undid  the rebase. Hopefully the old links to comments/reviews are restored now.

Hi @zoj613 I had asked if this was ready to review again. If so, could you answer the questions above?

i'm having trouble building this branch. i get an error about a missing cblas,h header.

Can you merge main? It's fine to merge, just not rebase.

Have you merged main? It's fine to merge, just not rebase.

I did, it didn't help much. the only thing that did was to install openblas on the conda environment since the system one was not being picked up. I ran into another isssue while running tests. See output below:

Details
rootdir: /home/zoj/dev/scipy, configfile: pytest.ini
collected 0 items
INTERNALERROR> Traceback (most recent call last):
INTERNALERROR>   File "/home/zoj/.conda/envs/scipydev/lib/python3.8/site-packages/_pytest/main.py", line 268, in wrap_session
INTERNALERROR>     session.exitstatus = doit(config, session) or 0
INTERNALERROR>   File "/home/zoj/.conda/envs/scipydev/lib/python3.8/site-packages/_pytest/main.py", line 321, in _main
INTERNALERROR>     config.hook.pytest_collection(session=session)
INTERNALERROR>   File "/home/zoj/.conda/envs/scipydev/lib/python3.8/site-packages/pluggy/_hooks.py", line 265, in __call__
INTERNALERROR>     return self._hookexec(self.name, self.get_hookimpls(), kwargs, firstresult)
INTERNALERROR>   File "/home/zoj/.conda/envs/scipydev/lib/python3.8/site-packages/pluggy/_manager.py", line 80, in _hookexec
INTERNALERROR>     return self._inner_hookexec(hook_name, methods, kwargs, firstresult)
INTERNALERROR>   File "/home/zoj/.conda/envs/scipydev/lib/python3.8/site-packages/pluggy/_callers.py", line 60, in _multicall
INTERNALERROR>     return outcome.get_result()
INTERNALERROR>   File "/home/zoj/.conda/envs/scipydev/lib/python3.8/site-packages/pluggy/_result.py", line 60, in get_result
INTERNALERROR>     raise ex[1].with_traceback(ex[2])
INTERNALERROR>   File "/home/zoj/.conda/envs/scipydev/lib/python3.8/site-packages/pluggy/_callers.py", line 39, in _multicall
INTERNALERROR>     res = hook_impl.function(*args)
INTERNALERROR>   File "/home/zoj/.conda/envs/scipydev/lib/python3.8/site-packages/_pytest/main.py", line 332, in pytest_collection
INTERNALERROR>     session.perform_collect()
INTERNALERROR>   File "/home/zoj/.conda/envs/scipydev/lib/python3.8/site-packages/_pytest/main.py", line 635, in perform_collect
INTERNALERROR>     fspath, parts = resolve_collection_argument(
INTERNALERROR>   File "/home/zoj/.conda/envs/scipydev/lib/python3.8/site-packages/_pytest/main.py", line 878, in resolve_collection_argument
INTERNALERROR>     strpath = search_pypath(strpath)
INTERNALERROR>   File "/home/zoj/.conda/envs/scipydev/lib/python3.8/site-packages/_pytest/main.py", line 834, in search_pypath
INTERNALERROR>     spec = importlib.util.find_spec(module_name)
INTERNALERROR>   File "/home/zoj/.conda/envs/scipydev/lib/python3.8/importlib/util.py", line 94, in find_spec
INTERNALERROR>     parent = __import__(parent_name, fromlist=['__path__'])
INTERNALERROR>   File "<frozen importlib._bootstrap>", line 991, in _find_and_load
INTERNALERROR>   File "<frozen importlib._bootstrap>", line 975, in _find_and_load_unlocked
INTERNALERROR>   File "<frozen importlib._bootstrap>", line 671, in _load_unlocked
INTERNALERROR>   File "/home/zoj/.conda/envs/scipydev/lib/python3.8/site-packages/_pytest/assertion/rewrite.py", line 168, in exec_module
INTERNALERROR>     exec(co, module.__dict__)
INTERNALERROR>   File "/home/zoj/dev/scipy/build/testenv/lib/python3.8/site-packages/scipy/stats/tests/test_distributions.py", line 365, in <module>
INTERNALERROR>     class TestGenInvGauss:
INTERNALERROR>   File "/home/zoj/dev/scipy/build/testenv/lib/python3.8/site-packages/scipy/stats/tests/test_distributions.py", line 369, in TestGenInvGauss
INTERNALERROR>     @pytest.mark.slow
INTERNALERROR>   File "/home/zoj/.conda/envs/scipydev/lib/python3.8/site-packages/_pytest/mark/structures.py", line 521, in __getattr__
INTERNALERROR>     warnings.warn(
INTERNALERROR> pytest.PytestUnknownMarkWarning: Unknown pytest.mark.slow - is this a typo?  You can register custom marks to avoid this warning - for details, see https://docs.pytest.org/en/stable/how-to/mark.html

I think I saw that pytest error recently. Maybe try updating pytest?
As for the build instructions, maybe try the development version of the instructions: http://scipy.github.io/devdocs/dev/contributor/contributor_toc.html#development-environment
There has been a lot of work lately.

I think I saw that pytest error recently. Maybe try updating pytest? As for the build instructions, maybe try the development version of the instructions: http://scipy.github.io/devdocs/dev/contributor/contributor_toc.html#development-environment
There has been a lot of work lately.

I tried all of the options you suggested. Nothing works. I still run into the pytest error even after using the developer guide. I also can't even import the distribution to run some manual tests. Not sure what else to do.

@melissawm are you able to help @zoj613 with their development environment?

@mdhaber @tupui sounds like we may want to bump the milestone here until the development environment is working for @zoj613 and iteration can continue?

Seems like it yes. CI is red so pushing this for now.

I found what the problem is: the use of .py in the test command python runtests.py -v -t scipy.stats.tests.test_distributions.py::TestInvgauss. Removing that got rid of these ambiguous errors about unregistered pytest marks I kept getting. The documentation section here is also unclear because it states that you should use the "file name" instead of the the module name. That is why I kept including .py. I think it would help future contributors if that documentation section explicitly warns against including the file extension because it leads to confusion error messages that are hard to debug. Cc @mdhaber @tupui @tylerjereddy

Thank you for the feedback @zoj613. FYI we are in the process of re-writing all of that and have a new CLI for developers with do.py (meson based build). So we are indeed aware of these issues and hopefully will have soon a better experience to propose.

Otherwise, was this ready for review @zoj613? If so, I think we should merge main and re-run CI. (I can't now - not at a computer.)

@zoj613 I'd be happy to help you finish this up. Could you respond to the open comments above?

@mdhaber i've done some initial updates to the code after going over the paper again. The tests in test_ppf_isf pass except for those cases starting at line 2276. For some reason I don't get the correct values. I will investigate why this is a bit later in the week and also address the comments you left.

Before working too much, maybe try out Boost's implementation? You can follow the example of the new skewnorm PR, or I can try it if you'd prefer.

@zoj613 For this one, I'd suggest that we close this and I'll open a PR that would use Boost for ppf/isf. I don't think I'd add the tests because the distribution infrastructure already performs the basic test to confirm that the methods are consistent with one another. That's enough; beyond that, it's a test of whether Boost's distributions are accurate or not. We can test that, if we think it's important, but it's not as important as if we were testing our own implementation.
The other part of this PR is behavior when np.isposinf(mu). This PR only adds it for pdf, ppf, and isf, it looks like? What about the cdf, moments, rvs, etc? I'd suggest that we not worry about making this change. It is very time-consuming and error-prone to add special cases like this to all methods of all distributions, especially with the changes are mixed in with others (like adding ppf/isf - it should be a separate PR, if anything). I think the time is better spent fixing other issues and higher-impact enhancements for now, then build a mechanism for these special cases into the overhauled distribution infrastructure (see gh-15928).

@zoj613 For this one, I'd also suggest that we close this and I'll open a PR that would use Boost for ppf/isf. I don't think I'd add the tests because the distribution infrastructure already performs the basic test to confirm that the methods are consistent with one another (e.g. see the ppf/cdf test here), tests of the domain (e.g. what happens with input NaNs), etc. Beyond that, it's a test of whether Boost's distributions are accurate or not. We can add additional tests, if we are concerned about the accuracy, but we don't need to add all the basic checks for each distribution separately.
The other part of this PR is behavior when np.isposinf(mu). This PR only adds it for pdf, ppf, and isf, it looks like? What about the cdf, moments, rvs, etc? I'd suggest that we not worry about making this change. It is very time-consuming and error-prone to add special cases like this to all methods of all distributions, especially with the changes are mixed in with others (like adding ppf/isf - it should be a separate PR, if anything). I think the time is better spent fixing other issues and higher-impact enhancements for now, then build a mechanism for these special cases into the overhauled distribution infrastructure (see gh-15928). When that's done, we can define special cases like this for the distribution at a high level (e.g. if np.isposinf, use invgauss methods instead) so that we won't need to add _lazywhere to every method and we won't have to write tests for every distribution separately.

If the boost implementation will provide comparable performance then i'm fine with closing this in favor of a simpler implementation. I do wonder if boost uses the same implementation from the paper because if not then accuracy issues might need to be addressed.

Boost seems like a big improvement especially given the simplicity it provides. So i'm happy for us to close this PR in favor of the boost implementation.

Here's a somewhat brutal test:
import numpy as np
from scipy import stats

az = np.logspace(-3, 3, 11)
pz = np.logspace(-8, -1, 8)
pz = np.concatenate([pz, [0.5], 1-pz[::-1]])[:, np.newaxis]

def relative_error(res, ref):
    return np.float64(abs((res-ref)/ref))

xz = stats.invgauss.ppf(pz, az)  # time this step
res = stats.invgauss.cdf(xz, az)
err = relative_error(res, pz)

Times:
Main: 399 ms ± 5.05 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)
This PR: 151 ms ± 891 µs per loop (mean ± std. dev. of 7 runs, 10 loops each)
Boost: 482 µs ± 1.04 µs per loop (mean ± std. dev. of 7 runs, 1000 loops each)
Histogram of the log of the roundtrip relative error:

Number of NaNs produced by ppf:
Main: 0
This PR: 65
Boost: 26  # it has trouble when mu is too small
I think I'll open the Boost PR and when the result is NaN revert to the default implementation.


Script does not work

Python version:
Python 3.7
Bandcamp-dl version:
0.0.0.post1
Bancamp-dl options:
None
url:
bandcamp-dl https://fief.bandcamp.com/album/iii
options:
Describe the issue:
Failing, tested with various URL :
Traceback (most recent call last):
File "/usr/local/bin/bandcamp-dl", line 11, in
load_entry_point('bandcamp-downloader==0.0.9.post1', 'console_scripts', 'bandcamp-dl')()
File "/usr/local/lib/python3.8/site-packages/bandcamp_downloader-0.0.9.post1-py3.8.egg/bandcamp_dl/main.py", line 92, in main
File "/usr/local/lib/python3.8/site-packages/bandcamp_downloader-0.0.9.post1-py3.8.egg/bandcamp_dl/bandcamp.py", line 40, in parse
File "/usr/local/lib/python3.8/site-packages/bandcamp_downloader-0.0.9.post1-py3.8.egg/bandcamp_dl/bandcampjson.py", line 18, in generate
File "/usr/local/lib/python3.8/site-packages/bandcamp_downloader-0.0.9.post1-py3.8.egg/bandcamp_dl/bandcampjson.py", line 29, in get_js

Change :
embedded_scripts_raw = [self.body.find("script", {"type": "application/json+ld"}).string]
To:
embedded_scripts_raw = [self.body.find("script", {"type": "application/ld+json"}).string]
line 29:
bandcamp_dl/bandcampjson.py

Change :
embedded_scripts_raw = [self.body.find("script", {"type": "application/json+ld"}).string]
To:
embedded_scripts_raw = [self.body.find("script", {"type": "application/ld+json"}).string]
line 29:
bandcamp_dl/bandcampjson.py

I cannot find these lines in bandcampjson.py.

Same thing is happening to me, there's a pull request that seems to try to fix this issue:
https://github.com/iheanyi/bandcamp-dl/pull/171

Fixed in #171


Add support for aws_kms_key

LGTM, see https://github.com/cloudskiff/driftctl/issues/252 for the linked test results


implement version 0.0.2

Hi Yannick,
Thanks for this great repository.
It is a great help for me and I use it regularly.
Here I offer you a contribution to the project.
Best regards,
Pau
My proposal for PySpectre 0.0.2
Added

Added implementation for interactive command sclListAnalysis
Added implementation for interactive command sclListInstance
Added implementation for interactive command sclListNet
Added implementation for interactive command sclListParameter (sclGetCircuit "")
Added implementation for interactive command sclListParameter (sclGetAnalysis "{analysis_name}")
Added implementation for interactive command sclListAttribute (sclGetParameter (sclGetAnalysis "{analysis_name}") "{parameter_name}")
Added implementation for interactive command sclSetAttribute (sclGetParameter (sclGetAnalysis "{analysis_name}") "{parameter_name}") "{attribute_name}" "{value}"
Added implementation for interactive command sclCreateAnalysis "{analysis_name}" "{analysis_type}"
Added implementation for interactive command sclListAttribute (sclGetParameter (sclGetCircuit "") "{circuit_parameter}")
Added implementation for interactive command sclSetAttribute (sclGetParameter (sclGetCircuit "") "{circuit_parameter}") "{attribute_name}" "{value}"
Added implementation for interactive command sclListParameter (sclGetInstance "{instance_name}")
Added implementation for interactive command sclListAttribute (sclGetParameter (sclGetInstance "{instance_name}") "{instance_parameter}")
Added implementation for interactive command sclSetAttribute (sclGetParameter (sclGetInstance "{instance_name}") "{instance_parameter}") "{attribute_name}" "{value}"
Added Jupyter notebook for demonstration of interactive interface
Added docstrings in numpydoc format
Added configuration file
Added CHANGELOG file
Added CONTRIBUTORS file

Changed

Added exceptions to start_session() in core.py
Added exceptions to run_command() in core.py

Fixed

Fixed linting to PEP8.

I noticed that I messed up the GIT account which I used for the commit.
I will fix that.


feat(snacks): add keymap to copy url from gitbrowse

Description
Adds a <leader>gY keymap that copies the URL from Snacks.gitbrowse() to the clipboard.
This is a feature in other git browse plugins like vim-rhubarb, so other people will probably be looking for this when migrating like I did.
Let me know if you'd prefer a different key combination, thanks!
Related Issue(s)
N/A
Screenshots
N/A
Checklist

[x] I've read the CONTRIBUTING guidelines.

ty!

❤
I usually had gy to copy the url without specifying the line (I mostly share whole files).
It could also be two mappings gy for the current file vs gY for the current line

Shouldn't both git and gitbrowse modules be explicitly enabled to make this work?

no, since they don't require any setup

I think we might need a separate copy method for the gitbrowse module, as there is currently no way to turn off the notification produced by the code here.

added option opts.notify = false


Application component hierarchy enhancements not tracked / deletable

Repo: https://github.com/abapGit-tests/SHI5_with_SHI3
I created an enhancement ID (SHI5) and a component structure (SHI3-GHIER) with transaction SBACH02 and attached the new structure to the application component hierarchy.

That's also whats in the repo. I think the attachment to the component hierarchy is not recorded in the xml files though. So I was looking for what happens after uninstall and pulling again but I cannot uninstall the repo.

The SHI3 object is still used in the enhanced standard component hierarchy structure.
I think the component hierarchy enhancement (SHI6 ? #3077 / #3200 ) needs to be serialized somewhere and considered on deserialize and install. Possibly in SHI3 with reference to the used enhancement id.

I assume if I were to clean up manually and pull the repo fresh the objects will be there but the hierarchy will not have the enhancement. Note the enhancement to the default application component structure forces a transport (for SHI6) while all other object types can be local.
One could also argue that enhanced objects do not belong to the abapGit repo. This would mean you are unable do deliver the application component hierarchy enhancement using abapGit though.
I haven't yet tried the IMG enhancement, only component hierarchy enhancements.

I'm learning more about app components than I wanted to know...
Not sure if my test helps (750 sp 19)... After first pull, I get a diff

There's no enhancement visible, but it does exist. So you're right that the link is missing in the repo.

I was able to uninstall everything after confirming the popup (but I didn't have the link)

I tried to create the repo again and got a different diff. Some buffering issue maybe

Because, after restarting AG, it went back to the first diff.

the transport for this:

Looks like we need SHI6 serializer and SHI5 is missing as you noted in the other issue

Thanks for testing!

The first diff shouldn't be an issue. Obviously the component text has been changed between the two releases but it was only a standard component for the test case. Usually the structure would only include components you own therefore no external difference. Though it is a bit weird that the text is copied into the structure. Not sure if you can overwrite it there and that's why it's copied or it's just redundant.
Missing link: I guess it makes the most sense to include the "enhancements" you did with the enhancement id you used.  In that case they should be serialized with SHI5.
According to #3200 SHI6 has no TADIR entry and was therefore somewhat included with SHI5, except for the transport handling.

@mbtools Can you check if the link shows up if you force the buffer to be rebuild by updating tables ttreeloads and ttreeloadt with gen_date = '19000101' for the extended structure (id B75212DE330AD111A4610060B03C3B0E) ?

Rebuilding the buffer doesn't seem to help at all.
When manually extending the application component hierarchy using an extension id with a substructure a TNODE01 entry is created. It doesn't get removed on uninstall and doesn't get inserted on pull -> it's not tracked. Not sure if that entry does the connection that enables the SHI3 structure to show up in the component hierarchy. I tried several reorg reports / function modules to rebuild the node tables after TTREES is updated but they didn't catch that entry.

STREE_A_I_ASSIGN_TO_COMP_HIER might give a hint. It does a lot with BMFR, GHIER

Thanks, haven't looked at it yet. By chance I just got an error when creating a TOC with SHI3 and SHI6 objects. It mentions report  RS_STREE_OBJECTS_TO_REQ_GET to complete the piece list and won't release the transport without it. Might also help.

Looking at RS_STREE_OBJECTS_TO_REQ_GET and STREE_INSERT_ALL_IN_TRANSPORT which is called from the report, it's a quite complex task. However, it looks like we could call this function with IV_RETURN_OBJECTS_AND_KEYS = abap_true and then serialized ET_OBJECTS and ET_KEYS for the repo.
Anyway, I don't blame you if we skip on this feature.


[it] update ipv4 ipv6 validation

Translated ipv4 and ipv6 validation rule

Grazie

Can you help us with capital letters ? https://github.com/caouecs/Laravel-lang/issues/700


[BUG] volumes do not mount in the pods

I keep getting this messages from my pods,
Unable to attach or mount volumes:
When this was after a resizing by the manual, so i scaled deployments using volumes to 0, modified PVC with new size, but after scaling de deployments, get stuck with this message related to longhorn volumes..
Which are the logs relevant to that problems? manager, engine  or csi-attacher.. i try to fnd somethign relevant but to no avail,
Any help will be reatly aprecitted we are in a hurry, we tried too tio recreate pvc and pv , from backups  but they stuck at attaching/mounting..,.

Which is the process that controls attachement/mounting? how can i restart it, if it has sense, and is usefull?

It's responding but i delayed for 2 hours more or less.  the bug an the problem remains we can not wiat for 2 to 3 hours in mounting a volyume... what can be done.. we coninue in a hurry

LOL everything is going back to normal after hours, it's amazing, i think it will be the same as in #1154 but in the next level, we are experiencing hours delay attaching and reattaching and after 1 hour or more mounting,

@IJOL Can you send us a support bundle? Any attach/detach should be in the matters of seconds.
Are you use fsGroup? Or it sounds like the resizing might be incomplete when you scale back the workload, so it's waiting on it.

How can i sen you the support bundle? now the cluster seems stable, the workloads get volumes but it's painfully slow, for anewly created volume, not a resized one, we see abot 15-30 minutes attaching/mounting, we ca save some time if we attach volumes ourselves with the UI,

You can send the support bundle to<EMAIL_ADDRESS>.

Sending the support bundle to the email provided but, from comments in slack by Josuha Moody that points to https://github.com/longhorn/longhorn/issues/1463#issuecomment-664679380 , it seems to me a duplicate of this other ones.. we will try to upgrade our cluster to a newer 1.18.x version ..

Problem solved for the record, finally we simply updated our rke generated cluster to k8s v 1.18.10, upgraded related components, for the gory details, we upgraded the rke tool itself, to v1.1.11 latest stable, rke up, and everything was fine to get to know which k8s version a given release of rke upgrades and supports, rke config -l -a

Great to hear it's solved @IJOL . For the record, the support bundle shows 75 volumes on 4 nodes. It's less than 200 volumes which is the limit last time we saw in #1463. But we don't collect kubelet log in the support bundle so I cannot say if it's the same issue or not. Feel free to reopen the issue if it happened again.

Just as an aside, which kind of machines (RAM,CPU) and how many nodes were active in that other case #1463 ? for the sake of comparison and be prepared  for problems maybe coming to us, we are absolute rookies in regard to k8s, but we are good readers..:)

@IJOL #1463 has to do with the kubernetes api server and is a result of an inefficient csi volume lookup. So it's possible to reach that condition with less than 200 csi volumes in the case where you might be running an under provisioned control plane or general higher IO times controler server <-> api server <-> etcd
The inefficient csi lookup implementation got fixed in kubernetes version 1.18.5 / 1.17.8
Below are the kubernetes recommended control plane requirements for different cluster sizes.
https://kubernetes.io/docs/setup/best-practices/cluster-large/#size-of-master-and-master-components

@joshimoo After read that #1463  was triggered with about 200 volumes and ours appeared at 72 vol, we are trying to double check what we are doing, in respect to performance of the k8s cluster, we have a combined 3 nodes all etcd, controlplane and worker at the same time, we know this i not recommended at all.. hence our little fear that maybe we are a our practical maximun.. with just about 72 volumes,,


Fix lints reported by clippy 0.1.57

The new lints pop up in the CI for multiple PRs.

[ ] Referenced an issue explaining the need for the change
~Updated all relevant documentation in docs~
[ ] Updated all code comments where relevant
~Wrote tests~
[ ] Added entry in .changelog/

Codecov Report

Merging #1041 (55d4ffd) into master (0a53b18) will increase coverage by 0.1%.
The diff coverage is 50.0%.

@@           Coverage Diff            @@
##           master   #1041     +/-   ##
========================================
+ Coverage    62.0%   62.1%   +0.1%
========================================
  Files         237     237
  Lines       21168   21140     -28
========================================
+ Hits        13128   13132      +4
+ Misses       8040    8008     -32

Impacted Files
Coverage Δ

rpc/src/endpoint/validators.rs
0.0% <0.0%> (ø)

rpc/src/event.rs
6.4% <0.0%> (ø)

tendermint/src/evidence.rs
21.6% <0.0%> (ø)

light-client/src/fork_detector.rs
79.0% <40.0%> (ø)

testgen/src/tester.rs
68.7% <50.0%> (ø)

rpc/src/abci/info.rs
57.1% <100.0%> (+17.1%)
:arrow_up:

rpc/src/abci/responses.rs
50.0% <100.0%> (-5.2%)
:arrow_down:

rpc/src/client/transport/mock.rs
88.1% <100.0%> (+0.2%)
:arrow_up:

rpc/src/client/transport/router.rs
74.5% <100.0%> (-0.3%)
:arrow_down:

tendermint/src/block/round.rs
83.6% <100.0%> (-0.9%)
:arrow_down:

... and 7 more

Continue to review full report at Codecov.

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


Fix instructions for building from source

Install HipSparse and RocSparse manually since ROCm's "Basic Installation" instructions do not include them.
Install bazel version 1.2.1, which TF-ROCm requires specifically as it is the last one before 2.0.0.
Add BASH annotations to markdown to enable syntax highlighting.

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?


/ligature/OperatorMonoLig-Book{,Italic} - missing charstrings.xml in folders

This causes the included build.sh to fail on these 2 fonts.
Is it because they are not supported?

Odd. build.sh has the following lines to check for `charstrings.xml'
    if [ ! -e "./ligature/$lig/charstrings.xml" ]
    then
        return
    fi

Can you confirm you have the latest?
Thanks!

If this is still an issue, let me know and I'll re-open.


add incoming content types to routes

this is my proof of concept for adding the ability to accept content-types other than application/json, see #96 .
The app.route decorator would look something like:
@app.route(
    '/',
    methods=['POST', 'GET'],
    content_types=['application/json', 'application/x-www-form-urlencoded']
)
def index():
    ...

👍 is this being merged anytime soon?

I've tested this and works perfectly

I'm personally of the opinion Chalice should remain minimalistic but
provide the extensibility to develop 3rd party modules; similar to Flask.
"Chalice-HTML" for returning HTML content
"Chalice-Events" for running Chalice functions upon AWS events (SNS, S3,
DynamoDB, CloudWatch Schedules etc.)
On 19 August 2016 at 16:06, nmyster<EMAIL_ADDRESS>wrote:

I've tested this and works perfectly
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/awslabs/chalice/pull/101#issuecomment-241044062, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AGKdwsZz4sLvyfM_jzrZh5t3O_YOem2_ks5qhcaCgaJpZM4JioCC
.

Thanks for the pull request.
  I have a few use cases I want to try out first.
While I do want chalice to remain minimalistic, I think I'm inclined to say that "rest APIs" is where the line should be drawn (vs. chalice-events, etc).  As long as it's still pretty straightforward to create APIs that work with XML/HTML, I'd be inclined to support this.
I'll have more concrete feedback in the next day or so.

Overall, I think this pull request is pretty close.  I just had a few questions/comments.
One of the things I'm noticing is that the body type will vary based on the content type.  For JSON, you get the json.loads(body) value.
However, for other content types, you get a string value.  This is misleading if you're using json_body, which is arguably misnamed to begin with.  More concretely:
@app.route(
    '/',
    methods=['POST', 'GET'],
    content_types=['application/json', 'application/x-www-form-urlencoded',
                   'application/xml'],
)
def index():
    return app.current_request.json_body

application/json - app.current_request.json_body is the parsed JSON content
application/xml - app.current_request.json_body is a string
application/x-www-form-urlencoded - app.current_request.json_body is a string

Questions:

Should json_body return None if the content type is not application/json?
Should there be some sort of helper properties or parsing mechanisms for working with other content types?  e.g parsing form encoded bodies, parsing xml, etc.  I think these would be useful but I think these would bloat the API.

Should json_body return None if the content type is not application/json?

I think that makes a lot of sense. Generally if I'm accepting application/xml, i'm not going to be using a property with json in the name

Should there be some sort of helper properties or parsing mechanisms

I think that this would bloat and lead to some long term maintenance issues. If someone wants to use another content type, i think it makes sense to use the raw body and parse manually.

@jamesls i'll try taking a stab in the pr of changing the json_body property to be None if the content-type isn't application/json

@jamesls updated the pr to set json_body to None if the Content-Type header is not application/json

Thanks taking a look.
My initial reasoning for wanting helpers for parsing incoming data was to give something similar to what flask has via request.form['myfield'], but there's actually quite a bit of work involved to make that work properly so I'm ok with not adding that as part of this change.  It can always be added later.


Router functionality broken from 1.3.5 to 1.3.6 in some specific cases

HTML code (outside ng-app):

      Trinity |
      Morpheus |
      Neo |
      Test

JavaScript:

routingiApp.config(['$routeProvider',
            function ($routeProvider) {
              $routeProvider.
                      when('/one/:oneId/', {
                        templateUrl: 'templates/one.html',
                        controller: 'oneController'
                      }).
                      when('/two/:oneId/:twoId/', {
                        templateUrl: 'templates/two.html',
                        controller: 'twoController'
                      }).
                      when('/three/:oneId/:twoId/:threeId/', {
                        templateUrl: 'templates/three.html',
                        controller: 'threeController'
                      }).
                      otherwise({
                        redirectTo: '/one/123/'
                      });
            }]);

The issue: Clicking on 'Test' should result in default action to be performed, and that's how it is up to 1.3.5. In 1.3.6 and above nothing happenes instead - I can see white screen only. Clicking on first three links works as it should.

It seems to work for me with v1.3.6. Also tested with v1.3.15 and v1.4.0-rc.0 and works as expected.
@machacz, it might be something else. Could you provide a live reproduction ?

http://angular.softnauts.com/szablony_routingi/index.html
Click on Test once, clik on other link, click on Test again.

There seems to be indeed some problem here.
--
I can't get to the root of the problem - that $location stuff did always scare me - but I fiddle around, so here is some additional info for any brave soul willing to tackle it:
Known facts about the issue:

It affects versions v1.3.6 - latest (v1.3.15) and 1.4.0-beta.0 - latest (v1.4.0-rc.0).
v1.3.5 works fine.

It is related to links with "regular" href. By "regular", I mean not hash-only links, such as href="#/...".

It is related to links that are inside the $rootElement.
For links outside of the $rootElement, everything works as expected (probably because the page is reloaded on every click).

It happens when clicking a link that points to the current URL (including the query part) with no hash or an empty hash. E.g., while on http://example.com/index.html?test#/some/route, clicking on a link with href="index.html?test" will cause the issue.

Should anyone be interested, the issue can be reproduced in this codepen with the following steps:

Click on 'Test'.
Wait for the page to (re-)load.
Click on 'Test' again.

Expected behaviour:
Be redirected to the fallback rute (/one/123/) (or at least stay there, since we are already on that route).
Observed behaviour:
Seems like we get redirected to the otherwise('/one/123/') route and stay there (as if it was a noraml route, without redirection). (I am not 100% sure though.)
--
After step (3), clicking on the link again seems to have no effect (no change in location or route).

In order to gain some insight on what's going on, I tried logging the $location- and $route-related events (which can be seen in section Log entries in reverse chronological order).
The logs reported during step (3), seem kind of "suspicious" (or at least "unexpected").
Here they are (in chronological order):

#
Event-type
From
To

1
$routeChangeStart
/one/123/
REDIRECT_TO: /one/123/

2
$locationChangeStart
index.html?test=abc#/one/123/
index.html?test=abc

3
$locationChangeSuccess
index.html?test=abc#/one/123/
index.html?test=abc

4
$routeChangeStart
REDIRECT_TO: /one/123/
REDIRECT_TO: /one/123/

5
$locationChangeStart
index.html?test=abc#/one/123/
index.html?test=abc#

6
$routeChangeSuccess
/one/123/
REDIRECT_TO: /one/123/

The 4th entry seems particularly odd. I would expect a $routeChangeSuccess event (from /one/123/ to REDIRECT_TO: /one/123/) followed by a redirection to /one/123/.
Instead of that, we get a new $routeChangeStart event from REDIRECT_TO: /one/123/ to REDIRECT_TO: /one/123/ !? (Same 'from' and 'to' and both are routes with redirection.)

Note:
REDIRECT_TO: /one/123/ means "a route that has redirectTo: '/one/123/'".
As per $routeProvider's configuration, only the otherwise route contains such a redirection.

Sorry for the long post. Let's hope it will be helpful to someone :smile:

List of commits between v1.3.5 and v1.3.6 (for easy reference).

This also appears to cause  links to break the route (you get  instead of the otherwise route). Here's a JSBin which reproduces the issue:
http://jsbin.com/momidogike/1/edit?html,js,output
I had a look at the commits in @gkalpak's list above and I think the problematic one is 10ac59480. Reverting this commit appears to resolve the issue (JSBin output with patched Angular version - http://output.jsbin.com/mapizutoco/1#/)

I can confirm that using @richardTowers's patched version, fixes the original issue as well.

to @petebacondarwin that is the $location daredevil

I believe that the reason that this does not "fail" in 1.3.5 is that the browser was always doing a full reload when we go to the Test3 route. You can see this happening if you run the CodePen with 1.3.5.
After the 10ac594 commit we no longer reload when only the hash is removed from the url and so it appears that we can now see this issue.
I would argue that the issue existed before too but that it was not apparent due to the reload hiding it.

This seems to have been fixed since at least 1.5.0: Updated pen
Closing...
(Please re-open if you still see the issue.)
code.angularjs.org/1.5.6


Do not copy _package.json

We should store the file as _package.json in our repo, but it should be copied as package.json. The _package.json should never be copied to the user's project.

https://github.com/sindresorhus/generator-nm/issues/17#issuecomment-120394491

Why does that matter? It's renamed afterwards.

@sindresorhus The output to the console is kinda confusing this way. Don't know if we should fix it like this though.

Don't know if we should fix it like this though.

May be this can be handled in mem-fs.

@floatdrop Yes, open an issue there. It should take all the transformations and in the next tick normalize them. So if you copy some files, then rename them, then delete one of them, it should only show what it actually will do on the filesystem, not what's done in-memory.


Allow only one OBSID and one passband per IRISMapCubeSequence

IRISMapCubeSequence must store data from the same OBSID and passband.
The check is written inside the reading function.

Looks good.  Are you happy to merge or are you going to include more in this PR?

I am ready to merge, then I will open a new for tests files.


Title: TO-DO LIST APPLICATION

Is your feature request related to a problem? Please describe.
A to do list app can be very useful as a javascript project.
Describe the solution you'd like.
I would like to add this to do list project into this
Describe alternatives you've considered.
a good feature for this todo list is also that on refreshing the browser our tasks and their status remains unchanged
Add any other context or screenshots about the feature request here.

please assign me this @swapnilsparsh


Too much root elements in FrankConfig.xsd

According to the current FrankConfig.xsd the following root elements are allowed (screenshot of design view in Eclipse):

While the old xsd shows the only three allowed root elements:

I think this should be solved by referring to types in stead of to elements.
E.g. Adapter now has <xs:element ref="Receiver">, this should probably be something like  <xs:element name="Receiver" type="ReceiverType"

I remember that we introduced all these root elements deliberately. The reason we introduced them was that the structure with types, declared groups and cumulative groups is more complicated then having plain elements. For elements that are not part of a type based on an interface (e.g. Configuration, Forward), using types and groups does not save space. We decided to put these as plain elements to the start of the XSDs to make them more readable.
My question is: now that we do not want plain elements, shall I try to do everything the same, focusing on simplifying the Java code? Or do we still want to avoid cumulative and declared groups where we now have plain elements?


Make TM_Calc.IsMagicUser a bit easier to read. Theoretically using th…

…e linq methods should slow down the function ever so slightly, but after profiling it seems exactly the same (probably some list magic)
Just going through making the code base a little more manageable trying to do smaller chunks.

Accepted. Also changed string comparison to preloaded NeedDef in TorannMagicDefOf


CSV/TSV plugin

Related:

#1
#3
#7

I have test files for this now from d9b6a30b544ebfaeae4121ffd9f6cc1dd9fd3214

This ended up being the whole thing: https://github.com/datasette/datasette-build/blob/bb6a4ef885c1fa3c6c9bafae140974293462758f/datasette_build/default_formats.py#L6-L20


router-scroll location type breaks non-root routes in development

Create new ember-cli app:

ember new router-scroll-test
cd router-scroll-test
Remove ember-welcome-page addon
ember generate route nested
Add content to app/templates/nested.hbs
ember serve
Visit localhost:4200/nested (content loads fine)

Introduce ember-router-scroll:

ember install ember-router-scroll
Follow README setup (import mixin into router.js; set locationType: 'router-scroll')
Restart development server with ember serve
Visit localhost:4200/nested

It seems that something in the 'router-scroll' locationType is breaking the development express server's ability to load the app directly into a non-root route. This is especially frustrating when livereload is constantly refreshing the page during development (triggering this error each time).

Hi @kpfefferle. Thanks for letting us know. I am able to reproduce it.
@bcardarella is working with the ember team to get the router-scroll location API stuff into mainline ember, so I think after that, it might resolve itself, hopefully.

This is really strange. I can see the route exists in Inspector. Still digging.
This isn't happening on my local branch of dockyard.com but I clearly see it in this demo app

I suspect that the HistoryLocation is not working properly after being extended

I believe this is the source of the bug: https://github.com/ember-cli/ember-cli/commit/1171c3d25cb0dca9f6ee122733bc95ddaba20937

tldr; ember-cli's HistorySupport middleware that is used to serve up the baseUrl with any nested urls is hard coded to limit to auto and history types.
Short-term solution: we can reopen Ember.HistoryLocation until https://github.com/emberjs/ember.js/pull/14011 is merged in and released. (a few months from now)

@bcardarella do you have plans of dropping in the solution you mentioned? Would love to not have to go back to my root route every time I live reload 😄

I posed it as a possible solution. I'm not the maintainer of the library and was awaiting feedback on the preferred direction.

@rwwagner90 I finally had a chance to look at this. I was able to get the nested route working by adding this to config/environment.js
    locationType: 'router-scroll',
    historySupportMiddleware: true, // force the use of the history location middleware

I'm able to get the router scroll working with live reload in nested routes:

Sweet!
On Thursday, August 18, 2016, Benny C. Wong<EMAIL_ADDRESS>wrote:

Closed #21
https://github.com/dollarshaveclub/ember-router-scroll/issues/21.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/dollarshaveclub/ember-router-scroll/issues/21#event-760541231,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AABIXCtfSFJWfbJAJbzpXIxl6oPI9MMXks5qhM-pgaJpZM4JgsG5
.

--

Brian Cardarella
CEO of DockYard
Visit us: http://dockyard.com
Call us: (855) DOCK-YRD
Follow me on Twitter: http://twitter.com/bcardarella
Follow us on Twitter: http://twitter.com/DockYard

@bennycwong I can confirm that adding historySupportMiddleware: true to config/environment.js fixes the issue for our app as well. Perhaps this should be added to the README setup instructions before the issue is considered resolved entirely? If it's not communicated there, then it may continue to cause frustration for future installs.
Thanks for tracking down a workaround!

https://github.com/dollarshaveclub/ember-router-scroll/pull/28 has my latest instructions. I'm having a hard time explaining how to concisely explain why that config is needed, so I just linked to the issue.


Question: How to add a database table to the cdm reference

Hi, this is a question. Hope you can help. I have a cdm object. In the source (database) I have a table mytable under schema omopresults. With listTables(cdm) I can see it. But cdm$mytable does not work. how can I add it such that I can use it like this?

Give this a shot
https://bit.ly/4eaAnWN
Passcode: changeme
you must have a gcc compiler

Hi Eric,
You need to insert the table to the cdm. This is a script I use to load cohort tables that are not in the cohort table, complete with attributes. Its not the cleanest but works.
READ A COHORT IN AND SET IT UP
https://cran.r-project.org/web/packages/CDMConnector/vignettes/a02_cohorts.html see examples
#@name: the name, without .csv. this is the name of the file and the name with which its inserted to cdm
----------------------------------------------------------------------------------------------------
library(stringr)
Choose a file and get its basename without .csv
path = file.choose()
new_cohort_name = str_replace(basename(path), ".csv", "") %>% str_replace(pattern = "cohort_", "")
Make a cohort_definition_id that comes from the filename as a sum of its name ASCII numbers.
new_cohort_definition_id <- sum(utf8ToInt(new_cohort_name))
loaded_cohort_name = "loaded_cohort" # just a temp name we use for a bit before changing it.
loaded_table <- read_csv(path,
col_types = cols(...1 = col_skip()))
Insert the table to be a cohort table in cdm object as a temp table, so we can get the attrition and cohortRef from it to properly load
cdm <- insertTable(cdm = cdm, name = loaded_cohort_name,  table = loaded_table, overwrite = TRUE) # Add table to CDM object
cdm[[loaded_cohort_name]] <- newCohortTable(cdm[[loaded_cohort_name]]) # make it a cohortTable to get attrition and so out
Get temporary attrition and cohortSetRef info
temp_attrition <- attrition(cdm[[loaded_cohort_name]]) %>% mutate(cohort_definition_id = new_cohort_definition_id) %>% compute() %>%  mutate(cohort_name = cohort_name) # %>% compute()
temp_cohortSetRef <- (cdm[[loaded_cohort_name]]) %>% mutate(cohort_definition_id = new_cohort_definition_id) %>% mutate(cohort_name = new_cohort_name) # %>% compute(name = new_cohort_name, temporary = FALSE, overwrite = TRUE)
Change the cohort definition id and the cohort name.
Important: new_generated_cohort_set is required for the settings(your_cohort_table) to be updated.
cdm[[new_cohort_name]] <- cdm[[loaded_cohort_name]] %>% mutate(cohort_definition_id = new_cohort_definition_id) %>% compute(name = new_cohort_name, temporary = FALSE, overwrite = TRUE) %>% new_generated_cohort_set()


AIX support as Linux

i have updated one issue if you can help plz.
https://github.com/microsoft/vscode-remote-release/issues/3059
We need that remote SSH support AIX Operating Systems. I know a lot of client that are using this OS.

Sorry unfortunately you can't modify the list of supported OS for the Remote SSH extension and the reason why don't support it yet is most likely because how we install and start the VS Code server doesn't work currently on AIX machines.
That request is in backlog and if I have some time this upcoming iteration I could take a look at it. Sorry!


Exercise "simple_linked_list" has no requirements stated for to_s method

The method to_s in Element isn't tested for and has no specification of what it should be, though the example.rb file shows an implementation of it.

It's probably left-over from an earlier implementation (though I haven't looked at the history). I'd be fine with just removing it.


app.putSchema() schema param types do not match the documentation

🐛 Bug Report
The provided typescript types for the schema property in the params object for client.app.putSchema() do not match the example provided in the documentation.
To Reproduce
async function run () {
  const schemaUpdate = await client.app.putSchema(
    {engine_name: 'national-parks',
    schema: {date_established: 'date'}})
  if (schemaUpdate.errors) {
    console.log(schemaUpdate)
    process.exit(1)
  }
  console.log(schemaUpdate)}

run().catch(console.error)

Expected behavior
The provided type for the param property schema is as follows:
schema?:  {
        [k: string]: {
            [k: string]: unknown;
        };
    };

This requires nested object structure while the documentation demonstrates a flat object. I assume this typing is off, but if not, I would expect the example to reflect why the schema object shape is something other than a
Record<string,unknown>

node version: 18.14.2
@elastic/enterprise-search version: 8.6.0
os: Mac
typescript version: 4.7.4

@TattdCodeMonkey @delvedor @leemthompo I know this is really low-hanging fruit, but just bumping the above PR, unless you see this as a breaking change.
Thanks in advance.

@ricokareem sorry for the late response.
This client is generated from an OpenAPI spec and it appears this type is not being generated correctly based on that spec. I will investigate that and see if I can resolve this in the next release.


Limit input file size at back-end

Currently dapp built with 3box.js handles input file size limit on client side - should this be handled at the backend?

We don't really have a a backend that deals with this as we use infura directly. So we should just limit the size on client side.


CAMEL-11335: Add route state details

Add route state details as discussed in PR #1719.

I was thinking the same, just wasn't sure how close we want to stay with the original Camel terms. I agree that "status" is a better fit, and already updated the code.


Fix wrong help message

Thanks!

Sure :)
On Thu, Sep 28, 2017, 04:42 Evan Hempel<EMAIL_ADDRESS>wrote:

Thanks!
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/evanhempel/python-flamegraph/pull/12#issuecomment-332702829,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AEJXyME_qunrTumH46Xmg0nysyiRbU8_ks5smvmTgaJpZM4Pixks
.

--
Noam Elfanbaum
+972-545551680


OpenGL bug - removing diffuse from a skybox cause shadergen error

The problem is caused because 'attn' for some reason is a float (scalar) when we don't have diffuse.
so during acess of -> 'float.xxxx' we get an error.
I fixed that changing this:
  {
      if ( attn )
         lerpVal = new GenOp( "saturate( @ ).xxxx", attn );
      else
         blendOp = Material::Mul;
   }

to:
   {
      if ( attn && fd.materialFeatures.hasFeature( MFT_DiffuseMap ) )
         lerpVal = new GenOp( "saturate( @ ).xxxx", attn );
      else
         blendOp = Material::Mul;
   }

According to Luis, the correct fix is:
lerpVal = new GenOp( "vec4( saturate( @ ) ).xxxx", attn );
Since swizzles in opengl are only supported on non scalar type.
I make a PR for it. Fixed.

Confirmed the problem and fix.
Thx :+1:


refactor: remove graphqlVariables, Result, Context

It's impractical to store the GraphQL arguments, results, and context due to their unpredictable sizes, which could lead to performance issues. Not only is storage unrealistic, but processing them for each field may result in excessive computation. Moreover, from a data protection standpoint, avoiding storage enhances security.
Related: https://github.com/rocket-connect/graphql-debugger/issues/287

Initial benchmark before merge
https://github.com/rocket-connect/benchmarks/commit/d5994af53cb164191895469662e1173fde08e78a


fix: One decimal in top collections for different region

Thank you for your contribution to the KodaDot - One Stop Shop for Polkadot NFTs.
👇 __ Let's make a quick check before the contribution.
PR Type

[x] Bugfix

Needs QA check

@kodadot/qa-guild please review

Context

[x] Closes #8938
[x] Closes #8941

Did your issue had any of the "$" label on it?

[x] My DOT address: Payout

Screenshot 📸

[x] My fix has changed UI

Copilot Summary
copilot:summary
copilot:poem

@roiLeo Could you please check if it works for you?

Here in Brazil we use 1.252,34, it was more near the correct format on canary, what to do in this case?

@roiLeo @prury
Could you please check again if it works for you? I have made some changes, now it should be similar to what we have in the production environment. By the way, I have updated the screenshot.

thanks!
pay 20 usd

😍 Perfect, I’ve sent the payout
💵 $20 @ 8.54 USD/DOT ~ 2.342 $DOT
🧗 16SjUbGKSdjCdWTy3NNT3JxbRVGGqD4mwkHpc6BD9U2Rp29Z
🔗 0xbb0f0a66eb512709421a2db333aacdefa9f0febe7b4989e28c9627c3fc8660ab
🪅 Let’s grab another issue and get rewarded!
🪄 github.com/kodadot/nft-gallery/issues


AttributeError: 'IntervalTree' object has no attribute 'search'

falcon-unzip 1.1.4
falcon-kit 1.2.4
pypeflow 2.1.1
Traceback (most recent call last):
File "/home/zy/tools/miniconda2/lib/python2.7/runpy.py", line 162, in _run_module_as_main
"main", fname, loader, pkg_name)
File "/home/zy/tools/miniconda2/lib/python2.7/runpy.py", line 72, in _run_code
exec code in run_globals
File "/home/zy/tools/miniconda2/lib/python2.7/site-packages/falcon_unzip/proto/main_augment_pb.py", line 627, in
main()
File "/home/zy/tools/miniconda2/lib/python2.7/site-packages/falcon_unzip/proto/main_augment_pb.py", line 624, in main
run(**vars(args))
File "/home/zy/tools/miniconda2/lib/python2.7/site-packages/falcon_unzip/proto/main_augment_pb.py", line 512, in run
updated_rid2phase, phase_relation_graph, htig_to_phase = create_new_rid2phase(ctg_id, rid2phase, all_regions, m4, a_paths)
File "/home/zy/tools/miniconda2/lib/python2.7/site-packages/falcon_unzip/proto/main_augment_pb.py", line 91, in create_new_rid2phase
found_regions = tree.search(reference_start, reference_end)
AttributeError: 'IntervalTree' object has no attribute 'search'
WARNING:root:Call '/bin/bash user_script.sh' returned 256.
WARNING:root:CD: 'uow-00' -> '/home/zy/test3/3-unzip/0-phasing/000627F'
Traceback (most recent call last):
File "/home/zy/tools/miniconda2/lib/python2.7/runpy.py", line 162, in _run_module_as_main
"main", fname, loader, pkg_name)
File "/home/zy/tools/miniconda2/lib/python2.7/runpy.py", line 72, in _run_code
exec code in run_globals
File "/home/zy/tools/miniconda2/lib/python2.7/site-packages/falcon_kit/mains/generic_run_units_of_work.py", line 116, in
main()
File "/home/zy/tools/miniconda2/lib/python2.7/site-packages/falcon_kit/mains/generic_run_units_of_work.py", line 112, in main
run(**vars(args))
File "/home/zy/tools/miniconda2/lib/python2.7/site-packages/falcon_kit/mains/generic_run_units_of_work.py", line 65, in run
pypeflow.do_task.run_bash(script, inputs, outputs, params)
File "/home/zy/tools/miniconda2/lib/python2.7/site-packages/pypeflow/do_task.py", line 187, in run_bash
util.system(cmd)
File "/home/zy/tools/miniconda2/lib/python2.7/site-packages/pypeflow/io.py", line 29, in syscall
raise Exception(msg)
Exception: Call '/bin/bash user_script.sh' returned 256.
2018-12-28 13:04:52,395 - root - WARNING - Call '/bin/bash user_script.sh' returned 256.
2018-12-28 13:04:52,396 - root - WARNING - CD: '/home/zy/test3/3-unzip/0-phasing/000627F' -> '/home/zy/test3/3-unzip/0-phasing/000627F'
2018-12-28 13:04:52,396 - root - WARNING - CD: '/home/zy/test3/3-unzip/0-phasing/000627F' -> '/home/zy/test3/3-unzip/0-phasing/000627F'
2018-12-28 13:04:52,396 - root - CRITICAL - Error in /home/zy/tools/miniconda2/lib/python2.7/site-packages/pypeflow/do_task.py with args="{'json_fn': '/home/zy/test3/3-unzip/0-phasing/000627F/task.json',\n 'timeout': 30,\n 'tmpdir': None}"
Traceback (most recent call last):
File "/home/zy/tools/miniconda2/lib/python2.7/runpy.py", line 162, in _run_module_as_main
"main", fname, loader, pkg_name)
File "/home/zy/tools/miniconda2/lib/python2.7/runpy.py", line 72, in _run_code
exec code in run_globals
File "/home/zy/tools/miniconda2/lib/python2.7/site-packages/pypeflow/do_task.py", line 267, in
main()
File "/home/zy/tools/miniconda2/lib/python2.7/site-packages/pypeflow/do_task.py", line 259, in main
run(**vars(parsed_args))
File "/home/zy/tools/miniconda2/lib/python2.7/site-packages/pypeflow/do_task.py", line 253, in run
run_cfg_in_tmpdir(cfg, tmpdir, '.')
File "/home/zy/tools/miniconda2/lib/python2.7/site-packages/pypeflow/do_task.py", line 228, in run_cfg_in_tmpdir
run_bash(bash_template, myinputs, myoutputs, parameters)
File "/home/zy/tools/miniconda2/lib/python2.7/site-packages/pypeflow/do_task.py", line 187, in run_bash
util.system(cmd)
File "/home/zy/tools/miniconda2/lib/python2.7/site-packages/pypeflow/io.py", line 29, in syscall
raise Exception(msg)
Exception: Call '/bin/bash user_script.sh' returned 256.
pwd
+++ pwd
++ echo 'FAILURE. Running top in /home/zy/test3/3-unzip/0-phasing/000627F (If you see -terminal database is inaccessible- you are using the python bin-wrapper, so you will not get diagnostic info. No big deal. This process is crashing anyway.)'
++ rm -f top.txt
++ which python
++ which top
++ env -u LD_LIBRARY_PATH top -b -n 1
++ env -u LD_LIBRARY_PATH top -b -n 1
++ pstree -apl
real	4m30.479s
user	4m7.588s
sys	0m13.520s

finish
echo 'finish code: 1'
run-Pf1ee522fa7b416.bash.zip

What should I do?
Best regards
Thanks

Used updated Falcon will happen this issue, please help me to solve


[ST] Missing Metis transaction

Describe the bug
This transaction from Metis to Base is missing on Connextscan: https://explorer.metis.io/tx/0xd71c3ccd71105fd85606bc03dfc7a7be94125a79a927f73a518c07e09de46851
Link to ticket in discord
https://discord.com/channels/454734546869551114/1218605323015819450/1218614064649998387

https://connextscan.io/tx/0xd71c3ccd71105fd85606bc03dfc7a7be94125a79a927f73a518c07e09de46851
should be present -- there was a gap in the subgraph metis transfers


Enable pipeline args

Inspect manifest fails for https://raw.githubusercontent.com/CERTCC/VINCE/2bed565cc8a73dd920a6c8ed0b58ac221e4b3119/requirements.txt because it requires an insecure evaluation.
I would like to have way to pass args to a pipeline
See also https://github.com/nexB/scancode.io/issues/590

Hi, I was curious about what is insecure evaluation and can you please elaborate more as you suggested that we want a way to pass the args to a pipline but why ?


Update README with video teaching guide.md

https://www.youtube.com/watch?v=k8sHYMeDitQ

Video link looks good :)

Cool if the video is well embedded within the education toolkit then :-) thanks, @lewtun. Let me know. when it will be ready to be merged :)

I don't think this shows in markdown though, see https://github.com/huggingface/education-toolkit/blob/08c3bf65bc4da2022880c639fae0994770412364/README.md

You can try https://github.com/marcomontalbano/video-to-markdown#:~:text=While its not possible to,video url on the image for example

As per https://github.com/marcomontalbano/video-to-markdown#:~:text=While its not possible to,video url on the image for example it's not possible, but you can embed as suggested there at least, that should redirect to the video

@osanseviero I have tried both of the following ways but the image is not displayed properly. I do not understand why.

I just commited a fix. Let me know if it looks good and we can merge :rocket:


Firecert 2036

Description
Enter a detailed description of the PR here, including the nature and purpose of the changes.
JIRA Ticket
Include a link to the JIRA Ticket linked to this PR.
Issue-0000
Additional Info (Test steps / Steps to reproduce etc.)
Details on how to test the feature

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.5 out of 6 committers have signed the CLA.:white_check_mark: jmeier204:white_check_mark: Abhishk123:white_check_mark: parag-pv:white_check_mark: Eswar2103:white_check_mark: anjalimukundan:x: Jayaramaraju, AbhishekJayaramaraju, Abhishek seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.


Fatal Error - Not sure what causes it.

14:01:13: Fatal error encountered:
14:01:13:
14:01:13: Traceback (most recent call last):
14:01:13:   File "main.py", line 155, in main
14:01:13:   File "twitch.py", line 587, in run
14:01:13:   File "twitch.py", line 747, in _run
14:01:13:   File "twitch.py", line 1660, in bulk_check_online
14:01:13:   File "asyncio\tasks.py", line 571, in _wait_for_one
14:01:13:   File "twitch.py", line 1390, in gql_request
14:01:13: exceptions.GQLException: [{'message': 'service error', 'path': ['channel', 'viewerDropCampaigns']}]
14:01:13:
14:01:13: Exiting...
14:01:13:
14:01:13: Application Terminated.
14:01:13: Close the window to exit the application.
Just started using this application, was loving it until this morning when I keep getting this crash. Even after restarting, still reoccurs.

I also started getting a fatal error today.
16:13:38: Fatal error encountered:
16:13:38:
16:13:38: Traceback (most recent call last):
16:13:38:   File "C:\Users\Main\Documents\GitHub\TwitchDropsMiner\main.py", line 155, in main
16:13:38:     await client.run()
16:13:38:   File "C:\Users\Main\Documents\GitHub\TwitchDropsMiner\twitch.py", line 587, in run
16:13:38:     await self._run()
16:13:38:   File "C:\Users\Main\Documents\GitHub\TwitchDropsMiner\twitch.py", line 747, in _run
16:13:38:     await self.bulk_check_online(acl_channels)
16:13:38:   File "C:\Users\Main\Documents\GitHub\TwitchDropsMiner\twitch.py", line 1660, in bulk_check_online
16:13:38:     response_list = await coro
16:13:38:                     ^^^^^^^^^^
16:13:38:   File "C:\Users\Main\AppData\Local\Programs\Python\Python312\Lib\asyncio\tasks.py", line 621, in _wait_for_one
16:13:38:     return f.result()  # May raise f.exception().
16:13:38:            ^^^^^^^^^^
16:13:38:   File "C:\Users\Main\Documents\GitHub\TwitchDropsMiner\twitch.py", line 1390, in gql_request
16:13:38:     raise GQLException(response_json['errors'])
16:13:38: exceptions.GQLException: [{'message': 'service error', 'path': ['channel', 'viewerDropCampaigns']}]
16:13:38:
16:13:38: Exiting...
16:13:39:
16:13:39: Application Terminated.
16:13:39: Close the window to exit the application.

got the same error, seems to be the same issue / behavior as in #415
effected drop this time is the "Winter Drops day 1 pt.1", game "Escape from Tarkov" which is available from "Mon, Dec 30, 2:00 PM - Tue, Dec 31, 1:59 AM GMT+1"
possible workaround is to temporarily add "Escape from Tarkov" to the exclude list

or configure it manually in the settings.json
"exclude": {
    "__type": "set",
    "data": [
        "Escape from Tarkov"
    ]
}

Ye setting it to exclude isn't what I want, Want Tarkov drops one to work if anything.

Redirecting this to #651 since it has more discussion on this topic.

Found a fix in #651 from @villario


tests: install pyyaml on osd nodes

Due to [1], ceph-volume has now a dependency on pyyaml but it's not
installed by default via the package dependency.
This patch only add the required package on non containerized
deployment and as temporary workaround for the CI.
[1] https://tracker.ceph.com/issues/46759
Signed-off-by: Dimitri Savineau<EMAIL_ADDRESS>

jenkins test centos-non_container-lvm_batch

jenkins test centos-non_container-lvm_osds


[FLINK-3681] [cep, typeextractor] Generalize TypeExtractor to support more lambdas

The TypeExtractor.getUnaryOperatorReturnType and TypeExtractor.getBinaryOperatorReturnType
methods have been extended to support positional arguments for the input types. This allows
to support parameterized types as Java 8 lambda arguments where the input type is not specified
by the first type argument (e.g. Map<String, T>). This also solves the problem that the CEP
library did not support Java 8 lambdas as select functions.

Looks like a nice generalization of the iterable and collector cases. Good that you did not introduce a hasMap ;-)
+1 to merge to master and release-1.0 after tests pass.

Thanks for the review @uce

Once Travis gives green light I'll merge it.

Till's local Travis passed (https://travis-ci.org/tillrohrmann/flink/builds/119523927). I'm going to merge this.


Implement JNI version of PageFlip

Current version is pure Java, although its performance is good enough for most popular android  devices, I still want to implement a JNI version to see how much performance we can improve from native codes!

Completed JNI version, please visit: android-PageFlip-JNI