fix(evm): fuzzing not properly collecting data

Seems like we weren't using any of the collected values from PUSH and storage.  For both fuzzing and invariants!
Fuzz & Invariant

PUSH values were being collected with a left alignment. (4442...0000 vs 0000...4442) . testNeedle(uint256) now successfully breaks, before it wouldnt.
Storage values were being collected in the wrong endianness. (efbe...0000 vs 0000...beef). testIncrement(address) now successfully breaks, before it wouldnt.

Invariant Dictionary Flooding

Disabled memory value collection until we find a better way to parse the values. Stuff like ab12...000..12ab...0000 is mostly spam.
Remove from the StateChangeSet the randomly generated sender before collect_state_from_call. Otherwise, the dictionary gets flooded with irrelevant addresses.

Some current limitations/follow-ups :

Packed values kinda break the storage collection. If you have a bool(true) & address(0xbeef), you might collect a value like 0000...beef01, which is useless.
Some parameter-aware dictionary would be nice. At the moment, if we want an address we might be getting a value from the dictionary which was an uint.
Values bigger than 32 bytes are not properly collected/used. (strings, bytes)
We collect PUSH bytes all the time on all calls. Adding some cache for ABI/addresses before re-collecting them, might increase speed in some cases.

--
Added a quick way to inspect the dictionary. Example
$ ~/projects/foundry/testdata$ RUST_LOG=trace tforge test -c fuzz/FuzzCollection.t.sol  -m invariantCounter -vvvvvv | grep dictionary
2022-08-11T15:57:44.060025Z TRACE contract{name=fuzz/FuzzCollection.t.sol:SampleContractTest}:invariant-test: forge::test::invariant::dictionary:["0000000000000000000000000000000000000000000000000000000000000000", "0000000000000000000000000000000000000000000000000000000000000001", "0000000000000000000000000000000000000000000000000000000000000002", "0000000000000000000000000000000000000000000000000000000000000003", "0000000000000000000000000000000000000000000000000000000000000004", "000000000000000000000000000000000000000000000000000000000000000a", "000000000000000000000000000000000000000000000000000000000000000c", "0000000000000000000000000000000000000000000000000000000000000010", "0000000000000000000000000000000000000000000000000000000000000011", "0000000000000000000000000000000000000000000000000000000000000014", "0000000000000000000000000000000000000000000000000000000000000020", "0000000000000000000000000000000000000000000000000000000000000024", "0000000000000000000000000000000000000000000000000000000000000039", "0000000000000000000000000000000000000000000000000000000000000040", "0000000000000000000000000000000000000000000000000000000000000044", "000000000000000000000000000000000000000000000000000000000000005b", "0000000000000000000000000000000000000000000000000000000000000064", "000000000000000000000000000000000000000000000000000000000000007d", "0000000000000000000000000000000000000000000000000000000000000080", "0000000000000000000000000000000000000000000000000000000000000082", "0000000000000000000000000000000000000000000000000000000000000084", "000000000000000000000000000000000000000000000000000000000000008a", "000000000000000000000000000000000000000000000000000000000000008b", "0000000000000000000000000000000000000000000000000000000000000095", "000000000000000000000000000000000000000000000000000000000000009e", "00000000000000000000000000000000000000000000000000000000000000a0", "00000000000000000000000000000000000000000000000000000000000000a4", "00000000000000000000000000000000000000000000000000000000000000ac", "00000000000000000000000000000000000000000000000000000000000000b1", "00000000000000000000000000000000000000000000000000000000000000b3", "00000000000000000000000000000000000000000000000000000000000000c7", "00000000000000000000000000000000000000000000000000000000000000d7", "00000000000000000000000000000000000000000000000000000000000000e0", "00000000000000000000000000000000000000000000000000000000000000e5", "00000000000000000000000000000000000000000000000000000000000000f3", "00000000000000000000000000000000000000000000000000000000000000ff", "000000000000000000000000000000000000000000000000000000000000010b", "0000000000000000000000000000000000000000000000000000000000000119", "000000000000000000000000000000000000000000000000000000000000011e", "000000000000000000000000000000000000000000000000000000000000012c", "0000000000000000000000000000000000000000000000000000000000000131", "000000000000000000000000000000000000000000000000000000000000017c", "000000000000000000000000000000000000000000000000000000000000018d", "000000000000000000000000000000000000000000000000000000000000019e", "00000000000000000000000000000000000000000000000000000000000001af", "00000000000000000000000000000000000000000000000000000000000001ed", "00000000000000000000000000000000000000000000000000000000000001fc", "00000000000000000000000000000000000000000000000000000000000001ff", "000000000000000000000000000000000000000000000000000000000000021e", "0000000000000000000000000000000000000000000000000000000000000230", "0000000000000000000000000000000000000000000000000000000000000237", "000000000000000000000000000000000000000000000000000000000000024d", "0000000000000000000000000000000000000000000000000000000000000260", "0000000000000000000000000000000000000000000000000000000000000265", "000000000000000000000000000000000000000000000000000000000000027f", "0000000000000000000000000000000000000000000000000000000000004446", "0000000000000000000000000000000000000000000000000000000000005556", "000000000000000000000000000000000000000000000000000000000000beef", "0000000000000000000000000000000000000000000000000000000000461bcd", "000000000000000000000000000000000000000000000000000000000108aff0", "0000000000000000000000000000000000000000000000000000000003df179c", "000000000000000000000000000000000000000000000000000000002f2e16d6", "000000000000000000000000000000000000000000000000000000004e487b71", "0000000000000000000000000000000000000000000000000000000061bc221a", "000000000000000000000000000000000000000000000000000000008da5cb5b", "000000000000000000000000000000000000000000000000000000009f16168e", "00000000000000000000000000000000000000000000000000000000c4b8c257", "00000000000000000000000000000000000000000000000000000000fd4459b1", "0000000000000000000000000000000000000000000000000000006970667358", "0000000000000000000000000000000000000000000027a7262cafa7aba722a9", "0000000000000000000000000000000000000000ffffffffffffffffffffffff", "0000000000000000000000000000000000004e6a5e87b5a058cdb06137a7099f", "000000000000000000000000006060e164736f6c634300080f00330000000000", "00000000000000000000000000a329c0648769a73afac7f9381e08fb43dbea72", "0000000000000000000000001804c8ab1f12e6bbf3894d4083f33e07309d1f38", "0000000000000000000000003fab184622dc19b6109349b94811493bf2a45362", "0000000000000000000000004e59b44847b379578588920ca78fbf26c0b4956c", "0000000000000000000000007109709ecfa91a80626ff3989d68f67f5b1dd12d", "000000000000000000000000ce71065d4017f316ec606fe4422e11eb2c47c246", "000000000000000000000001000000000000000000000000000000000000beef", "20d8a6f5a693f9d1d627a598e8820f7a55ee74c183aa8f1a30e8d4e8dd9a8d84", "ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffe0"]

PUSH values were being collected with a left alignment. (4442...0000 vs 0000...4442) . testNeedle(uint256) now successfully breaks, before it wouldnt.

Storage values were being collected in the wrong endianness. (efbe...0000 vs 0000...beef). testIncrement(address) now successfully breaks, before it wouldnt.

@transmissions11 this explains the storage/constants issue we encountered the other day during the invariants demo.

Packed values kinda break the storage collection. If you have a bool(true) & address(0xbeef), you might collect a value like 0000...beef01, which is useless.

@brockelmore I think you were looking into storage packing/unpacking for forge-std?

Disabled memory value collection until we find a better way to parse the values. Stuff like ab12...000..12ab...0000 is mostly spam.

sounds good. is there a nice way to find memory that's not spam-looking?

Remove from the StateChangeSet the randomly generated sender before collect_state_from_call. Otherwise, the dictionary gets flooded with irrelevant addresses.

what does that mean? do we will use the dictionary to populate potential senders?

Some parameter-aware dictionary would be nice. At the moment, if we want an address we might be getting a value from the dictionary which was an uint.
Values bigger than 32 bytes are not properly collected/used. (strings, bytes)

this should be a matter of a type-refactor of the dictionary to contain each data type? and have the proptest selector use from that? should also address the 32 bytes thing

We collect PUSH bytes all the time on all calls. Adding some cache for ABI/addresses before re-collecting them, might increase speed in some cases.

yep this would be good

what does that mean? do we will use the dictionary to populate potential senders?

A randomly generated sender 0x1337 would be part of the changeset (because of the nonce increase), and therefore, its address would be added to the dictionary. It only applies to EOA, and we no longer allow it.
In a long session, the dictionary would be full of these addresses, burying other potential important addresses.

sounds good. is there a nice way to find memory that's not spam-looking?

One option would be to inspect in-between steps and look for mstore and mload. I wonder if it makes things very slow though...

Seems like this might have been the cause of https://github.com/foundry-rs/foundry/issues/1168? If I understand correctly, we were collecting push bytes etc, but they were just collected in the wrong order (i.e. in reverse)?

@brockelmore I think you were looking into storage packing/unpacking for forge-std?

Yes but that is really a sub-optimal method only used in forge-std because we likely wont have access to storage layout from solc for fork tests. Here, you rarely run fuzz tests in a forked environment so we should have all storage layouts available
As for typed dictionary, should be possible in limited cases easily, and can get infinitely complicated trying to get more intelligent there. For example, we can (relatively) easily type return data and storage (changeset) just via storage layout and ABIs. This would improve and expand dynamic type support (string, bytes, lists). Typing the changeset with storage layout is a bit annoying for sha3-ed slots, but probably can be done a la banteg's method of preimage magic but would come at execution time cost (but would be nice to have for the debugger anyway).

I think we need to be extra careful about storage layout assumptions, or any language-specific assumptions in general if they have some amount of complexity, since a long term goal is still to support more languages, and we cannot guarantee that the storage layout is the same. If we start making huge complex solutions to decode storage layout for the fuzzer, we're potentially shooting ourselves in the foot. Also not even sure how much it would improve the fuzzer vs. something like a coverage guided fuzzer

On the typed dictionary front, are we positive that is overall good for the fuzzer? There is something nice about type obfuscation to try to screw things up. May be worthwhile long term to have some percentage of the strategy do type obfuscation for inputs to increase "relevant" randomness, instead of typing everything and only using known types (especially while typing is limited)

Seems like this might have been the cause of #1168? If I understand correctly, we were collecting push bytes etc, but they were just collected in the wrong order (i.e. in reverse)?
Edit: Nvm, this does not necessarily resolve #1168

It does seem to solve it though:
[⠢] Compiling...
No files changed, compilation skipped

Running 2 tests for test/SampleContract.t.sol:FuzzerDictTest
[FAIL. Reason: Undefined. Counterexample: calldata=0xe53491ce0000000000000000000000000000000000000000000000000000000000000064, args=[0x0000000000000000000000000000000000000064]] testImmutableOwner(address) (runs: 205, μ: 6176, ~: 6176)
[PASS] testStorageOwner(address) (runs: 256, μ: 8243, ~: 8243)
Test result: FAILED. 1 passed; 1 failed; finished in 179.75ms

