Fix horizontal scroll on pages with vertical scroll

Every page that has a vertical scroll also has a small horizontal scroll.
That is because of width: 100vw; on the header. Viewport width does not care about scroll bars, so when there are vertical scrollbars the header does not resize and overflows (by 15px on Chrome).
Replacing width: 100vw; by width: 100%; fixes this issue.

Pull Request Test Coverage Report for Build 179

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 56.276%

Totals

Change from base Build 171:
0.0%

Covered Lines:
1004

Relevant Lines:
1568

💛  - Coveralls

I'm using 100vw because the menu should be scrollable on mobile. It doesn't work with 100% and I'm not sure how to get it working.
Here's an example: https://codepen.io/electerious/pen/mdbNwdp (simply replace 100% with 100vwand it's working as expected)
This sounds so simple, but it seems to be very complex when using display: grid.

Thanks for the explaination. I'll look into it

Could you take a look at this?
What I did :

change the display on .body and #main to grid so that the header can keep scrolling without setting its width in vw
wrap the two overlays in a new class called overlay that has display: grid and min-height: 100vh so that the overlays are displayed in grid and centered horizontally and vertically.

On a side note, I see that you are working on the develop branch, do you want me to make the PR on this branch rather than master?
Second side note: I'm not sure if you really work using this coding style (no jsx, module.exports = , require, 'use strict' ), but it makes it fairly difficult to contribute. If you don't use this coding style and are actually generating it with another version of the code, would you mind making it public, giving dev & contribution guidelines ?

Thanks for the changes. I will take a look at them by time!
I somehow still can't believe that there's no simple way to limit the grid size, so I need to give it a try too.

On a side note, I see that you are working on the develop branch, do you want me to make the PR on this branch rather than master?

That's ok for now, but develop would be better in the future.

Second side note: I'm not sure if you really work using this coding style (no jsx, module.exports = , require, 'use strict' ), but it makes it fairly difficult to contribute. If you don't use this coding style and are actually generating it with another version of the code, would you mind making it public, giving dev & contribution guidelines ?

Yes, I'm writing react like this 😃 I might be the only one who likes to use the createElement (h) function instead of JSX. I will add the eslint configs.

Adding grid-template-columns: 100%; to the grid layout seems to work: https://css-tricks.com/preventing-a-grid-blowout/
Can you give the develop branch a try?

develop looks good to me, tested on android chrome & chrome on linux desktop!


Migrate to json

In order to the action to run, you have to enable the read and write permissions for the actions from the repo settings


Verify view connections in remote slots matching strategy

also move mapping local consumed slots strategy into its own file.
https://github.com/PolymerLabs/arcs/issues/313

ops, sorry about that, all fixed now.


feat: add release bump to package-lock.json

Codecov Report
Base: 17.56% // Head: 17.56% // No change to project coverage :thumbsup:

Coverage data is based on head (64bce17) compared to base (18c31cf).
Patch has no changes to coverable lines.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
Additional details and impacted files
@@           Coverage Diff            @@
##           develop     #473   +/-   ##
========================================
  Coverage    17.56%   17.56%
========================================
  Files           57       57
  Lines         6087     6087
========================================
  Hits          1069     1069
  Misses        4936     4936
  Partials        82       82

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


Doesn't seem to start enough jobs?

When I start a job with:
with WorkerPool(n_jobs=24, keep_alive=True) as pool:
    pool.map_unordered(do_work, arg_list, worker_lifespan=2, chunk_size=1, progress_bar=True)

I only seem to see 7% avg CPU usage on our m7i.8xlarge (32 vCPUs). Am I using this wrong? When I run
tqdm.contribu.concurrent.process_map(do_work, arg_list, max_workers=24, chunksize=1, maxtasksperchild=2)

I see 75% usage, as expected (caveat: I'm using our wrapper around that function that supports maxtasksperchild, but it's basically the same). Is there a recommended way to debug this?

Your code seems fine to be honest. I never had issues with cpu usage, it usually is always at 100%.
What happens with the cpu usage when you don't use worker_lifespan? If you experiment a bit with different settings then maybe we can pinpoint the problem.

Stale


Upgrade to Parcel 2

I was having the hardest time figuring out why everything in the template worked on my MacBook but not on my Windows desktop. Turns out this template doesn't work with Parcel version 2 and above. I was wondering if you plan to update your templates to use newer versions of Parcel? Thank you!

