feat: add keyExists helper into StdJson

Proposing keyExists(...) helper that will explicitly determine if a given key exists in a JSON.
Rationale: For an average user, who is using the StdJson decode helpers, it is not trivial to find a way around sudden EVM reverts if requested JSON key doesn't exist.
The documentation doesn't mention what to do in such a case, and try/catch statements do not work either.
This helper can help to avoid reverts when parsing JSON.
Implementation: Although verifying the key exists is just checking the return length of raw parseJson bytes, for an average user this method is not trivial nor well documented (and also looks ugly in code).
Testing: Although lack of formal tests, the implementation was manually verified against an empty string (encodes as 64 bytes: 0x20 and 0x00), null (encoded as 32 zero bytes). Not existing key returns 0x empty bytes array with zero length. More edge cases might need to be verified, depending on how rust JSON parser works.
Example use case:
Assume we use addresses.json containing deployment addresses, and we need to know if a contract was already deployed to a given network or we need to deploy it. keyExists('network.ContractName') will give us the answer.

This seems reasonable to me, I like it. Would be great to add a simple test for each case, there's a broadcast.log.json already in the repo we can use
@odyslam wdyt of this?

Yeah, please add more tests and a mention to the docs.
TBH, it's not super intuitive that it returns an empty string (vs reverting). At nomad we sort of do the same to see if a key exists, so it's it's nice to standardise it.

@odyslam Do you think we should modify vm.parseJson to revert if the key isn't found, then add a vm.tryParseJson that returns an empty string if not found? That way the default/current usage becomes a little stricter and safer, and then this forge-std method wold operate on tryParseJson, since older solidity versions don't have try/catch?

We discussed this internally and aligned that it's better to return an empty string, as it adds flexibility. So, after using this for prod, we aligned that we don't think a revert behavior had any value for us.
Pinging @anna-carroll and  @prestwich in case they want to chime in about the UX. We have used JSON input/output extensively  over the last month.

Hmm, but doesn't the above split into two methods enable the same flexibility but add add safety when that's not needed?
Personally I'd prefer to revert in parseJson if the key isn't found (and tbh I assumed it did), that way it's easy to catch if my JSON input file has a typo in the key name or is missing a key, and my script doesn't succeed anyway with empty/wrong input values. This feels like an easy footgun when using JSON inputs in scripts. How are you currently mitigating this risk?
Another approach is modifying the read* stdJson methods to revert if parseJson returns an empty string, and adding tryRead* alternatives for when you need the flexibility. But this forces users to use the stdJson lib to get that safety, so this seems less ideal
Now I'm wondering how many people have accidentally ran scripts/deployed contracts with the wrong values due to a misconfigured JSON input 😅

Now I'm wondering how many people have accidentally ran scripts/deployed contracts with the wrong values due to a misconfigured JSON input

probably very few, because you generally have to abi decode the output of readJson

Personally I'd prefer to revert in parseJson if the key isn't found (and tbh I assumed it did), that way it's easy to catch if my JSON input file has a typo in the key name or is missing a key