Failing tests:
Encountered 1 failing test in test/SampleContract.t.sol:FuzzerDictTest
[FAIL. Reason: Undefined. Counterexample: calldata=0xe53491ce0000000000000000000000000000000000000000000000000000000000000064, args=[0x0000000000000000000000000000000000000064]] testImmutableOwner(address) (runs: 205, μ: 6176, ~: 6176)

On the typed dictionary front, are we positive that is overall good for the fuzzer? There is something nice about type obfuscation to try to screw things up. May be worthwhile long term to have some percentage of the strategy do type obfuscation for inputs to increase "relevant" randomness, instead of typing everything and only using known types (especially while typing is limited)

This is a good discussion point. I think the most valuable areas where this can happen is when trying to handcraft a bytes memory that's abi.encode/abi.encodePacked from a bunch of other values (e.g. the Nomad hack). Not sure how valuable that is to have, when compared to having a more targeted typed dict. Worth discussing in a separate issue.

solid, should we move ahead with this as-is? what follow ups do we have?

I'm hitting a test failure on forge-std:
[FAIL. Reason: Too many global rejects] testAssertEq_BytesErr_Pass(bytes,bytes) (runs: 53, μ: 20801, ~: 21464)
need to investigate

This makes me think our dict got too big / noisy?

This makes me think our dict got too big / noisy?

Hmm, maybe. That failed test (and others in forge-std) take two inputs a and b and have vm.assume(a == b). So a failure here implies we that this PR makes the fuzzer less likely to pass the same inputs for both inputs, which is a valuable thing for the fuzzer to try.

Okay figured it out, but I'm unsure on how to proceed:
I added PUSH data collection on build_initial_state(). I guess this leads to collecting PUSH values from the test contract. During collect_state_from_data don't get collected either, since the test contract doesn't have a statechangeset.
Do we disregard the PUSH values in this scenario ? @brockelmore @mds1

Once I remove it, the forge-std test passes fine.
Do we disregard the PUSH values in this scenario ? @brockelmore @mds1 Following the logic from before, I'd rather include them and change the forge-std test I think.

 That would cover u8 -> u256 / address etc., whereas it'd omit things like small masks or function selectors etc.

It sounds like ultimately we may need to get smarter about which PUSH bytes are collected? @gakonst's idea is an interesting heuristic. Curious to hear what @brockelmore thinks but I'd be ok with changing the forge-std tests if required for now. Though as mentioned above occasionally passing the same value for both inputs is a good property so I don't think we want to lose that in the long term.

Though as mentioned above occasionally passing the same value for both inputs is a good property so I don't think we want to lose that in the long term.

Yeah we want this. Unrelated, but I also think we should still be generating the same call twice, e.g. transfer(0x1234, 100) -> transfer(0x1234, 100) in invariants, not sure how possible this is right now. Wonder if we should add an extra strategy for that.

@joshieDo are we still getting too many rejects after not collecting baalnces/nonces?

OK - let's remove the PUSH bytes collection in the dictionary for now & get this merged with the endianness fix.
Let's investigate a smart technique for collecting PUSH values in a separate PR.


Edit hdinsight-administer-use-management-portal.md

Edit complete.
On line 59, I changed "remote desktop connection" to "Remote Desktop Connection" because I assume you're referring to the Windows feature. If you're using the term generically, please use "a remote desktop connection" instead.
On line 79, "the cluster using it" should be either "the cluster that uses it" or "the cluster by using it" (whichever is accurate).
I tried to be consistent in using "Remote Desktop" (initial capped) to refer to the feature, and using "remote desktop" (lowercase) for generic references to a desktop. Please confirm that I made the right choices.
I tried to make sure that capitalization of UI items mentioned in text matches the capitalization shown in the screen shot (and is consistent). It would be ideal to confirm that all UI items mentioned in text are capitalized as they appear on the UI.

Hi @ShawnJackson, I'm your friendly neighborhood Azure Pull Request Bot (You can call me AZPRBOT). Thanks for your contribution!

It looks like you're working at Microsoft (v-shawja). If you're full-time, we DON'T require a contribution license agreement.

If you are a vendor, or work for Microsoft Open Technologies, DO please sign the electronic contribution license agreement. It will take 2 minutes and there's no faxing! https://cla.azure.com.

TTYL, AZPRBOT;


Remove owner from tokens table

Current plan: await availability of owner from daemon, leave owner in table

Adding owner info to the archive database


Lack summernote after insert image

Hi,
I use your plugin in Angular project but after insert image as base64, type in editor with delay and some times after 4 second from key-press character shown.
Thanks

Hi,How do you solve Base64 uploads?

I use another editor


Cookie vs anon consent

We'll be adding the cookie consent as a non-changeable consent, part of the whole list of consents.


Getting all collections based on another collection in a many-to-many relation?

I doubt I used the correct terms in the title... Currently, I have my item model, and my store model in a many-to-many relation. My table for the relation is here. Is there a way to get all items at a store based on the store id?

Yep. Two methods, pick your favourite:
// Load a store instance with related items.
Store.forge({id: 5}).fetch({withRelated: 'items'}).then(function (store) {
  console.log('Here is the store', store.toJSON());
  console.log('Here are the items', store.related('items').toJSON());
});

// Create a store instance and load its related items (without loading the store instance).
Store.forge({id: 5}).related('items').fetch().then(function (items) {
  console.log('Here are all the items at store with ID 5', items.toJSON());
});

For some reason, that also adds _pivot_store_id, and _pivot_item_id. Even if I specify columns in the fetch to be ['name', 'description']
Also, is there another way to ask for help other than filling your repo with issues?

For some reason, that also adds _pivot_store_id, and _pivot_item_id. Even if I specify columns in the fetch to be ['name', 'description']

These are not attributes in your model, but are generated by toJSON. You can disable this behaviour by calling toJSON({omitPivot: true}).

Also, is there another way to ask for help other than filling your repo with issues?

Yes, you may use any of the options here. Although reporting here is the most likely way to get a response. It also allows us to note problems with documentation - such as omitPivot not being documented under toJSON.


DB: Change ConsentMechanism "Necessary" to "Notice Only"

Is your feature request related to a specific problem?
Consent Mechanism "Necessary" is changing to "Notice Only"
A description of what you want to happen.
Add a migration that does the following:

Add “notice_only” enum to list
Update all privacy notice and privacy notice history records that have a consent_mechanism of “necessary” to be “notice_only”.  3) Remove “necessary” as an option.

Describe the solution you'd like
Describe alternatives you've considered, if any
A description of any alternative solutions or features you've considered.
Additional context
Add any other context or screenshots about the feature request here.

moving to done


🔧 Gradle wrapper upgrade to 8.4, enabling configuration cache, config…

Updated Gradle wrapper to 8.4
enabled configuration cache
configured test to use JUnitPlatform
updated source/testCompatibility to use JavaVersion

Just checking in to see if there's an issue with the PR?

Thank you for your contribution!


Default filesystem

Idea: to be able to register an instance as the "default" for a given protocol, so that filesystem(protocol), without additional kwargs, gets that particular instance. Will mean ability for pandas (for example) to do IO without figuring out a way to pass storage_options or other arguments through.

@jcrist : this is the idea that I mentioned. What the "default" for a given protocol is could be defined as part of configuration options.


Problems starting the file.

I suffer this problem when attempting to run the file with python. Is there something I am doing incorrectly?
`main.py
Traceback (most recent call last):
File "D:\Downloads\discord-predb-main\main.py", line 4, in
from PYxREL import xREL
File "D:\Downloads\discord-predb-main\PYxREL_init_.py", line 1, in
from .xREL import xREL
File "D:\Downloads\discord-predb-main\PYxREL\xREL.py", line 1, in
from .APIHelper import APIHelper
File "D:\Downloads\discord-predb-main\PYxREL\APIHelper.py", line 1, in
import requests
ModuleNotFoundError: No module named 'requests'`

Thanks for opening up the issue.
I made a mistake by thinking that the requests module is part of the standard library, but it is in fact an external module.
I added a requirements.txt and edited the README.
You can install the requests module by using either of these two approaches:
pip install requests
pip install -r requirements.txt

I'm not sure what's going on, but i had the issue that was raised, but even after trying both of the commands mentioned above, it still says:
import requests

ModuleNotFoundError: No module named 'requests'
I verified that the module was installed (which it was) and i could uninstall it to try each method.

That's a common hiccup when your Python setup struggles to find the installed modules. I don't know what your setup is, but you could try running it with "python main.py" instead of "python3 main.py". This answer on StackOverflow also provides good guidance.
Another option is to use virtual enviroments for Python, you can find the documentation here and a good answer in post on StackOverflow. They explain it better than I could.

Got further but both my windows installation an dlinux both now say the following:
Request failed: Expecting value: line 1 column 1 (char 0)
I only have python3 & pip3 installed on each of these. Not sure if that helps.

That certainly is a step further! It seems like the json response from the API is not correct, which I haven't encountered before. Can you try to print the "response.text" in PYxREL -> APIHelper.py? I'd put it directly under line 13, which is 'response = requests.get(api_url, params=parameters)'. I also made a new commit and changed the error handling a bit, which hopefully gives more information.

Cool, thanks!
I now see this:
Invalid response format: Expecting value: line 1 column 1 (char 0)
Response content: Just a moment...Enable JavaScript and cookies to continue

How weird! It seems xREL has implemented additional security measures using Javascript. That might be due to rate limiting or IP blocking.
Have .json files been created in the directory where main.py is located? If they are there, are they filled with content?

nope, no .jason file in there. by the way, is it possible to customize feeds easily, for things like movies, or would that require af fundamental code change?

Yeah, it must be the VPN! They state in their documentation "Important info: due to abusive requests to xrel.to, we had to block some IP ranges including some VPN providers. If this is a problem for you, please use https://xrel-api.nfos.to/ to access the API instead of https://api.xrel.to/.".  Glad it works now though!
Yes, the first time there won't be a message, because it does an intial scan, so it does need a new release. But you can run test.py and should get a message to your webhooks immediately to cofirm everything works.


Correct typo - usx'er -> user

Simple typo correction

@clarotech : Thanks for your contribution! The author(s) have been notified to review your proposed change.

Looks good; thanks.


Vespa content pod created snapshot folder owned by nobody user in a high RAM situation