Subscribe. But in case you need it, I created repo with Angular as a server and a bit of a boilerplate for phaser. Will update it later as I move through the book. And will try to make it work on Parcel 2 after I finish the book.
Cheers


Added input sanitization to fix self-xss issue

Description
The Merge functionality takes untrusted user input (file name) and uses it directly in the creation of HTML pages allowing any unauthenticated to execute JavaScript code in the context of the user.
Added input sanitization so that JavaScript can't be executed.
Addresses the security issue raised in https://github.com/Stirling-Tools/Stirling-PDF/security/advisories/GHSA-9j55-gvf2-cqwv
Checklist

[ x ] I have read the Contribution Guidelines
[ x ] I have performed a self-review of my own code
[ - ] I have attached images of the change if it is UI based
[ x ] I have commented my code, particularly in hard-to-understand areas
[ x ] My changes generate no new warnings
[ x ] I have read the section Add New Translation Tags (for new translation tags only)

Greatly appreciated! Thanks

Thanks @Frooodle. Would you be able to update the security advisory (https://github.com/Stirling-Tools/Stirling-PDF/security/advisories/GHSA-9j55-gvf2-cqwv) as well?


[Performance]: updateDocument functions are taking too much time

@esthercheran can you flesh this out still?


Add tools to help visualize effective receptive field

Describe the feature
Visualize effective receptive field (ERF) of a given layer in network.

Image taken from Segformer paper
Motivation
I want to know why my model fails
Related resources
I found a receptive visualization implemented in Pytorch: https://github.com/shelfwise/receptivefield
but I don't know if the implementation is correct.
Segformer ERF visualization implemented based on ERF paper but they didn't provide the code

It is better to put a link when multiposting.
https://github.com/open-mmlab/mmcv/issues/2095


[stdlib] Add another fast path for generic floating-point conversion

Based on my reading of IEEE 754, for any given w (exponent bit width) and p (precision, or significand bit width + 1), there can be one and only one encoding of any finite value in a binary interchange format with those parameters. Therefore, we can use init(sign:exponentBitPattern:significandBitPattern:) to convert from any binary floating-point type with w and p parameters that match a known standard library type's parameters to the latter type. From there, we can use the existing protocol requirements to convert to Self.
In a perfect world, since everything is inlinable, the compiler would be able to see that essentially the whole conversion involves bit shifting values in opposite directions and converting between unsigned integer types that are type aliases of each other, turning everything into no-ops. But I would imagine that there is some overhead here that can't quite be eliminated.
There is a companion PR (#33821) with benchmarks that should be merged to test how well this fast path does the job.

cc @troughton

@swift-ci smoke test

@swift-ci benchmark

Performance: -O

Regression
OLD
NEW
DELTA
RATIO

FlattenListFlatMap
2373
3023
+27.4%
0.78x (?)

UTF8Decode_InitDecoding
140
172
+22.9%
0.81x

UTF8Decode_InitFromCustom_contiguous
143
173
+21.0%
0.83x (?)

ParseFloat.Float.Exp
8
9
+12.5%
0.89x (?)

FlattenListLoop
927
1022
+10.2%
0.91x (?)

UTF8Decode_InitFromCustom_noncontiguous
298
326
+9.4%
0.91x (?)

FloatingPointPrinting_Float_description_uniform
3500
3800
+8.6%
0.92x (?)

StringHashing_latin1
214
232
+8.4%
0.92x (?)

ArrayInClass
915
990
+8.2%
0.92x (?)

StringHashing_fastPrenormal
620
670
+8.1%
0.93x (?)

ParseInt.IntSmall.Decimal
263
284
+8.0%
0.93x (?)

Improvement
OLD
NEW
DELTA
RATIO

ConvertFloatingPoint.MockFloat64ToDouble
2727
18
-99.3%
151.49x

EqualSubstringSubstring
29
22
-24.1%
1.32x

LessSubstringSubstring
29
22
-24.1%
1.32x

EqualStringSubstring
29
22
-24.1%
1.32x

EqualSubstringSubstringGenericEquatable
29
22
-24.1%
1.32x (?)

EqualSubstringString
29
22
-24.1%
1.32x

LessSubstringSubstringGenericComparable
29
22
-24.1%
1.32x

StringComparison_longSharedPrefix
378
342
-9.5%
1.11x (?)

Set.isSubset.Seq.Empty.Int
87
79
-9.2%
1.10x

Set.isDisjoint.Seq.Empty.Int
92
84
-8.7%
1.10x

Set.isDisjoint.Empty.Int
92
84
-8.7%
1.10x (?)

ArrayAppendUTF16Substring
33588
30780
-8.4%
1.09x (?)

ArrayAppendAsciiSubstring
33588
30780
-8.4%
1.09x (?)

ArrayAppendLatin1Substring
34236
31392
-8.3%
1.09x (?)

Set.isDisjoint.Empty.Box
94
87
-7.4%
1.08x (?)

Set.isSuperset.Seq.Int.Empty
94
87
-7.4%
1.08x (?)

Set.isDisjoint.Seq.Empty.Box
94
87
-7.4%
1.08x (?)

Code size: -O
Performance: -Osize

Regression
OLD
NEW
DELTA
RATIO

UTF8Decode_InitDecoding
140
172
+22.9%
0.81x

UTF8Decode_InitFromCustom_contiguous
141
169
+19.9%
0.83x

UTF8Decode_InitFromCustom_noncontiguous
260
291
+11.9%
0.89x (?)

ArrayAppendUTF16Substring
32580
35280
+8.3%
0.92x (?)

StringHashing_fastPrenormal
620
670
+8.1%
0.93x (?)

ArrayAppendAsciiSubstring
32580
35136
+7.8%
0.93x (?)

Improvement
OLD
NEW
DELTA
RATIO

ConvertFloatingPoint.MockFloat64ToDouble
2737
20
-99.3%
136.84x

EqualSubstringSubstring
29
22
-24.1%
1.32x

LessSubstringSubstring
29
22
-24.1%
1.32x

EqualStringSubstring
29
22
-24.1%
1.32x

EqualSubstringSubstringGenericEquatable
29
22
-24.1%
1.32x

EqualSubstringString
29
22
-24.1%
1.32x

LessSubstringSubstringGenericComparable
29
22
-24.1%
1.32x

Set.isSuperset.Seq.Int.Empty
95
84
-11.6%
1.13x (?)

FlattenListLoop
1548
1386
-10.5%
1.12x (?)

StringComparison_longSharedPrefix
379
341
-10.0%
1.11x (?)

Data.hash.Medium
33
30
-9.1%
1.10x (?)

Set.isDisjoint.Seq.Empty.Int
92
84
-8.7%
1.10x (?)

Set.isDisjoint.Empty.Int
92
84
-8.7%
1.10x (?)

DropFirstAnySequenceLazy
1768
1643
-7.1%
1.08x (?)

Code size: -Osize
Performance: -Onone

Regression
OLD
NEW
DELTA
RATIO

UTF8Decode_InitDecoding
149
180
+20.8%
0.83x

UTF8Decode_InitFromCustom_contiguous
154
182
+18.2%
0.85x

ConvertFloatingPoint.GenericDoubleToDouble
1143
1280
+12.0%
0.89x (?)

ArrayOfPOD
652
726
+11.3%
0.90x (?)

Improvement
OLD
NEW
DELTA
RATIO

ConvertFloatingPoint.MockFloat64ToDouble
4450
2250
-49.4%
1.98x

EqualSubstringSubstringGenericEquatable
33
26
-21.2%
1.27x

LessSubstringSubstringGenericComparable
33
26
-21.2%
1.27x

EqualSubstringSubstring
34
27
-20.6%
1.26x

LessSubstringSubstring
34
27
-20.6%
1.26x

EqualStringSubstring
34
27
-20.6%
1.26x (?)

EqualSubstringString
34
28
-17.6%
1.21x

Set.subtracting.Seq.Empty.Box
1157
1031
-10.9%
1.12x (?)

Set.subtracting.Empty.Box
221
197
-10.9%
1.12x (?)

StringAdder
426
381
-10.6%
1.12x (?)

ArrayAppendAscii
25874
23290
-10.0%
1.11x (?)

Set.isDisjoint.Empty.Box
1074
973
-9.4%
1.10x (?)

ArrayAppendLatin1
25704
23290
-9.4%
1.10x (?)

Set.isDisjoint.Box.Empty
1181
1074
-9.1%
1.10x (?)

Set.isDisjoint.Seq.Empty.Box
914
832
-9.0%
1.10x (?)

Set.subtracting.Box.Empty
246
225
-8.5%
1.09x (?)

ArrayAppendAsciiSubstring
47592
43596
-8.4%
1.09x (?)

SetIsSubsetBox0
1233
1131
-8.3%
1.09x (?)

Set.isDisjoint.Seq.Box.Empty
1128
1035
-8.2%
1.09x (?)

NSDictionaryCastToSwift
3460
3190
-7.8%
1.08x (?)

ArrayPlusEqualFiveElementCollection
176601
164724
-6.7%
1.07x (?)

ArrayValueProp4
5203
4860
-6.6%
1.07x (?)

Code size: -swiftlibs

How to read the data
The tables contain differences in performance which are larger than 8% and
differences in code size which are larger than 1%.
If you see any unexpected regressions, you should consider fixing the
regressions before you merge the PR.
Noise: Sometimes the performance results (not code size!) contain false
alarms. Unexpected regressions which are marked with '(?)' are probably noise.
If you see regressions which you cannot explain you can try to run the
benchmarks again. If regressions still show up, please consult with the
performance team (@eeckstein).

Hardware Overview
  Model Name: Mac mini
  Model Identifier: Macmini8,1
  Processor Name: 6-Core Intel Core i7
  Processor Speed: 3.2 GHz
  Number of Processors: 1
  Total Number of Cores: 6
  L2 Cache (per Core): 256 KB
  L3 Cache: 12 MB
  Memory: 64 GB

Wow. I did not expect that. Wow.

As written, the approach is sound.
The main question I have is whether it makes sense to simply use an unsafeBitCast, which would eliminate some tests from the fast path (and eliminate potential slow paths entirely). That's formally unsound, but in a way that's fundamentally uninteresting and unlikely to cause problems. In particular, we could tighten the semantic requirements of BinaryFloatingPoint to specify the layout, and make the problem go away.

I think the unsafeBitCast would certainly be a practical approach, but unless my eyes deceive me, the compiler is doing a fantastic job with this safe code.
I have already refactored to merge both switches into one that matches on encoding parameters only, which actually might be faster (it appeared, with the previous change, that there was some difference between concrete and generic Double-to-Double conversion which I would hypothesize arises from not being able to optimize away the first dynamic check whether the value can be cast to Float).
I've changed the fast path condition from value.isFinite to !value.isNaN, since the IEEE 754 specification also fixes the encoding of infinities. I'll run the benchmarks again to see where this all shakes out.

@swift-ci test

@swift-ci benchmark

@swift-ci test

@swift-ci benchmark

Performance: -O

Regression
OLD
NEW
DELTA
RATIO

AngryPhonebook.ASCII2
110
142
+29.1%
0.77x

UTF8Decode_InitFromCustom_contiguous
141
171
+21.3%
0.82x

UTF8Decode_InitDecoding
141
170
+20.6%
0.83x

ParseInt.IntSmall.Decimal
263
285
+8.4%
0.92x (?)

Improvement
OLD
NEW
DELTA
RATIO

ConvertFloatingPoint.MockFloat64ToDouble
2726
19
-99.3%
143.47x

ConvertFloatingPoint.GenericDoubleToDouble
59
15
-74.6%
3.93x

EqualSubstringSubstring
29
22
-24.1%
1.32x

LessSubstringSubstring
29
22
-24.1%
1.32x (?)

EqualStringSubstring
29
22
-24.1%
1.32x

EqualSubstringSubstringGenericEquatable
29
22
-24.1%
1.32x

EqualSubstringString
29
22
-24.1%
1.32x

LessSubstringSubstringGenericComparable
29
22
-24.1%
1.32x

StringComparison_longSharedPrefix
378
342
-9.5%
1.11x (?)

FlattenListLoop
1022
933
-8.7%
1.10x (?)

Set.isDisjoint.Seq.Empty.Int
92
84
-8.7%
1.10x (?)

Set.isDisjoint.Empty.Int
92
84
-8.7%
1.10x (?)

ArrayAppendUTF16Substring
33552
30780
-8.3%
1.09x (?)

Set.isSubset.Seq.Empty.Int
87
80
-8.0%
1.09x (?)

Set.isDisjoint.Empty.Box
94
87
-7.4%
1.08x (?)

Set.isSuperset.Seq.Int.Empty
94
87
-7.4%
1.08x (?)

Set.isDisjoint.Seq.Empty.Box
94
87
-7.4%
1.08x (?)

Code size: -O
Performance: -Osize

Regression
OLD
NEW
DELTA
RATIO

StringFromLongWholeSubstringGeneric
3
4
+33.3%
0.75x

AngryPhonebook.ASCII2
110
142
+29.1%
0.77x

UTF8Decode_InitFromCustom_contiguous
142
170
+19.7%
0.84x (?)

UTF8Decode_InitDecoding
142
169
+19.0%
0.84x (?)

UTF8Decode_InitFromCustom_noncontiguous
262
290
+10.7%
0.90x (?)

ArrayAppendUTF16Substring
32580
35388
+8.6%
0.92x (?)

ArrayAppendLatin1Substring
33300
36036
+8.2%
0.92x (?)

Improvement
OLD
NEW
DELTA
RATIO

ConvertFloatingPoint.MockFloat64ToDouble
2730
19
-99.3%
143.68x

ConvertFloatingPoint.GenericDoubleToDouble
59
15
-74.6%
3.93x

EqualSubstringSubstring
29
22
-24.1%
1.32x

LessSubstringSubstring
29
22
-24.1%
1.32x

EqualStringSubstring
29
22
-24.1%
1.32x

EqualSubstringSubstringGenericEquatable
29
22
-24.1%
1.32x

EqualSubstringString
29
22
-24.1%
1.32x

LessSubstringSubstringGenericComparable
29
22
-24.1%
1.32x

StringComparison_longSharedPrefix
379
340
-10.3%
1.11x (?)

Data.hash.Medium
33
30
-9.1%
1.10x (?)

Set.isDisjoint.Seq.Empty.Int
92
84
-8.7%
1.10x (?)

Set.isDisjoint.Empty.Int
92
84
-8.7%
1.10x (?)

Set.isDisjoint.Empty.Box
95
88
-7.4%
1.08x (?)

Set.isSuperset.Seq.Int.Empty
95
88
-7.4%
1.08x (?)

Set.isStrictSubset.Int.Empty
56
52
-7.1%
1.08x (?)

PrefixAnySequenceLazy
1327
1233
-7.1%
1.08x (?)

PrefixWhileAnySequenceLazy
1328
1234
-7.1%
1.08x (?)

DropFirstAnySequenceLazy
1768
1643
-7.1%
1.08x (?)

ArrayAppendLatin1Substring
48204
42876
-11.1%
1.12x (?)

Set.subtracting.Seq.Empty.Box
1157
1032
-10.8%
1.12x

Set.isDisjoint.Seq.Empty.Box
915
819
-10.5%
1.12x

Set.subtracting.Empty.Box
222
200
-9.9%
1.11x

ArrayAppendAscii
25840
23290
-9.9%
1.11x (?)

DropFirstAnySequenceLazy
9461
8541
-9.7%
1.11x (?)

StringWalk
3320
3000
-9.6%
1.11x (?)

ArrayAppendLatin1
25738
23290
-9.5%
1.11x (?)

Set.subtracting.Box.Empty
247
225
-8.9%
1.10x

Set.isDisjoint.Box.Empty
1182
1078
-8.8%
1.10x (?)

Set.isDisjoint.Empty.Box
1073
979
-8.8%
1.10x (?)

Set.isDisjoint.Seq.Box.Empty
1124
1026
-8.7%
1.10x (?)

Set.subtracting.Seq.Empty.Int
554
508
-8.3%
1.09x (?)

StringAdder
423
389
-8.0%
1.09x (?)

SetIsSubsetBox0
1232
1135
-7.9%
1.09x (?)

StackPromo
75200
69300
-7.8%
1.09x (?)

DropWhileAnySequenceLazy
12352
11415
-7.6%
1.08x (?)

PrefixSequence
6959
6486
-6.8%
1.07x (?)

Code size: -swiftlibs

How to read the data
The tables contain differences in performance which are larger than 8% and
differences in code size which are larger than 1%.
If you see any unexpected regressions, you should consider fixing the
regressions before you merge the PR.
Noise: Sometimes the performance results (not code size!) contain false
alarms. Unexpected regressions which are marked with '(?)' are probably noise.
If you see regressions which you cannot explain you can try to run the
benchmarks again. If regressions still show up, please consult with the
performance team (@eeckstein).

Hardware Overview
  Model Name: Mac mini
  Model Identifier: Macmini8,1
  Processor Name: 6-Core Intel Core i7
  Processor Speed: 3.2 GHz
  Number of Processors: 1
  Total Number of Cores: 6
  L2 Cache (per Core): 256 KB
  L3 Cache: 12 MB
  Memory: 64 GB

func convert<
  T: BinaryFloatingPoint, U: BinaryFloatingPoint
>(_ value: T, to: U.Type) -> U {
  U(value)
}

func testDoubleToDouble(_ x: Double) -> Double {
  return convert(x, to: Double.self)
}

func testDoubleToFloat(_ x: Double) -> Float {
  return convert(x, to: Float.self)
}

The SIL generated for conversion between known stdlib types is perfect:
// testDoubleToDouble(_:)
sil hidden @$s5input012testDoubleToC0yS2dF : $@convention(thin) (Double) -> Double {
// %0 "x"                                         // users: %2, %3, %1
bb0(%0 : $Double):
  debug_value %0 : $Double, let, name "x", argno 1 // id: %1
  debug_value %0 : $Double, let, name "value", argno 1 // id: %2
  return %0 : $Double                             // id: %3
} // end sil function '$s5input012testDoubleToC0yS2dF'

// testDoubleToFloat(_:)
sil hidden @$s5input17testDoubleToFloatySfSdF : $@convention(thin) (Double) -> Float {
// %0 "x"                                         // users: %2, %3, %1
bb0(%0 : $Double):
  debug_value %0 : $Double, let, name "x", argno 1 // id: %1
  debug_value %0 : $Double, let, name "value", argno 1 // id: %2
  %3 = struct_extract %0 : $Double, #Double._value // user: %4
  %4 = builtin "fptrunc_FPIEEE64_FPIEEE32"(%3 : $Builtin.FPIEEE64) : $Builtin.FPIEEE32 // user: %5
  %5 = struct $Float (%4 : $Builtin.FPIEEE32)     // user: %6
  return %5 : $Float                              // id: %6
} // end sil function '$s5input17testDoubleToFloatySfSdF'

...for MockFloat64, not so much.

Can we factor the !isNaN out of the switch?

@stephentyrone Yeah, I'm not totally satisfied with the control flow here, so I'm going to try something.
I don't think there's any harm--even theoretical--in preserving the encoding of any NaN values as-is between two types with the same exponent and significand bit width; there is the Float/Double/Float80-to-Self conversion afterwards in any case that will do its thing. Therefore, I'm going to delete the check for NaN and refactor accordingly.
It makes the whole implementation a lot more concise. I'll have to see if it affects code generation though.

@swift-ci test

@swift-ci benchmark

@swift-ci test

@swift-ci benchmark

@swift-ci test macOS platform

@swift-ci test Linux platform

@swift-ci benchmark

@swift-ci test macOS platform

@swift-ci test macOS platform please?

@swift-ci benchmark

It makes the whole implementation a lot more concise. I'll have to see if it affects code generation though.

Code generation for standard library types is good.

@swift-ci benchmark

@swift-ci benchmark

@swift-ci test

@xwu CI outage. Should be restored now.

@swift-ci test Windows platform

Performance: -O

Regression
OLD
NEW
DELTA
RATIO

AngryPhonebook.ASCII2
109
144
+32.1%
0.76x

EqualSubstringSubstring
22
29
+31.8%
0.76x

LessSubstringSubstring
22
29
+31.8%
0.76x (?)

EqualSubstringSubstringGenericEquatable
22
29
+31.8%
0.76x

EqualSubstringString
22
29
+31.8%
0.76x

LessSubstringSubstringGenericComparable
22
29
+31.8%
0.76x

EqualStringSubstring
23
29
+26.1%
0.79x

NopDeinit
8800
9900
+12.5%
0.89x

StringComparison_longSharedPrefix
341
379
+11.1%
0.90x (?)

ObjectiveCBridgeStringHash
82
89
+8.5%
0.92x (?)

Improvement
OLD
NEW
DELTA
RATIO

ConvertFloatingPoint.MockFloat64ToDouble
2707
16
-99.4%
169.18x

Dictionary4
194
149
-23.2%
1.30x

Dictionary4OfObjects
223
184
-17.5%
1.21x

Set.isDisjoint.Int.Empty
59
53
-10.2%
1.11x (?)

Set.isDisjoint.Seq.Empty.Int
92
84
-8.7%
1.10x (?)

Set.isDisjoint.Empty.Int
92
84
-8.7%
1.10x

StringHashing_latin1
230
212
-7.8%
1.08x (?)

NSDictionaryCastToSwift
1440
1330
-7.6%
1.08x (?)

StringHashing_fastPrenormal
660
610
-7.6%
1.08x (?)

Set.isSuperset.Seq.Int.Empty
94
87
-7.4%
1.08x

Set.isStrictSubset.Empty.Int
139
129
-7.2%
1.08x (?)

Code size: -O
Performance: -Osize

Regression
OLD
NEW
DELTA
RATIO

AngryPhonebook.ASCII2
109
144
+32.1%
0.76x

EqualSubstringSubstring
22
29
+31.8%
0.76x

LessSubstringSubstring
22
29
+31.8%
0.76x

EqualStringSubstring
22
29
+31.8%
0.76x (?)

EqualSubstringSubstringGenericEquatable
22
29
+31.8%
0.76x

EqualSubstringString
22
29
+31.8%
0.76x

LessSubstringSubstringGenericComparable
22
29
+31.8%
0.76x

StringComparison_longSharedPrefix
341
377
+10.6%
0.90x (?)

ObjectiveCBridgeStringHash
82
89
+8.5%
0.92x (?)

NSStringConversion.Long
612
662
+8.2%
0.92x (?)

Improvement
OLD
NEW
DELTA
RATIO

ConvertFloatingPoint.MockFloat64ToDouble
2706
16
-99.4%
169.11x

CharacterLiteralsLarge
71
63
-11.3%
1.13x (?)

ArrayLiteral2
116
104
-10.3%
1.12x (?)

StrComplexWalk
3280
2960
-9.8%
1.11x (?)

Set.isSubset.Seq.Empty.Int
88
80
-9.1%
1.10x (?)

PrefixWhileSequence
234
213
-9.0%
1.10x (?)

Set.isDisjoint.Seq.Empty.Int
92
84
-8.7%
1.10x (?)

Set.isDisjoint.Empty.Int
92
84
-8.7%
1.10x (?)

Set.isDisjoint.Int.Empty
61
56
-8.2%
1.09x (?)

StringHashing_latin1
230
212
-7.8%
1.08x (?)

NormalizedIterator_fastPrenormal
790
730
-7.6%
1.08x (?)

StringHashing_fastPrenormal
660
610
-7.6%
1.08x (?)

Set.isDisjoint.Empty.Box
95
88
-7.4%
1.08x (?)

Set.isSuperset.Seq.Int.Empty
95
88
-7.4%
1.08x (?)

StringWalk
1640
1520
-7.3%
1.08x (?)

Set.isStrictSubset.Int.Empty
56
52
-7.1%
1.08x (?)

Set.isDisjoint.Seq.Int100
128
119
-7.0%
1.08x (?)

NormalizedIterator_latin1
270
252
-6.7%
1.07x (?)

Code size: -Osize
Performance: -Onone

Regression
OLD
NEW
DELTA
RATIO

AngryPhonebook.ASCII2
109
144
+32.1%
0.76x

EqualStringSubstring
27
35
+29.6%
0.77x

EqualSubstringSubstring
27
34
+25.9%
0.79x

LessSubstringSubstring
27
34
+25.9%
0.79x

EqualSubstringSubstringGenericEquatable
27
33
+22.2%
0.82x

LessSubstringSubstringGenericComparable
27
33
+22.2%
0.82x (?)

EqualSubstringString
28
34
+21.4%
0.82x

StringWalk
3000
3360
+12.0%
0.89x (?)

Improvement
OLD
NEW
DELTA
RATIO

ConvertFloatingPoint.MockFloat64ToDouble
4524
1608
-64.5%
2.81x

ArrayAppendAsciiSubstring
50400
44136
-12.4%
1.14x (?)

ArrayAppendLatin1Substring
50832
44604
-12.3%
1.14x (?)

ArrayAppendUTF16Substring
50292
44460
-11.6%
1.13x (?)

DropWhileSequenceLazy
12237
10863
-11.2%
1.13x (?)

Set.subtracting.Empty.Box
224
201
-10.3%
1.11x (?)

ArrayAppendAscii
25772
23222
-9.9%
1.11x (?)

SequenceAlgosUnfoldSequence
5790
5240
-9.5%
1.10x (?)

NSDictionaryCastToSwift
3490
3160
-9.5%
1.10x (?)

Set.isDisjoint.Seq.Empty.Box
926
840
-9.3%
1.10x (?)

Set.isDisjoint.Box.Empty
1182
1076
-9.0%
1.10x (?)

ArrayAppendLatin1
25568
23290
-8.9%
1.10x (?)

Set.subtracting.Seq.Empty.Box
1153
1051
-8.8%
1.10x (?)

DropWhileSequence
12360
11280
-8.7%
1.10x (?)

Combos
2040
1866
-8.5%
1.09x (?)

Set.isDisjoint.Seq.Box.Empty
1119
1027
-8.2%
1.09x (?)

Set.isDisjoint.Empty.Box
1086
1002
-7.7%
1.08x (?)

StringMatch
50000
46200
-7.6%
1.08x (?)

DropWhileAnySequenceLazy
12046
11145
-7.5%
1.08x (?)

ArrayInitFromSlice
616
574
-6.8%
1.07x (?)

PrefixWhileSequenceLazy
10275
9602
-6.5%
1.07x (?)

Code size: -swiftlibs

How to read the data
The tables contain differences in performance which are larger than 8% and
differences in code size which are larger than 1%.
If you see any unexpected regressions, you should consider fixing the
regressions before you merge the PR.
Noise: Sometimes the performance results (not code size!) contain false
alarms. Unexpected regressions which are marked with '(?)' are probably noise.
If you see regressions which you cannot explain you can try to run the
benchmarks again. If regressions still show up, please consult with the
performance team (@eeckstein).

Hardware Overview
  Model Name: Mac mini
  Model Identifier: Macmini8,1
  Processor Name: 6-Core Intel Core i7
  Processor Speed: 3.2 GHz
  Number of Processors: 1
  Total Number of Cores: 6
  L2 Cache (per Core): 256 KB
  L3 Cache: 12 MB
  Memory: 64 GB

@swift-ci test Windows platform

@stephentyrone Thoughts on the latest (and simplest) iteration?

Seems reasonable to me. I would like to have a cleaner solution, but this is an acceptable stopgap.
We have to do due diligence on the regressions still. I'm fairly certain that they're just noise, but it would be good to disassemble the worst few and make sure there isn't a real problem somehow caused by this change (I can help with this).

Sure, your help with that would be great. The String/Substring tests oscillate between 22 and 29 μs (see earlier iterations of the benchmarks), but it would be worth confirming that we're not missing anything.

@stephentyrone Disassembly of AngryPhonebook.o, NopDeinit.o, and Substring.o (optimized x86_64) is identical before and after applying this patch.

@swift-ci test Windows platform


Change the FactoryMethodQuery behavior to skip pseudo factory methods

Addresses issue #643.

Thank you for your contribution :+1: – I left a comment in #643 and another one here.

LGTM :+1:
This Pull Request makes sense, as it improves the heuristic we currently have for static Factory Methods.

As far as I understand this pull request, it skips 'impossible' 'factory' methods, effectively ignoring that they exist. Did I misunderstand anything?

That is correct.

What AutoFixture usually does when detecting something that's 'wrong' is to throw an exception with a more detailed error message, explaining what the problem is, and how to address it. See e.g. https://github.com/AutoFixture/AutoFixture/issues/94 or https://github.com/AutoFixture/AutoFixture/issues/19.
Is there any case where the design described in #643 is appropriate?

If I understand you correctly, the suggestion is to stop trying to bypass the 'inconvenient' API and give a developer as much details as possible. Is this what you're saying?
The current error message that @moodmosaic has mentioned earlier contains the class info but says nothing about the factory method that cause the problem (public static Stream Synchronized(Stream stream) in my case). Would you like to see the method name mentioned in the exception message?

@ploeh FWIW, i think the problem is it gives a lot of irrelevant details about a method that is not a factory method (because it requires an instance of itself as input). Attempting to use it as a factory method then reporting detailed failure is sending the developers in the wrong direction.
AFAICT...

Is there any case where the design described in #643 is appropriate?

Sorry, I didn't get this part completely... Are you asking why would one design a class like I described in #643? Could you please elaborate on this. Thanks.

At the moment, I'm trying to understand if there might be a good reason for designing a method like that.
If there could be a proper reason for such a design, then I agree that the best AutoFixture can do is to skip that method.
When I originally saw this pull request, I was inclined to think it was an issue like #94 - that is: something that compiles, but can never work.
When it comes to System.IO.Stream.Synchronized, the design looks a bit odd, but it turns out that it's still possible to use such a method. At first, I didn't realise that, because I'm not used to thinking in inheritance hierarchies :flushed:
As such, I agree that this isn't a factory, and that the current algorithm needs adjustment.
I've reversed my thinking on this within the last 30 minutes, so I need to let it sit a bit longer, but at the moment, I'm inclined to go forward with this.

Thank you for your contribution; it's now available as AutoFixture 3.47.7.