optional keys are standard practice in most real-world json (see e.g. the x-nullable in openapi ,or "type: ["string", "null"] in json schema). A config may not need a key under certain conditions, and should have a way to test if that is the case without reverting the tx. Your desire to revert is served by the failing ABI decoding after the parseJson returns an empty string.
basically, reverting would be bad behavior, considering that optional keys are standard in json, and not indicative of malformatted input

probably very few, because you generally have to abi decode the output of parseJson...Your desire to revert is served by the failing ABI decoding after the parseJson returns an empty string.

Yea, my thinking was this would mainly be an issue for string/bytes types which admittedly are less common input types. Or would ABI decoding revert for those types also? I just assumed it'd return the same empty value.

optional keys are standard practice in most real-world json (see e.g. the x-nullable in openapi ,or "type: ["string", "null"] in json schema). A config may not need a key under certain conditions, and should have a way to test if that is the case without reverting the tx.
basically, reverting would be bad behavior, considering that optional keys are standard in json, and not indicative of malformatted input

This is a fair point, though I think there's an argument to be made that things are a bit different with e.g. contract deploys or one off scripts, where you might never have optional keys and need to get it right the first execution. Unless ABI decoding into all types fails when an empty value is given, in which case I'm happy to concede 🙂 (will have to test this later, or perhaps you know offhand)

empty string is not a valid abi encoding of empty string. strings are
always 96 bytes or linger when encoded. in fact, it's not a valid abi
encoding of any type. the minimum length of an abi encoded blob is 32. so
decoding it will always revert.
for a real world example, you might have configs specialized by network, so
you check config.NETWORK_NAME.OPTIONAL_KEY to see if the network needs a
particular setting
On Sat, Nov 19, 2022 at 8:36 PM Matt Solomon @.***>
wrote:

probably very few, because you generally have to abi decode the output of
parseJson...Your desire to revert is served by the failing ABI decoding
after the parseJson returns an empty string.
Yea, my thinking was this would mainly be an issue for string/bytes types
which admittedly are less common input types. Or would ABI decoding revert
for those types also? I just assumed it'd return the same empty value.
optional keys are standard practice in most real-world json (see e.g. the
x-nullable in openapi ,or "type: ["string", "null"] in json schema). A
config may not need a key under certain conditions, and should have a way
to test if that is the case without reverting the tx.
basically, reverting would be bad behavior, considering that optional keys
are standard in json, and not indicative of malformatted input
This is a fair point, though I think there's an argument to be made that
things are a bit different with e.g. contract deploys or one off scripts,
where you might never have optional keys and need to get it right the first
execution. Unless ABI decoding into all types fails when an empty value is
given, in which case I'm happy to concede 🙂 (will have to test this
later, or perhaps you know offhand)
—
Reply to this email directly, view it on GitHub
https://github.com/foundry-rs/forge-std/pull/226#issuecomment-1321010291,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACNN4MIDX6LIMP7B7BNFCSTWJF6C5ANCNFSM6AAAAAASEUM6H4
.
You are receiving this because you were mentioned.Message ID:
@.***>

the minimum length of an abi encoded blob is 32. so
decoding it will always revert.

Ahh right of course, ok awesome. Thanks
So current approach + PR all LGTM

@vicnaum do you mind adding a few tests before we merge? you can use the existing JSON file in the repo

I would also urge @vicnaum to add a small mention to the docs :)

@vicnaum do you mind adding a few tests before we merge? you can use the existing JSON file in the repo

Sure! Will add the tests. Should I test only this feature? Cause I don't seem to find any StdJson tests...

@mds1  @odyslam @prestwich I've committed some tests for keyExists and... houston, we have a problem:

Empty object (as in "returns": {}) is parsed as "0x"
"0x0" (as in "value": "0x0") is also parsed as "0x"

So both of these result in the same empty bytes array as if key didn't exist. How should we fix this?
Also, null (as in "to": null) is parsed as an empty string "", which doesn't sound right for me, but I'm not sure what it should parse to - there's no null in Solidity.

Valid solidity types should output valid encodings, while invalid types should output the empty encoding

"0x0" (as in "value": "0x0") is also parsed as "0x"

this seems like a bug?

Empty object (as in "returns": {}) is parsed as "0x"

this seems correct, there is no abi encoding of an empty struct. Empty structs are not valid solidity either.

Empty arrays are similarly illegal.

Also, null (as in "to": null) is parsed as an empty string "", which doesn't sound right to me, but I'm not sure what it should parse to - there's no null in Solidity.

This seems correct, as null is not a legal type in solidity.

the documentation of parseJson should probably explicitly state that invalid solidity types will be parsed into invalid abi encodings 🤔

Valid solidity types should output valid encodings, while invalid types should output the empty encoding

"0x0" (as in "value": "0x0") is also parsed as "0x"

this seems like a bug in the parser? I would expect 0x0 to be treated as either

I'm super sorry! That was a bug on my tests side - the json key path was wrong and pointed to non-existent object :)
I've fixed the tests and yes: the value: "0x0" is parsed as bytes 0x00 of length 1, which is correct imho.
For the rest of the cases - I've left TODO's in tests with these comments - in case if somebody would want to change the parser to revert on null and emptyArray. Right now the parser behavior in these special cases it's a little bit inconsistent (it still reverts on emptyObject), but I reckon this is a separate issue.

emptyArray

Oh one edge-case, empty dynamic arrays are legal. so an empty json array should probably be parsed as the 32 byte \x00 null string

Let's move the parser discussion to a foundry repo, I've created an issue there:
https://github.com/foundry-rs/foundry/issues/3731
After there is a decision on parser behavior - I can update the tests accordingly.

Closing since this will be implemented natively in https://github.com/foundry-rs/foundry/pull/5431


Preview mode

Will be cool to have the ability to quickly preview a file (with a press of a spacebar, as on macOS) in a side panel.

Done! Not in master, will release soon.


merging fixes and tests

It looks like you're taking over this project, so I thought I would reach out to you to see you're interested in some changes that I made. I've had a fork of Truth's fork for a while now and I've been adding test cases and fixing broken features. It looks like Truth abandoned his fork, so I figured I might merge with yours.
My Changes

I added support for the new log events from the recent Arena update. My approach to this issue was a bit different from yours, and I decided to try to make the change backward compatible and potentially future-proof. WOTC has reverted changes in the past, so it's possible that they might revert these ones. I verified my changes for premier, quick, and traditional drafts (see tests/test_card_logic.py), but not sealed.
I fixed the Chrome plugin, which had stopped working a while ago. I also modified the UI change a bit to make it clearer that this is not part of the 17Lands site.
I fixed some broken application code related to tier comments and split cards.
I changed the limited_sets code so that when you download a set, you also download the bonus sheet, special guest, list, etc. This was an existing feature in the original project that I believe was used for downloading cube datasets. I just made the change for all of the sets. If you delete your old Temp/temp_set_list file, the app will create a new one with the modified set codes.
I refactored the code so that the latest versions of PIL and Pydantic are supported.
I added GitHub workflows for running the pytest test cases whenever a pull request is created. It includes workflows for Windows, macOS, and Ubuntu.

Truth's Changes

They addressed an issue with the original tool where it wouldn't download card data if the ALSA or ATA values were null (below the confidence threshold).
Replaced the old card compare autocomplete with a custom version. You now use the up and down arrow keys to cycle through matches.

I needed to make some additional changes to the test_app_update file to pass everything after the merge.

I made the limited_sets change for MKM, but I just confirmed that it still works for OTJ. As you can see in the image below, the Big Score, Special Guest, and Breaking News cards are showing up. As stated in my earlier comment, you need to either delete the temp_set_list file and have the app build another, or you can just edit your current file and change the arena field to "ALL".

If you have any questions about what I had changed, feel free to add them to this request and I will try to answer them.

I just noticed this. Thank you so much! I'll take a look and get it in the next release.

Thank you for adding/updating the tests. I'll run them and update them as needed in the future.
I made a change in v3.12 because I broke Quick Draft. There is still a "Payload" section in the pack log.
I see your comment about the bonus sheets and am trying to understand your approach compared to what I did in 3.13. Your approach is obviously ideal, but why did the original author set it up like they did if they didn't need to?

I see your comment about the bonus sheets and am trying to understand your approach compared to what I did in 3.13. Your approach is obviously ideal, but why did the original author set it up like they did if they didn't need to?

You're hardcoding the codes for the set, whereas the original app automatically supported new sets. My change simply modifies this process using a code option that already existed. I'm not sure if you'll want to support this tool with every new release, which you will have to do with your approach.
I believe there's a tradeoff when using the "ALL" code. If the individual set codes are in the temp_set_list file, the app builds a dataset that only includes the cards from those sets. However, if you use the "ALL" code, the tool retrieves a list of card names from 17Lands and constructs a dataset with every instance of those cards on Arena. Using the individual codes would result in a smaller dataset and file. Additionally, The List doesn't seem to have a set code in Arena, so you wouldn't be able to build a dataset that includes those cards without using "ALL".

I'm going to merge this in and get a new release updated. You've done a lot of work for the community!

Included in the latest release: https://github.com/unrealities/MTGA_Draft_17Lands/releases/tag/MTGA_Draft_Tool_V0314


I just ran into this problem. I'm also running Stirling PDF behind behind a reverse proxy (caddy) using path /pdf . I noticed that, for example, crop operation is sending a request to /api/v1/general/crop (which results in 404 error) rather than /pdf/api/v1/general/crop. I tried setting SYSTEM_ROOTURIPATH=/pdf but it makes no difference.

          I just ran into this problem. I'm also running Stirling PDF behind behind a reverse proxy (caddy) using path `/pdf` . I noticed that, for example, crop operation is sending a request to `/api/v1/general/crop` (which results in 404 error) rather than `/pdf/api/v1/general/crop`. I tried setting `SYSTEM_ROOTURIPATH=/pdf` but it makes no difference.

Originally posted by @porjo in https://github.com/Stirling-Tools/Stirling-PDF/issues/14#issuecomment-1876839889

Ignore, I was trying to reference this issue and ended up creating a new issue. My humble apologies.


nativeStackAndroid only contains up to 10 stack traces

nativeStackAndroid only contains up to 10 stack traces. This is due to the "ERROR_STACK_FRAME_LIMIT" set to 10 on https://github.com/facebook/react-native/blob/master/ReactAndroid/src/main/java/com/facebook/react/bridge/PromiseImpl.java.

nativeStackAndroid should contain all the native stack traces like nativeStackIOS. another improvement could be adding the "declaringClass" on top of the "methodName", "LineNumber", and "file" on the stack trace frameMap.

nativeStackIOS contains all 28 stack traces.

React Native version:

info
React Native Environment Info:
System:
OS: macOS 10.14.4
CPU: x64 Intel(R) Core(TM) i7-8750H CPU @ 2.20GHz
Memory: 57.51 MB / 32.00 GB
Shell: 3.2.57 - /bin/bash
Binaries:
Node: 8.12.0 - /usr/local/bin/node
Yarn: 1.12.1 - /usr/local/bin/yarn
npm: 6.9.0 - /usr/local/bin/npm
Watchman: 4.9.0 - /usr/local/bin/watchman
SDKs:
iOS SDK:
Platforms: iOS 12.1, macOS 10.14, tvOS 12.1, watchOS 5.1
Android SDK:
Build Tools: 27.0.2, 27.0.3, 28.0.0, 28.0.3
API Levels: 19, 23, 24, 25, 26, 27, 28
IDEs:
Android Studio: 3.3 AI-182.5<IP_ADDRESS>14842
Xcode: 10.1/10B61 - /usr/bin/xcodebuild
npmPackages:
@types/react: ^16.4.14 => 16.8.17
@types/react-native: ^0.57.4 => 0.57.58
react: 16.8.3 => 16.8.3
react-native: 0.59.8 => 0.59.8
npmGlobalPackages:
react-native-cli: 2.0.1
Steps To Reproduce

Promise.reject with an Throwble object on the native side.
Check the error object on react-native side.

Describe what you expected to happen:
nativeStackAndroid should contain all the native stack traces like nativeStackIOS.
Snack, code example, or link to a repository:

not a bug, as the behavior matches what the author has intended. still it could be consistent among iOS/Android.
@Salakar in your PR https://github.com/facebook/react-native/commit/794d2264f93b6eaeab4eb53c7d2eaf7880b89649 do you remember why you limited Android stacktrace to 10 items? Is there an issue with stacktraces too long?

Not a bug as @hey99xx pointed out,
I implemented it with a limit as the output is structured to match the JS StackFrames format RN uses (Array of Maps) compared to iOS which just gives you an unparsed array of strings, the plan was implement a follow up PR to do the same format for iOS if possible, that way they can be merged into a single nativeStack property.
I wasn't entirely sure on the performance implications of this given that I've seen some very long stack traces before in Android and that it'd need to construct a ReadableMap for each frame.
If you like, I'd suggest submitting a PR with a higher limit, such as 30 and tag me in it for review.


How can I run vpnclient on macos?

I download the vpnserver manager on my mbp,but I found there is no username input for me to connect vpnserver:

It's different between windows vpn manager, how can I use it like windows?

It looks like the screen of the VPN Server Manager, not the VPN Client Manager.

It looks like the screen of the VPN Server Manager, not the VPN Client Manager.

yes,I can not find the download address of vpn client manager,can you give some tips for me?thanks a lot

The VPN Client Manager is not officially offered for MacOS.
The official usage is to control the service on the command line using vpncmd.
However, using WINE may be able to use Windows version of Manager.

VPN客户端管理器未正式提供给MacOS。
官方用法是使用vpncmd在命令行上控制服务。
但是，使用WINE可能能够使用Windows版本的Manager。

ok,i will try to use wine,thanks XD

I just downloaded softether-vpnclient-v4.29-9680-rtm-2019.02.28-windows-x86_x64-intel.exe, then install and execute using wine. After adding the virtual network, some error appeared....
Unhandled exception: page fault on read access to 0x00000000 in 64-bit code (0x0000000000361259).
Register dump:
 rip:0000000000361259 rsp:000000000076ee50 rbp:000000000076ffd0 eflags:00010206 (  R- --  I   - -P- )
 rax:0000000000000000 rbx:0000000000000008 rcx:0000000001727ba0 rdx:0000000000000010
 rsi:0000000000000000 rdi:0000000000140000  r8:00000000009b00a8  r9:0000000000000000 r10:16094d7185f500d1
 r11:0000000001727c00 r12:0000000000000000 r13:0000000000000000 r14:000000007ffdf000 r15:0000000000000000
Stack dump:
0x000000000076ee50:<PHONE_NUMBER>000000<PHONE_NUMBER>000000
0x000000000076ee60:<PHONE_NUMBER>000000<PHONE_NUMBER>000000
0x000000000076ee70:<PHONE_NUMBER>000000<PHONE_NUMBER>000000
0x000000000076ee80:<PHONE_NUMBER>000000<PHONE_NUMBER>727ba0
0x000000000076ee90:<PHONE_NUMBER>000000<PHONE_NUMBER>000000
0x000000000076eea0:<PHONE_NUMBER>000000<PHONE_NUMBER>000000
0x000000000076eeb0:<PHONE_NUMBER>000000<PHONE_NUMBER>000000
0x000000000076eec0:<PHONE_NUMBER>000000<PHONE_NUMBER>000000
0x000000000076eed0:<PHONE_NUMBER>128478<PHONE_NUMBER>000011
0x000000000076eee0:<PHONE_NUMBER>76f010 000000007bc3aa40
0x000000000076eef0:<PHONE_NUMBER>000000<PHONE_NUMBER>000000
0x000000000076ef00:<PHONE_NUMBER>000000<PHONE_NUMBER>000000
Backtrace:
=>0 0x0000000000361259 EntryPoint+0xffffffffffffffff() in driver_installer (0x000000000076ffd0)
  1 0x0000000000361107 EntryPoint+0xffffffffffffffff() in driver_installer (0x000000000076ffd0)
  2 0x000000000035c993 EntryPoint+0xffffffffffffffff() in driver_installer (0x000000000076ffd0)
  3 0x000000000035c81d EntryPoint+0xffffffffffffffff() in driver_installer (0x000000000076ffd0)
  4 0x000000000014112c EntryPoint+0xffffffffffffffff() in driver_installer (0x000000000076ffd0)
  5 0x00000000001414a2 EntryPoint+0xffffffffffffffff() in driver_installer (0x000000000076ffd0)
  6 0x00000000001415a9 EntryPoint+0xffffffffffffffff() in driver_installer (0x000000000076ffd0)
  7 0x0000000000503267 EntryPoint+0xffffffffffffffff() in driver_installer (0x000000000076ffd0)
  8 0x000000007b4571ef in kernel32 (+0x471ee) (0x000000000076ffd0)
0x0000000000361259 EntryPoint+0xffffffffffffffff in driver_installer: movl	(%rax),%eax
Modules:
Module	Address					Debug info	Name (40 modules)
PE	          140000-          663000	Export          driver_installer
PE	        68710000-        68714000	Deferred        advapi32
PE	        687b0000-        687b4000	Deferred        version
PE	        687d0000-        687d3000	Deferred        shcore
PE	        6b010000-        6b014000	Deferred        gdi32
PE	        6b180000-        6b193000	Deferred        comdlg32
PE	        6b210000-        6b214000	Deferred        shlwapi
PE	        6b2c0000-        6b2c3000	Deferred        usp10
PE	        6b410000-        6bc7b000	Deferred        shell32
PE	        6bdf0000-        6beca000	Deferred        user32
PE	        6c040000-        6c068000	Deferred        ole32
PE	        6c230000-        6c234000	Deferred        rpcrt4
PE	        6c2f0000-        6c330000	Deferred        comctl32
PE	        6c440000-        6c444000	Deferred        imm32
PE	        6c470000-        6c476000	Deferred        winspool
PE	        6c4b0000-        6c4b7000	Deferred        oleaut32
PE	        6c660000-        6c664000	Deferred        ws2_32
PE	        6c6a0000-        6c6ab000	Deferred        winmm
PE	        6c700000-        6c704000	Deferred        msacm32
PE	        6c730000-        6c733000	Deferred        netapi32
PE	        6c760000-        6c764000	Deferred        iphlpapi
PE	        6c7a0000-        6c7a4000	Deferred        mpr
PE	        6c910000-        6c91b000	Deferred        urlmon
PE	        6cc10000-        6cc15000	Deferred        wininet
PE	        6cd20000-        6cd24000	Deferred        winemac
PE	        6cf10000-        6cf14000	Deferred        uxtheme
PE	        6cf60000-        6cf63000	Deferred        icmp
PE	        6cf80000-        6cf84000	Deferred        psapi
PE	        6cf90000-        6cf93000	Deferred        newdev
PE	        6cfa0000-        6cfa3000	Deferred        secur32
PE	        6cff0000-        6cff3000	Deferred        kerberos
PE	        6fd00000-        6fd04000	Deferred        setupapi
PE	        6fd90000-        6fd94000	Deferred        dbghelp
PE	        6fe10000-        6fe14000	Deferred        dwmapi
PE	        6fe20000-        6fe23000	Deferred        wtsapi32
PE	        6fe40000-        6fe4c000	Deferred        msi
PE	        6ff90000-        6ff94000	Deferred        cabinet
PE	        7b410000-        7b469000	Export          kernel32
PE	        7bc10000-        7bc14000	Deferred        ntdll
ELF	        7c400000-        7c404000	Deferred        <wine-loader>
Threads:
process  tid      prio (all id:s are in hex)
0000000e services.exe
	0000004b    0
	00000022    0
	0000001b    0
	00000013    0
	00000010    0
	0000000f    0
00000011 winedevice.exe
	00000018    0
	00000017    0
	00000016    0
	00000012    0
00000019 plugplay.exe
	0000001d    0
	0000001c    0
	0000001a    0
00000020 winedevice.exe
	00000034    0
	00000033    0
	00000032    0
	00000031    0
	00000030    0
	0000002f    0
	0000002e    0
	0000002d    0
	0000002c    0
	0000002b    0
	0000002a    0
	00000029    0
	00000028    0
	00000027    0
	00000024    0
	00000023    0
	00000021    0
00000025 explorer.exe
	00000037    0
	00000036    0
	00000035    0
	00000026    0
00000049 vpnclient_x64.exe
	00000093    0
	00000092    0
	00000091    0
	0000008e    0
	00000063    0
	00000062    0
	00000061    0
	00000060    0
	00000059  -15
	00000058    0
	00000057    0
	00000050   15
	0000004d    0
	0000004c    0
	0000004a    0
00000074 vpnclient_x64.exe
	00000094    0
	00000090    0
	00000078    0
	00000077    0
	00000076   15
	00000075    0
00000088 vpncmgr_x64.exe
	0000008f    0
	0000008d    0
	0000008c    0
	0000008a   15
	00000089    0
00000095 (D) C:\users\wangbin\Temp\VPN_EDD9\driver_installer.exe
	00000098    0
	00000097   15
	00000096    0 <==
System information:
    Wine build: wine-4.0
    Platform: x86_64
    Version: Windows 7
    Host system: Darwin
    Host version: 18.2.0

Even WINE can not install drivers.
Create a virtual LAN card with vpncmd.

I still can't run, because tuntop can't be installed correctly, I noticed that the latest version of tuntop for mac is 2015.
Is there any other way, such as L2TP (or whatever)  can help me?

Please ask the administrator which protocol the server you want to connect supports.


Allow explicit usage of libiconv

Allow developers to opt for libiconv variant instead of the built-in iconv support of their platform.
This helps with cross-compilation of binaries to platforms like macOS, which requires bulky SDK being installed in order to support linking to their bundled iconv library.
Alternatively, developer should be able to build a static version of iconv (libiconv) and be able to link with it by forcing its usage with -Duse_libiconv:
$ crystal build app.cr --cross-compile --target x86_64-apple-darwin -Duse_libiconv

Relevant links:

https://forum.crystal-lang.org/t/macos-compilation-and-libiconv-support/4439
https://github.com/ziglang/zig/issues/10485#issuecomment-1013723542

A bit unrelated to this PR, but I think the way the code is right now could be improved. Right now we have this:
# c/iconv.cr

@[Link("iconv")]
lib LibC
  type IconvT = Void*

  fun iconv(x0 : IconvT, x1 : Char**, x2 : SizeT*, x3 : Char**, x4 : SizeT*) : SizeT
  fun iconv_close(x0 : IconvT) : Int
  fun iconv_open(x0 : Char*, x1 : Char*) : IconvT
end

# c/lib_iconv.cr

@[Link("iconv")]
lib LibIconv
  type IconvT = Void*

  alias Int = LibC::Int
  alias Char = LibC::Char
  alias SizeT = LibC::SizeT

  fun iconv = libiconv(cd : IconvT, inbuf : Char**, inbytesleft : SizeT*, outbuf : Char**, outbytesleft : SizeT*) : SizeT
  fun iconv_close = libiconv_close(cd : IconvT) : Int
  fun iconv_open = libiconv_open(tocode : Char*, fromcode : Char*) : IconvT
end

They are exactly the same! Except that:

One is named LibC and the other is named LibIconv
One has functions that start with "lib", but their Crystal alias name is the same

So I propose we rename both of these to LibIconv. I think it's actually wrong to put them in LibC if we are linking against "iconv".
Once we do that, we can remove that USE_LIBICONV constant, or maybe not, but all the condition code and macros around that can be gone. That's the whole idea of lib function aliases, so you don't have to do this code switch.
What do you think?
Once we merge this, I think I'll send a PR for this.

But isn't it equally wrong to put them in LibIconv if we are linking against "c"?

But isn't it equally wrong to put them in LibIconv if we are linking against "c"?

Not really. There's not actual connection between the name of the Crystal type and the library which provides the symbols. You can't even reliably know that because it depends on which libraries are available to the linker.

A bit unrelated to this PR, but I think the way the code is right now could be improved. Right now we have this:
# c/iconv.cr

@[Link("iconv")]
lib LibC
  type IconvT = Void*

  fun iconv(x0 : IconvT, x1 : Char**, x2 : SizeT*, x3 : Char**, x4 : SizeT*) : SizeT
  fun iconv_close(x0 : IconvT) : Int
  fun iconv_open(x0 : Char*, x1 : Char*) : IconvT
end

This is per-platform, and doesn't apply to all platforms. musl doesn't @[Link("iconv")] like Darwin:

https://github.com/crystal-lang/crystal/blob/master/src%2Flib_c%2Fx86_64-darwin%2Fc%2Ficonv.cr
https://github.com/crystal-lang/crystal/blob/master/src/lib_c/x86_64-linux-gnu/c/iconv.cr
https://github.com/crystal-lang/crystal/blob/master/src/lib_c/x86_64-linux-musl/c/iconv.cr

And other BSD platforms need additonal definitions:
https://github.com/crystal-lang/crystal/blob/master/src%2Flib_c%2Fx86_64-dragonfly%2Fc%2Ficonv.cr
If I understand it, the improvement will be to move from per-platform definition to a single one with macros wrapping the need for @[Link()]?
Sounds interesting and definitely something that could be explored to see if the change makes harder or clearer to understand all the iconv_ related definitions.
Cheers.

@asterite and @HertzDevil, went ahead and created issue #11882 so we can keep the conversation there and is not lost in this PR 😊
Thank you both for the feedback!
Cheers.
❤ ❤ ❤

I can use this compile-time flag to compile app for aarch64 macOS on my AMD64 linux laptop without docker.
 ╰─ $ shards build --production --static --no-debug -Duse_libiconv --cross-compile --target=aarch64-darwin --link-flags=-s

 ╰─ $ zig cc -target aarch64-macos-none /home/zw963/Crystal/crystal-lang/shards/bin/shards.o -o /home/zw963/Crystal/crystal-lang/shards/bin/shards -s -rdynamic -static -L/home/zw963/Crystal/static_libraries/aarch64-apple-darwin21.0 -lyaml -lpcre2-8 -lgc -lpthread -ldl -levent -liconv -lunwind

 ╰─ $ file bin/shards
bin/shards: Mach-O 64-bit arm64 executable, flags:<NOUNDEFS|DYLDLINK|TWOLEVEL|PIE|HAS_TLV_DESCRIPTORS>

I don't have an apple machine to test if it works, It seems okay anyway.
Should we add this to the crystal-book?

Wired, those flag documented on crystal-book, but never show in site.

https://crystal-lang.org/reference/1.11/syntax_and_semantics/compile_time_flags.html

Somethings is broken, right?

Looks like it, yeah.


Replacing Pytorch layers to Rearrange from einops

ok let's move on here but I would suggest to open an issue so support of
newer version is in the roadmap.
If you think skorch devs are creating more problems than they should you
should contact them eg by pinging
them in your issue.

Message ID: @.***
com>

ok let's move on here but I would suggest to open an issue so support of newer version is in the roadmap. If you think skorch devs are creating more problems than they should you should contact them eg by pinging them in your issue.
…
Message ID: @.*** com>

Okay @agramfort, I will ping next time.
Can we merge @dcwil, @robintibor and @agramfort?

thx @bruAristimunha

Hi Dan (@dcwil)!
I need your review or approval to be able to merge the PR :)