Describe the bug
var/db/vespa/search/cluster.lexdoc/n0/documents/testDocument/0.ready/attribute/testField13_s_attr/snapshot-2298**
Size: 148             Blocks: 0          IO Block: 4096   directory
Device: fd09h/64777d    Inode: 447003      Links: 1
Access: (0755/drwxr-xr-x)  Uid: (65534/  nobody)   Gid: (65534/  nobody)
To Reproduce
Push the content node's RAM beyond limits and you may be able to see this
Our RAM was just slightly lower than 80% and we pushed a schema change to convert numerics to non-paged attributes. This led to multiple hours of searchnode restarts initially without any warning and spike in RAM i.e. crash, and subsequently warnings like these appeared in a few restarts. Lastly we reached the state described above where the podman container itself crashed
Expected behavior
Understand that ram needs to be in check, but the last thing we expect is creation of file by a user other than the vespa user
Screenshots
1713931119.902770       vespa.content    10      -       vespa-start-services    warning Could not create a file in directory 'var/db/vespa/search/cluster.lexdoc/n0/documents/testDocument/0.ready/attribute/testField13_s_attr/snapshot-2298'
1713931119.902798       vespa.content    10      -       vespa-start-services    warning problem: open var/db/vespa/search/cluster.lexdoc/n0/documents/testDocument/0.ready/attribute/testField13_s_attr/snapshot-2298/tmp.probe.656871207.tmp: permission denied
1713931119.902802       vespa.content    10      -       vespa-start-services    warning Currently running as user: vespa
1713931119.902805       vespa.content    10      -       vespa-start-services    warning Wanted var/db/vespa/search/cluster.lexdoc/n0/documents/testDocument/0.ready/attribute/testField13_s_attr/snapshot-2298 to be owned by user id: 1000
1713931119.902807       vespa.content    10      -       vespa-start-services    warning Wanted var/db/vespa/search/cluster.lexdoc/n0/documents/testDocument/0.ready/attribute/testField13_s_attr/snapshot-2298 to have group id: 1000
1713931119.902811       vespa.content    10      -       vespa-start-services    warning Wanted var/db/vespa/search/cluster.lexdoc/n0/documents/testDocument/0.ready/attribute/testField13_s_attr/snapshot-2298 to have permissions: -rwxr-xr-x
1713931119.902813       vespa.content    10      -       vespa-start-services    warning current status of var/db/vespa/search/cluster.lexdoc/n0/documents/testDocument/0.ready/attribute/testField13_s_attr/snapshot-2298 is:
1713931119.904633       vespa.content    10      -       vespa-start-services    warning   File: var/db/vespa/search/cluster.lexdoc/n0/documents/testDocument/0.ready/attribute/testField13_s_attr/snapshot-2298
Size: 148             Blocks: 0          IO Block: 4096   directory
Device: fd09h/64777d    Inode: 447003      Links: 1
Access: (0755/drwxr-xr-x)  Uid: (65534/  nobody)   Gid: (65534/  nobody)
Access: 2024-04-23 22:18:09.444566411 +0000
Modify: 2024-04-23 22:18:09.429566725 +0000
Change: 2024-04-23 22:18:09.429566725 +0000
Birth: 2024-04-23 22:18:09.406567205 +0000
1713931119.904645       vespa.content    10      -       vespa-start-services    warning this is a fatal error!
open var/db/vespa/search/cluster.lexdoc/n0/documents/testDocument/0.ready/attribute/testField13_s_attr/snapshot-2298/tmp.probe.656871207.tmp: permission denied
Environment (please complete the following information):

OS: RHEL8 v8
Infrastructure: Podman 4.4.1

Vespa version
8.221.29
Additional context
Just before this problem occurred, for several hours nodes restart was accompanied with warnings like these due to high RAM
[2024-04-23 18:12:47.075] WARNING searchnode       vespa-proton-bin     Wanted<PHONE_NUMBER>3709551615 as limit for core file size but cannot exceed current hard limit: 0
[2024-04-23 18:18:18.792] WARNING searchnode       proton.proton.server.disk_mem_usage_filter   Write operations are now blocked: 'memoryLimitReached: { action: "add more content nodes", reason: "memory used (0.925613) > memory limit (0.9)", stats: { mapped: { virt:<PHONE_NUMBER>2, rss: 4988928}, anonymous: { virt:<PHONE_NUMBER>0, rss:<PHONE_NUMBER>2}, physicalMemory:<PHONE_NUMBER>0, memoryUsed: 0.925613, memoryLimit: 0.9}}'
[2024-04-24 03:17:59.062] WARNING searchnode       proton.persistence.util      Slow processing of message GetIterCommand(). Processing time: 154.5 s (>=5.0 s)
[2024-04-24 03:19:40.088] WARNING searchnode       proton.deadlock.detector     Thread filestormanager has gone 255035 milliseconds without registering a tick. Global slack not expended yet. Warning for now. Attempting to dump stack of thread...\nBacktrace:\n  /opt/vespa/lib64/libsearchlib.so(+0x77704e) [0x7f4d6010204e]\n  /opt/vespa/sbin/vespa-proton-bin() [0x6a0d22]\n  /opt/vespa/sbin/vespa-proton-bin(proton::DocumentRetriever::populate(unsigned int, document::Document&, document::Field::Set const&) const+0x91) [0x5f3281]\n  /opt/vespa/sbin/vespa-proton-bin() [0x5f36ec]\n  /opt/vespa/lib64/libsearchlib.so(+0x90150e) [0x7f4d6028c50e]\n  /opt/vespa/lib64/libsearchlib.so(search::FileChunk::read(__gnu_cxx::__normal_iterator<search::LidInfoWithLid const*, std::vector<search::LidInfoWithLid, std::allocatorsearch::LidInfoWithLid > >, unsigned long, search::FileChunk::ChunkInfo, search::IBufferVisitor&) const+0xf1) [0x7f4d60291591]\n  /opt/vespa/lib64/libsearchlib.so(search::FileChunk::read(__gnu_cxx::__normal_iterator<search::LidInfoWithLid const*, std::vector<search::LidInfoWithLid, std::allocatorsearch::LidInfoWithLid > >, unsigned long, search::IBufferVisitor&) const+0xa1) [0x7f4d602916f1]\n  /opt/vespa/lib64/libsearchlib.so(search::LogDataStore::read(std::vector<unsigned int, std::allocator > const&, search::IBufferVisitor&) const+0x2d5) [0x7f4d60296e25]\n  /opt/vespa/lib64/libsearchlib.so(search::docstore::BackingStore::visit(std::vector<unsigned int, std::allocator > const&, document::DocumentTypeRepo const&, search::IDocumentVisitor&) const+0x29) [0x7f4d6028b899]\n  /opt/vespa/sbin/vespa-proton-bin(proton::DocumentRetriever::visitDocuments(std::vector<unsigned int, std::allocator > const&, search::IDocumentVisitor&, storage::spi::ReadConsistency) const+0x4e) [0x5f1f8e]\n  /opt/vespa/sbin/vespa-proton-bin(proton::DocumentIterator::fetchCompleteSource(proton::IDocumentRetriever const&, std::vector<std::unique_ptr<storage::spi::DocEntry, std::default_deletestorage::spi::DocEntry >, std::allocator<std::unique_ptr<storage::spi::DocEntry, std::default_deletestorage::spi::DocEntry > > >&)+0x765) [0x619335]\n  /opt/vespa/sbin/vespa-proton-bin(proton::DocumentIterator::iterate(unsigned long)+0x62) [0x619c62]\n  /opt/vespa/sbin/vespa-proton-bin(proton::PersistenceEngine::iterate(storage::spi::IteratorId, unsigned long) const+0x155) [0x60b8a5]\n  /opt/vespa/lib64/libstorage.so(storage::ProviderErrorWrapper::iterate(storage::spi::IteratorId, unsigned long) const+0x37f) [0x7f4d5e84801f]\n  /opt/vespa/lib64/libstorage.so(storage::SimpleMessageHandler::handleGetIter(storage::GetIterCommand&, std::unique_ptr<storage::MessageTracker, std::default_deletestorage::MessageTracker >) const+0x5e) [0x7f4d5e84934e]\n  /opt/vespa/lib64/libstorage.so(storage::PersistenceHandler::handleCommandSplitByType(storage::api::StorageCommand&, std::unique_ptr<storage::MessageTracker, std::default_deletestorage::MessageTracker >) const+0x59f) [0x7f4d5e83df2f]\n  /opt/vespa/lib64/libstorage.so(storage::PersistenceHandler::processMessage(storage::api::StorageMessage&, std::unique_ptr<storage::MessageTracker, std::default_deletestorage::MessageTracker >) const+0x14b) [0x7f4d5e83e16b]\n  /opt/vespa/lib64/libstorage.so(storage::PersistenceHandler::processLockedMessage(storage::FileStorHandler::LockedMessage) const+0x1a5) [0x7f4d5e83e675]\n  /opt/vespa/lib64/libstorage.so(storage::PersistenceThread::run(storage::framework::ThreadHandle&)+0xd2) [0x7f4d5e83ec62]\n  /opt/vespa/lib64/libstorage.so(storage::framework::defaultimplementation::ThreadImpl::run()+0x53) [0x7f4d5e983f83]\n  /lib64/libstdc++.so.6(+0xc2b23) [0x7f4d5113bb23]\n  /opt/vespa/lib64/vespa/malloc/libvespamalloc.so(+0x8c30) [0x7f4d60888c30]\n  /lib64/libpthread.so.0(+0x81ca) [0x7f4d5c8d31ca]\n  /lib64/libc.so.6(clone+0x43) [0x7f4d50753e73]\n  [(nil)] (Repeated 5 times since<PHONE_NUMBER>.703860)

It is XFS indeed

Entirely anecdotally, we have not observed this issue for some time on our systems. We do regular fleet-wide OS upgrades, so it's possible the underlying issue has been fixed in the upstream kernel.
What's the kernel version you are running? I.e. uname -rv.
For instance, https://github.com/torvalds/linux/commit/28b4b0596343d19d140da059eee0e5c2b5328731 (which I have no idea if is related, but does sound strikingly familiar...) appears to be part of kernel v6.2 and beyond. After doing some digging it looks like this particular fix was backported into RHEL8 kernel version 4.18.0-513.5.1.

Since this is assumed to be an in-kernel XFS bug and thus outside of Vespa's control, I'm marking this issue as closed. Hopefully the underlying bug has been fixed in newer versions of the kernel—there is at least some empirical evidence to suggest this.


IntrusiveList/Parent/Block assertion fixes

Fixes #198, #199 and #200
It wasn't possible to make IntrusiveList.from behave differently just for IntrusiveList inputs, so I made splitOn just return an ArrayBuffer.

Is there a test for the specific problem this fixes? If not can you add one please


Code from terrain example compiles with errors for wasm

Disclaimer: I am a beginner to wasm and rust, so please be understanding.
I tried to execute the code from the terrain example 1:1 for WebAssembly. Getting errors due to the main function not being found (No main function was found in a binary crate). I did some digging, and it seems that for wasm (rt-multi-thread feature is allowed only for not wasm architectures, just like in the example). That's why it cannot be async, and as a consequence, there is no main function recognised. Am I missing something? I guess one can just create an empty, not async main function, but I don't know if this is the proper convention.

