Turn on 'as' bridging for Linux (2)

(This is a second attempt at https://github.com/apple/swift/pull/16022.)
Turn on some of the same kinds of bridging on Linux as Swift already allows on Darwin, reducing language differences between platforms.
The following bridging situations will now work the same from a developer's perspective on Linux as they do on Darwin:

bridging known struct types and numeric types to Foundation reference types and vice versa (NSString(…) as String, "abc" as NSString, 1.23 as NSNumber).
bridging arbitrary Swift values to opaque (_SwiftValue) reference types and vice versa (with struct X {}: ([X(), X(), X()] as NSArray) as! [X] will work).
bridging Optional<_>.none to an appropriate object and back. (If Foundation is available, we will use NSNull as the object, to match Darwin behavior. For example, (([nil, nil, nil] as [Int?]) as NSArray) as! [Int?] will work, and the NSArray will be [NSNull(), NSNull(), NSNull()] like it is on Darwin.)

Just like on Darwin, these objects are all laid out identically to CFTypeRefs, meaning for example that an array of these values, including opaque boxed values, can be casted to CFArrayRef and back correctly just like it can on Darwin. Likewise, if Foundation is linked, these opaque objects will be castable to Foundation.NSObject and implement Foundation.NSCopying just like they can on Darwin; while this isn't part of the contract for these objects, code that unwittingly relies on this will continue to work on Linux as well.
This does not target enabling other as{,?,!} casts that work on Darwin but not on Linux that strictly require the ObjC runtime:

Any value whose type is a metatype X.self from/to AnyObject
Closures from/to AnyObject

This patch must land in lockstep with a separate Foundation patch (at https://github.com/apple/swift-corelibs-foundation/pull/1526). This patch doesn't require that applications link Foundation; apps that do not link it will still be able to use as AnyObject casts for any value to turn it into a bridged object, if they implement _ObjectiveCBridgeable (which still remains an implementation detail), or an opaque boxed value; this also reflects Swift language behavior for Darwin applications that do not import Foundation. One difference with Darwin is that in this case the opaque box returned by casting will not be a NSObject, since that's only available if Foundation is.

Please test with the following:
https://github.com/apple/swift-corelibs-foundation/pull/1526
@swift-ci please smoke test

@millenomi just a quick check: did you use the eager bridging stub? At some point we are going to want to try to enable that. (TBH I didn't look through the PR I just wanted to make sure that you were aware of this and if it was necessary used it).

I’m not sure what you mean by that, unless that’s how _bridgeAnythingToObjectiveC is referred to? Do you have pointers?

@gottesmm for the question above.
cc for review: @jckarter @jrose-apple @rjmccall @rudkx — Thanks for your time taking a look at this; some feedback from https://github.com/apple/swift/pull/16022 has been applied. I would prefer if possible to tackle moving the Swift bits to C++ in a follow-up patch and keep the class hierarchy the same, but we can discuss options on this.

Please test with the following:
https://github.com/apple/swift-corelibs-foundation/pull/1526
@swift-ci please smoke test

cc @itaiferber for changes to Codable.swift.gyb.

@millenomi Sorry I missed your question. Here is the code:
https://github.com/apple/swift/commit/32146274e73fe07bf3f9633f49624cc6728f1ae3
Context: rdar://35943342

I'm still concerned about dynamically changing the bridging behavior based on the presence of Foundation. That would create a schism between Foundation-using and non-Foundation-using libraries, and mean that the former can't be dynamically loaded. If value boxes need to be NSCopying, then can you extend the class to be NSCopying from Foundation? We never really wanted _SwiftValue to be an NSObject subclass even on Darwin, and it'd be nice if that were the way things began on Linux, but if we really must make boxed values be NSObject subclasses when Foundation is loaded, we should look into doing so in a way that doesn't invalidate boxed values that exist from before loading Foundation. For instance, we could make it so that boxing uses heap objects that start out with non-class heap metadata, and overwrite the metadata with an NSObject subclass when Foundation gets loaded.

Question. @millenomi do you think it would make sense to just enable eager bridging straight up now on Linux? It would make optimizing arrays significantly easier and prevent the lazy behavior that really hurts the optimizer on macOS.
I would rather us stay away from those legacy problems on Linux if we can.

@millenomi Just to be complete: these are design flaws from the optimizer's perspective.

Any type of associated object like functionality by default (I'd be ok with opt in). The issue is this makes the optimizer be extremely conservative when analyzing deinits.
Any type of swizzling of methods/etc (I'd be ok again if this is opt in). This is another way thing that doing them by default hurts the optimizer.
Any type of lazy bridging. This makes simple operations like subscripting much more complicated for the optimizer to analyze. It makes simple subscripting operations far more dynamic than they need to be.
We really do not want Foundation to be special. Why should it be special? Is there a large benefit to doing so?

@gottesmm The code modified by https://github.com/apple/swift/commit/32146274e73fe07bf3f9633f49624cc6728f1ae3 is not compiled on Linux.
On Linux, there is Core Foundation but no ObjC runtime. This means that there is no need to consider invocations to ObjC classes; it is my understanding that those are the reason the bridging paths are not on Darwin. The use case here is instead for interop with Core Foundation, which contains the ultimate implementation of many basic algorithms and is used by swift-corelibs-foundation to ensure behavior remains close to Darwin, and source and behavior interop when bridging is invoked by user code, which unfortunately is necessary for use of some Foundation API that return Any (like NSKeyedUnarchiver).
Thus, we have decided to not use the stdlib potentially-lazy bridging approach. Instead, we use the current behavior of the bridging primitives in s-c-f, which bridge eagerly at the transition point. The code you point to is guarded by #if _runtime(ObjC); what story do we want to have on that one? Do we need to expose that compiler intrinsic on Linux? How would it interface with Foundation? (Foundation sits below the stdlib on ObjC but above it on Linux.)
Insofar as the other points you mention:

Thanks to eager bridging, we do not have associated object use for this patch.

Swizzling isn’t available on Linux.

All bridging done here is eager.

We would like Foundation not to be special per se, but to be equally special across platforms. In this case, reference types have been discussed already as both a way to work around some rare issues with value types and as an important element of its goal of allowing people to produce predictably interoperable code — write and test on Darwin and deploy on Linux and have a reasonably clear picture of how the code will behave if it compiles. This is why  it gets to use compiler SPI such as _ObjectiveCBridgeable, and why this patch to ensure it works the same on the cases that make sense for Linux developers to use.

@jckarter One of the targets of this patch is to prevent silent dependency scenarios. A typical example is NSSecureCoding implementations:
class Problem: NSSecureCoding { … }

class ProblemHolder: NSSecureCoding {
  …
  required init?(coder: NSCoder) {
    guard let problems = coder.decode(of: [NSArray.self, Problem.self], forKey: "MaybeNinetyNineProblems") as? [Problem] else { … }
   …
  }
  …
}

the as? [Problem] cast is perfectly valid on Darwin, and we currently do not have a way that we share between Darwin and Linux of decoding value types. Note how here it introduces an unexpected failure point — returning nil from the cast will make it impossible to read a valid archive.
The misgivings you have re: NSObject are of a similar silent nature. On Darwin, as? NSObject queries are true for boxed objects, just like as? NSCopying ones. While we do not guarantee it, the goal is predictability: this kind of dependency is allowed on Darwin, has different behavior silently on Linux and is not really detectable at compile time (would you deny casting any Any to NSObject?)
I'd rather be thorough here than not. I understand this prevents an application from dlopen()ing Foundation-linking libraries unless it itself links Foundation — I'll note tho that the supported API for loading libraries that apps are likely to be using is in Foundation (the Bundle class). Still, yours is a concern that I tried to work around several times in this patch to little avail (including, at one point, moving NSObject down to the stdlib, breaking several method signatures on the base class that require Foundation types).
Any solution I can come up with so far has significant drawbacks, and this looked like a sweet spot in behavior and drawback. Any improvement suggestion is welcome.

@gottesmm I'll look into running benchmarks on Linux and see if there's anything I can do to fix or have them fixed.

(To be clear: we do have a way that we share between Darwin and Linux to (de)serialize value types, Codable, but there are important use cases for reading and writing NSKeyedArchiver archives on Linux and there's no interface to that currently that allows for value types unless bridging is present.)

The misgivings you have re: NSObject are of a similar silent nature. On Darwin, as? NSObject queries are true for boxed objects, just like as? NSCopying ones. While we do not guarantee it, the goal is predictability: this kind of dependency is allowed on Darwin, has different behavior silently on Linux and is not really detectable at compile time (would you deny casting any Any to NSObject?)

Predictability is all well and good within reason, but I think the solution here trades one impredictability for worse and harder-to-manage ones. I would expect as? NSObject casts to be relatively rare, since in practice everything on Darwin is NSObject-like-enough for that question to be largely unnecessary. A quick Github code search seems to bear that out: https://github.com/search?l=Swift&p=1&q="as+NSObject"&type=Code From the examples of as! NSObject I could find, it looks like they're all expecting something that either is an NSObject subclass or is bridgable to one.  Boxed values are not NSCoding on either Darwin or Linux, so boxes not being NSObject subclasses shouldn't be an issue in archive compatibility. We could also get predictable behavior here by following through on making the Darwin version of _SwiftValue a non-NSObject class.

I'd rather be thorough here than not. I understand this prevents an application from dlopen()ing Foundation-linking libraries unless it itself links Foundation — I'll note tho that the supported API for loading libraries that apps are likely to be using is in Foundation (the Bundle class). Still, yours is a concern that I tried to work around several times in this patch to little avail (including, at one point, moving NSObject down to the stdlib, breaking several method signatures on the base class that require Foundation types).

Using dlopen and dlsym from Swift is supported too. We shouldn't break it.

I am very worried for the churn I see in trying to implement your proposal, in particular:

Since I cannot express generically an existential of the form 'This thing is Hashable but may belong to one of two different class hierarchies', any usage of NSObject in a Hashable context (e.g. dictionary key, which s-c-f is rife with) within swift-corelibs-foundation now needs to have additional as! casts to go to and from AnyHashable to accommodate a non-NSObject box. This makes decently-sized chunks of that codebase type unsafe.

We'd need to redo how CFEqual() and CFHash() interact with objects, as right now they are looking up and invoking NSObject class methods on them.

(Silly idea: is it possible for us to 'fake' reparenting a stdlib _SwiftValue to be of NSObject type if they're laid out identically in memory?)

(Silly idea: is it possible for us to 'fake' reparenting a stdlib _SwiftValue to be of NSObject type if they're laid out identically in memory?)

It's not silly at all. Since NSObject doesn't have any storage, it wouldn't be unreasonable to try dynamically turning the boxed value metadata into an NSObject subclass. We would however need to know the extents of the NSObject class object, which would require knowing a maximum size for its vtable, which may not be acceptable depending on how much freedom you all want for adding new members to NSObject in the future.

Since I cannot express generically an existential of the form 'This thing is Hashable but may belong to one of two different class hierarchies', any usage of NSObject in a Hashable context (e.g. dictionary key, which s-c-f is rife with) within swift-corelibs-foundation now needs to have additional as! casts to go to and from AnyHashable to accommodate a non-NSObject box. This makes decently-sized chunks of that codebase type unsafe, in the sense that it will shift correctness checking at runtime.

Note that NSObject as the key type on Darwin is already kind-of a lie. A Swift dictionary with keys of a Swift class type that's Hashable but not an NSObject subclass will still blindly bridge to [NSObject: AnyObject]. _SwiftObject quacks enough like an NSObject on Darwin that maybe you won't notice, but that issue might be more glaring on Linux.

@rudkx I have readded (and where necessary, reworked) the tests you pointed to. How does this look?

Please test with the following:
https://github.com/apple/swift-corelibs-foundation/pull/1526
@swift-ci please smoke test

@eeckstein @gottesmm How do we want to proceed with benchmarks? After landing?

I am pretty close. Let me see what I can do tonight.

@gottesmm Thank you so much for the after hours help!

Got it to work. I am going to go grab a coffee/upstream. It is slightly manual (it is an external build), but I have a script that you just need to pass in the args and it will just work.

@gottesmm Thanks! I’ll sync up with you after the holiday.

Please test with the following:
https://github.com/apple/swift-corelibs-foundation/pull/1526
@swift-ci please smoke benchmark

Please test with the following:
https://github.com/apple/swift-corelibs-foundation/pull/1526
@swift-ci please smoke test

@eeckstein @gottesmm Benchmarks have been taken:
perf-patch-applied.txt
perf-master-baseline.txt
These benchmarks include the fixes I just pushed, which prevented a large slowdown in AnyHashable tests. Some slowdowns are expected; as a summary, the following tests have a slowdown over 10%:

TEST
SLOWDOWN

AnyHashableWithAClass
1.80

ArrayAppend
2.60

ArrayAppendAscii
1.17

CStringLongAscii
1.23

CStringLongNonAscii
1.11

CharacterPropertiesFetch
1.21

DataAppendArray
1.18

DataAppendBytes
1.25

DataAppendDataMediumToMedium
1.20

DataAppendDataSmallToMedium
1.25

DictionarySwapAt
1.16

DropLastSequence
1.12

DropLastSequenceLazy
1.12

MapReduceShort
1.13

SortStringsUnicode
1.12

StringWithCString
1.22

Numbers have been generated by merging https://github.com/apple/swift/pull/16882 and running:
utils/build-script --preset="buildbot_linux,no_test" install_destdir=~/Install/root installable_package=~/Install/archive
benchmark/scripts/build_linux.py `which cmake` ~/Developer/Sources/Swift/swift ~/Developer/Sources/Swift/build/buildbot_linux/llvm-linux-x86_64/bin/clang ~/Install/root/usr ~/Install/benchmark --clean
~/Install/benchmark/bin/Benchmark_O --num-samples=5

I am at this point really inclined to investigate these as a follow-up; is that ok with you?

(an enormous thank you to @gottesmm for his timely work on https://github.com/apple/swift/pull/16882.)

Build comment file:
Optimized (O)

Regression (9)

TEST
OLD
NEW
DELTA
SPEEDUP

StringBuilderWithLongSubstring
1466
1690
+15.3%
0.87x (?)

ReversedBidirectional
16744
18899
+12.9%
0.89x (?)

FloatingPointPrinting_Float_interpolated
39871
44505
+11.6%
0.90x

CharIndexing_tweet_unicodeScalars
33456
36858
+10.2%
0.91x

ObjectiveCBridgeFromNSArrayAnyObjectToStringForced
43710
47803
+9.4%
0.91x (?)

DataCopyBytes
471
510
+8.3%
0.92x (?)

ObjectiveCBridgeFromNSArrayAnyObjectForced
4817
5198
+7.9%
0.93x (?)

DataAppendDataSmallToSmall
5766
6190
+7.4%
0.93x (?)

DropWhileAnySeqCRangeIter
21243
22596
+6.4%
0.94x

Improvement (12)

TEST
OLD
NEW
DELTA
SPEEDUP

StringBuilderLong
1716
1252
-27.0%
1.37x (?)

ArrayAppendAscii
4514
3949
-12.5%
1.14x (?)

PopFrontUnsafePointer
9666
8765
-9.3%
1.10x (?)

ObjectiveCBridgeFromNSArrayAnyObjectToString
50769
46078
-9.2%
1.10x (?)

DropLastAnySeqCntRange
14
13
-7.1%
1.08x

DropLastAnySeqCntRangeLazy
14
13
-7.1%
1.08x

ObjectiveCBridgeStubToNSDate
16298
15276
-6.3%
1.07x (?)

CharIndexing_chinese_unicodeScalars
13969
13120
-6.1%
1.06x (?)

ObjectiveCBridgeFromNSDictionaryAnyObject
116593
109860
-5.8%
1.06x (?)

ObjectiveCBridgeFromNSSetAnyObjectForced
5702
5408
-5.2%
1.05x (?)

NSDictionaryCastToSwift
7230
6871
-5.0%
1.05x (?)

DataAppendArray
5530
5263
-4.8%
1.05x

No Changes (417)

TEST
OLD
NEW
DELTA
SPEEDUP

AngryPhonebook
4248
4122
-3.0%
1.03x (?)

AnyHashableWithAClass
85921
86555
+0.7%
0.99x

Array2D
2850
2854
+0.1%
1.00x (?)

ArrayAppend
1081
1078
-0.3%
1.00x (?)

ArrayAppendArrayOfInt
789
798
+1.1%
0.99x (?)

ArrayAppendAsciiSubstring
24241
24246
+0.0%
1.00x (?)

ArrayAppendFromGeneric
794
800
+0.8%
0.99x (?)

ArrayAppendGenericStructs
1425
1428
+0.2%
1.00x (?)

ArrayAppendLatin1
41379
41316
-0.2%
1.00x

ArrayAppendLatin1Substring
141877
141706
-0.1%
1.00x (?)

ArrayAppendLazyMap
1344
1342
-0.1%
1.00x (?)

ArrayAppendOptionals
1428
1427
-0.1%
1.00x (?)

ArrayAppendRepeatCol
1329
1338
+0.7%
0.99x (?)

ArrayAppendReserved
812
813
+0.1%
1.00x (?)

ArrayAppendSequence
1121
1121
+0.0%
1.00x

ArrayAppendStrings
6213
6213
+0.0%
1.00x

ArrayAppendToFromGeneric
799
798
-0.1%
1.00x (?)

ArrayAppendToGeneric
789
784
-0.6%
1.01x (?)

ArrayAppendUTF16
41027
41013
-0.0%
1.00x (?)

ArrayAppendUTF16Substring
139440
140294
+0.6%
0.99x

ArrayInClass
86
86
+0.0%
1.00x

ArrayLiteral
0
0
+0.0%
1.00x

ArrayOfGenericPOD2
151
151
+0.0%
1.00x

ArrayOfGenericRef
4496
4500
+0.1%
1.00x

ArrayOfPOD
183
184
+0.5%
0.99x

ArrayOfRef
4400
4428
+0.6%
0.99x (?)

ArrayPlusEqualArrayOfInt
796
796
+0.0%
1.00x

ArrayPlusEqualFiveElementCollection
5452
5458
+0.1%
1.00x (?)

ArrayPlusEqualSingleElementCollection
1080
1084
+0.4%
1.00x (?)

ArrayPlusEqualThreeElements
1668
1658
-0.6%
1.01x (?)

ArraySubscript
1535
1533
-0.1%
1.00x (?)

ArrayValueProp
8
8
+0.0%
1.00x

ArrayValueProp2
8
8
+0.0%
1.00x

ArrayValueProp3
8
8
+0.0%
1.00x

ArrayValueProp4
8
8
+0.0%
1.00x

BinaryFloatingPointPropertiesBinade
31
31
+0.0%
1.00x

BinaryFloatingPointPropertiesNextUp
28
28
+0.0%
1.00x

BinaryFloatingPointPropertiesUlp
37
37
+0.0%
1.00x

BitCount
211
212
+0.5%
1.00x

ByteSwap
105
105
+0.0%
1.00x

COWArrayGuaranteedParameterOverhead
9819
9805
-0.1%
1.00x (?)

COWTree
5322
5365
+0.8%
0.99x (?)

CSVParsing
667267
660841
-1.0%
1.01x (?)

CSVParsingAlt
806841
801865
-0.6%
1.01x (?)

CSVParsingAltIndices
339715
339907
+0.1%
1.00x (?)

CStringLongAscii
4207
4208
+0.0%
1.00x (?)

CStringLongNonAscii
2440
2438
-0.1%
1.00x (?)

CStringShortAscii
3348
3345
-0.1%
1.00x (?)

Calculator
317
316
-0.3%
1.00x (?)

CaptureProp
4129
4128
-0.0%
1.00x (?)

ChainedFilterMap
1247
1247
+0.0%
1.00x

CharIndexing_ascii_unicodeScalars
17551
17286
-1.5%
1.02x (?)

CharIndexing_ascii_unicodeScalars_Backwards
16851
16833
-0.1%
1.00x (?)

CharIndexing_chinese_unicodeScalars_Backwards
12759
12760
+0.0%
1.00x (?)

CharIndexing_japanese_unicodeScalars
21249
20754
-2.3%
1.02x (?)

CharIndexing_japanese_unicodeScalars_Backwards
20274
20222
-0.3%
1.00x (?)

CharIndexing_korean_unicodeScalars
16761
16814
+0.3%
1.00x (?)

CharIndexing_korean_unicodeScalars_Backwards
16317
16392
+0.5%
1.00x

CharIndexing_punctuatedJapanese_unicodeScalars
3116
3116
+0.0%
1.00x

CharIndexing_punctuatedJapanese_unicodeScalars_Backwards
3046
3175
+4.2%
0.96x

CharIndexing_punctuated_unicodeScalars
4094
3934
-3.9%
1.04x (?)

CharIndexing_punctuated_unicodeScalars_Backwards
3800
3800
+0.0%
1.00x

CharIndexing_russian_unicodeScalars
14872
14424
-3.0%
1.03x (?)

CharIndexing_russian_unicodeScalars_Backwards
14051
14045
-0.0%
1.00x (?)

CharIndexing_tweet_unicodeScalars_Backwards
32940
32981
+0.1%
1.00x (?)

CharIndexing_utf16_unicodeScalars
23200
23675
+2.0%
0.98x (?)

CharIndexing_utf16_unicodeScalars_Backwards
23418
23420
+0.0%
1.00x (?)

CharIteration_ascii_unicodeScalars
21762
21779
+0.1%
1.00x

CharIteration_ascii_unicodeScalars_Backwards
15189
15201
+0.1%
1.00x

CharIteration_chinese_unicodeScalars
16456
16472
+0.1%
1.00x (?)

CharIteration_chinese_unicodeScalars_Backwards
11509
11514
+0.0%
1.00x (?)

CharIteration_japanese_unicodeScalars
26067
26084
+0.1%
1.00x

CharIteration_japanese_unicodeScalars_Backwards
18179
18180
+0.0%
1.00x (?)

CharIteration_korean_unicodeScalars
21122
21100
-0.1%
1.00x

CharIteration_korean_unicodeScalars_Backwards
14821
14746
-0.5%
1.01x

CharIteration_punctuatedJapanese_unicodeScalars
3888
3886
-0.1%
1.00x (?)

CharIteration_punctuatedJapanese_unicodeScalars_Backwards
2757
2771
+0.5%
0.99x

CharIteration_punctuated_unicodeScalars
4885
4883
-0.0%
1.00x (?)

CharIteration_punctuated_unicodeScalars_Backwards
3449
3444
-0.1%
1.00x (?)

CharIteration_russian_unicodeScalars
18123
18132
+0.0%
1.00x (?)

CharIteration_russian_unicodeScalars_Backwards
12678
12658
-0.2%
1.00x (?)

CharIteration_tweet_unicodeScalars
43030
43023
-0.0%
1.00x (?)

CharIteration_tweet_unicodeScalars_Backwards
30059
30092
+0.1%
1.00x (?)

CharIteration_utf16_unicodeScalars
28041
28069
+0.1%
1.00x (?)

CharIteration_utf16_unicodeScalars_Backwards
18593
18582
-0.1%
1.00x (?)

CharacterLiteralsLarge
5942
5882
-1.0%
1.01x (?)

CharacterLiteralsSmall
217
217
+0.0%
1.00x

CharacterPropertiesFetch
4579
4615
+0.8%
0.99x (?)

CharacterPropertiesPrecomputed
1106
1106
+0.0%
1.00x

CharacterPropertiesStashed
1461
1456
-0.3%
1.00x

CharacterPropertiesStashedMemo
1545
1547
+0.1%
1.00x (?)

Chars
1217
1218
+0.1%
1.00x (?)

ClassArrayGetter
15
15
+0.0%
1.00x

Combos
488
488
+0.0%
1.00x

DataAccessBytes
1146
1147
+0.1%
1.00x (?)

DataAppendBytes
4915
4959
+0.9%
0.99x (?)

DataAppendDataLargeToLarge
68543
69513
+1.4%
0.99x (?)

DataAppendDataLargeToMedium
35545
35737
+0.5%
0.99x (?)

DataAppendDataLargeToSmall
34726
34356
-1.1%
1.01x (?)

DataAppendDataMediumToLarge
37834
37939
+0.3%
1.00x (?)

DataAppendDataMediumToMedium
6886
6845
-0.6%
1.01x (?)

DataAppendDataMediumToSmall
6015
5980
-0.6%
1.01x (?)

DataAppendDataSmallToLarge
37507
37850
+0.9%
0.99x (?)

DataAppendDataSmallToMedium
6395
6217
-2.8%
1.03x (?)

DataAppendSequence
7287679
7623700
+4.6%
0.96x (?)

DataCount
34
34
+0.0%
1.00x

DataMutateBytes
3863
3960
+2.5%
0.98x (?)

DataReplaceLarge
37470
36661
-2.2%
1.02x (?)

DataReplaceLargeBuffer
57376
57394
+0.0%
1.00x (?)

DataReplaceMedium
7975
7805
-2.1%
1.02x (?)

DataReplaceMediumBuffer
11786
12048
+2.2%
0.98x (?)

DataReplaceSmall
5795
5773
-0.4%
1.00x (?)

DataReplaceSmallBuffer
8648
8626
-0.3%
1.00x (?)

DataReset
2963
2919
-1.5%
1.02x (?)

DataSetCount
551
563
+2.2%
0.98x (?)

DataSubscript
220
220
+0.0%
1.00x

DictOfArraysToArrayOfDicts
805
789
-2.0%
1.02x (?)

Dictionary
520
521
+0.2%
1.00x (?)

Dictionary2
638
639
+0.2%
1.00x (?)

Dictionary2OfObjects
2075
2077
+0.1%
1.00x (?)

Dictionary3
231
229
-0.9%
1.01x

Dictionary3OfObjects
735
735
+0.0%
1.00x

Dictionary4
340
340
+0.0%
1.00x

Dictionary4Legacy
724
724
+0.0%
1.00x

Dictionary4OfObjects
454
455
+0.2%
1.00x

Dictionary4OfObjectsLegacy
937
937
+0.0%
1.00x

DictionaryBridge
1223
1214
-0.7%
1.01x (?)

DictionaryCopy
107553
106185
-1.3%
1.01x

DictionaryFilter
107230
106966
-0.2%
1.00x (?)

DictionaryGroup
217
215
-0.9%
1.01x

DictionaryGroupOfObjects
2140
2131
-0.4%
1.00x (?)

DictionaryKeysContainsCocoa
39
39
+0.0%
1.00x

DictionaryKeysContainsNative
32
32
+0.0%
1.00x

DictionaryLiteral
1907
1906
-0.1%
1.00x (?)

DictionaryOfObjects
2375
2383
+0.3%
1.00x (?)

DictionaryRemove
4173
4184
+0.3%
1.00x (?)

DictionaryRemoveOfObjects
25919
25957
+0.1%
1.00x (?)

DictionarySubscriptDefaultMutation
265
265
+0.0%
1.00x

DictionarySubscriptDefaultMutationArray
619
619
+0.0%
1.00x

DictionarySubscriptDefaultMutationArrayOfObjects
4024
4048
+0.6%
0.99x (?)

DictionarySubscriptDefaultMutationOfObjects
1728
1725
-0.2%
1.00x (?)

DictionarySwap
1042
1043
+0.1%
1.00x (?)

DictionarySwapAt
6697
6652
-0.7%
1.01x (?)

DictionarySwapAtOfObjects
52534
52315
-0.4%
1.00x (?)

DictionarySwapOfObjects
8849
9002
+1.7%
0.98x

DoubleWidthDivision
0
0
+0.0%
1.00x

DropFirstAnyCollection
84
84
+0.0%
1.00x

DropFirstAnyCollectionLazy
69499
68994
-0.7%
1.01x (?)

DropFirstAnySeqCRangeIter
27147
26997
-0.6%
1.01x

DropFirstAnySeqCRangeIterLazy
27115
27081
-0.1%
1.00x (?)

DropFirstAnySeqCntRange
41
41
+0.0%
1.00x

DropFirstAnySeqCntRangeLazy
41
41
+0.0%
1.00x

DropFirstAnySequence
4953
4940
-0.3%
1.00x (?)

DropFirstAnySequenceLazy
4951
4937
-0.3%
1.00x (?)

DropLastAnyCollection
31
31
+0.0%
1.00x

DropLastAnyCollectionLazy
22797
22825
+0.1%
1.00x (?)

DropLastAnySeqCRangeIter
3527
3528
+0.0%
1.00x (?)

DropLastAnySeqCRangeIterLazy
3611
3520
-2.5%
1.03x (?)

DropLastAnySequence
4930
4926
-0.1%
1.00x (?)

DropLastAnySequenceLazy
5022
5027
+0.1%
1.00x (?)

DropLastCountableRange
11
11
+0.0%
1.00x

DropLastCountableRangeLazy
12
12
+0.0%
1.00x

DropLastSequence
664
667
+0.5%
1.00x (?)

DropLastSequenceLazy
666
666
+0.0%
1.00x

DropWhileAnyCollection
107
107
+0.0%
1.00x

DropWhileAnyCollectionLazy
125
125
+0.0%
1.00x

DropWhileAnySeqCRangeIterLazy
125
125
+0.0%
1.00x

DropWhileAnySeqCntRange
50
50
+0.0%
1.00x

DropWhileAnySeqCntRangeLazy
125
125
+0.0%
1.00x

DropWhileAnySequence
4838
4841
+0.1%
1.00x (?)

DropWhileAnySequenceLazy
1857
1857
+0.0%
1.00x

DropWhileArrayLazy
88
88
+0.0%
1.00x

DropWhileCountableRange
36
36
+0.0%
1.00x

DropWhileCountableRangeLazy
105
105
+0.0%
1.00x

DropWhileSequence
2224
2225
+0.0%
1.00x (?)

DropWhileSequenceLazy
88
88
+0.0%
1.00x

EqualStringSubstring
50
50
+0.0%
1.00x

EqualSubstringString
49
49
+0.0%
1.00x

EqualSubstringSubstring
49
49
+0.0%
1.00x

EqualSubstringSubstringGenericEquatable
49
49
+0.0%
1.00x

ErrorHandling
1180
1188
+0.7%
0.99x

ExclusivityGlobal
5
5
+0.0%
1.00x

ExclusivityIndependent
2
2
+0.0%
1.00x

FatCompactMap
199412
199231
-0.1%
1.00x

FilterEvenUsingReduce
1310
1310
+0.0%
1.00x

FilterEvenUsingReduceInto
147
147
+0.0%
1.00x

FloatingPointPrinting_Double_description_small
23850
23703
-0.6%
1.01x (?)

FloatingPointPrinting_Double_description_uniform
23080
23047
-0.1%
1.00x (?)

FloatingPointPrinting_Double_interpolated
65592
64978
-0.9%
1.01x (?)

FloatingPointPrinting_Float80_description_small
30453
30354
-0.3%
1.00x (?)

FloatingPointPrinting_Float80_description_uniform
29602
29536
-0.2%
1.00x

FloatingPointPrinting_Float80_interpolated
68954
68627
-0.5%
1.00x (?)

FloatingPointPrinting_Float_description_small
5443
5441
-0.0%
1.00x (?)

FloatingPointPrinting_Float_description_uniform
5350
5355
+0.1%
1.00x (?)

FrequenciesUsingReduce
5012
5012
+0.0%
1.00x

FrequenciesUsingReduceInto
1532
1524
-0.5%
1.01x (?)

Hanoi
2164
2168
+0.2%
1.00x (?)

HashTest
961
959
-0.2%
1.00x (?)

Histogram
705
705
+0.0%
1.00x

Integrate
335
334
-0.3%
1.00x

IterateData
1665
1666
+0.1%
1.00x

Join
169
170
+0.6%
0.99x (?)

LazilyFilteredArrayContains
36268
36271
+0.0%
1.00x (?)

LazilyFilteredArrays
66970
64907
-3.1%
1.03x (?)

LazilyFilteredRange
3733
3735
+0.1%
1.00x (?)

LessSubstringSubstring
49
49
+0.0%
1.00x

LessSubstringSubstringGenericComparable
49
49
+0.0%
1.00x

LinkedList
7658
7611
-0.6%
1.01x

LuhnAlgoEager
436
444
+1.8%
0.98x

LuhnAlgoLazy
441
447
+1.4%
0.99x

MapReduce
398
398
+0.0%
1.00x

MapReduceAnyCollection
429
429
+0.0%
1.00x

MapReduceAnyCollectionShort
2233
2232
-0.0%
1.00x (?)

MapReduceClass
3011
3011
+0.0%
1.00x

MapReduceClassShort
4624
4627
+0.1%
1.00x

MapReduceLazyCollection
13
13
+0.0%
1.00x

MapReduceLazyCollectionShort
34
34
+0.0%
1.00x

MapReduceLazySequence
86
86
+0.0%
1.00x

MapReduceSequence
453
453
+0.0%
1.00x

MapReduceShort
1991
1990
-0.1%
1.00x (?)

MapReduceShortString
21
21
+0.0%
1.00x

MapReduceString
48
48
+0.0%
1.00x

Memset
216
219
+1.4%
0.99x (?)

MonteCarloE
10238
10237
-0.0%
1.00x (?)

MonteCarloPi
42783
42777
-0.0%
1.00x (?)

NSError
170
171
+0.6%
0.99x (?)

NSStringConversion
698
699
+0.1%
1.00x

NibbleSort
3670
3669
-0.0%
1.00x (?)

NopDeinit
30232
30190
-0.1%
1.00x

ObjectAllocation
132
133
+0.8%
0.99x (?)

ObjectiveCBridgeFromNSArrayAnyObject
25974
27023
+4.0%
0.96x (?)

ObjectiveCBridgeFromNSSetAnyObject
52145
52232
+0.2%
1.00x (?)

ObjectiveCBridgeFromNSSetAnyObjectToString
65028
66761
+2.7%
0.97x

ObjectiveCBridgeFromNSString
1184
1187
+0.3%
1.00x (?)

ObjectiveCBridgeFromNSStringForced
2702
2693
-0.3%
1.00x (?)

ObjectiveCBridgeStubDataAppend
6249
6396
+2.4%
0.98x (?)

ObjectiveCBridgeStubDateMutation
401
401
+0.0%
1.00x

ObjectiveCBridgeStubFromArrayOfNSString
36172
35953
-0.6%
1.01x (?)

ObjectiveCBridgeStubFromNSDate
7159
7161
+0.0%
1.00x (?)

ObjectiveCBridgeStubFromNSString
1035
1034
-0.1%
1.00x (?)

ObjectiveCBridgeStubFromNSStringRef
161
161
+0.0%
1.00x

ObjectiveCBridgeStubNSDataAppend
2579
2648
+2.7%
0.97x (?)

ObjectiveCBridgeStubNSDateMutationRef
13535
13729
+1.4%
0.99x (?)

ObjectiveCBridgeStubToArrayOfNSString
39352
40292
+2.4%
0.98x (?)

ObjectiveCBridgeStubToNSDateRef
3486
3458
-0.8%
1.01x

ObjectiveCBridgeStubToNSString
2386
2382
-0.2%
1.00x (?)

ObjectiveCBridgeStubToNSStringRef
116
116
+0.0%
1.00x

ObjectiveCBridgeStubURLAppendPath
290601
294287
+1.3%
0.99x (?)

ObjectiveCBridgeStubURLAppendPathRef
291354
300844
+3.3%
0.97x (?)

ObjectiveCBridgeToNSArray
15402
15292
-0.7%
1.01x (?)

ObjectiveCBridgeToNSDictionary
25806
26824
+3.9%
0.96x (?)

ObjectiveCBridgeToNSSet
17384
17361
-0.1%
1.00x (?)

ObjectiveCBridgeToNSString
486
486
+0.0%
1.00x

ObserverClosure
2156
2199
+2.0%
0.98x (?)

ObserverForwarderStruct
1262
1259
-0.2%
1.00x (?)

ObserverPartiallyAppliedMethod
3722
3713
-0.2%
1.00x (?)

ObserverUnappliedMethod
2526
2553
+1.1%
0.99x (?)

OpaqueConsumingUsers
4183
4182
-0.0%
1.00x (?)

OpenClose
65
65
+0.0%
1.00x

PartialApplyDynamicType
0
0
+0.0%
1.00x

Phonebook
6836
6841
+0.1%
1.00x (?)

PointerArithmetics
31495
31511
+0.1%
1.00x (?)

PolymorphicCalls
25
25
+0.0%
1.00x

PopFrontArray
1985
1987
+0.1%
1.00x (?)

PopFrontArrayGeneric
2014
1975
-1.9%
1.02x (?)

PrefixAnyCollection
84
84
+0.0%
1.00x

PrefixAnyCollectionLazy
68978
68993
+0.0%
1.00x (?)

PrefixAnySeqCRangeIter
20808
20833
+0.1%
1.00x (?)

PrefixAnySeqCRangeIterLazy
20826
20905
+0.4%
1.00x (?)

PrefixAnySeqCntRange
28
28
+0.0%
1.00x

PrefixAnySeqCntRangeLazy
28
28
+0.0%
1.00x

PrefixAnySequence
4336
4333
-0.1%
1.00x (?)

PrefixAnySequenceLazy
4336
4337
+0.0%
1.00x (?)

PrefixSequenceLazy
2278
2276
-0.1%
1.00x (?)

PrefixWhileAnyCollection
154
154
+0.0%
1.00x

PrefixWhileAnyCollectionLazy
90
90
+0.0%
1.00x

PrefixWhileAnySeqCRangeIter
8702
8818
+1.3%
0.99x

PrefixWhileAnySeqCRangeIterLazy
72
72
+0.0%
1.00x

PrefixWhileAnySeqCntRange
60
60
+0.0%
1.00x

PrefixWhileAnySeqCntRangeLazy
90
90
+0.0%
1.00x

PrefixWhileAnySequence
9790
9838
+0.5%
1.00x (?)

PrefixWhileAnySequenceLazy
1393
1392
-0.1%
1.00x

PrefixWhileArray
88
88
+0.0%
1.00x

PrefixWhileArrayLazy
70
70
+0.0%
1.00x

PrefixWhileCountableRange
36
36
+0.0%
1.00x

PrefixWhileCountableRangeLazy
35
35
+0.0%
1.00x

PrefixWhileSequence
364
363
-0.3%
1.00x

PrefixWhileSequenceLazy
52
52
+0.0%
1.00x

Prims
899
905
+0.7%
0.99x (?)

PrimsSplit
914
915
+0.1%
1.00x (?)

QueueConcrete
1147
1149
+0.2%
1.00x (?)

QueueGeneric
1148
1149
+0.1%
1.00x (?)

RC4
166
166
+0.0%
1.00x

RGBHistogram
3221
3240
+0.6%
0.99x (?)

RGBHistogramOfObjects
23781
23704
-0.3%
1.00x (?)

RandomDoubleDef
27891
27857
-0.1%
1.00x (?)

RandomDoubleLCG
4413
4414
+0.0%
1.00x (?)

RandomIntegersDef
25491
25455
-0.1%
1.00x (?)

RandomIntegersLCG
2294
2295
+0.0%
1.00x (?)

RandomShuffleDef
828980
829564
+0.1%
1.00x (?)

RandomShuffleLCG
156095
153820
-1.5%
1.01x (?)

RangeAssignment
337
338
+0.3%
1.00x (?)

RangeIterationSigned
200
200
+0.0%
1.00x

RangeReplaceableCollectionPlusDefault
1012
1012
+0.0%
1.00x

RecursiveOwnedParameter
115
115
+0.0%
1.00x

RemoveWhereFilterInts
46
46
+0.0%
1.00x

RemoveWhereFilterString
251
251
+0.0%
1.00x

RemoveWhereFilterStrings
438
439
+0.2%
1.00x

RemoveWhereMoveInts
15
15
+0.0%
1.00x

RemoveWhereMoveStrings
712
710
-0.3%
1.00x

RemoveWhereQuadraticInts
1296
1298
+0.2%
1.00x (?)

RemoveWhereQuadraticString
385
382
-0.8%
1.01x

RemoveWhereQuadraticStrings
2762
2780
+0.7%
0.99x

RemoveWhereSwapInts
19
19
+0.0%
1.00x

RemoveWhereSwapStrings
862
861
-0.1%
1.00x

ReversedArray
57
57
+0.0%
1.00x

ReversedDictionary
270
271
+0.4%
1.00x (?)

RomanNumbers
82711
82599
-0.1%
1.00x (?)

SequenceAlgosAnySequence
15424
15380
-0.3%
1.00x (?)

SequenceAlgosArray
1579
1580
+0.1%
1.00x (?)

SequenceAlgosContiguousArray
1583
1581
-0.1%
1.00x

SequenceAlgosList
1359
1358
-0.1%
1.00x

SequenceAlgosRange
2578
2578
+0.0%
1.00x

SequenceAlgosUnfoldSequence
1103
1103
+0.0%
1.00x

SetExclusiveOr
5198
5190
-0.2%
1.00x (?)

SetExclusiveOr_OfObjects
11733
11760
+0.2%
1.00x (?)

SetIntersect
699
697
-0.3%
1.00x (?)

SetIntersect_OfObjects
1757
1760
+0.2%
1.00x (?)

SetIsSubsetOf
355
354
-0.3%
1.00x

SetIsSubsetOf_OfObjects
454
454
+0.0%
1.00x

SetUnion
4432
4440
+0.2%
1.00x (?)

SetUnion_OfObjects
10108
10130
+0.2%
1.00x (?)

SevenBoom
872
878
+0.7%
0.99x (?)

Sim2DArray
599
599
+0.0%
1.00x

SortLargeExistentials
5477
5473
-0.1%
1.00x (?)

SortLettersInPlace
989
991
+0.2%
1.00x (?)

SortSortedStrings
868
870
+0.2%
1.00x

SortStrings
1777
1777
+0.0%
1.00x

SortStringsUnicode
2614
2612
-0.1%
1.00x (?)

StackPromo
24770
24725
-0.2%
1.00x (?)

StaticArray
10
10
+0.0%
1.00x

StrComplexWalk
1776
1776
+0.0%
1.00x

StrToInt
3193
3187
-0.2%
1.00x (?)

StringAdder
577
577
+0.0%
1.00x

StringBuilder
559
559
+0.0%
1.00x

StringBuilderSmallReservingCapacity
579
579
+0.0%
1.00x

StringComparison_abnormal
780
785
+0.6%
0.99x

StringComparison_ascii
1034
1034
+0.0%
1.00x

StringComparison_emoji
829
828
-0.1%
1.00x (?)

StringComparison_fastPrenormal
877
877
+0.0%
1.00x

StringComparison_latin1
687
687
+0.0%
1.00x

StringComparison_longSharedPrefix
960
959
-0.1%
1.00x (?)

StringComparison_nonBMPSlowestPrenormal
1615
1613
-0.1%
1.00x (?)

StringComparison_slowerPrenormal
1718
1719
+0.1%
1.00x (?)

StringComparison_zalgo
127194
126535
-0.5%
1.01x (?)

StringEdits
184806
178807
-3.2%
1.03x

StringEnumRawValueInitialization
856
854
-0.2%
1.00x

StringEqualPointerComparison
304
305
+0.3%
1.00x

StringFromLongWholeSubstring
22
22
+0.0%
1.00x

StringFromLongWholeSubstringGeneric
21
21
+0.0%
1.00x

StringHasPrefixAscii
2233
2234
+0.0%
1.00x (?)

StringHasPrefixUnicode
101605
101535
-0.1%
1.00x (?)

StringHasSuffixAscii
2320
2319
-0.0%
1.00x

StringHasSuffixUnicode
101046
100987
-0.1%
1.00x (?)

StringInterpolation
9681
9799
+1.2%
0.99x (?)

StringInterpolationManySmallSegments
18753
19056
+1.6%
0.98x (?)

StringInterpolationSmall
4257
4254
-0.1%
1.00x (?)

StringMatch
12869
12864
-0.0%
1.00x (?)

StringRemoveDupes
498
500
+0.4%
1.00x

StringUTF16Builder
2706
2690
-0.6%
1.01x (?)

StringUTF16SubstringBuilder
5976
5958
-0.3%
1.00x (?)

StringWalk
1437
1438
+0.1%
1.00x

StringWithCString
44938
44935
-0.0%
1.00x (?)

StringWordBuilder
2254
2248
-0.3%
1.00x (?)

StringWordBuilderReservingCapacity
1836
1832
-0.2%
1.00x (?)

SubstringComparable
13
13
+0.0%
1.00x

SubstringEqualString
615
612
-0.5%
1.00x (?)

SubstringEquatable
1407
1408
+0.1%
1.00x (?)

SubstringFromLongString
10
10
+0.0%
1.00x

SubstringFromLongStringGeneric
74
74
+0.0%
1.00x

SuffixAnyCollection
31
31
+0.0%
1.00x

SuffixAnyCollectionLazy
24017
23037
-4.1%
1.04x

SuffixAnySeqCRangeIter
3758
3761
+0.1%
1.00x (?)

SuffixAnySeqCRangeIterLazy
3755
3758
+0.1%
1.00x (?)

SuffixAnySeqCntRange
21
20
-4.8%
1.05x

SuffixAnySeqCntRangeLazy
21
21
+0.0%
1.00x

SuffixAnySequence
4916
4916
+0.0%
1.00x

SuffixAnySequenceLazy
5007
5016
+0.2%
1.00x (?)

SuffixCountableRange
11
11
+0.0%
1.00x

SuffixCountableRangeLazy
12
12
+0.0%
1.00x

SuffixSequence
3647
3648
+0.0%
1.00x (?)

SuffixSequenceLazy
3648
3648
+0.0%
1.00x

SumUsingReduce
102
102
+0.0%
1.00x

SumUsingReduceInto
97
97
+0.0%
1.00x

SuperChars
15508
15561
+0.3%
1.00x (?)

TwoSum
1494
1487
-0.5%
1.00x (?)

TypeFlood
0
0
+0.0%
1.00x

UTF8Decode
298
298
+0.0%
1.00x

Walsh
432
431
-0.2%
1.00x (?)

WordCountHistogramASCII
8081
8068
-0.2%
1.00x

WordCountHistogramUTF16
15076
15160
+0.6%
0.99x (?)

WordCountUniqueASCII
2110
2096
-0.7%
1.01x (?)

WordCountUniqueUTF16
8238
8147
-1.1%
1.01x

WordSplitASCII
6818
6840
+0.3%
1.00x (?)

WordSplitUTF16
8829
8909
+0.9%
0.99x (?)

XorLoop
402
401
-0.2%
1.00x (?)

Hardware Overview
  Model Name: Mac Pro
  Model Identifier: MacPro6,1
  Processor Name: 12-Core Intel Xeon E5
  Processor Speed: 2.7 GHz
  Number of Processors: 1
  Total Number of Cores: 12
  L2 Cache (per Core): 256 KB
  L3 Cache: 30 MB
  Memory: 64 GB

I am at this point really inclined to investigate these as a follow-up; is that ok with you?

Fine with me

Follow-ups I promised beyond @jckarter's:

https://bugs.swift.org/browse/SR-7816
https://bugs.swift.org/browse/SR-7815

Simultaneous merging with https://github.com/apple/swift-corelibs-foundation/pull/1526 imminent…

Simultaneous merging with https://github.com/apple/swift-corelibs-foundation/pull/1526 imminent…

Standing by for CI now.

@benlangmuir FYI, this has been merged; standing by for CI.


[FLINK-12624][table][sql] Make Flink case-insensitive to meta object names

What is the purpose of the change
Note that this is not a final PR. I'm testing it
This PR makes Flink case-insensitive to meta object names.
Currently Flink is case-sensitive to meta object names. For example, for table names, "t1" and "T1" are two distinct tables in Flink.
There are two main reasons to make Flink case-insensitive to such names.

To make it more user-friendly for SQL users. Most popular databases nowadays are case insensitive to meta object names, to tolerate user typos in SQL commands and reduce user friction
We chose Hive metastore as the main persistent catalog, and Hive metastore is case insensitive.

Brief change log

Change SQL parser lex from JAVA to MYSQL

Verifying this change
This change is a trivial rework / code cleanup without any test coverage.
(or)
This change is already covered by existing tests, such as (please describe tests).
(or)
This change added tests and can be verified as follows:
Does this pull request potentially affect one of the following parts:

Dependencies (does it add or upgrade a dependency): (no)
The public API, i.e., is any changed class annotated with @Public(Evolving): (no)
The serializers: (no)
The runtime per-record code paths (performance sensitive): (no)
Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Yarn/Mesos, ZooKeeper: (no)
The S3 file system connector: (no)

Documentation

Does this pull request introduce a new feature? (no)
If yes, how is the feature documented? (not applicable)

closing this for now


 However, when trying to check the trading days for the next year 2022, I ran into an error, with the defined end being later than the last available calendar date.
Please see the following code example, which triggers the error:
import exchange_calendars as ecal
cal_FRA = ecal.get_calendar("XFRA")
cal_XETR = ecal.get_calendar("XETR")

start, end = "2022-01-01", "2022-12-31"
df_trading_days_xetra =  pd.DataFrame((cal_XETR.trading_index(start, end, "24h", intervals=False)), columns=['Dates'])
print(df_trading_days_xetra)

This results in the following error
Traceback (most recent call last):   File "R:\Zentrale\ZB-S\Daten\S5\S52\AD\JL\python\python_eikon\join_test.py", line 63, in <module>     df_trading_days_xetra =  pd.DataFrame((cal_XETR.trading_index(start, end, "24h", intervals=False)), columns=['Dates'])   File "C:\Workspace\Python_Runtime\Envs\python_eikon\lib\site-packages\exchange_calendars\exchange_calendar.py", line 2347, in trading_index     start, end = self._parse_start_end_dates(start, end, parse)   File "C:\Workspace\Python_Runtime\Envs\python_eikon\lib\site-packages\exchange_calendars\exchange_calendar.py", line 1980, in _parse_start_end_dates     return parse_date(start, "start", self), parse_date(end, "end", self)   File "C:\Workspace\Python_Runtime\Envs\python_eikon\lib\site-packages\exchange_calendars\calendar_helpers.py", line 323, in parse_date     raise errors.DateOutOfBounds(calendar, ts, param_name) exchange_calendars.errors.DateOutOfBounds: Parameter end receieved as '2022-12-31 00:00:00+00:00' although cannot be later than the last session of calendar 'XETR' ('2022-12-29 00:00:00+00:00').
When changing the start date to days before 2022-12-28, the dataframe gets created without any issue.

Hi @hannes101.
By default, a calendar ends one year ahead of the current date. The trading index method has raised the error as end was passed as a date that's later than the calendar's last session (2022-12-29).
Just pass get_calendar's optional end parameter to define the calendar end as a session that's no earlier than the last date that you want to the index to cover. For example...
import exchange_calendars as xcals
cal = xcals.get_calendar("XETR", end="2023-01-15")  # for example
start, end = "2022-01-01", "2022-12-31"
index = cal.trading_index(start, end, "24h", intervals=False)

Thanks a lot for the quick response!


DIVER: Consistent verb use in the cli

get/set
list / ls
create / delete

Need to make a decision on which is the correct usage.

What about mirroring existing Docker conventions?
inspect for getting a resource
ls for listing
rm to delete
create to create
'set' would be implicit like diver ucp interlock --enable
Not sure about downloads (like client bundle and potentially support dump), download? pull (confusing as used for images mostly)? diver ucp client-bundle download? Seems fine?

Yeah, I'm still up in the air about naming as most of the container ecosystem tools use different verbs.
Docker = inspect / Kubectl = describe etc..
I'd started to standardise of create/delete/list/get/set but I'm happy to change to whatever people think is best :)


[SQL] change catalog references to datasource.

Is your feature request related to a problem?
We are going ahead with datasource name instead of catalog. The ask from this issue is to rename all the references of catalog to datasource.
What solution would you like?
A clear and concise description of what you want to happen.
What alternatives have you considered?
A clear and concise description of any alternative solutions or features you've considered.
Do you have any additional context?
Add any other context or screenshots about the feature request here.

Why not schema to comply with other DBs?

schema represents group of tables under a datasource.
datasource --> schema --> table is the heirarchy.
In order to not conflict with this project: https://github.com/opensearch-project/opensearch-catalog/blob/main/docs/catalog-rfc.md
we are changing catalog to datasource.

Thank you for clarifying details!


tryLogin() can't parse token

I followed readme.md to setup my app, and it woks until token returns.  It can't parse token and try login over and over again.
I found after loading document, the window.location.hash is disappear. so tryLogin is fail. please tell me How can I do ? Thank you.
private configureWithNewConfigApi() {

    this.oauthService.configure(authConfig);
    this.oauthService.tokenValidationHandler = new JwksValidationHandler();

    console.log('configureWithNewConfigApi', window.location);

    this.oauthService.loadDiscoveryDocument().then((doc) => {
        console.log('loadDiscoveryDocument', window.location);
        this.oauthService.tryLogin({
            onTokenReceived: context => {
                console.log('onTokenReceived:', context);
                this.authService.init();
            },
            onLoginError: (err) => {
                console.log('onLoginError:', err);
            }
        }).then(() => {
            if (!this.oauthService.hasValidIdToken() || !this.oauthService.hasValidAccessToken()) {
                this.oauthService.initImplicitFlow();
            }
        });
    });
}

I am facing the same error here guys.
It is related to this issue.
Angular router actually strips out the query string params and when the oauthService got instantiated is too late to retrieve the token.
Possible strategies could be:

store the access_token inside a very first entrypoint of the app. In this case we should be able to call the storeAccessTokenResponse from an "outside component" (the method needs to be public in the case...)
once we've stored access_token in the very first entrypoint in some way, we can call tryLogin(<access_token>). In this case the tryLogin method needs to accept a param.

@manfredsteyer any advices on this topic?

@AndreaPaciolla
Here is my current solution.
    const hash = window.location.hash;

    this.oauthService.loadDiscoveryDocument().then((doc) => {

        this.oauthService.tryLogin({
            customHashFragment: hash,
            onTokenReceived: context => {
                this.oauthService.loadUserProfile().then((userInfo) => {
                    this.init((<UserInfo>userInfo));
                    this.router.navigate(['/']);
                });
            },
            onLoginError: (err) => {
                this.logger.log('onLoginError:', err);
            }
        }).then(() => {
            if (!this.oauthService.hasValidIdToken() || !this.oauthService.hasValidAccessToken()) {
                this.oauthService.initImplicitFlow();
            }
        });
    });

Yes @alonstar for now that seems to be the way. Thank you

Thx for this. I think turning off initial routing, like shown here [1] should also do the job.
Perhaps adding a catch all route (path: '**') at the end of the AppModule's routing table also helps.
Btw: There is a new convenince method that does almost what your method does. It's called loadDiscoveryDocumentAndLogin (not to be confused with loadDiscoveryDocumentAndTryLogin). See also my comment in #179 for this.
[1] https://manfredsteyer.github.io/angular-oauth2-oidc/angular-oauth2-oidc/docs/additional-documentation/routing-with-the-hashstrategy.html

Thanks for your suggestions @manfredsteyer.
Just a clarification about:

Perhaps adding a catch all route (path: '**') at the end of the AppModule's routing table also helps.

That could be the case when ** is not already used for 404 component, as in my context.


How to dim view

Hi,
is it possible to dim background (self.view not popTipView)?

I'm also interested in this.


fix max-height, min-height bug for text component

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.


Importer Doesn't Import Rules

So I tried using the rules importer after updating the osx-attacks.conf pack by hand:

The results created a pack named imported but didn't upload any queries:

I don't think this is expected.

Hi,
I have the same issue too.
Thanks.
Best regards.


Rentrancy model

For #7 interrupt support:

[x] Make parent jump buf a local variable of operator(), so that re-entry to that function can be unwound correctly (bodge it into yield() for now using a pointer as a member of the class).
[x] Undo above bodge by implementing re-enterer-saves for the pointer in operator() (need to split out a run_iteration() due to #18)
[ ] In child states, split RUNNING into RUNNING and RUNNABLE. RUNNING when actually running child (and not reenterable) and other states only when safely re-enterable.

So, -> RUNNING should be first of a sequence of updates to child state variables, and RUNNING -> should be last after a sequence of reads. Maybe it should be BUSY instead, to better convey the idea of "please don't touch".

Was crashing while trying to run enabler re-enter before the longjmp to parent. So moved to end of operator() and took out some of the re-entrancy stuff. Now cannot use eg get_current in enabler (but can still capture it by value).

see new example hopping.ino


Add CsvHandler

Thanks but I don't really see the point of this when we have JSON and other more powerful formats available.. So I would rather suggest that you publish this as a third party handler package and add it to https://github.com/Seldaek/monolog/wiki/Third-Party-Packages

The point to have a CsvHandler is to be able to store directly those files via a "load data infile". Files can be written down a SSD and consumed later to be treated in SQL database for analysis. I would do a Third party app but I need a fix in StreamHandler to keep it clean. May I create another PR with this fix only?

Yeah I am fine with the StreamHandler patch, but I think you should rather pass $record to streamWrite() to give more flexibility instead of passing only the formatted part to it.

Also create the PR against the 1.x branch otherwise it'll be only for monolog 2.0 which is not yet stable :)


use lora_modulation types for SF, BW, CR

Note that making the codr field an Option in TxPk will break clients of this library right?

Yes, fair point! I've bumped the version from 0.11 to 0.12 since we're sub 1.0. This was a result of CodingRate previously have CodingRate::OFF as a setting which IMO is better expressed as a None situation combined with the exhausted CodingRates of lora-modulation.
I can't merge despite the approval, but please feel free to squash and merge when you see fit!

There's a handful of other API changes anyway too removing the "get" verb from the getters


run_classifier.py gets struck while saving checkpoint

INFO:tensorflow:  name = bert/encoder/layer_23/output/LayerNorm/gamma:0, shape = (1024,), INIT_FROM_CKPT
INFO:tensorflow:  name = bert/pooler/dense/kernel:0, shape = (1024, 1024), INIT_FROM_CKPT
INFO:tensorflow:  name = bert/pooler/dense/bias:0, shape = (1024,), INIT_FROM_CKPT
INFO:tensorflow:  name = output_weights:0, shape = (2, 1024)
INFO:tensorflow:  name = output_bias:0, shape = (2,)
INFO:tensorflow:Done calling model_fn.
INFO:tensorflow:Create CheckpointSaverHook.
INFO:tensorflow:Graph was finalized.
INFO:tensorflow:Restoring parameters from output/model.ckpt-0
INFO:tensorflow:Running local_init_op.
INFO:tensorflow:Done running local_init_op.
INFO:tensorflow:Saving checkpoints for 0 into output/model.ckpt.
It gets struck after this am I doing something wrong.
python run_classifier.py
--task_name=MRPC
--do_train=true
--do_eval=true
--data_dir=$GLUE_DIR/MRPC
--vocab_file=$BERT_BASE_DIR/vocab.txt
--bert_config_file=$BERT_BASE_DIR/bert_config.json
--init_checkpoint=$BERT_BASE_DIR/bert_model.ckpt
--max_seq_length=128
--train_batch_size=32
--learning_rate=2e-5
--num_train_epochs=3.0
--output_dir=/tmp/mrpc_output/

that's pretty normal from my experience. I left it to run overnight and check it on the second day, it solves

I'm pretty confident the lag is not caused by saving the checkpoint itself although the logging says saving checkpoint.... I checked my bucket and I found that the checkpoint gets saved within a minute. I also tried running with only 20 steps and it the run completes just fine. Maybe logging should be the fix here; such that instead of logging saving..., it should log after the save is done and it says saved.... That way we're not mislead to debug the saving. Also extra logging to signal that the run is still alive would be very helpful!


Fixed the bug when export lb service with no hostname routing rules

Tested by adding 2 links: 1 with hostname routing rules ("ports" param) and another without - in the integration test
https://github.com/rancher/rancher/issues/1645

LGTM


Refactor formatters

Should be class- rather than function-based (allows overriding of formatter functionality), and there should be a global flag for human vs machine readable output.

Done!


RPC subscriptions send back subscription message before sending back the subscription ID

To reproduce:

websocat --jsonrpc wss://rpc.polkadot.io
state_subscribeRuntimeVersion []

The node responds with:

{"jsonrpc":"2.0","method":"state_runtimeVersion","params":{"result":{"apis":[["0xdf6acb689907609b",3],["0x37e397fc7c91f5e4",1],["0x40fe3ad401f8959a",5],["0xd2bc9897eed08f15",3],["0xf78b278be53f454c",2],["0xaf2c0297a23e6d3d",1],["0x49eaaf1b548a0cb0",1],["0x91d5df18b0d2cf58",1],["0xed99c5acb25eedf5",3],["0xcbca25e39f142387",2],["0x687ad44ad37f03c2",1],["0xab3c0572291feb8b",1],["0xbc9d89904f5b923f",1],["0x37c8bb1350a9a2a8",1]],"authoringVersion":0,"implName":"parity-polkadot","implVersion":0,"specName":"polkadot","specVersion":9151,"stateVersion":0,"transactionVersion":9},"subscription":"rcCL9jxosJlIDZ2C"}}
{"jsonrpc":"2.0","result":"rcCL9jxosJlIDZ2C","id":1}

As you can see, we receive a notification for the subscription rCL9jxosJlIDZ2C before the state_subscribeRuntimeVersion is actually answered.
Doing this doesn't make. You can't know which subscription the first message is associated to before receiving the second. It forces the JSON-RPC client to buffer messages of unknown subscriptions in order to associate them later.
Happens on Polkadot version 0.9.16
cc @dvdplm @niklasad1

hrm, I think I have bumped to this too when I tried in subxt for a while ago.
I'm no expert on the jsonrpc crate but this looks not be coupled the actual add_subscription so it possible that the subscription response might be sent before the actual subscription ID....

It forces the JSON-RPC client to buffer messages of unknown subscriptions in order to associate them later.

I'm also running into this situation. With each subscription, one must buffer incoming messages, await the subscription call result, then iterate over the message buffer, match message subscription ids and then trigger the initial callback with the matched messages. To simply trust the response order would be preferable (to say the least). Any updates?

it should go away once https://github.com/paritytech/substrate/pull/8783 is merged.

Excellent! Thank you for the update.

Should be fixed by #8783, would be good if you try it out in JS/smoldot too.


Release v0.1.9 please :)

Do you think it's possible to make a new release ?
Thanks a lot !

+1

It looks like v0.1.9 is out:  https://github.com/kubernetes-sigs/cluster-api-provider-kubevirt/releases/tag/v0.1.9.


[Bug]: The level.py file is stateful - which causes each worker to create its own password

When level.py file is initialsed by a worker it creates a random password for a level. This is stateful and unique to each worker process. This causes password reveled by GPT in one worker to be invalidated by password stored in a different worker. The password validation and retrieval should happen from database directly and not stored in the memory.

Issue is fixed now. Game data is fetched from db and saved in cache


only reference webpack-injected DEBUG from files not needed for CLI node scripts

Review please @gniezen? And maybe give the CLI tools a try again yourself to double-check me?

Successfully uploaded with both the CareLink and OmniPod CLI tools. Also checked that DEBUG_ERROR environment variable still works for Uploader. I'm assuming it's still safe for the Tandem driver to use the __DEBUG__ global?
LGTM!

Yup, the Tandem driver has no CLI tool that requires it, so no problems there.
Can we include this in one of the small bundles so it will get the benefit of whatever smoke testing happens with those?

Merging to include in OmniPod bundle of small tasks.


add typings to project 📝

I added typings for the whole project, so editors can support autocompletion. ✨
Everything is a little bit rushed, so please take a good look on everything. 👀
Some parameters and class members are still having any types because I couldn't guess their actual types due to lacking documentation.
In addition to that, I only made some rough testing so some more testing is definitely needed.
Let me know if there's anything to improve. ^^
Greetings from Remscheid :)

Thanks a lot for your contribution!
Unfortunately, we will probably not merge this. We already provide type definitions through JSDoc which any good IDE should support just as well as Typescript definitions. Separated definitions only add complexity and potential for errors. Merging this would require us to maintain those definitions in the future and we don't see a good reason to do that.
Maybe a better idea would be for you to publish your definitions in a separate unofficial package. This allows you and others to use them but doesn't require us to officially support and maintain them.

Thank you for your reply!
Oh okay, I can understand that very well.
I'll move the definitions to DefinitelyTyped then. ^^


Parse error when operators are adjacent to type applications

{-# LANGUAGE TypeApplications #-}
f <. g = f . g
myid = id @Int <. id

Is this an error from hlint or HSE? Is there an easy way for me as a user to figure that out easily and hence report issues correctly in the future?

Basically all parse errors are issues with HSE. If you want to report on to https://github.com/haskell-suite/haskell-src-exts/issues that would be great

Will do, thanks!


Make azure use latest rustc

Builds are failing for dev server - run rustup update stable after curl installer
Fixes #887

yes - initially i was hard coding it but i've since changed my approach. edited description to reflect.


MP Checks - SYSTEM-1, 2, 3

The scope of this ticket is to address the following Checks:
ECMPS Monitoring Plan Check Specifications

[x] SYSTEM-1 - System Begin Date Valid (Results A, B)
[x] SYSTEM-2 - System Begin Hour Valid  (Results A, B)
[x] SYSTEM-3 - System End Date Valid (Result A)

Test Case: TC1252
Test Passed


default value of textBreakStrategy prop for TextInput is not 'simple'

Description
The document mentions that the default value of textBreakStrategy for TextInput component is 'simple'. However on Android device it behaves like highQuality strategy.

React Native Version
0.72.1
Output of npx react-native info
➜  AwesomeProject npx react-native info
info Fetching system and libraries information...
System:
  OS: macOS 13.4.1
  CPU: (10) arm64 Apple M1 Pro
  Memory: 780.70 MB / 32.00 GB
  Shell:
    version: "5.9"
    path: /bin/zsh
Binaries:
  Node:
    version: 16.17.0
    path: ~/.nvm/versions/node/v16.17.0/bin/node
  Yarn:
    version: 1.22.19
    path: ~/.nvm/versions/node/v16.17.0/bin/yarn
  npm:
    version: 8.15.0
    path: ~/.nvm/versions/node/v16.17.0/bin/npm
  Watchman:
    version: 2<IP_ADDRESS>
    path: /opt/homebrew/bin/watchman
Managers:
  CocoaPods:
    version: 1.12.1
    path: /opt/homebrew/lib/ruby/gems/3.0.0/bin/pod
SDKs:
  iOS SDK:
    Platforms:
      - DriverKit 22.4
      - iOS 16.4
      - macOS 13.3
      - tvOS 16.4
      - watchOS 9.4
  Android SDK:
    API Levels:
      - "28"
      - "29"
      - "30"
      - "31"
      - "32"
      - "33"
    Build Tools:
      - 30.0.2
      - 30.0.3
      - 31.0.0
      - 32.0.0
      - 33.0.0
      - 33.0.0
    System Images:
      - android-32 | Google APIs ARM 64 v8a
      - android-34 | Google APIs ARM 64 v8a
    Android NDK: Not Found
IDEs:
  Android Studio: 2022.2 AI-222.4459.24.2221.10121639
  Xcode:
    version: 14.3.1/14E300c
    path: /usr/bin/xcodebuild
Languages:
  Java:
    version: 11.0.11
    path: /usr/bin/javac
  Ruby:
    version: 3.2.2
    path: /opt/homebrew/opt/ruby/bin/ruby
npmPackages:
  "@react-native-community/cli": Not Found
  react:
    installed: 18.2.0
    wanted: 18.2.0
  react-native:
    installed: 0.72.1
    wanted: 0.72.1
  react-native-macos: Not Found
npmGlobalPackages:
  "*react-native*": Not Found
Android:
  hermesEnabled: true
  newArchEnabled: false
iOS:
  hermesEnabled: true
  newArchEnabled: false

Steps to reproduce

Create a new react-native app
Replace App.tsx with below content

import {TextInput, View} from 'react-native';
import React from 'react';

function App(): JSX.Element {
  const [value, setValue] = React.useState(
<EMAIL_ADDRESS>  );
  return (
    <View style={{padding: 20, justifyContent: 'center', flex: 1}}>
      <TextInput
        value={value}
        onChangeText={setValue}
        style={{fontSize: 20, color: 'black', borderWidth: 1}}
        multiline
      />
    </View>
  );
}

export default App;

Run the app on an android device / simulator
Check how the content inside text input gets wrapped
Edit the value of the TextInput by deleting characters from the end
Observe how the text wrapping keeps on changing while characters gets removed.

Snack, code example, screenshot, or link to a repository
https://snack.expo.dev/EXM6N4Rkm

Default value of textBreakStrategy for TextInput is being initialised to highQuality here.  However as per documentation default value of textBreakStrategy should be simple. Android documentation also sets the same expectation for EditText component, as highQuality strategy would cause the text to "dance around" while user types in the input.
https://github.com/facebook/react-native/blob/50f620a1ad8e925a46d2aa8e6439d5ce6f4f2ce4/packages/react-native/ReactAndroid/src/main/java/com/facebook/react/views/textinput/ReactTextInputShadowNode.java#L56-L59
I'm still not able to figure out where is the default value being set for newArchitecture. As far as I could decipher default value for textBreakStrategy is being read from ParagraphAttributes. This value is shared with Text component and the default value should be highQuality
https://github.com/facebook/react-native/blob/50f620a1ad8e925a46d2aa8e6439d5ce6f4f2ce4/packages/react-native/ReactCommon/react/renderer/attributedstring/ParagraphAttributes.h#L45-L47

Can we initialise textBreakStrategy for AndroidTextInput at any of the below lines, so that it will not impact other Text related components?
https://github.com/facebook/react-native/blob/50f620a1ad8e925a46d2aa8e6439d5ce6f4f2ce4/packages/react-native/ReactCommon/react/renderer/components/textinput/androidtextinput/react/renderer/components/androidtextinput/AndroidTextInputProps.h#L87
https://github.com/facebook/react-native/blob/50f620a1ad8e925a46d2aa8e6439d5ce6f4f2ce4/packages/react-native/ReactCommon/react/renderer/components/textinput/androidtextinput/react/renderer/components/androidtextinput/AndroidTextInputProps.cpp#L63-L66


Sync a specific AD Group

Hi,
Is there a way to sync a specific group from AD ?
I think about something like this :
LDAP_BASE_DN=CN=BookStack_Group,OU=example,DC=example,DC=example,DC=example
For the moment I synchronise an OU and it works.
I read documentation but I'm not sure to understand everything...
If it's possible can You show me an example please ?

You can use ldap search filter
LDAP_USER_FILTER=(&(objectClass=user)(sAMAccountname={0})(memberOf=cn=BookStack,ou=groups,ou=OOO,dc=sth,dc=local))

Thank you ! it works like a charm.
Just another question please, it seems that all user of this group has no roles. And it disable the local admin account.
I understand that it is possible to synchronize a ADgroup with a BookStackrole, how can I do with this configuration?
For now I got something like this :
LDAP_SERVER=example.domain.com:389
LDAP_BASE_DN="OU=BASE,OU=DC=example,DC=domain,DC=com"

LDAP_DN="CN=BookStackUser,OU=BASE,OU=DC=example,DC=domain,DC=com"
LDAP_PASS=blablabla

LDAP_USER_FILTER=(&(sAMAccountName=${user})(memberOf=cn=BookStack_Group,OU=BASE,OU=DC=example,DC=domain,DC=com))
LDAP_VERSION=3
LDAP_ID_ATTRIBUTE=BIN;objectGUID

Check this documentation page, at the end you will find groups sync setup
https://www.bookstackapp.com/docs/admin/ldap-auth/

Ok thank you. After multiples trials, it works fine
I already read this but I have some gaps in English ... so I misunderstood some things... sorry. Now it's good for this part.
A last questionplease :
this is good :
LDAP_USER_FILTER=(&(objectClass=user)(sAMAccountname={0})(memberOf=cn=BookStack_Group,ou=example,DC=example,DC=example))

But if I put an ADgroup called "TECHservice" inside the ADgroup "BookStack_Group", users insides "TECHservice" can't connect.
Is it a way to allow group inside group ?

@Buliwif Looks like this stack overflow result might help for that scenario:
https://stackoverflow.com/questions/6195812/ldap-nested-group-membership
LDAP_USER_FILTER=(&(objectClass=user)(sAMAccountname={0})(memberOf:1.2.840.1135<IP_ADDRESS>1:=cn=BookStack_Group,ou=example,DC=example,DC=example))

Havn't got AD to test myself though.

Hi, sorry for late response, I wasn't at work yesterday. I'll try it today  and tell you if it's ok.
Thank you

I just have to say : thank you very much.
So happy to use your product, it's really the best I tried.

@Buliwif Thank you very much. Can you confirm if the above worked? Can this now be closed?


Make hooks importer for RuneStar

I came accross this repo: https://github.com/RuneStar/client
It contains almost every hook in the game, its really high quality. Someone should write an importer for the hooks it already has.
Just run mvn install and it will update all hooks, then in the updater/target folder there is a hooks.json file which should be made an importer for.

mvn install results in this for me:
[WARNING] The POM for org.runestar:general:jar:0.161.1-SNAPSHOT is missing, no dependency information available
...
[ERROR] Failed to execute goal on project client-updater-create-maven-plugin: Could not resolve dependencies for project org.runestar.client:client-updater-create-maven-plugin:maven-plugin:0.165.0-SNAPSHOT: Could not find artifact org.runestar:general:jar:0.161.1-SNAPSHOT -> [Help 1]

That is what https://github.com/runelite/runelite/tree/master/deobfuscator/src/test/java/net/runelite/runesuite is - the project got renamed awhile ago.


Develop way to simulate airgap locally and in CI

The airgap example is always painful to try and reproduce and we don't have a great story for users even though we've done so much to make things easier. We need a simpler way to iterate so that we can further improve things.

https://github.com/kubernetes-sigs/kind/issues/2776
Able to get this working locally but I needed a custom build of kind with my own tweaks and another container on that airgapped network to work from (so you need to mount the kubeconfig, sonobuoy, kubectl)
In addition, we'll need to either preload the images we want into it and/or set up a custom registry for those tests. The former is easier/faster but it probably wouldn't integrate with things like imgpkg/kbld since those want to push/pull.


Enable peeling for fully dynamic GEMMs and element-wise ops

Running some performance experiments for now

Performance numbers:

Micro-benchmark
No Vectorization
Padding
Peeling

Dynamic GEMM
9.47 ms
0.88ms*
1.44ms

Dynamic Element-wise
7.30 ms
7.30ms**
2.10ms

*Latency is lower with padding on GEMM because it vectorizes three dimensions, resulting in aggressive unrolling, and peeling is only vectorizing one (no unrolling).
** Padding is not implemented for element-wise ops.
Let me know what you think.

Hard for me to follow the code (the logic here is getting pretty complicated :( , we might need to consolidate things in the future).

I totally agree! I've been scattering comments about the same concerns in the last code reviews. I think we should follow a more principled approach and have a single source of truth for some of the codegen decisions/heuristics.

What is the default mode for GEMMs with dynamic shapes or elementwise ops with dynamic shapes? Is it peeling or padding.

GEMMs and element-wise ops that are fully dynamic (i.e., all dims are dynamic) are using peeling with this patch. Otherwise, padding is used. We modify the tile sizes so that we only vectorize the fastest-varying parallel dimension, if any, or, otherwise, the fastest varying reduction dimension. This is mostly to minimize the impact of peeling higher-order dimensions.


Add "Unknown" option to date created filter

Since we often don't know the creation dates for some types of resources (e.g., academic programs, research institutes), we need an unknown option as part of the filter so that users can more easily see that we have a lot of resources without dates.

Do you think people will actually want to filter out just the ones with "unknown" values? It doesn't feel like a common use-case of the filter.
If your only goal is to communicate to folks that some of these values could be empty, then I'm not sure that's the best way to do it...

Fair point. I can't think of many cases where you'd specifically want to find programs with no date provided. The goal for me really is more around people not being too confused when there are relatively few results when using this filter. Having a box for unknown helps explain this situation fairly easily but I'm definitely open to another way of accomplishing it.

I'd lean toward not providing this as a filter and communicating the absence of date created data another way. Maybe something to discuss.


No useful information provided with --verbose option when locking

I'd like to see what pipenv is doing during locking because it's tooooooo sloooooow.
I tried to use --verbose option to see what's going on, but it shows nothing.
[s1830001@vpcc-041 signate_ssd]$ pipenv lock -v
Locking [dev-packages] dependencies…
Locking [packages] dependencies…
? Locking...
        (... waiting for tens of minutes, but nothing happens)

I expect some useful information for --verbose option.
Is it possible to show something? (e.g. current progress)
Thanks.

+1, it would help to debug https://github.com/pypa/pipenv/issues/2681

There is plenty of verbose output these days.  I am closing this out as completed.


configure HP 300 ARM server

is in rack but needs to be configured

server came equipped with "Mellanox MCX631432AS-ADAI Ethernet 10/25Gb 2-port SFP28 OCP3 Adapter for HPE" management ports and there was no other option.
our switch is 1G, so i ordered SFP to RJ45 transceivers "453154-B21" should arrive 12/1/2023

done


Attempt to reuse RNNCell with a different variable scope than its first use

It seems that TensorFlow 1.1 has made some changes to how to use the tf.contrib.rnn.MultiRNNCell, please check here and (https://github.com/tensorflow/tensorflow/issues/8191)
For example,the current code inside tl.layers.DynamicRNNLayer only works in TensorFlow 1.0, not in TensorFlow 1.1. It will raise error shown in the title if TensorFlow 1.1 is used.
I changed the source code in tl.layers.DynamicRNNLayer to this, and it works again.
self.cell = MultiRNNCell_fn([self.cell] * n_layer, state_is_tuple=True)

changed to:
self.cell = MultiRNNCell_fn([tf.contrib.rnn.DropoutWrapper(cell_fn(num_units=n_hidden, **cell_init_args), input_keep_prob=in_keep_prob, output_keep_prob=1.0) for _ in range(n_layer)], state_is_tuple=True)

Can you update the RNN code for the latest TensorFlow? @zsdonghao  Thanks.

@CTTC Many thanks for your report.
Could you make a push request, because this is your contribution.
To make it works for all version, you may like to change as follow.
try: # TF1.1
     xxx
except:  # TF1.0
     xxx

Thanks in advance.

@zsdonghao  Sorry for the late reply. I'm happy to make a pull request. I will submit it ASAP.

@CTTC thank you very much indeed.


Woa2018 pt

Add the python chain of to convert in-situ temperature to potential temperature for woa2018/woa2013

Jiping, you asked for merging to master branch. You should set this to develop branch.


SDG249: Remove EnableCacheServer

Removing EnableAuth was done in a previous PR on another ticket and was already merged. I'm not sure how it showed up here, but a rebase solved it.


Updated stations dto, controller and service

dev
JIRA

Main JIRA ticket

Code reviewers

[ ] @github_username

Second Level Review

[ ] @github_username

Summary of issue
ToDo
Summary of change
ToDo
Testing approach
ToDo
CHECK LIST

[ ]  СI passed
[ ]  Сode coverage >=95%
[ ]  PR is reviewed manually again (to make sure you have 100% ready code)
[ ]  All reviewers agreed to merge the PR
[ ]  I've checked new feature as logged in and logged out user if needed
[ ]  PR meets all conventions

ok


[SPARK-27075] Remove duplicate execution tag parameters from the url, when accessing the execution table in the SQL page

What changes were proposed in this pull request?
When we sort any columns in the execution table of the SQL page in the WEBUI, it throws IllegalArgumentException. The root cause is that,  in the url, we are duplicating the execution tag parameters in the 'parameterPath'. Actually we should filter out the executionTag related entries while getting the 'parameterOtherTable'
https://github.com/apache/spark/blob/e9e8bb33ef9ad785473ded168bc85867dad4ee70/sql/core/src/main/scala/org/apache/spark/sql/execution/ui/AllExecutionsPage.scala#L161-L163
https://github.com/apache/spark/blob/e9e8bb33ef9ad785473ded168bc85867dad4ee70/sql/core/src/main/scala/org/apache/spark/sql/execution/ui/AllExecutionsPage.scala#L241
https://github.com/apache/spark/blob/e9e8bb33ef9ad785473ded168bc85867dad4ee70/sql/core/src/main/scala/org/apache/spark/sql/execution/ui/AllExecutionsPage.scala#L263-L266
How was this patch tested?
Manually tested
Test steps:
Sort any column in the sql page execution table
Before fix:

After fix:

Jenkins, test this please

Can one of the admins verify this patch?

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/testing-k8s-prb-make-spark-distribution-unified/8571/
Test PASSed.

Test build #103109 has started for PR 23994 at commit 348eeb9.

cc @vanzin Kindly review the PR.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/testing-k8s-prb-make-spark-distribution-unified/8572/
Test PASSed.

Test build #103111 has started for PR 23994 at commit df74cdf.

Test build #103109 has finished for PR 23994 at commit 348eeb9.

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

Merged build finished. Test PASSed.

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

Test build #103111 has finished for PR 23994 at commit df74cdf.

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

Merged build finished. Test PASSed.

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

Merging to master.

Thanks @vanzin


PDFs created with node-pdftk do not open on Chrome for iOS

Describe the bug
PDFs do not open on iOS Chrome. I've tested Safari on iOS, Chrome and Firefox on Android, Chrome, Firefox and Chromium Edge on Windows and Mac, and Safari on Mac. All work, just not that iOS Chrome.
I'm porting code from an old PHP app, and the PDFs the PHP version creates will open in iOS Chrome.
To Reproduce
Steps to reproduce the behavior:
const buffer: Buffer = await pdftk
  .input(blankPdfPath)
  .fillForm(data)
  .flatten()
  .output();

Buffer is then uploaded to S3.
I tested that the PDF that's input can be opened in Chrome just fine.
PDF does not open. It downloads and asks what to open the file with (choosing Chrome again does not work).
Expected behavior
PDF should open in Chrome.
System info that creates PDF:

Node version: 12
OS: Ubuntu
OS Version: 18.04, I believe

System info trying to open PDF:

OS: iOS
OS Version: 13
Browser: Chrome
Browser Version: any

Any other info?
I don't know what else might help you here... do you want one of the generated PDFs or the input PDF?

Sorry for the delay. Did you try using PDFtk directly and see if you have the same issue with the output? If that's the case, this is an issue with the PDFtk library. If that's not the case, I'll take a look at the input and generated PDFs.


Webpack watch breaks when @apply'ing a non-existing class.

First of all, thanks for this great project, I've been waiting for this since ages!
I don't know if I'm reporting this in the correct place, but my problem is this: if in my component I @apply a class that does not exist, I get an error such as:
ERROR in ./css/app.css
Module build failed: ModuleBuildError: Module build failed: Syntax Error

(3:3) No .foo class found.

and my webpack watch breaks, and does not pick up further changes until I stop and restart webpack.
I think it's because of Tailwind's implementation of @apply, which completely break the webpack watcher until the error is fixed and webpack restarted.
Any easy workaround for the time being? It's a bit frustrating to stop and restart webpack everytime I add a typo in my components.
How can I help?

Mmmm.. spent more time on this, and it seems this happens only on an @apply error in an @imported CSS file.
If I have a typo in my main css file, rebuild after error works.
I'm using postcss-easy-import which is basically postcss-import with globs, the problem is probably there. I'll report back.

Couldn't make it work with postcss-import. I've resolved by converting all my stylesheets to SASS and using it to concatenate imports, which are then processed by postcss and tailwind.
Here's my webpack rules:
 // Preloader to support globbed @import on SASS
      {
        test: /\.s?css$/,
        enforce: "pre",
        loader: "import-glob-loader"
      },
      {
        test: /\.s?css$/,
        use: ExtractTextPlugin.extract({
          fallback: "style-loader",
          use: ["css-loader", "postcss-loader", "sass-loader"]
        })
      }

And my main CSS:
@tailwind preflight;

@import "./components/*";

@tailwind utilities;

@import "./utilities";

Pinging #53 since I originally got the idea of using postcss-import from there.

I have the same issue that webpack sopts watching... It's not a dealbreaker but kind of annoying every time I need to restart the process.


Column plugins break memoization

Describe the bug (required)
When using the plugins useColumnOrder, useColumnVisibility, and the unstable usePivotColumns, a good deal of memoization is lost, which can cause a cascading effect that results in unnecessary re-renders (and is generally difficult to track down when one's in "Why did this render?" mode).
The reason is that these plugins add an array to the visibleColumnsDeps whose identity changes on every render, meaning that anything that directly or indirectly is memoized and is based on visibleColumnsDeps will never actually be memoized.
For example, visibleColumns is not memoized with these plugins, neither are allColumns, headerGroups, headers, or prepareRow.
Provide an example via Codesandbox! (required)
This isn't a behavioral bug that I can reproduce in Codesandbox, but any usage of these plugins will cause the re-renders.
Steps To Reproduce (required)
Steps to reproduce the behavior:

Use a plugin like useColumnOrder
Attempt to memoize a component based on a prop like table.headerGroups
Change some non-column-related table state
Observe the component from step 2 re-rendering

Expected behavior (Recommended)
These values do not change between renders.

Hm, useColumnVisibility is a core plugin, so I may be misunderstanding something here. Going to dig deeper.

Hm, useColumnVisibility is a core plugin, so I may be misunderstanding something here. Going to dig deeper.

I'm now convinced this is an issue in my own app. Sorry for the noise. I believe as long as the state values are stable in these dependencies, which they are by default unless a user updates them, there are no broken useMemo calls.

I'm now convinced this is an issue in my own app. Sorry for the noise. I believe as long as the state values are stable in these dependencies, which they are by default unless a user updates them, there are no broken useMemo calls.


InfiniteScrolling in 1.0

Hello Griddle Team!  Congrats on releasing 1.0.  Looking forward to using it.
Trying to migrate from 0.7.1 to 1.0 due to not being able to toggle column visibility out of the box and decided to just take the dive into 1.0.
Does Griddle still support Infinite Scrolling by setting a prop on the Griddle component, or is it possible now to integrate in a library like react-virtualized to handle rendering the RowDefinition components needed for Griddle?
Thanks!

Thanks so much -- we're excited to have it released. If you're successfully using 0.7.1 I would wait a bit until we have the official upgrade guide complete. @joellanciaux is kind of taking point on that one but it likely won't be too far off. That said, with the architecture changes, some of the plugins are not baked in to core Griddle and will be coming shortly there-after as plugins (namely subgrid and selection).
I would imagine someone could write a plugin for react-virtualized (and that would be really really cool to see), although the ability to have a pipeline of plugins may be lost depending on how the other plugins interact with the view components (it may not too -- I'd have to look more into how that could work).
Additionally, we have a plugin that does virtual scrolling that will be receiving some updates and performance fixes in the weeks to come that can be used as follows:
import Griddle, { plugins } from 'griddle-react'
...
<Griddle data={someData} plugins={[..., plugins.PositionPlugin({tableHeight: 600 }) />

https://github.com/GriddleGriddle/Griddle/blob/master/stories/index.js#L260 for more info on this. Please let us know if this helps :+1:

ahh nice!  That is what I am looking for.
Only place I didn't look to see about the virtual scrolling was in the stories dir! :smile:
Thanks for the speedy response!

@ryanlanciaux is Infinite scroll already in Griddle? If yes, could you give me an example how to implement it.

Is there an example of how the infinite scroll works for Griddle 1.0 and above? The link for https://github.com/GriddleGriddle/Griddle/blob/master/stories/index.js#L260  it's broken now

@jrmartin Is there an example of how the infinite scroll works for Griddle 1.0 and above?

https://github.com/GriddleGriddle/Griddle/blob/2988f42dd4b3db027587694028783f6507e7848d/stories/index.js#L258-L267

can we call the API service to get more data on scroll, what I mean i will load first 100 records and on each scroll will call the API to get the next 50 records(101-150) and append to the grid, is there any way to do this.

Is there any way to get the onscroll event handler in the griddle

Not without patching PositionPlugin, though adding a callback to its options should be pretty easy.

@dahlbyk how to access that 'config' parameter in my custom plugin, for example i am using components->Layout the layout component i am enhancing, i want to access that  'config' parameter in my Layout class. How to do it.
I just created a function that can access the 'config' data, but i am unable to pass it for my layout component.

I would mimic how PositionPlugin handles config: it merges the values into initialState.positionSettings and uses selectors to make the values available to components in TableEnhancer. You would use a similar technique with a LayoutEnhancer.

@dahlbyk I have implemented the infinite scroll by calling the services based on the user actions by creating the custom plugin, but I am facing one issue like the screen is getting flickering on some position of scroll, I debug the issue I came to know that if we are using 'PositionPlugin' in the 'tbody' by default one row(tr) is getting created and on each scroll the height of that 'tr' is changing in some position of scroll bar the value is keeping on updating and not stooping by this reason screen is getting flickering... please suggest me how to fix this issue.


Book 2, typo in Section 18.6.6

"We can then learning the parameters ..." -> "We can then learn the parameters"

fixed


NSLog doesn't handle certain URLs

When passed a url like the following (https://chefitpublic.file.core.windows.net/chefdeploy/bootstrap.json?sv=2017-04-17&ss=f&srt=so&sp=rl&se=2018-11-28T23:56:02Z&st=2017-11-28T15:56:02Z&spr=https&sig=b8%2FgLAzKtyHGTes0fe5SyWlIqs5p2ucUtLOmwBgW2a4%3D) Lines 278 and 446 will break with the following error:
  File "/Library/Application Support/installapplications/installapplications.py", line 654, in <module>
    main()
  File "/Library/Application Support/installapplications/installapplications.py", line 446, in main
    iaslog('Starting download: %s' % (json_data['url']))
  File "/Library/Application Support/installapplications/installapplications.py", line 56, in iaslog
    NSLog('[InstallApplications] ' + text)
ValueError: Too few arguments for format string [cur:1/len:1]

Reported by John McCrae

fixed with https://github.com/erikng/installapplications/commit/c5d2b20c57f7d76895e8d331c5dbf6ba83150a05


*: rename APIVersion to KvFormat

What is changed and how it works?
Issue Number: Ref #12394
What's Changed:
So it better reflect its functionality and follow Rust's convention.

Other notable changes are renaming `SSTXxxx` to `SstXxxx` and introduce a
macro to reduce test code related to ApiVersion.

Check List
Tests

Unit test
Integration test

Release note
None

BTW, Would you like to rename trait Engine to something else? maybe KvStorage

There will be Storage from transaction layer, KvStorage from tikv_kv component, KvEngine from engine trait. I'm not sure if it's a good name.
@pingyu @cfzjywxk do you have suggestions?

BTW, Would you like to rename trait Engine to something else? maybe KvStorage

There will be Storage from transaction layer, KvStorage from tikv_kv component, KvEngine from engine trait. I'm not sure if it's a good name.
@pingyu @cfzjywxk do you have suggestions?

Storage is not on transaction layer, it provides both raw_get and txn_get. I agree KvStorage is not a good enough name,  but have no better idea.

BTW, Would you like to rename trait Engine to something else? maybe KvStorage

There will be Storage from transaction layer, KvStorage from tikv_kv component, KvEngine from engine trait. I'm not sure if it's a good name.
@pingyu @cfzjywxk do you have suggestions?

How about "StorageEngine" ?
Then the dependent relationship would be Storage -> StorageEngine -> KvEngine.
(p.s. I'm sorry that I click the wrong button... )

BTW, Would you like to rename trait Engine to something else? maybe KvStorage

There will be Storage from transaction layer, KvStorage from tikv_kv component, KvEngine from engine trait. I'm not sure if it's a good name.
@pingyu @cfzjywxk do you have suggestions?

Storage is not on transaction layer, it provides both raw_get and txn_get. I agree KvStorage is not a good enough name, but have no better idea.

@BusyJay Another option is,  the trait Engine should be renamed to trait Storage, considering in grafana we already think async_write and async_snapshot are on the layer of Storage.
And rename struct Storage to something else, maybe TiKVHandler?

BTW, Would you like to rename trait Engine to something else? maybe KvStorage

There will be Storage from transaction layer, KvStorage from tikv_kv component, KvEngine from engine trait. I'm not sure if it's a good name.
@pingyu @cfzjywxk do you have suggestions?

Storage is not on transaction layer, it provides both raw_get and txn_get. I agree KvStorage is not a good enough name, but have no better idea.

@BusyJay Another option is, the trait Engine should be renamed to trait Storage, considering in grafana we already think async_write and async_snapshot are on the layer of Storage.
And rename struct Storage to something else, maybe TiKVHandler?

This seems to be good. The current struct storage is the command handling entry, in MySQL, this module is named handlerton(https://dev.mysql.com/doc/internals/en/custom-engine.html and https://dev.mysql.com/doc/internals/en/api-reference.html).
The storage could mean the generalized storage which contains transaction and raw kv related modules, or it could mean the actual standalone storage engine. It should be used with caution to avoid misunderstanding.

OK, then Storage is renamed to StorageHandler and trait Engine is renamed to Stroage. What do you think? @Connor1996 @pingyu @cfzjywxk

OK, then Storage is renamed to StorageHandler and trait Engine is renamed to Stroage. What do you think? @Connor1996 @pingyu @cfzjywxk

LGTM~

OK, then Storage is renamed to StorageHandler and trait Engine is renamed to Stroage. What do you think? @Connor1996 @pingyu @cfzjywxk

LGTM

OK, then Storage is renamed to StorageHandler and trait Engine is renamed to Stroage. What do you think? @Connor1996 @pingyu @cfzjywxk

LGTM

I find that renaming Engine to Storage may break a lot of things, not just codes but also docs and comments. It may also make future cherry-pick harder. I propose to just keep the existing naming in this PR.

I find that renaming Engine to Storage may break a lot of things, not just codes but also docs and comments. It may also make future cherry-pick harder. I propose to just keep the existing naming in this PR.

LGTM, and very thanks for your work ~
(I suggest to leave a comment to inform others that, don't try to rename Engine 🐶 )

LGTM, and very thanks for your work ~ (I suggest to leave a comment to inform others that, don't try to rename Engine 🐶 )

Actually, I think it's acceptable to me to rename it. However, because I'm not the one that do heavy cherry picks for transaction and storage change, so my opinion may not be significant. To do the refactor, I think community should get involved and get a consensus instead of just a small group of us. And it should be finished in a PR that take good care of all comments and docs.

LGTM, and very thanks for your work ~ (I suggest to leave a comment to inform others that, don't try to rename Engine 🐶 )

Actually, I think it's acceptable to me to rename it. However, because I'm not the one that do heavy cherry picks for transaction and storage change, so my opinion may not be significant. To do the refactor, I think community should get involved and get a consensus instead of just a small group of us. And it should be finished in a PR that take good care of all comments and docs.

The doc including these terms should be only source code readings, but they all are specified to a fixed version. And I believe cherry-pick won't suffer too much from these. The following version is 6.1 LTS, it's a good opportunity to say goodbye to these burdens. If we don't take the first step, it's even harder to change it later.
So I suggest let's merge it now without further subtle naming changes, and the rest subtle mismatch naming doesn't affect much and they will be iterated over time.

LGTM, and very thanks for your work ~ (I suggest to leave a comment to inform others that, don't try to rename Engine 🐶 )

Actually, I think it's acceptable to me to rename it. However, because I'm not the one that do heavy cherry picks for transaction and storage change, so my opinion may not be significant. To do the refactor, I think community should get involved and get a consensus instead of just a small group of us. And it should be finished in a PR that take good care of all comments and docs.

I agree. It would be better to have a more widespread discussion, if the change will affect most people of the community.

@Connor1996 I reverted the Engine change. If you still think it's necessary, I suggest you to send a proposal to internals.tidb.io and see the feed back first.

/merge

/merge


Set session keys for an account through another account

I am working on a PoA network (Aura+Grandpa) and want to onboard new validators through extrinisics.  Before an account can be set as a validator it needs to set its session keys by calling set_keys. The extrinsic will require fees to be paid and the new account (which calls set_keys) might not have the balance. The straightforward way to achieve that would be to have an extrinsic (called by sudo) in my pallet that accepts the AccountId and keys and call do_set_keys but do_set_keys is private. Is there a reason why do_set_keys cannot be public? If it can be then I can raise a PR but if it can't be then I would like advice. I see SignedExtension can be used to make transactions free (don't know exactly how) but I wouldn't like to make set_keys free for all.

I see i can use RawOrigin::Signed for origin while calling set_keys from my module. This solves my problem. I still think it would have been better to directly call do_set_keys though.


merge package template from arlac77/npm-package-template

Updated standard to latest version

Codecov Report

Merging #136 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #136   +/-   ##
=======================================
  Coverage   93.49%   93.49%
=======================================
  Files          18       18
  Lines         169      169
=======================================
  Hits          158      158
  Misses         11       11

Continue to review full report at Codecov.

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

Coverage remained the same at 93.491% when pulling 0cd97d9634126587aeaadad9641f82be07c69367 on template-sync-1 into 1c3acdca14755756df025974d89bcf9571715e4a on master.


Deprecate net-tools in favor of iproute2

The package net-tools has been deprecated for quite some time now: Linux Foundation statement
They state iproute2 as replacement, which is in fact part of alpine already. To still include net-tools is just redundant.
It should be removed to keep alpine slim. net-tools is probably not your main use case on docker. If you don't know how to use it yet: Blog post with explanations. (credit to Doug Vitale)

Problem is not that we don't know how to use it. Problem is all scripts that may use it and that may break.
Besides, we don't have the net-tools package installed in the first place so I'm not sure what you expect us to do? Remove the tools from busybox config? Can you give an estimate how much space we save on it?
I suspect the benefit will be low compared to cost (time to fix all broken scripts and spend time on justify why this was done to all upset people).

Hi @ncopa
thanks for your response. I know it is not you who doesn't know how to use it, but the people that haven't ever been made aware of the deprecation. I've precausiously included this in here for everyone being upset.
I know you don't have the packages installed directly as you use busybox.
I just went ahead and built busybox without arp, ifconfig, iptunnel, nameif, netstat, and route just with the menuconfig. It saved me pretty much point on 16KB of the busybox binary. I didn't have a look into the specific make config alpine uses, but I guess these values should also apply for you. However, you are way better suited to assess whether this is worth the effort than me.
Let me just rebuild my initial intend here: Alpine is base to all the containers that mostly are not involved with deep network mechanics (e.g. node servers). I think keeping a dependecy open that is deprecated and has a recommended alternative (iproute2 commands) built in is not necessary. If you'd want old tools because you somehow cannot parse the new, you should build a custom image. Not the other way around.
People have been clingy with ifconfig and others for a better half of 10 years now. Probably won't change. Doesn't mean it is not an issue.

Thank you for taking time to measure the space savings. Appreciate that.
Alpine has been used for deep network mechanics (eg firewalls, routers, VPN, phone systems, etc) for a longer time than docker existed. We build network devices with Alpine even before linux mainline kernel got support for containers (we actually used vserver patches back then for  what is called "containers" now). Some people still use Alpine for that.
Removing those tools from default busybox config will cause drama and it is not worth it to save 16k.

Now that's something I totally didn't realise. Fine for me then.

Ironically, ifconfig in BusyBox is likely more actively-maintained than it is in net-tools... :smile:


[WIP] implement torii provider

@broody how does the dynamic component schema look like? and is the schema file generated here correct?

@broody how does the dynamic component schema look like? and is the schema file generated here correct?

Yup that looks good, but it seems like you don't have any nameComponents queries. So in the ecs example you would two additional queries:
movesComponents(
    remaining: u8
    limit: Int
): [Moves]

positionComponents(
    x: u32
    y: u32
    limit: Int
): [Position]

You can also take a look at the playground at http://localhost:8080 and it will list all available queries there. Btw, trying to get https://github.com/dojoengine/dojo/pull/718 merged in the next day or so, then the returned value will be of type nameConnection

@kariy ideally we are using the gRPC api here, since it is a much better fit for high throughput communication. hopefully that will be ready soon. i'm happy to land this in the short term but let's not spend too much time on it. i would love to get something working e2e, so integrating the new client in something like starklander, using the rpc provider, before implementing additional providers / stores

Closing this while waiting for torii to support gRPC.


Official React Port

Will we see an official React port of current MaterializeCSS in near future, or like very soon? There is already a React Material-UI library and an unofficial (I guess)  but since lot of people have been using Materialize, it'll be really exciting and useful to have an official MaterializeCSS library for React.

I do not have much experience with react, but I do recognize it's popularity and usefulness. This is something that could be done in the future but no official plans right now. If someone who's experienced with react would like to help us out I'd be interested


fix(consensus): add timeout when waiting for first proposal message

If the StreamHandler sends a content receiver but never sends the first message, the timeout will cause a panic.

This change is

[!WARNING]
This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

#2758  👈 (View in Graphite)
#2748
#2746
#2745
#2730
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

crates/sequencing/papyrus_consensus/src/manager.rs line 213 at r1 (raw file):
Previously, matan-starkware wrote…
I'd prefer that you use try_recv().expect()
https://docs.rs/tokio/latest/tokio/sync/mpsc/struct.Receiver.html#method.try_recv

Sorry, try_recv

Merge activity

Dec 23, 4:33 AM EST: A user merged this pull request with Graphite.