Maximum volume on buy order

Is it possible to set the volume on a buy order to the maximum buying size?

Not currently via the API


Iframe Resizer and Bootstrap

Hello,
I found your promising little library and attempted to use it with a responsive Boostrap Layout.  At default size the embedded iframe works perfectly allowing it to be scrolled from the host (instead of directly), but when making the browser window smaller I would expect the content of my iframe to switch to a vertical layout (because of Bootstrap responsiveness) and still allows it to be scrolled from the host. Unfortunately at this point, the content of the iframe is simply cut.
I attach you two files, in order to demonstrate what I did so far. I understand perfectly it could be because of my little understanding of your library and that a solution might already exist if I configure the library properly.
Thank you very much, for your time, and for your piece of software,
Best regards from Switzerland,
Frederic Aubert
embedded.zip

The issue will most likely be something in your CSS. I'm afraid I don't have the time to debug everyone's code. I would suggest posting a question on StackOverflow.


Update ch. 4.4 text on reference time vs. UDUNITS

Update ch. 4.4 text on reference time vs. UDUNITS
Moderator
none yet
Moderator Status Review [last updated: YYYY-MM-DD]
Brief comment on current status, update periodically
Requirement Summary
The conventions text should be aligned with UDUNITS documentation and functionality, or departures should be specified.
Technical Proposal Summary
There are two parts to this proposal: (1) align how the since phrase is used in CF in relation to what UDUNITS accepts, and (2) remove a citation that is not present in the UDUNITS documentation.
Detailed Proposal
Point (1): Currently chapter 4.4 begins as follows:

Variables representing reference time must always explicitly include the units attribute; there is no default value. The units attribute takes a string value formatted as per the recommendations in the [UDUNITS] package.

In the UDUNIT-2 documentation at least I can not find any specific recommendation regarding formatting of a reference time unit. What however is specified in the unit grammar  is several alternatives to the "since" string:

<shift_op>: one of
"@"
"after"
"from"
"since"
"ref"

From discussions at the hackaton it is clear that at least a few exist files using the "@" alternative. However, in the light of the overwhelming dominance of the since alternative it seems as an unnecessary complication to freely allow the use of any alternative. Hence I suggest the text is changed to "strongly encourage" the use of since, or even "strongly discourage" the use of the alternatives to since.
Point (2): The CF text continues thus:

The following excerpt from the UDUNITS documentation explains the time unit encoding by example:
"The specification seconds since 1992-10-8 15:15:42.5 -6:00 indicates seconds since October 8th, 1992 at 3 hours, 15 minutes and 42.5 seconds in the afternoon in the time zone which is six hours to the west of Coordinated Universal Time (i.e. Mountain Daylight Time). The time zone specification can also be written without a colon using one or two digits (indicating hours) or three or four digits (indicating hours and minutes)."

Again, at least I cannot find the cited text in the UDUNITS-2 documentation. If the cited text is indeed not in the UDUNITS-2 documentation I suggest to simply drop the citation marks and rephrase the first line to drop the reference to UDUNITS.

I was not aware that there were synonyms for "since" allowed by udunits.  I do not see the advantage of having several options, so I would strongly support Lars in discouraging use of anything but "since" in a reference time.  (I wish we could forbid the other options, but it sounds like at least "@" is in use.)

Dear @larsbarring
(1) Like Karl I did not know about this! Indeed, UDUNITS supports it:
You have: day after 2-1-2022
You want: day after 1-1-2022
    1 day after 2-1-2022 = 366 (day after 1-1-2022)
    x/(day after 1-1-2022) = (x/(day after 2-1-2022)) + 365

I agree with you and Karl about preferring since. I would say that since "should be" used and the alternatives allowed by UDUNITS "should not be" used. That makes it a recommendation for the conformance document, and the cf-checker would give a warning about it.
(2) This text appears in the ununits(3) *nix man page e.g. at https://linux.die.net/man/3/udunits. Even so, it does not need to be given as a quotation, I agree.
Thanks for raising these points. Happy weekend
Jonathan

Reading my example again, I see my mistake from the absurd answer. :smile: Sorry! It should say
You have: day since 2022-1-2
You want: day since 2022-1-1
    1 day since 2022-1-2 = 2 (day since 2022-1-1)
    x/(day since 2022-1-1) = (x/(day since 2022-1-2)) + 1

Dear @JonathanGregory
Regarding (2) I think that we need to be a bit careful when thinking about references and links. The text cited is not [to my knowledge] in the UDUNITS2 documentation, and the link you give  to *nix  man pages refers to the previous UDUNITS version. For example, it refers to the old formatted text file holding units definitions (and mentions that on "October 9, 1992, it contained 446 entries".)
Anyway, the explanation as such is fine and can as you say remain without quotation.

Dear @larsbarring
Yes, I think you're right. The man page is out of date. Since the three of us who have contributed so far agree, and no-one's disagreed yet, will you propose exact changes to the wording?
Best wishes and thanks
Jonathan

Dear @JonathanGregory,
Yes, I can do that, and almost started already. But when thinking about the wording in concrete terms I wonder, @RosalynHatcher,  how the cf-checker currently handle the synonyms to since?
In principle I agree with Karl that it would be preferable to forbid the alternatives, but we cannot do this altogether for historic reasons. But I think that just stating that "since should be used" and the "alternatives should not be used" is not strong enough, because in principle it leaves the decision in the hands of the data writers, and I imagine that a fair number do not even know about the cf-checker. Hence I think that this is a good example of when deprecation is useful: files already produced according to previous CF versions are acceptable (more or less, depending on what the cf-checker does) but new files produced according to next CF version will have to use since.
Thanks,
Lars

And after having revisited #328 I should probably rephrase the previous comment to state that I would prefer the use of since to be a requirement (and thus to disallow the alternatives as of next CF Conventions version.)

I would support that unless "@" is really commonly used by some segment of our community (not just sporadically).