Hi @Kingeh. Thanks for your report and sorry for the late reply.
It works just fine for me (it's running here), what exactly is the command you're using to build the example to wasm? It should be
wasm-pack build examples/terrain --target web --out-name web --out-dir ../../pkg

And is it only the terrain example you have problems with?
The rt-multi-thread is only enabled in non-wasm builds, so shouldn't affect anything when building for wasm.

Okay, I tried again and now it worked.
Sorry for the inconvenience.

No problem, great that it is working 🥳


/driftreset not resetting the frames

hey there!
In an attempt to fix another issue i came across i attempted to reset all frames saved position
by typing /driftreset however when i do that WoW does not recognize the command (And i made sure the addon was loaded)
I also attempted /drift reset but neither worked. Is this something that is temporarly broken? or is named a different command? :)

Opening Escape>Interface>Drift>General options>BUTTON: Reset Frames
Does allow me to press the button to reset the frames, so its not the worst thing in the world :D Was just wondering why the commandline wasnt working.

Hi Wybe, thanks for letting me know about the issue! I have a couple questions to help narrow down the cause.

What version of Drift do you have installed? The /driftreset command was just added in the most recent version of the addon (1.0.4). If you have anything older installed, the command does not exist. You can check the version by doing Escape->Interface->AddOns->Drift and seeing what number is next to "Version".

Is the issue that WoW says Type /help for a listing of a few commands. after you enter /driftreset? Or is the issue that you enter /driftreset but nothing happens? I want to make sure I understand.

Also, I'm planning to add /drift reset in the future, but it's not implemented  yet.
-Jared

Oof, i did indeed not check if i had the latest version installed. Sorry that i forgot one of the most basic troubleshooting steps besides turning it on and off again haha!
I had version 1.03 installed, just installed the latest 1.04 and the chat command is now correctly working!! :)
Issue can be closed!


The solution file is invalid.

Hi,
When I attempt to import the solution into our Dynamics 365 environment, I get an error message with the below text in it.
Thanks,
Donal
The solution file is invalid. The compressed file must contain the following at its root: solution.xml,
customizations.xml, and [Content _ Types].xml. Customization files exported from previous versions of
Microsoft Dynamics 365 are not supported.

Thanks

Hi donalmc, I just tested, and works fine.
Please check if your CRM Version is the same version you have. there are 3 versions:
8.0: Dynamics CRM 2016
8.1: Dynamics CRM 2016 Update 1
8.2: Dynamics 365
Thanks,

Hi demianrasko,
Thanks for getting back to me. I got the version on Codeplex installed no problem.
When I look inside the zip available here, it does not seem to be structured as one would expect a Dynamics solution to be structured.
Thanks,
Donal

Please check again, I just uploaded a new version...please confirm if now works, to close the issue...

Hi, we just tried the new solution in an onpremises Dynamics 365 environment, and the solution upload fails.

Hi trondjun, could you share with me the build number of your CRM envirnoment and file name you downloaded?
Send me please also if you have the error details you get
Thanks

Hi!
Thanx for you quick reply!
I downloaded the master branch of your latest build, and we also tried the 1.38 build from cineplex.
I was not able to get the latest build into crm at all, and the latest from codeplex failed.
do you have an prebuilt version of the one with fixes from yesterday? Maybe that is the issue?
We are running Dynamics CRM OnPremises :
versjon 1612 (<IP_ADDRESS>9) (DB <IP_ADDRESS>9)
Thanx,
Trond

On 9 Apr 2017, at 14:09, Demian Adolfo Raschkovan<EMAIL_ADDRESS>wrote:
Hi trondjun, could you share with me the build number of your CRM envirnoment and file name you downloaded?
Send me please also if you have the error details you get
Thanks
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub https://github.com/demianrasko/Dynamics-365-Workflow-Tools/issues/1#issuecomment-292781972, or mute the thread https://github.com/notifications/unsubscribe-auth/ABLqDeyiZ9gbIBRzuheeUMhhti0At6Dxks5ruMqBgaJpZM4MxpFV.

Thanks!
I'll check that tonight...
Regards

Hi again!
This might actually be something on our installation.
Will let you know if this is an actual issue. We are not able to install any solutions / plugins at all.
Thanx
Trond

On 9 Apr 2017, at 15:15, Demian Adolfo Raschkovan<EMAIL_ADDRESS>wrote:
Thanks!
I'll check that tonight...
Regards
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub https://github.com/demianrasko/Dynamics-365-Workflow-Tools/issues/1#issuecomment-292785201, or mute the thread https://github.com/notifications/unsubscribe-auth/ABLqDdDfNCqj8AqXKYNpBjPdJjKitudKks5ruNnhgaJpZM4MxpFV.

Hi trondjun, I just tried in my D365 Onprem server, and works fine:

(I tested with this file: https://github.com/demianrasko/Dynamics-365-Workflow-Tools/releases/download/<IP_ADDRESS>/Dynamics365WorkflowTools_1_0_38_1_8.2.zip)
If you cannot import any solution, then the issue is not in this solution, is on your server implementation.
Please check if the service "Microsoft Dynamics CRM Sandbox Processing Service" is running (another user has this issue this week: https://github.com/demianrasko/Dynamics-365-Workflow-Tools/issues/2 )
hope this helps!
regards


The URDF problem of B2W

When I use Isaac Gym to load the URDF of BW2, I find that its right wheel always gets stuck in the ground.

I found that this seems to be caused by an incorrect collision body.


[Bug]: Cannot deploy latest release (1.7.5) to Heroku

Is there an existing issue for this?

[X] I have searched the existing issues

Description
I cannot deploy Appsmith to Heroku (using Mongo Atlas connection URL) per instructions in the documentation. I tried both master and 1.7.5 git tree. After the installation you get Appsmith server is unavailable screen and in the logs - Java exceptions (attached). Btw, I did verify MongoDB connection and it works.
intmaker-appsmith-logs-1656265317090.txt
Steps To Reproduce

Press "Deploy to Heroku" button from docs page and follow instructions
Deployed app does not start, logs contain lots of java exceptions

Public Sample App
No response
Version
Self Hosted - 1.7.5

Hey, thanks for sharing the full logs. I see the following error message in the logs:
Database name must not be empty

Can you confirm if you have a database name set in your value for APPSMITH_MONGODB_URI please?
For example, the has a database name called dbname:
<EMAIL_ADDRESS>

Hey @ribtoks, the database doesn't need creating. MongoDB will auto-create databases when someone attempts to use it. So, in your cluster URI, just set the database name to appsmith or something and restart, it should pick it up.

I can confirm that after appending appsmith to the MongoDB connection string, everything worked out. Thanks @sharat87 !


step 2 (1rst set of steps) is too vague

The text "Assign Storage Blob Data Contributor RBAC role to your SQL Database server." did not give me enough information to complete the step as I was not aware of how Assigned Identities worked.
Maybe change to "... role to your SQL Database sever by selecting your-database-servername when Assigning access to an 'Azure AD user, gruop, or service principle'"
Not sure if that is clear or not but something along those lines.

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

ID: 2eb5097c-fc6e-f0a5-07a6-a84e05aa0bb6
Version Independent ID: 1004e6b8-344f-6fdc-391a-35c540f4bf9d
Content: VNet endpoints and rules for single and pooled databases in Azure SQL
Content Source: articles/sql-database/sql-database-vnet-service-endpoint-rule-overview.md
Service: sql-database
Sub-service: security
GitHub Login: @oslake
Microsoft Alias: moslake

@eoq  Thanks for bringing this to our attention. Your feedback will be shared with the content owner for further review.

@eoq We are assigning it to author for further clarity regarding the text or if any additions are required.
@oslake Please review the mentioned part of the document under title "Impact of using VNet Service Endpoints with Azure storage" and please check if we can provide clarity regarding the same.

@VanMSFT - can you take a look at this one? Thanks!

@NavtejSaini-MSFT - can you assign this issue to @KavithaJonnakuti

#reassign:KavithaJonnakuti

@KavithaJonnakuti Please let us know if you need any further information regarding this issue.

@KavithaJonnakuti @stevestein Any update regarding this issue.

#reassign:julieMSFT

@eoq Thank you for your input on this article. I have made the changes and you should see them later today in the content. I will close this issue.

#please-close


Cosmetic changes in JS files, removed unused code

Parent issue: #2389

@skateman : would you to also review this one?

@romanblanco:  please, rebase

@martinpovolny rebased.

looks good @martinpovolny


Refactoring suggestions

While putting PR #625 together, I had to go again through most of PCUIC trying to understand the logic of each file, and while I was doing so I collected quite some things that I felt were strange/hard to grasp/unclear, here they are! I’ll try and take care of this soon.

PCUIC File
Issues

Syntax/PCUICTactics.v
should this be in Syntax or in utils?

utils/PCUICUtils.v
nothing to do here, move to template utils

utils/PCUICOnOne.v
same, move to template utils (merge with All_Forall?)

utils/PCUICSize.v
merge with AstUtils?

Syntax/PCUICInduction.v
merge with AstUtils?

Syntax/PCUICDepth.v
merge with AstUtils?

utils/PCUICPretty.v
merge with AstUtils? Why do we have print_term and string_of_term?

Syntax/PCUICPosition.v
Equality should depend on position, not the other way around?

Syntax/PCUICNamelessDef.v
subsumed by PCUICAlpha, to be removed

Syntax/PCUICClosed.v
what is the point of this given that we have OnFreeVars? Should we try and merge them?

Syntax/PCUICRenameDef.v
this is only 60 lines, and has a weird dependency on typing for something in "syntax", we should probably do something (at least change the name). Also, there is a concurrent notion in PCUICParallelReduction.

Syntax/PCUICInstDef.v
similar to PCUICRenameDef.v

Syntax/PCUICLiftSubst.v
how much of this should go into files

Syntax/PCUICContextRelation.v
made this a part of BasicAst, where context_decl is first defined

PCUICContextSubst.v
Is this worth keeping?

PCUICCasesContexts.v
similar to PCUICContextSubst.v

Conversion/PCUICNamelessConv.v
subsumed by PCUICAlpha, to be removed

Typing/PCUICNamelessTyp.v
subsumed by PCUICAlpha, to be removed

Conversion/PCUICWeakeningEnvConv.v
should contain the right lemmas which are for now in PCUICWeakeningEnvTyp.v

Conversion/PCUICUnivSubstitutionConv.v
same as for PCUICWeakeningEnvConv.v

Conversion/PCUICOnFreeVarsConv.v
should be renamed/moved into other files

Conversion/PCUICClosedConv.v
should be renamed/moves into other files

Typing/PCUICClosedTyp.v
this is not about stability of typing, does putting it with the others still make sense?

Typing/PCUICContextConversionTyp.v
there is no PCUICContextConversionConv counterpart, this is weird

PCUICReduction.v
needs a bit of cleaning up to present the congruence lemmas properly

PCUICGlobalEnv.v
should this be integrated to EnvironmentTyping.v? Nothing specific to typing here

PCUICGeneration.v
very short, should it be merged into Typing.v?

PCUICInversion.v
how much is this redundant with the equivalence bidirectional <-> undirected? should we mention this is a consequence of confluence?

PCUICEqualityDec.v
does this belong here or in the safe-checker?

PCUICSN.v
try and minimize dependencies?

PCUICSafeLemmata.v
should these lemmas be moved to other files where they belong?

PCUICSubstitution.v
there seems to be a lot of mess in this file, does all of it belong here?

PCUICCumulativity.v
maybe change the name to be clearer?

PCUICParallelReductionConfluence.v
should we change rho’s name? it is very uninformative as is

PCUICConfluence.v
also contains properties relating eq_term and reduction (eq_term is a simulation for confluence), should we split that apart?

PCUICWellScopedCumulativity.v
the name equality is very confusing here imho

PCUICConversion.v
There’s a lot here, putting forward the interesting bits or splitting the file might make sense

PCUICContexts.v
Not sure what the coherence is here

PCUICArities.v
There’s not much about arities here, maybe could be integrated into PCUICSpine (and maybe other places)?

PCUICSpine.v
Not sure what’s happening here

PCUICCanonicity.v
Does not prove canonicity at all… Should we still prove a form of progress here? Use other forms that are proven elsewhere more or less implicitely?

PCUICConvCumInversion.v
This looks like something we should do otherwise using the relations we already have

PCUICPrincipality.v
Should we keep this now that we have the proof using bidirectional typing?

Bidirectional/BDEnvironmentTyping.v
should ideally be integrated into EnvironmentTyping

Safe Checker file
Issue

PCUICWfEnv.v
Does this belong where it is? Maybe it should be integrated into

While putting PR #625 together, I had to go again through most of PCUIC trying to understand the logic of each file, and while I was doing so I collected quite some things that I felt were strange/hard to grasp/unclear, here they are! I’ll try and take care of this soon.

PCUIC File
Issues

Syntax/PCUICTactics.v
can be in utils?

utils/PCUICUtils.v
nothing to do here, move to template utils ✅

utils/PCUICOnOne.v
same, move to template utils (merge with All_Forall?) ✅

I think all the follow three could be merged but separately from AstUtils

PCUIC File
Issues

utils/PCUICSize.v
merge with AstUtils?

Syntax/PCUICInduction.v
merge with AstUtils?

Syntax/PCUICDepth.v
merge with AstUtils?

PCUIC File
Issues

utils/PCUICPretty.v
merge with AstUtils? Why do we have print_term and string_of_term?

I prefer having pretty printing separate from general AstUtils. print_term is more complex and requires an environment, string_of_term is really for the raw syntax.

PCUIC File
Issues

Syntax/PCUICPosition.v
Equality should depend on position, not the other way around? ✅

Syntax/PCUICNamelessDef.v
subsumed by PCUICAlpha, to be removed ✅

Syntax/PCUICClosed.v
what is the point of this given that we have OnFreeVars? Should we try and merge them?

The two definitions are useful, Closed is closer to what Coq implements (and uses first-order datastructures, more efficient than the on_free_vars predicate). Ideally we should move all the "closed" calls to the safe-checker and use only on_free_vars in the specs/PCUIC. But much of the metatheory would need to be adapted (it uses subst/subst_context a lot in lemma statements).

PCUIC File
Issues

Syntax/PCUICRenameDef.v
this is only 60 lines, and has a weird dependency on typing for something in "syntax", we should probably do something (at least change the name). Also, there is a concurrent notion in PCUICParallelReduction.

Syntax/PCUICInstDef.v
similar to PCUICRenameDef.v

There is no longer a concurrent notion, AFAICT. Maybe we should have a general file PCUICOperations or something with the definitions of renaming and substitution(s)?
Syntax/PCUICLiftSubst.v | how much of this should go into files
I think we should rather move general technical lemmas about lift/subst there.

PCUIC File
Issues

Syntax/PCUICContextRelation.v
made this a part of BasicAst, where context_decl is first defined ✅

PCUICContextSubst.v
Is this worth keeping?

This could go with the subslet/untyped_subslet theory. Merging these would be nice but will take some time.

PCUIC File
Issues

PCUICCasesContexts.v
similar to PCUICContextSubst.v

This should be split into PCUICCases for defs and PCUICAlpha for lemmas about alpha conversion

PCUIC File
Issues

Conversion/PCUICNamelessConv.v
subsumed by PCUICAlpha, to be removed ✅

Typing/PCUICNamelessTyp.v
subsumed by PCUICAlpha, to be removed ✅

Conversion/PCUICWeakeningEnvConv.v
should contain the right lemmas which are for now in PCUICWeakeningEnvTyp.v

Conversion/PCUICUnivSubstitutionConv.v
same as for PCUICWeakeningEnvConv.v

Conversion/PCUICOnFreeVarsConv.v
should be renamed/moved into other files

Conversion/PCUICClosedConv.v
should be renamed/moves into other files

Typing/PCUICClosedTyp.v
this is not about stability of typing, does putting it with the others still make sense?

Typing/PCUICContextConversionTyp.v
there is no PCUICContextConversionConv counterpart, this is weird

PCUICReduction.v
needs a bit of cleaning up to present the congruence lemmas properly

PCUICGlobalEnv.v
should this be integrated to EnvironmentTyping.v? Nothing specific to typing here

PCUICGeneration.v
very short, should it be merged into Typing.v?

PCUICInversion.v
how much is this redundant with the equivalence bidirectional <-> undirected? should we mention this is a consequence of confluence?

PCUICEqualityDec.v
does this belong here or in the safe-checker?

PCUICSN.v
try and minimize dependencies?

PCUICSafeLemmata.v
should these lemmas be moved to other files where they belong?

PCUICSubstitution.v
there seems to be a lot of mess in this file, does all of it belong here?

PCUICCumulativity.v
maybe change the name to be clearer?

PCUICParallelReductionConfluence.v
should we change rho’s name? it is very uninformative as is

PCUICConfluence.v
also contains properties relating eq_term and reduction (eq_term is a simulation for confluence), should we split that apart?

PCUICWellScopedCumulativity.v
the name equality is very confusing here imho

PCUICConversion.v
There’s a lot here, putting forward the interesting bits or splitting the file might make sense

PCUICContexts.v
Not sure what the coherence is here

PCUICArities.v
There’s not much about arities here, maybe could be integrated into PCUICSpine (and maybe other places)?

PCUICSpine.v
Not sure what’s happening here

PCUICCanonicity.v
Does not prove canonicity at all… Should we still prove a form of progress here? Use other forms that are proven elsewhere more or less implicitely?

PCUICConvCumInversion.v
This looks like something we should do otherwise using the relations we already have

PCUICPrincipality.v
Should we keep this now that we have the proof using bidirectional typing?

Bidirectional/BDEnvironmentTyping.v
should ideally be integrated into EnvironmentTyping

Sorry for the long comment but that seemed to be the best way :) I think this gives a clear TODO list in any case!


[CARBONDATA-2321] Fix selection of partition column after concurrent load fails randomly

Be sure to do all of the following checklist to help us incorporate
your contribution quickly and easily:

[x] Any interfaces changed? No

[x] Any backward compatibility impacted? No

[x] Document update required? No

[x] Testing done
Please provide details on
- Whether new unit test cases have been added or why no new tests are required? No Test Manually
- How it is tested? Please attach test report.
- Is it a performance related change? Please attach the performance test report.
- Any additional information to help reviewers in testing this change.

[x] For large changes, please consider breaking it into sub-tasks under an umbrella JIRA.

SDV Build Fail , Please check CI http://<IP_ADDRESS>:8080/job/ApacheSDVTests/4395/

LGTM


Injecting the container instance

Is your feature request related to a problem? Please describe.
There are situations, where I need to create instances of a class based on events. In these cases, I'd like to be able to ask the container for a new instance, but currently it doesn't seem possible to inject the container as a dependency.
Description
I'd like something along the lines of:
@injectable()
class Foo {
  constructor(private container: DependencyContainer ) {}
  onContextCreated() {
     const contextListener = this.container.resolve(ContextListener);
     //...
  }
}

Alternate solutions

I guess it might be possible to use registerInstance for this, but that doesn't seem very clean.
Using global context is not always a viable option

I'm still new to dependency injection, so maybe I'm missing a different pattern that should be used in such cases, but at least one other di lib supports this: https://github.com/justmoon/constitute#containers

I haven't tried this, but I think you can register the DependencyContainer manually, but I don't think we do that by default since it can result in usage of some anti-patterns (namely, Service Locator). You may have a valid exception to that if you can't find a way to inject ContextListener or a factory for it via the constructor.

No matter what I try to register DependencyContainer, I always get:
Error: Cannot inject the dependency at position #0 of "Foo" constructor. Reason:
    TypeInfo not known for "Object"

// This doesn't work either:
// container.register("DependencyContainer", { useFactory: (c) => c });

@injectable()
@registry([
  {
    token: "DependencyContainer",
    useFactory: (c) => c
  }
])
class Foo {
    constructor(public container: DependencyContainer) {
        // This sample is simplified.. I wouldn't use it in the constructor
        const bar = container.resolve(Bar);
    }
}

I'm guessing the above doesn't work, because it can't associate the interface with the string token somehow. Though I thought this was supposed to work.
This way seems to work, but is a bit ugly:

class MyContainer {
    constructor(public container: DependencyContainer) {
    }
}
container.register(MyContainer , { useFactory: (c) => new MyContainer (c) });

@injectable()
class Foo {
    constructor(public container: MyContainer) {
        // This sample is simplified.. I wouldn't use it in the constructor
        const bar = container.container.resolve(Bar);
    }
}

Taking this a step further, I guess this is somewhat acceptable:
class BarFactory {
    constructor(private container: DependencyContainer) {}
    create(): Bar {
        return this.container.resolve(Bar);
    }
}
container.register(BarFactory, { useFactory: (c) => new BarFactory(c) });

@injectable()
class Foo {
    constructor(public barFactory: BarFactory) {
        // This sample is simplified.. I wouldn't use it in the constructor
        const bar= barFactory.create();
    }
}

Not sure if there is an anti-pattern in there though

I think your last example (with BarFactory) is probably the way to go for delayed resolution. That way, Foo never needs to know anything about the container, and BarFactory only uses it as much as necessary.

I'm gonna go with that for now. Thanks for the feedback


Use Default in Cpu with dependency injection

Thanks for the contribution!
Unfortunately, this same contribution was discussed previously in this PR, and I decided not accept it (you can see my reasoning here), so don't think I'll be accepting this either.

OOhh! I completely misunderstood that point. I'm super sorry for cluttering your repo with the same thing over again : (

Hey, no worries! It'd be a pain to have to dig through every closed PR etc to find out what's been done before. Thanks for understanding!


Inconsistent implementation of MutablePersistable

The current implementation of PersistableImplementor generates byte-code that a typical compiler probably would not.
Let's take one of the sample classes part of the test suite:
@Getter
public class SampleAggregate implements AggregateRoot<SampleAggregate, SampleAggregateIdentifier> {

	private final SampleAggregateIdentifier id;

        // ... other non-relevant stuff

	public SampleAggregate(SampleAggregateIdentifier id) {
		this.id = id;
	}

        // ... other non-relevant stuff
}

The above will generate byte-code with the following problems:

It will incorrectly implement MutablePersistable, lacking the implementation for the  __jMolecules__markNotNew method
it will have an additional default constructor despite the final fields that need initialisation, in the original code

Suggestions:
The first problem might be fixable by always generating the missing implementation, instead of being conditional to a given callbackInterface.
e.g.
JMoleculesType implementPersistable(JMoleculesType type) {
    // ...
    return type.findIdField().map(field -> {
        // ...
        return type
            .implement(MutablePersistable.class, type.getTypeDescription(), field.getType())
            .mapBuilder(this::generateCallbacks)
            // fix (1): generate the method regardless
            .mapBuilder(it -> !it.hasMethod(named(MARK_NOT_NEW_METHOD)), this::generateMarkNotNewMethod)
            .mapBuilder(it -> !it.hasField(named(IS_NEW_FIELD)), this::generateIsNewField)
            .mapBuilder(it -> !it.hasMethod(isEquals()), it -> generateEquals(it, isIdField))
            .mapBuilder(it -> !it.hasMethod(isHashCode()), it -> generateHashCode(it, isIdField))
            .mapBuilder(it -> !it.hasMethod(hasMethodName(IS_NEW_METHOD)), this::generateIsNewMethod);
        }).orElse(type);
}

// ...

private Builder<?> generateCallbacks(Builder<?> builder) {
    if (options.callbackInterface != null) {
        // fix (1): method generation moved earlier
        builder = builder.require(createCallbackComponent(builder.toTypeDescription()));
    }

    // ...

    return builder;
}

Not sure how to fix (2) though.

It will incorrectly implement MutablePersistable, lacking the implementation for the __jMolecules__markNotNew method

Can you elaborate on that? I don't see how you come to that, as the code you show below checks for the presence of the method, and, if not present, generates it.

it will have an additional default constructor despite the final fields that need initialisation, in the original code

That's correct but mandated by JPA. None of the code generated here will be callable from user code, though.

Can you elaborate on that? I don't see how you come to that, as the code you show below checks for the presence of the method, and, if not present, generates it.
The code that I pasted in there is a possible fix, the current version doesn't look like that.
The latest version available here generates the method conditionally on whether callbackInterface has been provided or not. In cases where the callbackInterface is not provided the method is not getting generated, hence the interface not implemented properly.


Safecharge URLS

Why you are using https://test.safecharge.com/service.asmx/Process? instead of https://secure.SafeCharge.com/ppp/purchase.do?
Thank you

This is for SafeCharge Direct Gateway, not the "Cashier" (which is just like Gate2Shop @see https://github.com/mfauveau/omnipay-gate2shop).


Tests for https://github.com/stleary/JSON-java/pull/452

updates tests to cover more cases of tokenizing
uncomments tests that should now work

Approved, to be merged after https://github.com/stleary/JSON-java/pull/452 is committed.


cosmjs-types 0.9.0 doesn't compile

when I try to use it the following file stops vercel from building it.
removing the utf-8 character seems to make it happy locally.

Failed to compile.
16:28:22.092 |
16:28:22.092 | ./node_modules/@cosmjs/encoding/build/utf8.d.ts:1:1
16:28:22.092 | Type error: File appears to be binary.
16:28:22.092 |
16:28:22.093 | > 1 \| export declare function toUtf8(str: string): Uint8Array;
16:28:22.093 | \| ^
16:28:22.093 | 2 \| /**
16:28:22.093 | 3 \|  * Takes UTF-8 data and decodes it to a string.
16:28:22.093 | 4 \|  *
16:28:22.219 | Error: Command "yarn run build" exited with 1
16:28:22.843

<br class="Apple-interchange-newline">

Hey hey!
This looks like a bug in the tool that is executed at the build step. The linter? It probably checks for � to differentiate text from binary files but � is a valid unicode character. But it should be simple enough to change the doc comment to work around it.

Done in https://github.com/cosmos/cosmjs/pull/1570. This will be part of the next patch release of @cosmjs/encoding


cannot disable --info=inline + map esc to close fzf

this is info inline fzf config, i dont want this.
i tried disabling it from setup {} with   fzf_args            = '--exact -i -m --info=default'
it doesnt work.
and another problem: i am unable to find close_mapping for closing fzf popup.
i cant close it with ctlr-q, but i want to close it from <esc>

okey i found in fzf man page. there is an abort event which is triggered by default with esc or c-q, however, ctrl-q works in nvim, but esc doesnt.
and this is my config for fzf_binds, just doesnt work...
  fzf_binds           = {               -- fzf '--bind=' options
	["esc"] = "abort"
  },

lua require('fzf-lua').files({ fzf_info = "--info=default" })

this works, thanks.
about the , yea it works. it just gets out of insert mode in fzf. it doesnt get me out of fzf popup.

ups, i have this :tmap <Esc>

it works now. i've disabled the mapping. thanks man

ups, i have this t <Esc> * <C-\><C-N>
now makes sense, this also happens in telescope
and every terminal buffer.

Telescope isn't a terminal buffer though.

ups, i have this t <Esc> * <C-\><C-N>
now makes sense, this also happens in telescope
and every terminal buffer.

Telescope isn't a terminal buffer though.

but i had the same problem. i was put in normal mode in telescope input after pressing esc.


refactor(multiple): remove unused acceptance members

Currently there are some places with unused acceptance members, as in the stepper where have 12 (probably from a bad copy-paste)! So, in this PR I implemented the logic to handle these cases in coercionTypesRule where a class only can have "known" acceptance members. I also added CanStick interface to the rule configuration in tslint.json (it helped to caught another places with unnecessary acceptance members) and make use of mixinDisableRipple where I could to make sure using the static member (stepper doesn't accept a non-boolean today).

Yeah, initially acceptance members were not inherited. We never linted to remove/avoid these

@mmalerba @annieyw sorry for the delay, I rebased and fixed up the commit message.

FWIW I'll mention that TS 4.3 adds support for setters that have a different type from the corresponding getter (despite the TS team previously saying they wouldn't do this). Angular will probably add support for TS 4.3 in v12.1, at which point we can probably drop all of these completely.

I'm seeing ~200 failing tests in google when I test against this PR. I would suggest splitting out the actual code changes (changes to mixins and stuff) into a separate PR and having this one be just for removing unused acceptance members

I'm seeing ~200 failing tests in google when I test against this PR. I would suggest splitting out the actual code changes (changes to mixins and stuff) into a separate PR and having this one be just for removing unused acceptance members

I adjusted the PR accordingly. LMK if evertyhing is ok now.

I'm going to close this because it looks like accepting members are no longer needed.


Incorrect syntax for powershell.

Just started using this library and I am sorry if this is incorrect but tried running the code from package.json "wttab -t 'Run API' npm run run:api" and when windows terminal opens it throws an error:

When added debug statement "wttab -t 'Run API' npm run run:api --debug" i see that it tried running a command:
"wt.exe" -w 0  --title "'Run" -p "Windows PowerShell" -d "dir/path" API',npm,run,run:api
While testing the wt command I found out that the correct syntax should have been:
wt.exe -w 0  --title "Run API" -p "Windows PowerShell" -d "dir/path" powershell npm run run:api
This runs the code nicely.
Is it just my mistake or something is actually wrong?

I will look into this, and add some more testing.

Did this ever work after the fix?
I am facing exactly same issue.
Kindly help.

@malhar016 Yes if you use it in npm package JSON you need to escape the quotes. I'm working towards a new release with test cases, so if you encounter any other issues let me know


router: add new ratelimited retry backoff strategy

This PR implements a new retry back off strategy that uses values from response headers like Retry-After or X-RateLimit-Reset (the headers are configurable) to decide the back off interval before retrying a request.
This is PR (2/2) that addresses issue #12200. See also the design document: https://docs.google.com/document/d/1NSzrx3-KsAFs0ObaLQZUVIt9O4PZv3mXi3Lm7LNzmZE/edit?usp=sharing
Signed-off-by: Martin Matusiak<EMAIL_ADDRESS>Risk Level: Low
Testing: New unit tests added for all code changes.
Docs Changes: added
Release Notes: added

Please merge master and I will take a look. Thank you!
/wait

/wait

FYI: I'm currently working on #12356 that will ultimately provide the X-RateLimit-Reset header.

I think my initial stab at this PR was a little under documented. I've pushed a decent update to the docs which aims to improve this.
It includes the new protobuf message hashed out with the help of @zuercher. It also includes an example config and walks the user through exactly what will happen, including the various corner cases. My hope is that this makes the design much clearer and addresses @htuch's concern above. I belive it also clarifies most of your questions, Matt.
https://github.com/envoyproxy/envoy/pull/12202/commits/eeae8e8a098d4e6d6fd311bd5ed797f8ae68fd15#diff-762b98ebf225e9214f643752cf504760
The initial implementation was leaning on HeaderMatcher, which doesn't quite fit the use case. In order to process the new ResetHeader protobuf message in code I need to implement an abstraction similar to HeaderMatcher, but it will be specific to the use case of this PR. I'm thinking it will have an interface in header_map.h and an implementation similar to header_utility.h. @mattklein123 does this approach sound good to you?

Can you merge main and fix CI and I can take another look? Thank you.
/wait

Converted to draft because I need to implement the new design to make the code consistent with the api and get all the CI builds green.

Ready now, @mattklein123

Thanks for the api review, @mattklein123 !
@zuercher, do you have anything else you'd like to see in this PR?

I think we're good here, @mattklein123 ?
To the person merging this - can I get a little help getting this over the line? PRs are merged to master all the time and create conflicts against the release notes and the stats integration test. I've fixed it a bunch of times already, but if it conflicts again during US working hours I won't have a chance to resolve it until my Sydney morning and it won't have a chance to get merged until a day later, by which time there's probably a new conflict. So would you mind fixing the conflict if you see one? That'd be awesome!

I believe @zuercher was owning the review here. @zuercher can you see this through?

@mattklein123 still needs api approval

@numerodix please never force push. It makes reviews incredibly difficult. Just add commits and merge main. Thank you!

@mattklein123 Thanks! Can you merge this now?


remove enable reuse port for quic

This is by default to true in Envoy. So we can remove this

[ ] Ambient
[ ] Configuration Infrastructure
[ ] Docs
[ ] Installation
[ ] Networking
[ ] Performance and Scalability
[ ] Policies and Telemetry
[ ] Security
[ ] Test and Release
[ ] User Experience
[ ] Developer Infrastructure

I just accidentally came across this. No specific reason


[SPARK-13149][SQL]Add FileStreamSource

FileStreamSource is an implementation of org.apache.spark.sql.execution.streaming.Source. It takes advantage of the existing HadoopFsRelationProvider to support various file formats. It remembers files in each batch and stores it into the metadata files so as to recover them when restarting. The metadata files are stored in the file system. There will be a further PR to clean up the metadata files periodically.
This is based on the initial work from @marmbrus.

@marmbrus @tdas Please take a look.

Test build #50604 has started for PR 11034 at commit a2784ff.

Test build #50604 has finished for PR 11034 at commit a2784ff.

This patch passes all tests.
This patch merges cleanly.
This patch adds the following public classes (experimental):
class FileStreamSink(
class FileStreamSource(
trait HadoopFsRelationProvider extends StreamSourceProvider with StreamSinkProvider

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/50604/
Test PASSed.

Test build #50678 has started for PR 11034 at commit 71e6312.

Test build #50684 has started for PR 11034 at commit 6a90c55.

Test build #50678 has finished for PR 11034 at commit 71e6312.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/50678/
Test FAILed.

retest this please

Test build #50687 has started for PR 11034 at commit 6a90c55.

Test build #50684 has finished for PR 11034 at commit 6a90c55.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/50684/
Test PASSed.

Test build #50687 has finished for PR 11034 at commit 6a90c55.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/50687/
Test PASSed.

Test build #50779 has started for PR 11034 at commit 93af82e.

Test build #50780 has started for PR 11034 at commit 2af6fc8.

Test build #50779 has finished for PR 11034 at commit 93af82e.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/50779/
Test FAILed.

Test build #50780 has finished for PR 11034 at commit 2af6fc8.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/50780/
Test PASSed.

@marmbrus After discussing with @tdas offline, we think there will be a lot of changes to FileStreamSource if we want to cache the content of metadata files (so that we don't need to read them in getNextBatch) and handle corrupted metadata files. So it's meaningless to review this one now. Let me just work on that now and review this one later.

How long is it going to take to implement caching?  I'd rather measure the performance of this implementation before we start optimizing.

How long is it going to take to implement caching? I'd rather measure the performance of this implementation before we start optimizing.

Not a lot of work, actually. Just adding a <batch_id, files> map and updating it in getNextBatch.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/50803/
Test FAILed.

retest this please

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/50805/
Test FAILed.

retest this please

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/50806/
Test FAILed.

retest this please

Test build #50807 has started for PR 11034 at commit ca1e6b8.

Test build #50809 has started for PR 11034 at commit ca1e6b8.

Test build #50807 has finished for PR 11034 at commit ca1e6b8.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/50807/
Test PASSed.

Test build #50809 has finished for PR 11034 at commit ca1e6b8.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/50809/
Test PASSed.

Merged build finished. Test PASSed.

Test build #50828 has started for PR 11034 at commit d911963.

Changes to this PR:

Add a HashMap batchToMetadata to store the metadata in memory so that we don't need to read metadata files in getNextBatch
Load metadata files and handle corrupted metadata files when finding metadata files in the constructor
Only text format doesn't require a schema when there are no existing files. For other cases, it will throw IllegalArgumentException.

Test build #50830 has started for PR 11034 at commit ce0556d.

Test build #50838 has started for PR 11034 at commit 9a1042c.

Test build #50828 has finished for PR 11034 at commit d911963.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/50828/
Test PASSed.

Merged build finished. Test PASSed.

Test build #50830 has finished for PR 11034 at commit ce0556d.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/50830/
Test PASSed.

Test build #50838 has finished for PR 11034 at commit 9a1042c.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/50838/
Test PASSed.

Small comments, otherwise LGTM

Test build #50848 has started for PR 11034 at commit 1ffee5f.

Test build #50848 has finished for PR 11034 at commit 1ffee5f.

This patch passes all tests.
This patch merges cleanly.
This patch adds the following public classes (experimental):
  case class Result(avgMs: Double, bestRate: Double, bestMs: Double)
             s\"Unable to generate an encoder for inner class$`
case class NaturalJoin(tpe: JoinType) extends JoinType

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/50848/
Test PASSed.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/50932/
Test FAILed.

retest this please

Test build #50937 has started for PR 11034 at commit fb0e3f9.

Test build #50937 has finished for PR 11034 at commit fb0e3f9.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/50937/
Test PASSed.

Offline discussion:
It will be good to have a unit test that documents/tests the behavior of what file source gets generated when format and/or schema is provided/not provided and existing files present / not present, what is the schema generated in the source. So that we have clear understanding of what the behavior is.

Test build #51009 has started for PR 11034 at commit 07e2ddd.

Test build #51009 has finished for PR 11034 at commit 07e2ddd.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/51009/
Test PASSed.

Merged build finished. Test PASSed.

LGTM. New tests are great, and they make sense. Merging this!
Thanks @zsxwing and @marmbrus


What's going to happen to iPokeGo?

We can use what we have and wait for the API fix?
To be honest i lost hope....

@HasanY1989 "Use what we have"? What would that be? My map doesn't show Pokémon, PokéStops or Gyms so what I have is useless. I'm sure there are devs out there that are still going to crack the API (again) but unfortunately it won't be coming from that awesome repo.

I know, but the current stable vi have, cant we just implent the api thing? im not a coder my self mate


Composite foreign keys generate bogus lookup methods

Using the default templates, I get the following foreign key lookup method that fails to compile because it is attempting to call another method that does not exist:
// Machine returns the Machine associated with the Unit's ModelName (model_name).
//
// Generated from foreign key 'unit_machine_fk'.
func (u *Unit) Machine(db XODB) (*Machine, error) {
	return MachineByModelName(db, u.ModelName)
}

There is no MachineByModelName(db, modelName) method generated. The closest is MachineByModelNameMachineNum(db, modelName, machineNum), which matches the foreign key documented in the comment.
           Table "public.unit"
      Column       |  Type   | Modifiers
-------------------+---------+-----------
 model_name        | text    | not null
 application_name  | text    | not null
 machine_num       | integer | not null
 unit_name         | text    | not null
 subordinate_to    | text    |
 public_ip_address | inet    | not null
Indexes:
    "unit_pkey" PRIMARY KEY, btree (model_name, unit_name)
Check constraints:
    "unit_check" CHECK (unit_name ~~ (application_name || '/%'::text))
Foreign-key constraints:
    "unit_application_fk" FOREIGN KEY (model_name, application_name) REFERENCES application(model_name, application_name) ON DELETE CASCADE
    "unit_machine_fk" FOREIGN KEY (model_name, machine_num) REFERENCES machine(model_name, machine_num) ON DELETE CASCADE
    "unit_model_fk" FOREIGN KEY (model_name) REFERENCES model(model_name) ON DELETE CASCADE
    "unit_subordinate_fk" FOREIGN KEY (model_name, subordinate_to) REFERENCES unit(model_name, unit_name) ON DELETE CASCADE
Referenced by:
    TABLE "unit" CONSTRAINT "unit_subordinate_fk" FOREIGN KEY (model_name, subordinate_to) REFERENCES unit(model_name, unit_name) ON DELETE CASCADE

+1 for this, i think this is related to the lack of support of composite primary keys


pandas module is deprecated

@sebastian-luna-valero ,
I have noticed on a number of pipelines we are getting warnings that pandas modules are deprecated, specifically pandas.lib and pandas.core.datetools.
I think we should change pandas import statements so this doesn't happened, please see: https://github.com/yhat/ggpy/issues/618

Thanks @Acribbs
I am getting those as well, but looking deeper into them, this is caused by CGATReport, ggplot, and statsmodels:
/conda-install/envs/cgat-p/lib/python3.6/site-packages/CGATReport/DataTree.py:267: FutureWarning: '.reindex_axis' is deprecated and will be removed in a future version. Use '.reindex' instead.
/conda-install/envs/cgat-p/lib/python3.6/site-packages/ggplot/components/smoothers.py:4: FutureWarning: The pandas.lib module is deprecated and will be removed in a future version. These are private functions and can be accessed from pandas._libs.lib instead
/conda-install/envs/cgat-p/lib/python3.6/site-packages/statsmodels/compat/pandas.py:56: FutureWarning: The pandas.core.datetools module is deprecated and will be removed in a future version. Please use the pandas.tseries module instead.

So AFAIK, the refactoring should happen on those packages rather than in our pipelines. Presumably this will occur in new versions of those packages, and the FutureWarning will disappear after we upgrade our conda environments.
Will close but feel free to re-open if necessary.


Implement HTTP caching

In order to optimize performance between the streamer and other modules, we must make sure that the streamer implements proper HTTP caching.
A best practice document is available to summarize how the streamer should handle HTTP caching for the manifest, resources and APIs: https://github.com/readium/readium-2/blob/master/streamer/server/caching.md

This has already been handled in Go, we need to add issues and support for this in both Java and Swift implementations.

This is implemented in NodeJS too.
https://github.com/edrlab/r2-streamer-js


plugins/telescope-live-grep-args: init

Resolves: https://github.com/nix-community/nixvim/issues/1902

@mergifyio queue


EnvoyProxy patch type JSONMerge undocumented / not very useful

Description:
Background: for small scale tests (single node), I want to run envoyproxy without a load balancer and expose it directly using hostPort. To do this I need to patch the container ports of the resulting envoy deployment.
The two supported types of patching are StrategicMerge and JSONMerge.
A StrategicMerge type won't work because it uses containerPort as keys which aren't unique (see also upstream k8s issue https://github.com/kubernetes/kubernetes/issues/105610 ).
The JSONMerge is undocumented in the CRDs or in documentation, but implemented, however, RFC 7396 states the following, which is not very useful when I'd have to patch the entire containers array.

Also, it is not possible to patch part of a target that is not an object, such as to replace just some of the values in an array.

Repro steps:
This results in a single port of protocol UDP:
apiVersion: gateway.envoyproxy.io/v1alpha1
kind: EnvoyProxy
metadata:
  name: http-gateway
spec:
  provider:
    type: Kubernetes
    kubernetes:
      envoyService:
        type: ClusterIP
      envoyDeployment:
        strategy:
          type: Recreate
        patch:
          type: StrategicMerge
          value:
            spec:
              template:
                spec:
                  containers:
                    - name: envoy
                      ports:
                        - containerPort: 10080
                          hostPort: 80
                        - containerPort: 10443
                          protocol: TCP
                          hostPort: 443
                        - containerPort: 10443
                          protocol: UDP
                          hostPort: 443

Environment:
gateway version v1.0.2
Logs:
N/A

@seankhliao did you find any workarounds?

if you're trying to run the deployment or daemonset in host mode you could run
apiVersion: gateway.envoyproxy.io/v1alpha1
kind: EnvoyProxy
metadata:
  name: http-gateway
spec:
  provider:
    type: Kubernetes
    kubernetes:
      envoyService:
        type: ClusterIP
      envoyDeployment:
        useListenerPortAsContainerPort: true
        patch:
          type: StrategicMerge
          value:
            spec:
              template:
                spec:
                  hostNetwork: true

@arkodg I wanted to avoid using the host network namespace; also I think you patch needs dnsPolicy: ClusterFirstWithHostNet to allow it to resolve the XDS endpoint. I also ran into problems with binding privileged ports that I gave up trying to resolve (adding NET_BIND_SERVICE  capability didn't seem to sort it out, and I definitely want to avoid NET_ADMIN or privileged: true on an externally facing HTTP server).
In the end, I was able to get it to work with this patch:
patch:
  type: StrategicMerge
  value:
    spec:
      template:
        spec:
          containers:
            - name: envoy
              ports:
                - containerPort: 10080
                  hostPort: 80
                  name: http-80
                  protocol: TCP
                - containerPort: 19001
                  name: metrics
                  protocol: TCP

however this is a bit messy because it requires updating the patch every time you update the listeners on the gateway.

@arkodg  I agree that hostNetwork is bad practice (although repeated frequently in this repo).
hostPort is better, and at least with Cilium, it works without any additional privileges.
I also use hostPort, and the lack of support in Envoy Gateway means that I will continue to use Contour.

@erikschul can link the relevant contour documentation for enabling something like this

@arkodg
https://projectcontour.io/docs/main/deploy-options/
"Envoy as Daemonset"

I see, thanks for sharing, looks like Contour, auto populates the hostPort in DaemonSet mode.
Envoy Gateway's DaemonSet mode https://gateway.envoyproxy.io/docs/api/extension_types/#kubernetesdaemonsetspec doesnt support this feature by default but you can achieve it by setting the values via the patch field or using a NodePort service (ports cannot be fixed for this), keeping this issue open to hear what others think of this

Even if it's not explicitly supported, it would be nice to see it as a documented (i.e recognized) use case, like under Tasks/Traffic/Using hostPorts (and examples of Deployment/DaemonSet)

Cilium's gateway support hostNetwork, though I believe they don't remap listener ports like envoy does from 443->10443 so it can just work. https://docs.cilium.io/en/latest/network/servicemesh/gateway-api/gateway-api/#host-network-mode
They call out:

This is useful in cases where a LoadBalancer Service is unavailable, such as in development environments or environments with cluster-external loadbalancers.

I've mostly wanted this for local / simple (few nodes) bare metal deploys.


Nifty Row Code Review - Urgent

Hello Nifty Row,
I am doing the code review for your app "CA - NiftyRow NFT & Security Tokens Marketplace Autosave'' on behalf of CRDAO. There are some issues that need immediate attention. I've already emailed you using the one in the README, and also from the DEVxDAO Portal but did not receive a response. Please contact me at t.me/ggurbet so that they can be fixed as soon as possible.

@ggurbet , Thanks for reaching out. Please forward the email and any other materials to<EMAIL_ADDRESS>We'll reach out on telegram as well. Cheers!.

Thanks for the reply @JayEs23. However, that email address is unreachable. I will be waiting for your message on Telegram. See you there!


jax.random.multivariate_normal produces incorrect output with batches of covariance matrices

The tensordot on this line does not perform the intended broadcast matrix-vector multiply. I think you need this (or equivalent),
return mean + np.einsum('...ij,...j->...i', chol_factor, normal_samples)

Here's an example:
import jax.numpy as np
import jax.random

mean = np.zeros((10, 4))
cov = np.eye(4)[None,...].repeat(10, axis=0)
rng = jax.random.PRNGKey(0)
sample = jax.random.multivariate_normal(rng, mean, cov)
print(sample.shape) # is (10, 10, 4); should be (10, 4).

Thanks for the report – I agree that the einsum solution you propose looks correct. Would you like to submit a pull request with the fix?

Yeah! Let's get @slinderman's first of many JAX PRs here!

I left this bug in there just for you to find, Scott.

Ha, thanks @mattjj! I found another minor bug in the shape checking.  Submitted a PR with a new test case here: https://github.com/google/jax/pull/4002.

Merged the fix from Scott in #4002!


Eliminated variable length returns

Fixes #22
I left computeExpectationsInner() as is (e.g. dictionary), as that function is primarily geared intended for internal use.

If we aren't going to use the third argument, I think we can just omit it and nothing will complain:
https://github.com/choderalab/pymbar/pull/148/files#diff-6d49c4d7bec5063b52a900e8455a638bR135
For example, could we change
(Deltaf_ij_estimated, dDeltaf_ij_estimated, _theta) = mbar.getFreeEnergyDifferences()

to
(Deltaf_ij_estimated, dDeltaf_ij_estimated) = mbar.getFreeEnergyDifferences()

?

Nope, my bad.  That doesn't work.
>>> def foo():
...    return (1, 2, None)
...
>>> [x,y] = foo()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: too many values to unpack

Odd---I thought it did.

I see now.  My earlier example tricked me:
>>> def foo():
...    return 1, None
...
>>> [a,b] = foo()
>>> a = foo()

Here, the last line assigns a to the tuple (1, None).

It's less important to return theta at this point, because now if one wants
to return the covariance matrix, one can go down just one level, to the
inner loop code, instead of writing the routine from scratch.
Also, the covariance of differences code makes it easier to calculate the
uncertainties of sums and differences without theta. Note that that
function still needs a good example -- I'll ported that from another code
branch, but it doesn't have examples yet.
On Wed, Jan 7, 2015 at 3:52 PM, John Chodera<EMAIL_ADDRESS>wrote:

Nope, my bad. That doesn't work.

def foo():
...    return (1, 2, None)
...
[x,y] = foo()
Traceback (most recent call last):
File "", line 1, in
ValueError: too many values to unpack

Odd---I thought it did.
—
Reply to this email directly or view it on GitHub
https://github.com/choderalab/pymbar/pull/148#issuecomment-69107397.

OK, if desired we can do a separate pull request to remove the theta returns.


Add DoubleEndedIterator impl for gradient::Take, closes #153

gradient.take(n).rev() is now possible, closes #153

Looks like a fine solution for preserving the current behavior. :+1: An alternative could have been to use start position, end position and step size, but I don't know if it improves anything.
The skew towards the beginning of the range should also be fixed at some point, as I mentioned, but it may be better to do it in a separate PR. It's technically a breaking change, while this doesn't have to be.
The formatting is fine, but you can always just stage and commit the file you have changed, and reset the rest if you want. Either way, I would appreciate it a lot if you can write a short description and include the "closes ..." part in the PR description/initial comment. That makes it show up nicely in the merge commit. :slightly_smiling_face: I should really add a PR template for this...

OK, I added the "closes #" to the title. But I guess it's better on the commit message body alongside a short description. I'll do that and amend this commit.

Just to be clear, I'm talking about your first comment in this thread, where you mentioned cargo fmt. That goes into the merge commit.

Oh, sorry I didn't realize the PR title and description ended up in the merge commit. Almost hit push here.

Is this good?

That's excellent, thanks! It's not easy to know, but quite nice IMO. I just need to make that template, so it's more obvious...

I just took the liberty to remove it from the title, so it's not double.

bors r+


Add new Lint/ItWithoutArgumentsInBlock cop

Follow up https://bugs.ruby-lang.org/issues/18980 and https://github.com/ruby/ruby/pull/9152.
Emulates the following Ruby warnings in Ruby 3.3.
$ ruby -e '0.times { it }'
-e:1: warning: `it` calls without arguments will refer to the first block param in Ruby 3.4;
use it() or self.it

it calls without arguments will refer to the first block param in Ruby 3.4.
So use it() or self.it to ensure compatibility.
# bad
do_something { it }

# good
do_something { it() }
do_something { self.it }

Before submitting the PR make sure the following are checked:

[x] The PR relates to only one subject with a clear title and description in grammatically correct, complete sentences.
[x] Wrote good commit messages.
[ ] Commit message starts with [Fix #issue-number] (if the related issue exists).
[x] Feature branch is up-to-date with master (if not - rebase it).
[x] Squashed related commits together.
[x] Added tests.
[x] Ran bundle exec rake default. It executes all tests and runs RuboCop on its own code.
[x] Added an entry (file) to the changelog folder named {change_type}_{change_description}.md if the new code introduces user-observable changes. See changelog entry format for details.

Looks good!


Example IRI which is supposed to fail is actually valid

abc://should.fail.com is supposed to fail Statement validation according to the test.  However, this is a valid IRI via https://www.ietf.org/rfc/rfc2396.txt (Appendix B)

Yeah, this definitely looks like a bug as that is a valid IRI.

After discussion, Fix to be valid IRI.


SigningUtils and tests fixes

added SigningUtils.getPrivKeyFromPassphrase() to clean up the SigningUtils.decryptPassphrase() routine and implemented it.
changed testDecrypt() fixtures to use the same ones used for the nodejs client
changed testComplete() and testFromFile() fixtures to use a block.io hex-string formatted cleartext passphrase rather than an utf-8 string
removed skipTests config

I added 61c5dc0d6749f00af7ce42f43ae45401ed8ed63b cause the testFromFile would still fail  due to LF vs. CRLF line ending. Thanks for the fixess!


[SPARK-25121][SQL][FOLLOWUP] Add more unit tests for multi-part identifiers in join strategy hints

What changes were proposed in this pull request?

This pr intends to add unit tests for the other join hints (MERGEJOIN, SHUFFLE_HASH, and SHUFFLE_REPLICATE_NL). This is a followup PR of #27935.
Why are the changes needed?

For better test coverage.
Does this PR introduce any user-facing change?

No.
How was this patch tested?

Added unit tests.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/25023/
Test PASSed.

Test build #120315 has started for PR 28013 at commit 30e85a5.

Test build #120315 has finished for PR 28013 at commit 30e85a5.

This patch fails due to an unknown error code, -9.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/120315/
Test FAILed.

Retest this please.

Test build #120320 has started for PR 28013 at commit 30e85a5.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/25031/
Test PASSed.

Test build #120320 has finished for PR 28013 at commit 30e85a5.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/120320/
Test PASSed.

Thanks for the quick response, @dongjoon-hyun !


Livereloading

Hi, I discovered this project via your blog, which I find really inspiring!
I developed a similar project myself, but with the main objective of supporting livereload (when I update something, the browser refreshes automatically): https://code.pfad.fr/devf/
Maybe this is something that could be beneficial to your workflow (the last remaining pain point is having a cross-platform system to get notified of file changes events. I rely on iwaitnotify since I am running Linux).

Thanks for the feedback and the suggestion.
Live reloading is definitely one possible feature for this server that would be useful; I'll consider it, though at this time I don't have specific plans to significantly enhance static-server beyond its current capabilities.