Dear @larsbarring and @taylor13
I would be comfortable with deprecating all the alternatives to since. That means the checker would give a warning if they were used in new data (from the next version of CF) but not with existing data. That's the usual way it works.
Just above you say you'd prefer it to be a requirement, which is the same except that checker would give an error rather than a warning. I'm afraid we're going to disagree as we did on a very similar point in some other issue - I can't remember which one. :disappointed: The rule-of-thumb I am applying (my own rule, not a CF one) is that we should prohibit things that make the metadata impossible to interpret in some way, because they produce a contradiction or ambiguity, for instance. We deprecate things which make the metadata inconvenient or less satisfactory, but still useable. I don't think we should use more compulsion than necessary, because we don't want the convention to be onerous (that's one of the principles), but we should insist that the metadata is useable.
Best wishes
Jonathan

As @larsbarring implies, allowing aliases seems more difficult for those writing software to interpret data (though perhaps easier for those writing data).   I have never seen "@" used in a file, so it might be worthwhile pinging those at the hackathon who were aware of such files.  If "@" has only been used by a few individuals, but is not routinely used by any community (however small), then I would think we could outlaw it.  How can we poll folks to find out?

Hi Antonio, @cofinoa
Sorry for also pinging you this way, but do you have any further information/recollection regarding the files having "@" instead of "since" in the reference time unit?
Many thanks,
Lars

Just to add weight to the problem of software development: I did some further checks of software tools and it appears that the pretty central python package, cftime (ping @jswhit) requires "since", see below. Of course not everyone use python and tools that builds on cftime. Still, due to its popularity I think that this adds some weight to the idea that files using the "@" are rare.
>>> import numpy as np
>>> print(cftime.__version__)
1.5.2
>>> time = np.array([1])
>>> s = "days since 1970-01-01"
>>> f = "days from 1970-01-01"
>>> a = "days after 1970-01-01"
>>> r = "days ref 1970-01-01"
>>> at = "days @ 1970-01-01"
>>> calendar =  "standard"

>>> print(cftime.num2date(time , s, calendar))
[cftime.DatetimeGregorian(1970, 1, 2, 0, 0, 0, 0, has_year_zero=False)]

>>> print(cftime.num2date(time , f, calendar))
....
ValueError: no 'since' in unit_string

>>> print(cftime.num2date(time , a, calendar))
....
ValueError: no 'since' in unit_string

>>> print(cftime.num2date(time , at, calendar))
....
ValueError: no 'since' in unit_string

This seems o.k. to me.  Thanks.

As we are more or less in agreement I think that we should move on to draft an updated text. Here is a first go at section 4.4 Time coordinate:

Variables representing reference time must always explicitly include the units attribute; there is no default value.
The units attribute takes a string value that follows  UDUNITS formatting requirements.
For example, the time unit specification seconds since 1992-10-8 15:15:42.5 -6:00 indicates seconds since October 8th, 1992  at  3 hours,  15 minutes  and  42.5 seconds in the afternoon in the time zone which is six hours to the west of Coordinated Universal Time (i.e.  Mountain Daylight Time). The time zone specification can also be written without a colon using one or two digits (indicating hours) or three or four digits (indicating hours and minutes).
The acceptable units for time are given by the UDUNITS package <>.
The most commonly used of these strings (and their abbreviations) includes day (d), hour (hr, h), minute (min) and second (sec, s).
Plural forms are also acceptable.
UDUNITS permits a number of alternatives to the word since in the units of time coordinates. All the alternatives have exactly the same meaning in UDUNITS. For compatibility with other software, CF strongly recommends that since should be used.
The reference date/time string (appearing after the identifier since) is required.
.... ....

This looks fine to me except the missing link to udunits ("<>") in the above.

Thank you @taylor13. Regarding the missing link; in the draft pull request it is present as in the original text, I just did not render well when copy-pasted over to this issue.

And now there is (above) a draft pull request.

Dear @larsbarring
Since enough support has been expressed according to the rules, and much longer than three weeks has passed, I declare the proposal for change to be accepted. Thanks for preparing the pull request. I have a couple of comments:

In the sentence "The units attribute takes a string value that follows UDUNITS formatting requirements.", is there a reason for UDUNITS not to be a reference to the UDUNITS doc, as it is in the existing version?
Please add yourself to the additional authors in cf-conventions.adoc.

Best wishes
Jonathan

Thank you Jonathan @JonathanGregory
Regarding your first point I added the reference link (and removed the link in a later sentence). Also I added a new sentence to better connect the first paragraph to the second:
OLD:

Variables representing reference time must always explicitly include the units attribute; there is no default value.
The units attribute takes a string value that follows UDUNITS formatting requirements.
For example, the time unit specification ....

UPDATED:

Variables representing reference time must always explicitly include the units attribute; there is no default value. The units attribute takes a string value that follows the formatting requirements of the <> package. These requirements can best be described by an example with explanatory comments:
The time unit specification ....

I have updated the authors list as per your second point.

Thanks, Lars. I will merge now. This update will be included in 1.11.


Fixed respawn in game bug Critical

About the PR
There is a bug for endless respawn on most part of servers. Tested on official Wizard's Den and Corvax servers.
So if you type in game commands:
toggleready true
joingame Passenger station_id
You will latejoin the game as passenger, even if you was in round.
It was caused because toggleready was changing session's status without checking round's state.
P.S when you latejoining the game, the full command appears in client console.
Media
https://youtu.be/G2wFixFfjoE

[x] I have added screenshots/videos to this PR showcasing its changes ingame, or this PR does not require an ingame showcase

Changelog
:cl: freeze2222#7452

fix: Fixed respawn bug

Not really player facing, so the changelog isn't really necessary here.
Looks good otherwise.

this needs to be merged pro


Instructions on landing page refer to non-existent option

There are instructions that say to select the "create a function from scratch" option:

It looks like this option was renamed to "create your own custom function"? If so, the instruction text should be updated accordingly.

Chris will fix this

This is fixed now.


3phase "hybrid" stepper code sinePWM + SVPWM

Thanks to much research and tinkering done with @Copper280z

Thanks so much for contributing this!


some fixes for mwdt toolchain

define __INT*_C() and __UINT*_C() for mwdt toolchain
our minimal C library makes an alias of UINT*_C() to be __UINT*_C() and INT*_C() to __INT*_C().
However, in mwdt, these are not defined by default, so define them ourselves.
this commit reverts: https://github.com/zephyrproject-rtos/zephyr/commit/b1adc462be6258329ea94bced96e4457a0c4b5cb

use ATOMIC_OPERATIONS_BUILTIN for mwdt toolchain
ATOMIC_OPERATIONS_BUILTIN issue (internal jira number: P10019563-43273) has been fixed in
new relasese MWDT 2021.03. We can use builtin atomic.
we have similar fix for xcc: https://github.com/zephyrproject-rtos/zephyr/commit/5ef8db8ac989e683fb1b51572b00074780f82f0a

Instead of adding the __INT*_C() and __UINT*_C() to a Metaware header, wouldn't it be better to add them to the minimal C lib stdint.h file? That already has the definitions for GNU.
Maybe something to discuss in the toolchain WG? Btw, MetaWare's stdint.h already defines the INT*C(). I would expect that the stdint.h would always come from the toolchain, instead of the Zephyr minimal C lib.

Instead of adding the __INT*_C() and __UINT*_C() to a Metaware header, wouldn't it be better to add them to the minimal C lib stdint.h file? That already has the definitions for GNU.
Maybe something to discuss in the toolchain WG? Btw, MetaWare's stdint.h already defines the INT*C(). I would expect that the stdint.h would always come from the toolchain, instead of the Zephyr minimal C lib.

@ruuddw there is no feedback from other guys, maybe we can keep it in our own mwdt.h head file to let this fixes merged before release.

there is no feedback from other guys, maybe we can keep it in our own mwdt.h head file to let this fixes merged before release.

If we can later rework of this PR, I think it makes sense to check that now. There is still some time. Which other guys are you referring to? Did you explicitly ask for feedback? Did you check if an implementation in the minimal C lib stdint.h would be feasible?

there is no feedback from other guys, maybe we can keep it in our own mwdt.h head file to let this fixes merged before release.

If we can later rework of this PR, I think it makes sense to check that now. There is still some time. Which other guys are you referring to? Did you explicitly ask for feedback? Did you check if an implementation in the minimal C lib stdint.h would be feasible?

I havn't explicity ask for feedback. I have checked thar mwdt has these macros in stdint.h file. when we use zephyr minimal C lib, it also has stdint.h file. we will use the stdin.h file from zephyr minimal C lib, not from mwdt.

@ruuddw I have moved __INT*_C() and __UINT*_C() to minimal C lib stdint.h file.


Colors in log messages don't propagate over ipc

Expected behaviour:
When sending a command to a running flexget daemon, colors in log messages don't end up coming out as color tags.
Actual behaviour:

Color tags come through in <red></> tag format.

There are a couple solutions possible. The easiest thing is to just strip colors in log messages when they are transmitted over ipc. It would be nice if we could figure out a way to reproduce the colors on the client side though.

I tried doing a quick fix, where we just strip color codes when capturing logs to send over ipc, but ran into an issue. Opened up an issue at loguru to track that. https://github.com/Delgan/loguru/issues/198


ui: fix forced node removal modal paragraphs

enhancement#fix-forced-removal-modal-paragraphs
Signed-off-by: Vítor Avelino<EMAIL_ADDRESS>Before

After

 Bug 1095252 - Wrong usage or paragraphs on force removal confirmation modal


Form Flow that creates related entities

I was just wondering if the following use case is possible with the FormFlowBundle.
Suppose we have an Entity called "Team" and in step 1, we wish to add some "Players" to the Team. The Player entity has a single property of "name". The Team to Players relationship is a One-to-Many, and we're using Symfony's Form collection (as described here http://symfony.com/doc/current/cookbook/form/form_collections.html) to add as many Players as required to the Team. Then we click "next".
On Step 2, we have to choose which of the Players created in Step 1 is the captain of the Team. So, we have a form with a field labelled "Captain" and a select list showing the names of all the Players created in Step 1.
I would normally use the Symfony "entity" form field type for Step 2, but I know that it uses the IDs of the entities in the "choices" array to populate the Select list - so, if the Entities created in Step 1 are not yet saved in the database, they would not have an ID.
Can the FormFlow cope with such cases?

Figured out how it should be done now; the step2 form should use a "choice" field and a "choice_list" made up of the entities created in step1.


CLI examples don't work in windows

CLI examples:
https://github.com/dagger/dagger/blob/main/cmd/dagger/query.go#L29-L41
https://github.com/dagger/dagger/blob/main/cmd/dagger/exec.go#L21-L24
Are unix specific, we should change it to depending on which platform the CLI is built, examples differ.

@kpenfound is this still true? Is this something you can help with?


Create config python file with hardcoded strings

For avoiding too many manual errors we could introduce a config variable file. E.g. instead of using TableConfigurator().get_property("name") then it is TableConfigurator().get_property(conf.NAME).
conf.py:
NAME = "name"
PARTITIONING="partitioning"
....

constants.py file.
place under atc/

This is solved in #210 where you can generate just such a conf.py file from the configurator


Add getParentelem helper for tests

Following https://github.com/iterative/vscode-dvc/pull/2064#discussion_r927200095

Following @rogermparent's suggestion, I removed getParentElem and used a custom query instead. It does not need to disable any eslint rules, it is easier to reuse for that use case (does what it says it does) and gives meaningful error messages when failing.


"sync.anonymousGist" is an unknown configuration setting

Visual Studio Code Version : [ 1.21.0 ]
Code Settings Sync Version : [ 2.9.0 ]
Operating System : [ macOS High Sierra 10.13.3 ]
Hi,
Visual Studio Code doesn't recognize this configuration setting anymore, as you can see:

Does this configuration still exist? Because you still can find it on the Wiki page and the Visual Studio Marketplace description of this extension.
I can't find in the default settings file.
  // Ask gist name upon creating. Helps you to identify the gist if you have multiple gists.
  "sync.askGistName": false,

  // Set it true to Auto Download the settings on code start. [Code Restart Required]
  "sync.autoDownload": false,

  // Set it true to Auto Upload on the settings change. [Code Restart Required]
  "sync.autoUpload": false,

  // Set it to true if you want to download the settings even when you have latest settings.
  "sync.forceDownload": false,

  // GitHub GIST ID for Settings Sync.
  "sync.gist": "",

  // Set it to your GitHub Enterprise host if you want to use GHE.
  "sync.host": "",

  // Settings Sync last download date. Set it as empty if you want to manually hit download.
  "sync.lastDownload": "",

  // Settings Sync last upload date. Set it as empty if you want to manually hit download.
  "sync.lastUpload": "",

  // Set it to your GitHub Enterprise api prefix if you want to use GHE. Normally '/api/v3'. Only used when host is set.
  "sync.pathPrefix": "",

  // When set to true, will show the result in status bar instead of summary page.
  "sync.quietSync": false,

  // Set it to false if you dont want to remove extensions while downloading.
  "sync.removeExtensions": true,

  // Set it to false if you dont want to upload / download the extensions.
  "sync.syncExtensions": true,

This is safe to remove from settings.json.
anonymousGist support has been removed from Github.

Wiki Pages are outdated. Feel free to contribute and improve as i'm the only one to manage this project.

Ok, thanks @shanalikhan

Thanks @shanalikhan !


Adds checks against SSR for when pageMode is enabled

Hello! During SSR, we're getting the following error:
ReferenceError: Server-side code is attempting to access the global variable "window", which is client only. See https://sapper.svelte.dev/docs/#Server-side_rendering
We were able to fix it by adding some checks against the window object for when pageMode=true in the VirtualScroll.svelte file. Is this something we could have added to the project?
if (pageMode && !(typeof window === 'undefined')) {

Thanks, done


kubeless install --controller-version

That makes more sense to have an option to figure out the specific version of controller being installed. Will take the latest if the flag is not used. Like this:
$ kubeless install --controller-version 0.0.7

we should default to the latest released version not a latest tag.
that's what helm does.

closed by https://github.com/skippbox/kubeless/commit/52bf8d134272865f1aa29a9545894202c83f5ffa


weave-net pod fails to get peers after Kubernetes v1.12.0 upgrade

What you expected to happen?
Weave fills automatically the KUBE_PEERS env var and the connection between peers can initiate.
What happened?
After upgrading a working v1.11.3 Kubernetes cluster to v1.12.0, the weave container in of the two weave pods fails to obtain the peer list and enter the CrashLoopBackOff state, only logging Failed to get peers. The weave-npc container fails to contact <IP_ADDRESS> (kube-api) and every list issued fail with a timeout. Manually entering the peers in the daemonset allows the connection between weave pods to initiate successfully.
How to reproduce it?
Upgrade K8 cluster from v1.11.3 to v1.12.0 with kubeadm.
Anything else we need to know?
The cluster is running on bare metal with a single node and control plane. I also upgraded cni from 0.6.0 to 0.7.1. I have specified the cluster-cidr in the kube-proxy daemonset ( - --cluster-cidr=<IP_ADDRESS>/12 ).
Versions:

$ weave version
weave script 2.4.1
weave 2.4.1

$ docker version
Client:
 Version:           18.06.1-ce
 API version:       1.38
 Go version:        go1.10.3
 Git commit:        e68fc7a
 Built:             Tue Aug 21 17:16:31 2018
 OS/Arch:           linux/amd64
 Experimental:      false

Server:
 Engine:
  Version:          18.06.1-ce
  API version:      1.38 (minimum version 1.12)
  Go version:       go1.10.3
  Git commit:       e68fc7a
  Built:            Tue Aug 21 17:16:31 2018
  OS/Arch:          linux/amd64
  Experimental:     false

$ uname -a
Linux server-01 4.14.67-coreos #1 SMP Mon Sep 10 23:14:26 UTC 2018 x86_64 ...

$ kubectl version
Client Version: version.Info{Major:"1", Minor:"12", GitVersion:"v1.12.0", GitCommit:"0ed33881dc4355495f623c6f22e7dd0b7632b7c0", GitTreeState:"clean", BuildDate:"2018-09-27T17:05:32Z", GoVersion:"go1.10.4", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"12", GitVersion:"v1.12.0", GitCommit:"0ed33881dc4355495f623c6f22e7dd0b7632b7c0", GitTreeState:"clean", BuildDate:"2018-09-27T16:55:41Z", GoVersion:"go1.10.4", Compiler:"gc", Platform:"linux/amd64"}

Logs:
# On the failing pod

$ kubectl -n kube-system logs -f weave-net-c7nfb weave
Failed to get peers

# On the running pod

$ kubectl -n kube-system logs -f weave-net-47gdt weave
DEBU: 2018/09/28 10:01:22.164268 [kube-peers] Checking peer "b2:de:01:96:13:b4" against list &{[{b2:de:01:96:13:b4 server-01} {2e:53:d1:b4:0c:dd server-02}]}
INFO: 2018/09/28 10:01:22.358106 Command line options: map[no-dns:true db-prefix:/weavedb/weave-net host-root:/host mtu:8900 nickname:server-01 no-masq-local:true conn-limit:100 docker-api: ipalloc-init:consensus=2 metrics-addr:<IP_ADDRESS>:6782 datapath:datapath expect-npc:true ipalloc-range:<IP_ADDRESS>/12 name:b2:de:01:96:13:b4 http-addr:<IP_ADDRESS>:6784 log-level:debug port:6783]
INFO: 2018/09/28 10:01:22.358229 weave  2.4.1
INFO: 2018/09/28 10:01:22.742314 Re-exposing <IP_ADDRESS>/12 on bridge "weave"
INFO: 2018/09/28 10:01:22.810321 Bridge type is bridged_fastdp
INFO: 2018/09/28 10:01:22.810369 Communication between peers is unencrypted.
INFO: 2018/09/28 10:01:22.965628 Our name is b2:de:01:96:13:b4(server-01)
INFO: 2018/09/28 10:01:22.965673 Launch detected - using supplied peer list: [<IP_ADDRESS> <IP_ADDRESS>]
INFO: 2018/09/28 10:01:22.965708 Using "no-masq-local" LocalRangeTracker
INFO: 2018/09/28 10:01:22.965716 Checking for pre-existing addresses on weave bridge
INFO: 2018/09/28 10:01:22.965918 weave bridge has address <IP_ADDRESS>/12
INFO: 2018/09/28 10:01:22.998075 Found address <IP_ADDRESS>/12 for ID _
INFO: 2018/09/28 10:01:22.998406 Found address <IP_ADDRESS>/12 for ID _
INFO: 2018/09/28 10:01:23.000696 Found address <IP_ADDRESS>/12 for ID _
INFO: 2018/09/28 10:01:23.001317 Found address <IP_ADDRESS>/12 for ID _
INFO: 2018/09/28 10:01:23.004646 Found address <IP_ADDRESS>/12 for ID _
INFO: 2018/09/28 10:01:23.020759 Found address <IP_ADDRESS>/12 for ID _
INFO: 2018/09/28 10:01:23.020895 Found address <IP_ADDRESS>/12 for ID _
INFO: 2018/09/28 10:01:23.021175 Found address <IP_ADDRESS>/12 for ID _
INFO: 2018/09/28 10:01:23.021322 Found address <IP_ADDRESS>/12 for ID _
INFO: 2018/09/28 10:01:23.021439 Found address <IP_ADDRESS>/12 for ID _
INFO: 2018/09/28 10:01:23.021576 Found address <IP_ADDRESS>/12 for ID _
INFO: 2018/09/28 10:01:23.021720 Found address <IP_ADDRESS>/12 for ID _
INFO: 2018/09/28 10:01:23.021852 Found address <IP_ADDRESS>/12 for ID _
INFO: 2018/09/28 10:01:23.021997 Found address <IP_ADDRESS>/12 for ID _
INFO: 2018/09/28 10:01:23.022107 Found address <IP_ADDRESS>/12 for ID _
INFO: 2018/09/28 10:01:23.022220 Found address <IP_ADDRESS>/12 for ID _
INFO: 2018/09/28 10:01:23.022718 Found address <IP_ADDRESS>/12 for ID _
INFO: 2018/09/28 10:01:23.022817 Found address <IP_ADDRESS>/12 for ID _
INFO: 2018/09/28 10:01:23.023192 Found address <IP_ADDRESS>/12 for ID _
INFO: 2018/09/28 10:01:23.023292 Found address <IP_ADDRESS>/12 for ID _
INFO: 2018/09/28 10:01:23.023387 Found address <IP_ADDRESS>/12 for ID _
INFO: 2018/09/28 10:01:23.023481 Found address <IP_ADDRESS>/12 for ID _
INFO: 2018/09/28 10:01:23.023574 Found address <IP_ADDRESS>/12 for ID _
INFO: 2018/09/28 10:01:23.023661 Found address <IP_ADDRESS>/12 for ID _
INFO: 2018/09/28 10:01:23.023750 Found address <IP_ADDRESS>/12 for ID _
INFO: 2018/09/28 10:01:23.023849 Found address <IP_ADDRESS>/12 for ID _
INFO: 2018/09/28 10:01:23.023951 Found address <IP_ADDRESS>/12 for ID _
INFO: 2018/09/28 10:01:23.024045 Found address <IP_ADDRESS>/12 for ID _
INFO: 2018/09/28 10:01:23.024137 Found address <IP_ADDRESS>/12 for ID _
INFO: 2018/09/28 10:01:23.024234 Found address <IP_ADDRESS>/12 for ID _
INFO: 2018/09/28 10:01:23.024349 Found address <IP_ADDRESS>/12 for ID _
INFO: 2018/09/28 10:01:23.024438 Found address <IP_ADDRESS>/12 for ID _
INFO: 2018/09/28 10:01:23.024536 Found address <IP_ADDRESS>/12 for ID _
INFO: 2018/09/28 10:01:23.024629 Found address <IP_ADDRESS>/12 for ID _
INFO: 2018/09/28 10:01:23.024718 Found address <IP_ADDRESS>/12 for ID _
INFO: 2018/09/28 10:01:23.026770 adding entry <IP_ADDRESS>/13 to weaver-no-masq-local of
INFO: 2018/09/28 10:01:23.026787 added entry <IP_ADDRESS>/13 to weaver-no-masq-local of
INFO: 2018/09/28 10:01:23.027991 [allocator b2:de:01:96:13:b4] Initialising with persisted data
DEBU: 2018/09/28 10:01:23.028082 [allocator b2:de:01:96:13:b4]: Re-Claimed <IP_ADDRESS>/12 for weave:expose
DEBU: 2018/09/28 10:01:23.028130 [allocator b2:de:01:96:13:b4]: Re-Claimed <IP_ADDRESS>/12 for ID _ having existing ID as 5704052a8c81ca8e844d6480d3175623e26af7c346a1bbfa561b311db60d0ca1
DEBU: 2018/09/28 10:01:23.028161 [allocator b2:de:01:96:13:b4]: Re-Claimed <IP_ADDRESS>/12 for ID _ having existing ID as 5704052a8c81ca8e844d6480d3175623e26af7c346a1bbfa561b311db60d0ca1
DEBU: 2018/09/28 10:01:23.028184 [allocator b2:de:01:96:13:b4]: Re-Claimed <IP_ADDRESS>/12 for ID _ having existing ID as 21c3fe888aa6fdd8ee571f727662fe88f7f65b46b0808cd880ed696c8bcb817e
DEBU: 2018/09/28 10:01:23.028204 [allocator b2:de:01:96:13:b4]: Re-Claimed <IP_ADDRESS>/12 for ID _ having existing ID as 21c3fe888aa6fdd8ee571f727662fe88f7f65b46b0808cd880ed696c8bcb817e
DEBU: 2018/09/28 10:01:23.028223 [allocator b2:de:01:96:13:b4]: Re-Claimed <IP_ADDRESS>/12 for ID _ having existing ID as 5704052a8c81ca8e844d6480d3175623e26af7c346a1bbfa561b311db60d0ca1
DEBU: 2018/09/28 10:01:23.028242 [allocator b2:de:01:96:13:b4]: Re-Claimed <IP_ADDRESS>/12 for ID _ having existing ID as 5fd80d9d62e2cdecd8070846bb45725f4476c36aed63ba61fbb34169bfecf733
DEBU: 2018/09/28 10:01:23.028261 [allocator b2:de:01:96:13:b4]: Re-Claimed <IP_ADDRESS>/12 for ID _ having existing ID as bbe64a5def512cdb2a8f22740d80c3680067efa471f4a8fd526cc89d3c0112f2
DEBU: 2018/09/28 10:01:23.028279 [allocator b2:de:01:96:13:b4]: Re-Claimed <IP_ADDRESS>/12 for ID _ having existing ID as 5fd80d9d62e2cdecd8070846bb45725f4476c36aed63ba61fbb34169bfecf733
DEBU: 2018/09/28 10:01:23.028299 [allocator b2:de:01:96:13:b4]: Re-Claimed <IP_ADDRESS>/12 for ID _ having existing ID as dfe8a081908b7317e57113ca4f4bd3764bd2cc0c45cd3f1dbb971be1bec460df
DEBU: 2018/09/28 10:01:23.028319 [allocator b2:de:01:96:13:b4]: Re-Claimed <IP_ADDRESS>/12 for ID _ having existing ID as bbe64a5def512cdb2a8f22740d80c3680067efa471f4a8fd526cc89d3c0112f2
DEBU: 2018/09/28 10:01:23.028337 [allocator b2:de:01:96:13:b4]: Re-Claimed <IP_ADDRESS>/12 for ID _ having existing ID as dfe8a081908b7317e57113ca4f4bd3764bd2cc0c45cd3f1dbb971be1bec460df
DEBU: 2018/09/28 10:01:23.028356 [allocator b2:de:01:96:13:b4]: Re-Claimed <IP_ADDRESS>/12 for ID _ having existing ID as 589631e93ea890e3dc0ed144e95427a98ba4f6d7a78de4ca23bd7621bf114cd2
DEBU: 2018/09/28 10:01:23.028384 [allocator b2:de:01:96:13:b4]: Re-Claimed <IP_ADDRESS>/12 for ID _ having existing ID as b92578e6ab2d5aeecc8f37a8ca386448ce5e237abecef56bc5144b77b179c44d
DEBU: 2018/09/28 10:01:23.028404 [allocator b2:de:01:96:13:b4]: Re-Claimed <IP_ADDRESS>/12 for ID _ having existing ID as 21c3fe888aa6fdd8ee571f727662fe88f7f65b46b0808cd880ed696c8bcb817e
DEBU: 2018/09/28 10:01:23.028422 [allocator b2:de:01:96:13:b4]: Re-Claimed <IP_ADDRESS>/12 for ID _ having existing ID as 589631e93ea890e3dc0ed144e95427a98ba4f6d7a78de4ca23bd7621bf114cd2
DEBU: 2018/09/28 10:01:23.028442 [allocator b2:de:01:96:13:b4]: Re-Claimed <IP_ADDRESS>/12 for ID _ having existing ID as b92578e6ab2d5aeecc8f37a8ca386448ce5e237abecef56bc5144b77b179c44d
DEBU: 2018/09/28 10:01:23.028462 [allocator b2:de:01:96:13:b4]: Re-Claimed <IP_ADDRESS>/12 for ID _ having existing ID as 589631e93ea890e3dc0ed144e95427a98ba4f6d7a78de4ca23bd7621bf114cd2
DEBU: 2018/09/28 10:01:23.028480 [allocator b2:de:01:96:13:b4]: Re-Claimed <IP_ADDRESS>/12 for ID _ having existing ID as 589631e93ea890e3dc0ed144e95427a98ba4f6d7a78de4ca23bd7621bf114cd2
DEBU: 2018/09/28 10:01:23.028498 [allocator b2:de:01:96:13:b4]: Re-Claimed <IP_ADDRESS>/12 for ID _ having existing ID as 589631e93ea890e3dc0ed144e95427a98ba4f6d7a78de4ca23bd7621bf114cd2
DEBU: 2018/09/28 10:01:23.028516 [allocator b2:de:01:96:13:b4]: Re-Claimed <IP_ADDRESS>/12 for ID _ having existing ID as 589631e93ea890e3dc0ed144e95427a98ba4f6d7a78de4ca23bd7621bf114cd2
DEBU: 2018/09/28 10:01:23.028535 [allocator b2:de:01:96:13:b4]: Re-Claimed <IP_ADDRESS>/12 for ID _ having existing ID as 589631e93ea890e3dc0ed144e95427a98ba4f6d7a78de4ca23bd7621bf114cd2
DEBU: 2018/09/28 10:01:23.028558 [allocator b2:de:01:96:13:b4]: Re-Claimed <IP_ADDRESS>/12 for ID _ having existing ID as 589631e93ea890e3dc0ed144e95427a98ba4f6d7a78de4ca23bd7621bf114cd2
DEBU: 2018/09/28 10:01:23.028584 [allocator b2:de:01:96:13:b4]: Re-Claimed <IP_ADDRESS>/12 for ID _ having existing ID as 589631e93ea890e3dc0ed144e95427a98ba4f6d7a78de4ca23bd7621bf114cd2
DEBU: 2018/09/28 10:01:23.028603 [allocator b2:de:01:96:13:b4]: Re-Claimed <IP_ADDRESS>/12 for ID _ having existing ID as 589631e93ea890e3dc0ed144e95427a98ba4f6d7a78de4ca23bd7621bf114cd2
DEBU: 2018/09/28 10:01:23.028627 [allocator b2:de:01:96:13:b4]: Re-Claimed <IP_ADDRESS>/12 for ID _ having existing ID as 589631e93ea890e3dc0ed144e95427a98ba4f6d7a78de4ca23bd7621bf114cd2
DEBU: 2018/09/28 10:01:23.028658 [allocator b2:de:01:96:13:b4]: Re-Claimed <IP_ADDRESS>/12 for ID _ having existing ID as 589631e93ea890e3dc0ed144e95427a98ba4f6d7a78de4ca23bd7621bf114cd2
DEBU: 2018/09/28 10:01:23.028678 [allocator b2:de:01:96:13:b4]: Re-Claimed <IP_ADDRESS>/12 for ID _ having existing ID as 589631e93ea890e3dc0ed144e95427a98ba4f6d7a78de4ca23bd7621bf114cd2
DEBU: 2018/09/28 10:01:23.028701 [allocator b2:de:01:96:13:b4]: Re-Claimed <IP_ADDRESS>/12 for ID _ having existing ID as 589631e93ea890e3dc0ed144e95427a98ba4f6d7a78de4ca23bd7621bf114cd2
DEBU: 2018/09/28 10:01:23.028722 [allocator b2:de:01:96:13:b4]: Re-Claimed <IP_ADDRESS>/12 for ID _ having existing ID as 589631e93ea890e3dc0ed144e95427a98ba4f6d7a78de4ca23bd7621bf114cd2
DEBU: 2018/09/28 10:01:23.028741 [allocator b2:de:01:96:13:b4]: Re-Claimed <IP_ADDRESS>/12 for ID _ having existing ID as 589631e93ea890e3dc0ed144e95427a98ba4f6d7a78de4ca23bd7621bf114cd2
DEBU: 2018/09/28 10:01:23.028760 [allocator b2:de:01:96:13:b4]: Re-Claimed <IP_ADDRESS>/12 for ID _ having existing ID as b92578e6ab2d5aeecc8f37a8ca386448ce5e237abecef56bc5144b77b179c44d
DEBU: 2018/09/28 10:01:23.028779 [allocator b2:de:01:96:13:b4]: Re-Claimed <IP_ADDRESS>/12 for ID _ having existing ID as b92578e6ab2d5aeecc8f37a8ca386448ce5e237abecef56bc5144b77b179c44d
DEBU: 2018/09/28 10:01:23.028798 [allocator b2:de:01:96:13:b4]: Re-Claimed <IP_ADDRESS>/12 for ID _ having existing ID as b92578e6ab2d5aeecc8f37a8ca386448ce5e237abecef56bc5144b77b179c44d
DEBU: 2018/09/28 10:01:23.028822 [allocator b2:de:01:96:13:b4]: Re-Claimed <IP_ADDRESS>/12 for ID _ having existing ID as b92578e6ab2d5aeecc8f37a8ca386448ce5e237abecef56bc5144b77b179c44d
DEBU: 2018/09/28 10:01:23.028841 [allocator b2:de:01:96:13:b4]: Re-Claimed <IP_ADDRESS>/12 for ID _ having existing ID as b92578e6ab2d5aeecc8f37a8ca386448ce5e237abecef56bc5144b77b179c44d
INFO: 2018/09/28 10:01:23.028929 Sniffing traffic on datapath (via ODP)
INFO: 2018/09/28 10:01:23.029369 ->[<IP_ADDRESS>:6783] attempting connection
INFO: 2018/09/28 10:01:23.029515 ->[<IP_ADDRESS>:6783] attempting connection
INFO: 2018/09/28 10:01:23.029686 ->[<IP_ADDRESS>:51265] connection accepted
INFO: 2018/09/28 10:01:23.030007 ->[<IP_ADDRESS>:6783] error during connection attempt: dial tcp4 :0-><IP_ADDRESS>:6783: connect: connection refused
INFO: 2018/09/28 10:01:23.030492 ->[<IP_ADDRESS>:6783|b2:de:01:96:13:b4(server-01)]: connection shutting down due to error: cannot connect to ourself
INFO: 2018/09/28 10:01:23.030666 ->[<IP_ADDRESS>:51265|b2:de:01:96:13:b4(server-01)]: connection shutting down due to error: cannot connect to ourself
INFO: 2018/09/28 10:01:23.033900 Listening for HTTP control messages on <IP_ADDRESS>:6784
INFO: 2018/09/28 10:01:23.035258 Listening for metrics requests on <IP_ADDRESS>:6782
DEBU: 2018/09/28 10:01:23.114862 fastdp: broadcast{1 false} {b2:de:01:96:13:b4 ff:ff:ff:ff:ff:ff}
DEBU: 2018/09/28 10:01:23.114946 Discovered local MAC b2:de:01:96:13:b4
DEBU: 2018/09/28 10:01:23.115104 Creating ODP flow FlowSpec{keys: [InPortFlowKey{vport: 1} EthernetFlowKey{src: b2:de:01:96:13:b4, dst: ff:ff:ff:ff:ff:ff}], actions: [OutputAction{vport: 0}]}
DEBU: 2018/09/28 10:01:23.214435 [http] GET /status
DEBU: 2018/09/28 10:01:24.406060 ODP miss: map[22:UnknownFlowKey{type: 22, key: 00000000, mask: exact} 24:UnknownFlowKey{type: 24, key: 00000000, mask: exact} 4:EthernetFlowKey{src: 2e:53:d1:b4:0c:dd, dst: ff:ff:ff:ff:ff:ff} 20:BlobFlowKey{type: 20, key: 00000000, mask: ffffffff} 13:BlobFlowKey{type: 13, key: 0a2000010a28000500012e53d1b40cdd0000000000000000, mask: ffffffffffffffffffffffffffffffffffffffffffffffff} 2:BlobFlowKey{type: 2, key: 00000000, mask: ffffffff} 23:UnknownFlowKey{type: 23, key: 0000, mask: exact} 19:BlobFlowKey{type: 19, key: 00000000, mask: ffffffff} 25:UnknownFlowKey{type: 25, key:<PHONE_NUMBER>0000000000000000000000, mask: exact} 6:BlobFlowKey{type: 6, key: 0806, mask: ffff} 3:InPortFlowKey{vport: 2} 15:BlobFlowKey{type: 15, key: 00000000, mask: ffffffff} 16:TunnelFlowKey{id:<PHONE_NUMBER>f4f4d8, ipv4src: <IP_ADDRESS>, ipv4dst: <IP_ADDRESS>, ttl: 64, tpsrc: 48884, tpdst: 6784}] on port 2
INFO: 2018/09/28 10:01:25.416266 ->[<IP_ADDRESS>:6783] attempting connection
INFO: 2018/09/28 10:01:25.416933 ->[<IP_ADDRESS>:6783] error during connection attempt: dial tcp4 :0-><IP_ADDRESS>:6783: connect: connection refused
DEBU: 2018/09/28 10:01:25.465323 ODP miss: map[16:TunnelFlowKey{id:<PHONE_NUMBER>f4f4d8, ipv4src: <IP_ADDRESS>, ipv4dst: <IP_ADDRESS>, ttl: 64, tpsrc: 48884, tpdst: 6784} 25:UnknownFlowKey{type: 25, key:<PHONE_NUMBER>0000000000000000000000, mask: exact} 6:BlobFlowKey{type: 6, key: 0806, mask: ffff} 22:UnknownFlowKey{type: 22, key: 00000000, mask: exact} 15:BlobFlowKey{type: 15, key: 00000000, mask: ffffffff} 4:EthernetFlowKey{src: 2e:53:d1:b4:0c:dd, dst: ff:ff:ff:ff:ff:ff} 20:BlobFlowKey{type: 20, key: 00000000, mask: ffffffff} 19:BlobFlowKey{type: 19, key: 00000000, mask: ffffffff} 23:UnknownFlowKey{type: 23, key: 0000, mask: exact} 24:UnknownFlowKey{type: 24, key: 00000000, mask: exact} 3:InPortFlowKey{vport: 2} 13:BlobFlowKey{type: 13, key: 0a2000010a28000500012e53d1b40cdd0000000000000000, mask: ffffffffffffffffffffffffffffffffffffffffffffffff} 2:BlobFlowKey{type: 2, key: 00000000, mask: ffffffff}] on port 2
DEBU: 2018/09/28 10:01:26.489271 ODP miss: map[24:UnknownFlowKey{type: 24, key: 00000000, mask: exact} 4:EthernetFlowKey{src: 2e:53:d1:b4:0c:dd, dst: ff:ff:ff:ff:ff:ff} 22:UnknownFlowKey{type: 22, key: 00000000, mask: exact} 25:UnknownFlowKey{type: 25, key:<PHONE_NUMBER>0000000000000000000000, mask: exact} 20:BlobFlowKey{type: 20, key: 00000000, mask: ffffffff} 19:BlobFlowKey{type: 19, key: 00000000, mask: ffffffff} 16:TunnelFlowKey{id:<PHONE_NUMBER>f4f4d8, ipv4src: <IP_ADDRESS>, ipv4dst: <IP_ADDRESS>, ttl: 64, tpsrc: 48884, tpdst: 6784} 23:UnknownFlowKey{type: 23, key: 0000, mask: exact} 2:BlobFlowKey{type: 2, key: 00000000, mask: ffffffff} 3:InPortFlowKey{vport: 2} 15:BlobFlowKey{type: 15, key: 00000000, mask: ffffffff} 6:BlobFlowKey{type: 6, key: 0806, mask: ffff} 13:BlobFlowKey{type: 13, key: 0a2000010a28000500012e53d1b40cdd0000000000000000, mask: ffffffffffffffffffffffffffffffffffffffffffffffff}] on port 2
DEBU: 2018/09/28 10:01:29.406274 ODP miss: map[25:UnknownFlowKey{type: 25, key:<PHONE_NUMBER>0000000000000000000000, mask: exact} 13:BlobFlowKey{type: 13, key: 0a2000010a28000500012e53d1b40cdd0000000000000000, mask: ffffffffffffffffffffffffffffffffffffffffffffffff} 2:BlobFlowKey{type: 2, key: 00000000, mask: ffffffff} 22:UnknownFlowKey{type: 22, key: 00000000, mask: exact} 24:UnknownFlowKey{type: 24, key: 00000000, mask: exact} 23:UnknownFlowKey{type: 23, key: 0000, mask: exact} 6:BlobFlowKey{type: 6, key: 0806, mask: ffff} 20:BlobFlowKey{type: 20, key: 00000000, mask: ffffffff} 4:EthernetFlowKey{src: 2e:53:d1:b4:0c:dd, dst: ff:ff:ff:ff:ff:ff} 19:BlobFlowKey{type: 19, key: 00000000, mask: ffffffff} 16:TunnelFlowKey{id:<PHONE_NUMBER>f4f4d8, ipv4src: <IP_ADDRESS>, ipv4dst: <IP_ADDRESS>, ttl: 64, tpsrc: 48884, tpdst: 6784} 3:InPortFlowKey{vport: 2} 15:BlobFlowKey{type: 15, key: 00000000, mask: ffffffff}] on port 2
INFO: 2018/09/28 10:01:29.559178 ->[<IP_ADDRESS>:6783] attempting connection
INFO: 2018/09/28 10:01:29.559825 ->[<IP_ADDRESS>:6783] error during connection attempt: dial tcp4 :0-><IP_ADDRESS>:6783: connect: connection refused

Network:

$ ip route # node with failed weave pod
default via <redacted>.123.1 dev vlan1 proto static
<IP_ADDRESS>/12 dev weave proto kernel scope link src <IP_ADDRESS>
<IP_ADDRESS>/16 dev docker0 proto kernel scope link src <IP_ADDRESS> linkdown
<IP_ADDRESS>/24 dev vlan20 proto kernel scope link src <IP_ADDRESS>
<IP_ADDRESS>/24 dev vlan1 proto kernel scope link src <IP_ADDRESS>
<redacted>.123.0/24 dev vlan1 proto kernel scope link src <redacted>.123.160

$ ip route # control plane with running weave pod
default via <redacted>.123.1 dev vlan1 proto static
<IP_ADDRESS>/12 dev weave proto kernel scope link src <IP_ADDRESS>
<IP_ADDRESS>/24 dev enp0s20f0u1u6 proto kernel scope link src <IP_ADDRESS>
<IP_ADDRESS>/16 dev docker0 proto kernel scope link src <IP_ADDRESS>
<IP_ADDRESS>/24 dev vlan20 proto kernel scope link src <IP_ADDRESS>
<IP_ADDRESS>/24 dev vlan1 proto kernel scope link src <IP_ADDRESS>
<redacted>.123.0/24 dev vlan1 proto kernel scope link src <redacted>.123.161

$ ip -4 -o addr # node with failed weave pod
1: lo    inet <IP_ADDRESS>/8 scope host lo\       valid_lft forever preferred_lft forever
7: vlan1    inet <redacted>.123.160/24 brd <redacted>.123.255 scope global vlan1\       valid_lft forever preferred_lft forever
7: vlan1    inet <IP_ADDRESS>/24 brd <IP_ADDRESS> scope global vlan1\       valid_lft forever preferred_lft forever
8: vlan20    inet <IP_ADDRESS>/24 brd <IP_ADDRESS> scope global vlan20\       valid_lft forever preferred_lft forever
9: docker0    inet <IP_ADDRESS>/16 brd <IP_ADDRESS> scope global docker0\       valid_lft forever preferred_lft forever
12: weave    inet <IP_ADDRESS>/12 brd <IP_ADDRESS> scope global weave\       valid_lft forever preferred_lft forever

$ ip -4 -o addr # control plane with running weave pod
1: lo    inet <IP_ADDRESS>/8 scope host lo\       valid_lft forever preferred_lft forever
7: enp0s20f0u1u6    inet <IP_ADDRESS>/24 brd <IP_ADDRESS> scope global dynamic enp0s20f0u1u6\       valid_lft 499sec preferred_lft 499sec
8: vlan20    inet <IP_ADDRESS>/24 brd <IP_ADDRESS> scope global vlan20\       valid_lft forever preferred_lft forever
9: vlan1    inet <redacted>.123.161/24 brd <redacted>.123.255 scope global vlan1\       valid_lft forever preferred_lft forever
9: vlan1    inet <IP_ADDRESS>/24 brd <IP_ADDRESS> scope global vlan1\       valid_lft forever preferred_lft forever
12: docker0    inet <IP_ADDRESS>/16 brd <IP_ADDRESS> scope global docker0\       valid_lft forever preferred_lft forever
62: weave    inet <IP_ADDRESS>/12 brd <IP_ADDRESS> scope global weave\       valid_lft forever preferred_lft forever

$ sudo iptables-save
# Would be too long to paste here, tell me if this is really needed there.

Thanks for the detailed report.
The "running pod" is running because you manually inserted the list, right?
Can you shell into the weave container and run /home/weave/kube-utils -v=8 please?

The running pod can retrieve peers even without the peer list variable, while the other weave-net pod scheduled on the other node can't retrieve them automatically.
Here are my logs :
# Failing pod, command hangs and the pod get restarted

$ kubectl -n kube-system exec -it weave-net-5txmw /home/weave/kube-utils -v=8
I0928 14:59:36.840502   15871 loader.go:359] Config loaded from file /home/core/.kube/config
I0928 14:59:36.841149   15871 loader.go:359] Config loaded from file /home/core/.kube/config
I0928 14:59:36.841900   15871 loader.go:359] Config loaded from file /home/core/.kube/config
I0928 14:59:36.842992   15871 round_trippers.go:383] GET https://<IP_ADDRESS>:6443/api/v1/namespaces/kube-system/pods/weave-net-5txmw
I0928 14:59:36.843007   15871 round_trippers.go:390] Request Headers:
I0928 14:59:36.843017   15871 round_trippers.go:393]     Accept: application/json, */*
I0928 14:59:36.843026   15871 round_trippers.go:393]     User-Agent: kubectl/v1.12.0 (linux/amd64) kubernetes/0ed3388
I0928 14:59:36.871828   15871 round_trippers.go:408] Response Status: 200 OK in 28 milliseconds
I0928 14:59:36.871866   15871 round_trippers.go:411] Response Headers:
I0928 14:59:36.871881   15871 round_trippers.go:414]     Content-Type: application/json
I0928 14:59:36.871892   15871 round_trippers.go:414]     Date: Fri, 28 Sep 2018 14:59:36 GMT
I0928 14:59:36.872042   15871 request.go:942] Response Body: {"kind":"Pod","apiVersion":"v1","metadata":{"name":"weave-net-5txmw","generateName":"weave-net-","namespace":"kube-system","selfLink":"/api/v1/namespaces/kube-system/pods/weave-net-5txmw","uid":"19358ed3-c32f-11e8-8466-1aeeb4bf4c74","resourceVersion":"974971","creationTimestamp":"2018-09-28T14:59:28Z","labels":{"controller-revision-hash":"554488cfc7","name":"weave-net","pod-template-generation":"24"},"ownerReferences":[{"apiVersion":"apps/v1","kind":"DaemonSet","name":"weave-net","uid":"858e8705-bcf0-11e8-af8f-1aeeb4bf4c74","controller":true,"blockOwnerDeletion":true}]},"spec":{"volumes":[{"name":"weavedb","hostPath":{"path":"/var/lib/weave","type":""}},{"name":"cni-bin","hostPath":{"path":"/opt","type":""}},{"name":"cni-bin2","hostPath":{"path":"/home","type":""}},{"name":"cni-conf","hostPath":{"path":"/etc","type":""}},{"name":"dbus","hostPath":{"path":"/var/lib/dbus","type":""}},{"name":"lib-modules","hostPath":{"path":"/lib/modules","type":""}},{"name":"xtables-lock","hostPath":{"path":"/run/xtables.lock" [truncated 4219 chars]
Defaulting container name to weave.
Use 'kubectl describe pod/weave-net-5txmw -n kube-system' to see all of the containers in this pod.
I0928 14:59:36.880577   15871 round_trippers.go:383] POST https://<IP_ADDRESS>:6443/api/v1/namespaces/kube-system/pods/weave-net-5txmw/exec?command=%2Fhome%2Fweave%2Fkube-utils&container=weave&container=weave&stdin=true&stdout=true&tty=true
  I0928 14:59:36.880608   15871 round_trippers.go:390] Request Headers:
                                                                       I0928 14:59:36.880625   15871 round_trippers.go:393]     X-Stream-Protocol-Version: v4.channel.k8s.io
                                                                                I0928 14:59:36.880642   15871 round_trippers.go:393]     X-Stream-Protocol-Version: v3.channel.k8s.io
                                   I0928 14:59:36.880657   15871 round_trippers.go:393]     X-Stream-Protocol-Version: v2.channel.k8s.io
                                                                                I0928 14:59:36.880672   15871 round_trippers.go:393]     X-Stream-Protocol-Version: channel.k8s.io
                                                                                I0928 14:59:36.880687   15871 round_trippers.go:393]     User-Agent: kubectl/v1.12.0 (linux/amd64) kubernetes/0ed3388
                                                                                I0928 14:59:36.939761   15871 round_trippers.go:408] Response Status: 101 Switching Protocols in 59 milliseconds
                                                                                I0928 14:59:36.939779   15871 round_trippers.go:411] Response Headers:
                                                         I0928 14:59:36.939785   15871 round_trippers.go:414]     X-Stream-Protocol-Version: v4.channel.k8s.io
                                                                                I0928 14:59:36.939794   15871 round_trippers.go:414]     Date: Fri, 28 Sep 2018 14:59:36 GMT
            I0928 14:59:36.939803   15871 round_trippers.go:414]     Connection: Upgrade
                                                                                I0928 14:59:36.939812   15871 round_trippers.go:414]     Upgrade: SPDY/3.1

# Running pod on the other node

$ kubectl -n kube-system exec -it weave-net-zrnnc /home/weave/kube-utils -v=8
I0928 15:01:17.023511   18177 loader.go:359] Config loaded from file /home/core/.kube/config
I0928 15:01:17.024236   18177 loader.go:359] Config loaded from file /home/core/.kube/config
I0928 15:01:17.025085   18177 loader.go:359] Config loaded from file /home/core/.kube/config
I0928 15:01:17.026271   18177 round_trippers.go:383] GET https://<IP_ADDRESS>:6443/api/v1/namespaces/kube-system/pods/weave-net-zrnnc
I0928 15:01:17.026287   18177 round_trippers.go:390] Request Headers:
I0928 15:01:17.026295   18177 round_trippers.go:393]     Accept: application/json, */*
I0928 15:01:17.026303   18177 round_trippers.go:393]     User-Agent: kubectl/v1.12.0 (linux/amd64) kubernetes/0ed3388
I0928 15:01:17.053146   18177 round_trippers.go:408] Response Status: 200 OK in 26 milliseconds
I0928 15:01:17.053186   18177 round_trippers.go:411] Response Headers:
I0928 15:01:17.053204   18177 round_trippers.go:414]     Content-Type: application/json
I0928 15:01:17.053220   18177 round_trippers.go:414]     Date: Fri, 28 Sep 2018 15:01:17 GMT
I0928 15:01:17.053437   18177 request.go:942] Response Body: {"kind":"Pod","apiVersion":"v1","metadata":{"name":"weave-net-zrnnc","generateName":"weave-net-","namespace":"kube-system","selfLink":"/api/v1/namespaces/kube-system/pods/weave-net-zrnnc","uid":"1a772fcd-c32f-11e8-8466-1aeeb4bf4c74","resourceVersion":"974989","creationTimestamp":"2018-09-28T14:59:30Z","labels":{"controller-revision-hash":"554488cfc7","name":"weave-net","pod-template-generation":"24"},"ownerReferences":[{"apiVersion":"apps/v1","kind":"DaemonSet","name":"weave-net","uid":"858e8705-bcf0-11e8-af8f-1aeeb4bf4c74","controller":true,"blockOwnerDeletion":true}]},"spec":{"volumes":[{"name":"weavedb","hostPath":{"path":"/var/lib/weave","type":""}},{"name":"cni-bin","hostPath":{"path":"/opt","type":""}},{"name":"cni-bin2","hostPath":{"path":"/home","type":""}},{"name":"cni-conf","hostPath":{"path":"/etc","type":""}},{"name":"dbus","hostPath":{"path":"/var/lib/dbus","type":""}},{"name":"lib-modules","hostPath":{"path":"/lib/modules","type":""}},{"name":"xtables-lock","hostPath":{"path":"/run/xtables.lock" [truncated 4225 chars]
Defaulting container name to weave.
Use 'kubectl describe pod/weave-net-zrnnc -n kube-system' to see all of the containers in this pod.
I0928 15:01:17.067501   18177 round_trippers.go:383] POST https://<IP_ADDRESS>:6443/api/v1/namespaces/kube-system/pods/weave-net-zrnnc/exec?command=%2Fhome%2Fweave%2Fkube-utils&container=weave&container=weave&stdin=true&stdout=true&tty=true
  I0928 15:01:17.067546   18177 round_trippers.go:390] Request Headers:
                                                                       I0928 15:01:17.067564   18177 round_trippers.go:393]     X-Stream-Protocol-Version: v4.channel.k8s.io
                                                                                I0928 15:01:17.067579   18177 round_trippers.go:393]     X-Stream-Protocol-Version: v3.channel.k8s.io
                                   I0928 15:01:17.067594   18177 round_trippers.go:393]     X-Stream-Protocol-Version: v2.channel.k8s.io
                                                                                I0928 15:01:17.067609   18177 round_trippers.go:393]     X-Stream-Protocol-Version: channel.k8s.io
                                                                                I0928 15:01:17.067624   18177 round_trippers.go:393]     User-Agent: kubectl/v1.12.0 (linux/amd64) kubernetes/0ed3388
                                                                                I0928 15:01:17.147833   18177 round_trippers.go:408] Response Status: 101 Switching Protocols in 80 milliseconds
                                                                                I0928 15:01:17.147893   18177 round_trippers.go:411] Response Headers:
                                                         I0928 15:01:17.147912   18177 round_trippers.go:414]     X-Stream-Protocol-Version: v4.channel.k8s.io
                                                                                I0928 15:01:17.147928   18177 round_trippers.go:414]     Date: Fri, 28 Sep 2018 15:01:17 GMT
            I0928 15:01:17.147943   18177 round_trippers.go:414]     Connection: Upgrade
                                                                                I0928 15:01:17.147958   18177 round_trippers.go:414]     Upgrade: SPDY/3.1
                                                                                <IP_ADDRESS>
<IP_ADDRESS>

kubectl -n kube-system exec -it weave-net-5txmw /home/weave/kube-utils -v=8

This is printing the details of calls done by kubectl.
This is more like what I meant:
kubectl -n kube-system exec -it weave-net-5txmw -c weave -- /home/weave/kube-utils -v=8

however it turns out -v is not wired up in kube-utils or otherwise not doing what I wanted it to.

The fact that the second container returns only one address seems relevant - I'm wondering if this is the same as https://github.com/weaveworks/weave/issues/3392#issuecomment-418285487
Can you do kubectl get nodes -o wide please?

NAME      STATUS   ROLES    AGE     VERSION   INTERNAL-IP    EXTERNAL-IP   OS-IMAGE                                        KERNEL-VERSION   CONTAINER-RUNTIME
gaia      Ready       7d23h   v1.12.0   <IP_ADDRESS>           Container Linux by CoreOS 1855.4.0 (Rhyolite)   4.14.67-coreos   docker://18.6.1
ouranos   Ready    master   7d23h   v1.12.0   <IP_ADDRESS>           Container Linux by CoreOS 1855.4.0 (Rhyolite)   4.14.67-coreos   docker://18.6.1

OK, not the same as #3392.
I figured out how to make -v do what I wanted; please run:
kubectl -n kube-system exec -it weave-net-5txmw -c weave -- /home/weave/kube-utils -v=8 -alsologtostderr`

$ kubectl -n kube-system exec -it weave-net-v5ppz -c weave -- /home/weave/kube-utils -v=8 -alsologtostderr
I1001 08:54:41.083285   28904 round_trippers.go:414] GET https://<IP_ADDRESS>:443/api/v1/nodes
I1001 08:54:41.083804   28904 round_trippers.go:421] Request Headers:
I1001 08:54:41.083821   28904 round_trippers.go:424]     Accept: application/json, */*
I1001 08:54:41.083832   28904 round_trippers.go:424]     User-Agent: kube-utils/v0.0.0 (linux/amd64) kubernetes/$Format
I1001 08:54:41.083849   28904 round_trippers.go:424]     Authorization: Bearer eyJhbGciOiJSUzI1NiIsImtpZCI6IiJ9.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJrdWJlLXN5c3RlbSIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VjcmV0Lm5hbWUiOiJ3ZWF2ZS1uZXQtdG9rZW4tZGZ3dnoiLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlcnZpY2UtYWNjb3VudC5uYW1lIjoid2VhdmUtbmV0Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZXJ2aWNlLWFjY291bnQudWlkIjoiODU4MmQyYmItYmNmMC0xMWU4LWFmOGYtMWFlZWI0YmY0Yzc0Iiwic3ViIjoic3lzdGVtOnNlcnZpY2VhY2NvdW50Omt1YmUtc3lzdGVtOndlYXZlLW5ldCJ9.k6ztNyG2EG47Km11g8zPoJvw4sZquYKr1cKh367HANUI9cEq-86AsSzO5o27m-5oggXf-1IGxx7BFbBCOJCwFhiFYjtAtOmWW7AAExAEAVZc92NyAmYOfao53Y4PFLjUxBqFBX1eChoOLMGRN16U8zk8M9xh4PTxyLgubMiU81LA3zEOPYt7Rru9eJne-8Kov5aGWnkovyNLr6MViDXiB4-M4fEm1QFD4rRMBn8HufJws9j6rYEaBWgb7b7VlqmOy4viqlWkV67AAmflX-cizfyPcfoGxmZu7yUgdK8hi_piVuCf6aeyhHoDTxg23xeyDR886aiT7vDySABSTXeIMg

Then it timeout and restart.

I believe what we are looking at now is not exactly the same as the original behaviour:
$ kubectl -n kube-system logs -f weave-net-c7nfb weave
Failed to get peers

because it shouldn't get as far as "Failed to get peers" if the whole pod times out.
Nontheless, your system is not going to do anything if the node can't access the Kubernetes api-server.
I wonder if this is the thing where Linux picks the wrong source IP address for DNATted packets?
Try adding a route to <IP_ADDRESS>/24 via the appropriate network interface.  I see you have multiple on each host, for different vlans.

Hello, same behaviour here in some of our clusters.
It seems that weave want to  connect to api-server (kubernetes.default:443)  but for some reason kube-proxy do not forward it  to master_ip:6443
kubectl describe svc kubernetes  Name:              kubernetes Namespace:         default Labels:            component=apiserver                    provider=kubernetes Annotations:       <none> Selector:          <none> Type:              ClusterIP IP:                <IP_ADDRESS> Port:              https  443/TCP TargetPort:        6443/TCP Endpoints:         <IP_ADDRESS>:6443 Session Affinity:  None Events:            <none>

@gousse it's impossible to diagnose without a lot of detail; please open your own issue and fill in the information requested.

@bboreham understand, it was just to point out we have exact same situation, and found that the problem is kube-proxy failing to join apiserver

OK, I appreciate you are trying to help, but just to be clear to anyone else reading this your comment makes assumptions ahead of the information available in this particular case.
"the thing where Linux picks the wrong source address" is described more fully at https://github.com/kubernetes/kubeadm/issues/102#issuecomment-291532883

@bboreham just hit this issue after updating to 1.12 and after seeing your comment (https://github.com/kubernetes/kubeadm/issues/102#issuecomment-291532883) adding the route rule fixed the problem. The thing is that it fails consistently in 1.12 and it works in 1.8 using the same kernel version and bootstrap steps (kubeadm)
I do see that ip ro get <IP_ADDRESS> picks the default interface (which is not the cluster one) in both installations but for some reason  in 1.8 it still routes the traffic correctly.
If you want to reproduce this you can go to https://play-with-k8s.com (PWK co-creator here) and bootstrap the cluster with kubeadm to see what I'm saying. You can select between 1.12 and 1.8 with the gear icon in the left menu.

Why do you think this is an issue with Weave Net?  My understanding of the problem is that a process on a host cannot establish an TCP connection to an address it has been given. The same thing would happen for any process.

@marcosnils sorry, I mis-read the context

After investigating found what was causing the problem in v1.12.1. As stated in (https://github.com/kubernetes/kubeadm/issues/102#issuecomment-370753273) the following iptable rule was missing in the new version:
iptables -t nat -I KUBE-SERVICES -d <IP_ADDRESS>/32 -p tcp -m comment --comment "default/kubernetes:https cluster IP" -m tcp --dport 443 -j KUBE-MARK-MASQ
Not sure how / when / if that rule is necessary but after adding that it started working. I'd also love to know where K8s networking is using that MARK to forward the packet to the correct interface. I haven't found any routing tables that actually uses that mark.

KUBE-MARK-MASQ is used by another kube-proxy rule to masquerade the packet (change its source address).  Since the root problem is that Linux has initially made a bad choice of source address, changing the source address makes that problem go away.
I prefer adding a route as it has less overhead, and you might want to keep the original source address for tracing or policy reasons.

I think I just figured what was wrong with my setup. The pod CIDR (<IP_ADDRESS>/12) was not passed to some kubernetes system components because I did not initialized the cluster with the correct kubeadm parameter. This resulted in unreachable kubernetes API calls on the slave node.
Adding this in the correct places, it also fixed my nginx controller not being able to get source IP from clients.
The kubernetes documentation is slighlty misleading. It advices to set a pod CIDR for various pod network add-on but not for weave. See : https://kubernetes.io/docs/setup/independent/create-cluster-kubeadm/#pod-network
This isssue can be closed.

thanks for reporting back @tailtwo. FYI it's documented under Things to watch out for in weave net docs.

After investigating found what was causing the problem in v1.12.1. As stated in (kubernetes/kubeadm#102 (comment)) the following iptable rule was missing in the new version:
iptables -t nat -I KUBE-SERVICES -d <IP_ADDRESS>/32 -p tcp -m comment --comment "default/kubernetes:https cluster IP" -m tcp --dport 443 -j KUBE-MARK-MASQ
Not sure how / when / if that rule is necessary but after adding that it started working. I'd also love to know where K8s networking is using that MARK to forward the packet to the correct interface. I haven't found any routing tables that actually uses that mark.

Could you kindly explain the command in a bit so that one referring to this can understand what they're trying to do?

Could you kindly explain the command

The question about what MARK does is answered at https://github.com/weaveworks/weave/issues/3420#issuecomment-431326586; you can find descriptions of other iptables options at https://linux.die.net/man/8/iptables

iptables v1.8.5 (nf_tables): Couldn't load match comment

That suggests your Linux doesn't have the "comment" extension for iptables.  It is normally installed as standard.

iptables -t nat -I KUBE-SERVICES -d <IP_ADDRESS>/32 -p tcp -m comment --comment "default/kubernetes:https cluster IP" -m tcp --dport 443 -j KUBE-MARK-MASQ

This worked and solved my issue.


MERC-1025, MERC-1477: HTML refinements.

What?

Demonstrate usage of the locale_name variable for specifying the document language.
Add title attributes to all images.

Why?
For accessibility and SEO.
Testing / Proof

Ping @mcampa @lord2800 @bc-AlyssNoland

I think alt should be sufficient. I'd only use title if the text is different to alt and you want it to show as a tooltip. I think major search engines use alt text for indexing. If you use both and they are the same, you might even get penalised for keyword spamming. Screen readers also prefer alt over title for images. But MERC-1477 seems to suggest I'm wrong 😞

I think alt should be sufficient.
Historically I've used both just since browsers tended to prefer one or the other on mouseover, but I believe those days are past. Regardless, the discussion on Slack and the JIRA implies there's value in doing this, so...

Yeah, I'm not a SEO expert so I'm going to take his recommendation. :)


QueryGenerator or QueryConstructor

Here: https://github.com/castorini/anserini/blob/master/src/main/java/io/anserini/search/SearchCollection.java#L127
We're inconsistent in the use of QueryGenerator and QueryConstructor: should we standardize? I think I like QueryConstructor better, so this would entail renaming all the classes?
Thoughts @Chriskamphuis ?

I agree, especially if we ship this to Python it can be confusing with the native python generator objects.

The method name is called buildQuery... what about "builder"?
So, builder vs. constructor vs. generator? Maybe builder is even better because it doesn't get confused with class constructors?

Sure, however the native Lucene Query objects have a Builder object they use. So it would look something like this:
PhraseQueryBuilder:
-- BuildQuery()
----PhraseQuery.Builder builder = new PhraseQuery.Builder()
------builder.build()

which is a bit confusing maybe?

hrm. I like calling it "builder" but if we don't adopt Lucene's idiom, will we create confusion? I think separate builder classes in our context is over-engineering...

Clarified over Slack. @Chriskamphuis 's main point above is that if we named our class Builder, then internally we'll have to call Lucene's builder, which makes it terrible confusing with variable names...
tl;dr - since all the terms are overloaded and ambiguous (but in different ways), we're just going to stick to "generator", so the fix is to rename the "constructor" in SearchCollection.


PR: Allow underscore to be valid for Enter in File Switcher

Fixes #3575

The problem was that the regex to validate the line number filter wasn´t taking into account the underscore symbol, so the signal wouldn´t be emitted.

LGTM :-0

Nice!! Thanks @dalthviz :-)

You're welcome 👍


[Outreachy] Registry: Add Tags to Items #5336

#5336 - Add Tags to Items
Added Tags to the existing data entries

@svrnm Please Kindly review sir and I'll appreciate your feedback on it

@olamideTiana a few hints for you what needs to be done:
In the file https://github.com/open-telemetry/opentelemetry.io/blob/main/layouts/partials/ecosystem/registry/entry.html you will need to find a place where to put the tags. To begin with there is no need to read the data from the entry yet, just use some sample values to setup the user experience for it. You can take inspiration from other registries how they display tags, e.g. https://www.npmjs.com/search?q=opentelemetry

Ohh, sorry for the inconvenience @svrnm Thanks for shedding more light to the issue, I'll fix it now. By the way, can I close this PR

@svrnm Okay, thank you