2025-03-06 18:01:24 -05:00
|
|
|
```mermaid
|
|
|
|
|
flowchart LR
|
2025-04-29 06:38:52 -07:00
|
|
|
subgraph path18 [Path]
|
2025-05-06 08:44:03 +12:00
|
|
|
18["Path<br>[409, 452, 2]"]
|
|
|
|
|
38["Segment<br>[458, 496, 2]"]
|
|
|
|
|
39["Segment<br>[502, 542, 2]"]
|
|
|
|
|
40["Segment<br>[548, 587, 2]"]
|
|
|
|
|
41["Segment<br>[593, 615, 2]"]
|
Avoid using full revolve for now (#6912)
Avoid using revolve for now
When we moved to concurrent execution of KCL modules, we begun to see an
error we never fully understood, and because it was pretty hard to
trigger, we wound up never being able to fix it. Today we were able to
track it down to the `revolve` call here.
Specifically, the problem is triggered when we're doing a "Full Revolve"
(e.g., `angle = 359.999999` passes, but *not* `angle = 360` or the
default, as it is in `main`), and concurrently executing modules will
see something weird happen with `getNextAdjacentEdge`.
From all the smoke I believe this happens only when we are doing a *full
revolve*, *AND* we're executing other modules which are calling
`getNextAdjacentEdge`.
When the `revolve` is present, we can lose the race in *either*
`talk-button.kcl` OR `case.kcl`.
If I move back to single-threaded execution OR I add imports to sequence
things carefully, I can get the tests to pass. If the revolve is an
`extrude` or not a full revolve, it works fine.
My best guess is that it seems like the world got flipped upside down or
something, such that "next edge" has a different orentation for two
calls. My even further guess is that inside `revolve` we mutate
something connection-global such that it alters the intepretation of
calls made during the revolve implementation's "critical section".
2025-05-13 16:20:48 -04:00
|
|
|
149[Solid2d]
|
2025-03-06 18:01:24 -05:00
|
|
|
end
|
2025-04-29 06:38:52 -07:00
|
|
|
subgraph path19 [Path]
|
2025-05-06 08:44:03 +12:00
|
|
|
19["Path<br>[986, 1103, 2]"]
|
|
|
|
|
42["Segment<br>[1109, 1167, 2]"]
|
|
|
|
|
43["Segment<br>[1173, 1290, 2]"]
|
|
|
|
|
44["Segment<br>[1296, 1354, 2]"]
|
|
|
|
|
45["Segment<br>[1360, 1480, 2]"]
|
|
|
|
|
46["Segment<br>[1486, 1547, 2]"]
|
|
|
|
|
47["Segment<br>[1553, 1674, 2]"]
|
|
|
|
|
48["Segment<br>[1680, 1740, 2]"]
|
|
|
|
|
49["Segment<br>[1746, 1753, 2]"]
|
2025-05-13 21:07:24 -07:00
|
|
|
137[Solid2d]
|
2025-03-06 18:01:24 -05:00
|
|
|
end
|
2025-04-29 06:38:52 -07:00
|
|
|
subgraph path20 [Path]
|
2025-05-06 08:44:03 +12:00
|
|
|
20["Path<br>[1908, 1962, 2]"]
|
|
|
|
|
50["Segment<br>[1968, 2009, 2]"]
|
|
|
|
|
51["Segment<br>[2015, 2044, 2]"]
|
|
|
|
|
52["Segment<br>[2050, 2080, 2]"]
|
|
|
|
|
53["Segment<br>[2086, 2142, 2]"]
|
|
|
|
|
54["Segment<br>[2148, 2155, 2]"]
|
2025-05-13 21:07:24 -07:00
|
|
|
148[Solid2d]
|
2025-03-06 18:01:24 -05:00
|
|
|
end
|
2025-04-29 06:38:52 -07:00
|
|
|
subgraph path21 [Path]
|
2025-05-06 08:44:03 +12:00
|
|
|
21["Path<br>[2298, 2335, 2]"]
|
|
|
|
|
55["Segment<br>[2341, 2372, 2]"]
|
|
|
|
|
56["Segment<br>[2378, 2411, 2]"]
|
|
|
|
|
57["Segment<br>[2417, 2449, 2]"]
|
|
|
|
|
58["Segment<br>[2455, 2462, 2]"]
|
2025-05-13 21:07:24 -07:00
|
|
|
138[Solid2d]
|
2025-03-06 18:01:24 -05:00
|
|
|
end
|
2025-04-29 06:38:52 -07:00
|
|
|
subgraph path22 [Path]
|
2025-05-06 08:44:03 +12:00
|
|
|
22["Path<br>[496, 550, 3]"]
|
|
|
|
|
59["Segment<br>[556, 583, 3]"]
|
|
|
|
|
60["Segment<br>[589, 618, 3]"]
|
|
|
|
|
61["Segment<br>[624, 652, 3]"]
|
|
|
|
|
62["Segment<br>[658, 714, 3]"]
|
|
|
|
|
63["Segment<br>[720, 727, 3]"]
|
2025-05-13 21:07:24 -07:00
|
|
|
135[Solid2d]
|
2025-03-06 18:01:24 -05:00
|
|
|
end
|
2025-04-29 06:38:52 -07:00
|
|
|
subgraph path23 [Path]
|
2025-05-08 14:43:50 -04:00
|
|
|
23["Path<br>[1000, 1047, 3]"]
|
|
|
|
|
64["Segment<br>[1053, 1094, 3]"]
|
|
|
|
|
65["Segment<br>[1100, 1142, 3]"]
|
|
|
|
|
66["Segment<br>[1148, 1190, 3]"]
|
|
|
|
|
67["Segment<br>[1196, 1203, 3]"]
|
Avoid using full revolve for now (#6912)
Avoid using revolve for now
When we moved to concurrent execution of KCL modules, we begun to see an
error we never fully understood, and because it was pretty hard to
trigger, we wound up never being able to fix it. Today we were able to
track it down to the `revolve` call here.
Specifically, the problem is triggered when we're doing a "Full Revolve"
(e.g., `angle = 359.999999` passes, but *not* `angle = 360` or the
default, as it is in `main`), and concurrently executing modules will
see something weird happen with `getNextAdjacentEdge`.
From all the smoke I believe this happens only when we are doing a *full
revolve*, *AND* we're executing other modules which are calling
`getNextAdjacentEdge`.
When the `revolve` is present, we can lose the race in *either*
`talk-button.kcl` OR `case.kcl`.
If I move back to single-threaded execution OR I add imports to sequence
things carefully, I can get the tests to pass. If the revolve is an
`extrude` or not a full revolve, it works fine.
My best guess is that it seems like the world got flipped upside down or
something, such that "next edge" has a different orentation for two
calls. My even further guess is that inside `revolve` we mutate
something connection-global such that it alters the intepretation of
calls made during the revolve implementation's "critical section".
2025-05-13 16:20:48 -04:00
|
|
|
146[Solid2d]
|
2025-03-06 18:01:24 -05:00
|
|
|
end
|
2025-04-29 06:38:52 -07:00
|
|
|
subgraph path24 [Path]
|
2025-05-08 14:43:50 -04:00
|
|
|
24["Path<br>[1461, 1612, 3]"]
|
|
|
|
|
68["Segment<br>[1618, 1694, 3]"]
|
|
|
|
|
69["Segment<br>[1700, 1853, 3]"]
|
|
|
|
|
70["Segment<br>[1859, 1935, 3]"]
|
|
|
|
|
71["Segment<br>[1941, 2097, 3]"]
|
|
|
|
|
72["Segment<br>[2103, 2180, 3]"]
|
|
|
|
|
73["Segment<br>[2186, 2341, 3]"]
|
|
|
|
|
74["Segment<br>[2347, 2423, 3]"]
|
|
|
|
|
75["Segment<br>[2429, 2436, 3]"]
|
2025-05-13 21:07:24 -07:00
|
|
|
133[Solid2d]
|
2025-03-06 18:01:24 -05:00
|
|
|
end
|
2025-04-29 06:38:52 -07:00
|
|
|
subgraph path25 [Path]
|
2025-05-02 10:41:14 -07:00
|
|
|
25["Path<br>[123, 210, 4]"]
|
|
|
|
|
76["Segment<br>[218, 247, 4]"]
|
|
|
|
|
77["Segment<br>[255, 283, 4]"]
|
|
|
|
|
78["Segment<br>[291, 369, 4]"]
|
|
|
|
|
79["Segment<br>[377, 424, 4]"]
|
|
|
|
|
80["Segment<br>[432, 460, 4]"]
|
|
|
|
|
81["Segment<br>[468, 497, 4]"]
|
|
|
|
|
82["Segment<br>[505, 534, 4]"]
|
|
|
|
|
83["Segment<br>[542, 608, 4]"]
|
|
|
|
|
84["Segment<br>[616, 644, 4]"]
|
|
|
|
|
85["Segment<br>[652, 681, 4]"]
|
|
|
|
|
86["Segment<br>[689, 751, 4]"]
|
|
|
|
|
87["Segment<br>[759, 787, 4]"]
|
|
|
|
|
88["Segment<br>[795, 829, 4]"]
|
|
|
|
|
89["Segment<br>[837, 867, 4]"]
|
|
|
|
|
90["Segment<br>[875, 943, 4]"]
|
|
|
|
|
91["Segment<br>[951, 958, 4]"]
|
2025-05-13 21:07:24 -07:00
|
|
|
136[Solid2d]
|
2025-03-06 18:01:24 -05:00
|
|
|
end
|
2025-04-29 06:38:52 -07:00
|
|
|
subgraph path26 [Path]
|
2025-05-02 10:41:14 -07:00
|
|
|
26["Path<br>[1092, 1190, 4]"]
|
|
|
|
|
92["Segment<br>[1198, 1276, 4]"]
|
|
|
|
|
95["Segment<br>[1284, 1331, 4]"]
|
|
|
|
|
97["Segment<br>[1339, 1419, 4]"]
|
|
|
|
|
99["Segment<br>[1427, 1434, 4]"]
|
Avoid using full revolve for now (#6912)
Avoid using revolve for now
When we moved to concurrent execution of KCL modules, we begun to see an
error we never fully understood, and because it was pretty hard to
trigger, we wound up never being able to fix it. Today we were able to
track it down to the `revolve` call here.
Specifically, the problem is triggered when we're doing a "Full Revolve"
(e.g., `angle = 359.999999` passes, but *not* `angle = 360` or the
default, as it is in `main`), and concurrently executing modules will
see something weird happen with `getNextAdjacentEdge`.
From all the smoke I believe this happens only when we are doing a *full
revolve*, *AND* we're executing other modules which are calling
`getNextAdjacentEdge`.
When the `revolve` is present, we can lose the race in *either*
`talk-button.kcl` OR `case.kcl`.
If I move back to single-threaded execution OR I add imports to sequence
things carefully, I can get the tests to pass. If the revolve is an
`extrude` or not a full revolve, it works fine.
My best guess is that it seems like the world got flipped upside down or
something, such that "next edge" has a different orentation for two
calls. My even further guess is that inside `revolve` we mutate
something connection-global such that it alters the intepretation of
calls made during the revolve implementation's "critical section".
2025-05-13 16:20:48 -04:00
|
|
|
147[Solid2d]
|
2025-03-06 18:01:24 -05:00
|
|
|
end
|
2025-04-29 06:38:52 -07:00
|
|
|
subgraph path27 [Path]
|
2025-05-02 10:41:14 -07:00
|
|
|
27["Path<br>[1092, 1190, 4]"]
|
|
|
|
|
93["Segment<br>[1198, 1276, 4]"]
|
|
|
|
|
94["Segment<br>[1284, 1331, 4]"]
|
|
|
|
|
96["Segment<br>[1339, 1419, 4]"]
|
|
|
|
|
98["Segment<br>[1427, 1434, 4]"]
|
Avoid using full revolve for now (#6912)
Avoid using revolve for now
When we moved to concurrent execution of KCL modules, we begun to see an
error we never fully understood, and because it was pretty hard to
trigger, we wound up never being able to fix it. Today we were able to
track it down to the `revolve` call here.
Specifically, the problem is triggered when we're doing a "Full Revolve"
(e.g., `angle = 359.999999` passes, but *not* `angle = 360` or the
default, as it is in `main`), and concurrently executing modules will
see something weird happen with `getNextAdjacentEdge`.
From all the smoke I believe this happens only when we are doing a *full
revolve*, *AND* we're executing other modules which are calling
`getNextAdjacentEdge`.
When the `revolve` is present, we can lose the race in *either*
`talk-button.kcl` OR `case.kcl`.
If I move back to single-threaded execution OR I add imports to sequence
things carefully, I can get the tests to pass. If the revolve is an
`extrude` or not a full revolve, it works fine.
My best guess is that it seems like the world got flipped upside down or
something, such that "next edge" has a different orentation for two
calls. My even further guess is that inside `revolve` we mutate
something connection-global such that it alters the intepretation of
calls made during the revolve implementation's "critical section".
2025-05-13 16:20:48 -04:00
|
|
|
152[Solid2d]
|
2025-04-29 06:38:52 -07:00
|
|
|
end
|
|
|
|
|
subgraph path28 [Path]
|
2025-05-02 10:41:14 -07:00
|
|
|
28["Path<br>[1531, 1628, 4]"]
|
|
|
|
|
101["Segment<br>[1636, 1714, 4]"]
|
|
|
|
|
103["Segment<br>[1722, 1770, 4]"]
|
|
|
|
|
104["Segment<br>[1778, 1858, 4]"]
|
|
|
|
|
106["Segment<br>[1866, 1873, 4]"]
|
2025-05-13 21:07:24 -07:00
|
|
|
139[Solid2d]
|
2025-03-06 18:01:24 -05:00
|
|
|
end
|
2025-04-29 06:38:52 -07:00
|
|
|
subgraph path29 [Path]
|
2025-05-02 10:41:14 -07:00
|
|
|
29["Path<br>[1531, 1628, 4]"]
|
|
|
|
|
100["Segment<br>[1636, 1714, 4]"]
|
|
|
|
|
102["Segment<br>[1722, 1770, 4]"]
|
|
|
|
|
105["Segment<br>[1778, 1858, 4]"]
|
|
|
|
|
107["Segment<br>[1866, 1873, 4]"]
|
2025-05-13 21:07:24 -07:00
|
|
|
142[Solid2d]
|
2025-03-06 18:01:24 -05:00
|
|
|
end
|
2025-04-29 06:38:52 -07:00
|
|
|
subgraph path30 [Path]
|
Avoid using full revolve for now (#6912)
Avoid using revolve for now
When we moved to concurrent execution of KCL modules, we begun to see an
error we never fully understood, and because it was pretty hard to
trigger, we wound up never being able to fix it. Today we were able to
track it down to the `revolve` call here.
Specifically, the problem is triggered when we're doing a "Full Revolve"
(e.g., `angle = 359.999999` passes, but *not* `angle = 360` or the
default, as it is in `main`), and concurrently executing modules will
see something weird happen with `getNextAdjacentEdge`.
From all the smoke I believe this happens only when we are doing a *full
revolve*, *AND* we're executing other modules which are calling
`getNextAdjacentEdge`.
When the `revolve` is present, we can lose the race in *either*
`talk-button.kcl` OR `case.kcl`.
If I move back to single-threaded execution OR I add imports to sequence
things carefully, I can get the tests to pass. If the revolve is an
`extrude` or not a full revolve, it works fine.
My best guess is that it seems like the world got flipped upside down or
something, such that "next edge" has a different orentation for two
calls. My even further guess is that inside `revolve` we mutate
something connection-global such that it alters the intepretation of
calls made during the revolve implementation's "critical section".
2025-05-13 16:20:48 -04:00
|
|
|
30["Path<br>[348, 434, 5]"]
|
|
|
|
|
108["Segment<br>[440, 473, 5]"]
|
|
|
|
|
109["Segment<br>[479, 514, 5]"]
|
|
|
|
|
110["Segment<br>[520, 554, 5]"]
|
|
|
|
|
111["Segment<br>[560, 567, 5]"]
|
2025-05-13 21:07:24 -07:00
|
|
|
134[Solid2d]
|
2025-03-06 18:01:24 -05:00
|
|
|
end
|
2025-04-29 06:38:52 -07:00
|
|
|
subgraph path31 [Path]
|
Avoid using full revolve for now (#6912)
Avoid using revolve for now
When we moved to concurrent execution of KCL modules, we begun to see an
error we never fully understood, and because it was pretty hard to
trigger, we wound up never being able to fix it. Today we were able to
track it down to the `revolve` call here.
Specifically, the problem is triggered when we're doing a "Full Revolve"
(e.g., `angle = 359.999999` passes, but *not* `angle = 360` or the
default, as it is in `main`), and concurrently executing modules will
see something weird happen with `getNextAdjacentEdge`.
From all the smoke I believe this happens only when we are doing a *full
revolve*, *AND* we're executing other modules which are calling
`getNextAdjacentEdge`.
When the `revolve` is present, we can lose the race in *either*
`talk-button.kcl` OR `case.kcl`.
If I move back to single-threaded execution OR I add imports to sequence
things carefully, I can get the tests to pass. If the revolve is an
`extrude` or not a full revolve, it works fine.
My best guess is that it seems like the world got flipped upside down or
something, such that "next edge" has a different orentation for two
calls. My even further guess is that inside `revolve` we mutate
something connection-global such that it alters the intepretation of
calls made during the revolve implementation's "critical section".
2025-05-13 16:20:48 -04:00
|
|
|
31["Path<br>[703, 830, 5]"]
|
|
|
|
|
150[Solid2d]
|
2025-03-06 18:01:24 -05:00
|
|
|
end
|
2025-04-29 06:38:52 -07:00
|
|
|
subgraph path32 [Path]
|
2025-05-06 08:44:03 +12:00
|
|
|
32["Path<br>[279, 372, 6]"]
|
|
|
|
|
112["Segment<br>[378, 427, 6]"]
|
|
|
|
|
113["Segment<br>[433, 483, 6]"]
|
|
|
|
|
114["Segment<br>[489, 539, 6]"]
|
|
|
|
|
115["Segment<br>[545, 563, 6]"]
|
Avoid using full revolve for now (#6912)
Avoid using revolve for now
When we moved to concurrent execution of KCL modules, we begun to see an
error we never fully understood, and because it was pretty hard to
trigger, we wound up never being able to fix it. Today we were able to
track it down to the `revolve` call here.
Specifically, the problem is triggered when we're doing a "Full Revolve"
(e.g., `angle = 359.999999` passes, but *not* `angle = 360` or the
default, as it is in `main`), and concurrently executing modules will
see something weird happen with `getNextAdjacentEdge`.
From all the smoke I believe this happens only when we are doing a *full
revolve*, *AND* we're executing other modules which are calling
`getNextAdjacentEdge`.
When the `revolve` is present, we can lose the race in *either*
`talk-button.kcl` OR `case.kcl`.
If I move back to single-threaded execution OR I add imports to sequence
things carefully, I can get the tests to pass. If the revolve is an
`extrude` or not a full revolve, it works fine.
My best guess is that it seems like the world got flipped upside down or
something, such that "next edge" has a different orentation for two
calls. My even further guess is that inside `revolve` we mutate
something connection-global such that it alters the intepretation of
calls made during the revolve implementation's "critical section".
2025-05-13 16:20:48 -04:00
|
|
|
151[Solid2d]
|
2025-03-06 18:01:24 -05:00
|
|
|
end
|
2025-04-29 06:38:52 -07:00
|
|
|
subgraph path33 [Path]
|
Avoid using full revolve for now (#6912)
Avoid using revolve for now
When we moved to concurrent execution of KCL modules, we begun to see an
error we never fully understood, and because it was pretty hard to
trigger, we wound up never being able to fix it. Today we were able to
track it down to the `revolve` call here.
Specifically, the problem is triggered when we're doing a "Full Revolve"
(e.g., `angle = 359.999999` passes, but *not* `angle = 360` or the
default, as it is in `main`), and concurrently executing modules will
see something weird happen with `getNextAdjacentEdge`.
From all the smoke I believe this happens only when we are doing a *full
revolve*, *AND* we're executing other modules which are calling
`getNextAdjacentEdge`.
When the `revolve` is present, we can lose the race in *either*
`talk-button.kcl` OR `case.kcl`.
If I move back to single-threaded execution OR I add imports to sequence
things carefully, I can get the tests to pass. If the revolve is an
`extrude` or not a full revolve, it works fine.
My best guess is that it seems like the world got flipped upside down or
something, such that "next edge" has a different orentation for two
calls. My even further guess is that inside `revolve` we mutate
something connection-global such that it alters the intepretation of
calls made during the revolve implementation's "critical section".
2025-05-13 16:20:48 -04:00
|
|
|
33["Path<br>[333, 400, 7]"]
|
|
|
|
|
116["Segment<br>[333, 400, 7]"]
|
2025-05-13 21:07:24 -07:00
|
|
|
144[Solid2d]
|
2025-04-26 21:21:26 -07:00
|
|
|
end
|
2025-04-29 06:38:52 -07:00
|
|
|
subgraph path34 [Path]
|
2025-05-06 08:44:03 +12:00
|
|
|
34["Path<br>[416, 441, 8]"]
|
2025-05-13 21:07:24 -07:00
|
|
|
120["Segment<br>[449, 507, 8]"]
|
|
|
|
|
122["Segment<br>[515, 574, 8]"]
|
|
|
|
|
125["Segment<br>[582, 625, 8]"]
|
Avoid using full revolve for now (#6912)
Avoid using revolve for now
When we moved to concurrent execution of KCL modules, we begun to see an
error we never fully understood, and because it was pretty hard to
trigger, we wound up never being able to fix it. Today we were able to
track it down to the `revolve` call here.
Specifically, the problem is triggered when we're doing a "Full Revolve"
(e.g., `angle = 359.999999` passes, but *not* `angle = 360` or the
default, as it is in `main`), and concurrently executing modules will
see something weird happen with `getNextAdjacentEdge`.
From all the smoke I believe this happens only when we are doing a *full
revolve*, *AND* we're executing other modules which are calling
`getNextAdjacentEdge`.
When the `revolve` is present, we can lose the race in *either*
`talk-button.kcl` OR `case.kcl`.
If I move back to single-threaded execution OR I add imports to sequence
things carefully, I can get the tests to pass. If the revolve is an
`extrude` or not a full revolve, it works fine.
My best guess is that it seems like the world got flipped upside down or
something, such that "next edge" has a different orentation for two
calls. My even further guess is that inside `revolve` we mutate
something connection-global such that it alters the intepretation of
calls made during the revolve implementation's "critical section".
2025-05-13 16:20:48 -04:00
|
|
|
130["Segment<br>[633, 640, 8]"]
|
2025-05-13 21:07:24 -07:00
|
|
|
140[Solid2d]
|
2025-04-26 21:21:26 -07:00
|
|
|
end
|
2025-04-29 06:38:52 -07:00
|
|
|
subgraph path35 [Path]
|
2025-05-06 08:44:03 +12:00
|
|
|
35["Path<br>[416, 441, 8]"]
|
2025-05-13 21:07:24 -07:00
|
|
|
117["Segment<br>[449, 507, 8]"]
|
|
|
|
|
123["Segment<br>[515, 574, 8]"]
|
|
|
|
|
128["Segment<br>[582, 625, 8]"]
|
|
|
|
|
132["Segment<br>[633, 640, 8]"]
|
|
|
|
|
141[Solid2d]
|
2025-03-06 18:01:24 -05:00
|
|
|
end
|
2025-04-29 06:38:52 -07:00
|
|
|
subgraph path36 [Path]
|
2025-05-06 08:44:03 +12:00
|
|
|
36["Path<br>[416, 441, 8]"]
|
Avoid using full revolve for now (#6912)
Avoid using revolve for now
When we moved to concurrent execution of KCL modules, we begun to see an
error we never fully understood, and because it was pretty hard to
trigger, we wound up never being able to fix it. Today we were able to
track it down to the `revolve` call here.
Specifically, the problem is triggered when we're doing a "Full Revolve"
(e.g., `angle = 359.999999` passes, but *not* `angle = 360` or the
default, as it is in `main`), and concurrently executing modules will
see something weird happen with `getNextAdjacentEdge`.
From all the smoke I believe this happens only when we are doing a *full
revolve*, *AND* we're executing other modules which are calling
`getNextAdjacentEdge`.
When the `revolve` is present, we can lose the race in *either*
`talk-button.kcl` OR `case.kcl`.
If I move back to single-threaded execution OR I add imports to sequence
things carefully, I can get the tests to pass. If the revolve is an
`extrude` or not a full revolve, it works fine.
My best guess is that it seems like the world got flipped upside down or
something, such that "next edge" has a different orentation for two
calls. My even further guess is that inside `revolve` we mutate
something connection-global such that it alters the intepretation of
calls made during the revolve implementation's "critical section".
2025-05-13 16:20:48 -04:00
|
|
|
118["Segment<br>[449, 507, 8]"]
|
|
|
|
|
121["Segment<br>[515, 574, 8]"]
|
2025-05-13 21:07:24 -07:00
|
|
|
127["Segment<br>[582, 625, 8]"]
|
|
|
|
|
129["Segment<br>[633, 640, 8]"]
|
Avoid using full revolve for now (#6912)
Avoid using revolve for now
When we moved to concurrent execution of KCL modules, we begun to see an
error we never fully understood, and because it was pretty hard to
trigger, we wound up never being able to fix it. Today we were able to
track it down to the `revolve` call here.
Specifically, the problem is triggered when we're doing a "Full Revolve"
(e.g., `angle = 359.999999` passes, but *not* `angle = 360` or the
default, as it is in `main`), and concurrently executing modules will
see something weird happen with `getNextAdjacentEdge`.
From all the smoke I believe this happens only when we are doing a *full
revolve*, *AND* we're executing other modules which are calling
`getNextAdjacentEdge`.
When the `revolve` is present, we can lose the race in *either*
`talk-button.kcl` OR `case.kcl`.
If I move back to single-threaded execution OR I add imports to sequence
things carefully, I can get the tests to pass. If the revolve is an
`extrude` or not a full revolve, it works fine.
My best guess is that it seems like the world got flipped upside down or
something, such that "next edge" has a different orentation for two
calls. My even further guess is that inside `revolve` we mutate
something connection-global such that it alters the intepretation of
calls made during the revolve implementation's "critical section".
2025-05-13 16:20:48 -04:00
|
|
|
143[Solid2d]
|
2025-03-06 18:01:24 -05:00
|
|
|
end
|
2025-05-13 21:07:24 -07:00
|
|
|
subgraph path37 [Path]
|
|
|
|
|
37["Path<br>[416, 441, 8]"]
|
|
|
|
|
119["Segment<br>[449, 507, 8]"]
|
|
|
|
|
124["Segment<br>[515, 574, 8]"]
|
|
|
|
|
126["Segment<br>[582, 625, 8]"]
|
|
|
|
|
131["Segment<br>[633, 640, 8]"]
|
|
|
|
|
145[Solid2d]
|
|
|
|
|
end
|
2025-05-06 08:44:03 +12:00
|
|
|
1["Plane<br>[386, 403, 2]"]
|
|
|
|
|
2["Plane<br>[473, 490, 3]"]
|
2025-05-08 14:43:50 -04:00
|
|
|
3["Plane<br>[977, 994, 3]"]
|
|
|
|
|
4["Plane<br>[1438, 1455, 3]"]
|
|
|
|
|
5["Plane<br>[2587, 2604, 3]"]
|
|
|
|
|
6["Plane<br>[2684, 2701, 3]"]
|
|
|
|
|
7["Plane<br>[2783, 2800, 3]"]
|
|
|
|
|
8["Plane<br>[2881, 2898, 3]"]
|
|
|
|
|
9["Plane<br>[2979, 2996, 3]"]
|
2025-05-06 08:44:03 +12:00
|
|
|
10["Plane<br>[325, 342, 5]"]
|
Avoid using full revolve for now (#6912)
Avoid using revolve for now
When we moved to concurrent execution of KCL modules, we begun to see an
error we never fully understood, and because it was pretty hard to
trigger, we wound up never being able to fix it. Today we were able to
track it down to the `revolve` call here.
Specifically, the problem is triggered when we're doing a "Full Revolve"
(e.g., `angle = 359.999999` passes, but *not* `angle = 360` or the
default, as it is in `main`), and concurrently executing modules will
see something weird happen with `getNextAdjacentEdge`.
From all the smoke I believe this happens only when we are doing a *full
revolve*, *AND* we're executing other modules which are calling
`getNextAdjacentEdge`.
When the `revolve` is present, we can lose the race in *either*
`talk-button.kcl` OR `case.kcl`.
If I move back to single-threaded execution OR I add imports to sequence
things carefully, I can get the tests to pass. If the revolve is an
`extrude` or not a full revolve, it works fine.
My best guess is that it seems like the world got flipped upside down or
something, such that "next edge" has a different orentation for two
calls. My even further guess is that inside `revolve` we mutate
something connection-global such that it alters the intepretation of
calls made during the revolve implementation's "critical section".
2025-05-13 16:20:48 -04:00
|
|
|
11["Plane<br>[614, 653, 5]"]
|
2025-05-06 08:44:03 +12:00
|
|
|
12["Plane<br>[256, 273, 6]"]
|
Avoid using full revolve for now (#6912)
Avoid using revolve for now
When we moved to concurrent execution of KCL modules, we begun to see an
error we never fully understood, and because it was pretty hard to
trigger, we wound up never being able to fix it. Today we were able to
track it down to the `revolve` call here.
Specifically, the problem is triggered when we're doing a "Full Revolve"
(e.g., `angle = 359.999999` passes, but *not* `angle = 360` or the
default, as it is in `main`), and concurrently executing modules will
see something weird happen with `getNextAdjacentEdge`.
From all the smoke I believe this happens only when we are doing a *full
revolve*, *AND* we're executing other modules which are calling
`getNextAdjacentEdge`.
When the `revolve` is present, we can lose the race in *either*
`talk-button.kcl` OR `case.kcl`.
If I move back to single-threaded execution OR I add imports to sequence
things carefully, I can get the tests to pass. If the revolve is an
`extrude` or not a full revolve, it works fine.
My best guess is that it seems like the world got flipped upside down or
something, such that "next edge" has a different orentation for two
calls. My even further guess is that inside `revolve` we mutate
something connection-global such that it alters the intepretation of
calls made during the revolve implementation's "critical section".
2025-05-13 16:20:48 -04:00
|
|
|
13["Plane<br>[310, 327, 7]"]
|
2025-05-06 08:44:03 +12:00
|
|
|
14["Plane<br>[391, 408, 8]"]
|
|
|
|
|
15["Plane<br>[391, 408, 8]"]
|
|
|
|
|
16["Plane<br>[391, 408, 8]"]
|
|
|
|
|
17["Plane<br>[391, 408, 8]"]
|
Avoid using full revolve for now (#6912)
Avoid using revolve for now
When we moved to concurrent execution of KCL modules, we begun to see an
error we never fully understood, and because it was pretty hard to
trigger, we wound up never being able to fix it. Today we were able to
track it down to the `revolve` call here.
Specifically, the problem is triggered when we're doing a "Full Revolve"
(e.g., `angle = 359.999999` passes, but *not* `angle = 360` or the
default, as it is in `main`), and concurrently executing modules will
see something weird happen with `getNextAdjacentEdge`.
From all the smoke I believe this happens only when we are doing a *full
revolve*, *AND* we're executing other modules which are calling
`getNextAdjacentEdge`.
When the `revolve` is present, we can lose the race in *either*
`talk-button.kcl` OR `case.kcl`.
If I move back to single-threaded execution OR I add imports to sequence
things carefully, I can get the tests to pass. If the revolve is an
`extrude` or not a full revolve, it works fine.
My best guess is that it seems like the world got flipped upside down or
something, such that "next edge" has a different orentation for two
calls. My even further guess is that inside `revolve` we mutate
something connection-global such that it alters the intepretation of
calls made during the revolve implementation's "critical section".
2025-05-13 16:20:48 -04:00
|
|
|
153["Sweep Extrusion<br>[621, 651, 2]"]
|
|
|
|
|
154["Sweep Extrusion<br>[1767, 1810, 2]"]
|
|
|
|
|
155["Sweep Extrusion<br>[2169, 2212, 2]"]
|
|
|
|
|
156["Sweep Extrusion<br>[2464, 2497, 2]"]
|
|
|
|
|
157["Sweep Extrusion<br>[3037, 3068, 3]"]
|
|
|
|
|
158["Sweep Loft<br>[994, 1037, 5]"]
|
|
|
|
|
159["Sweep Extrusion<br>[609, 661, 6]"]
|
|
|
|
|
160["Sweep Extrusion<br>[406, 437, 7]"]
|
|
|
|
|
161["Sweep Extrusion<br>[652, 699, 8]"]
|
|
|
|
|
162["Sweep Extrusion<br>[652, 699, 8]"]
|
|
|
|
|
163["Sweep Extrusion<br>[652, 699, 8]"]
|
|
|
|
|
164["Sweep Extrusion<br>[652, 699, 8]"]
|
|
|
|
|
165[Wall]
|
2025-05-15 20:14:31 -04:00
|
|
|
%% face_code_ref=Missing NodePath
|
Avoid using full revolve for now (#6912)
Avoid using revolve for now
When we moved to concurrent execution of KCL modules, we begun to see an
error we never fully understood, and because it was pretty hard to
trigger, we wound up never being able to fix it. Today we were able to
track it down to the `revolve` call here.
Specifically, the problem is triggered when we're doing a "Full Revolve"
(e.g., `angle = 359.999999` passes, but *not* `angle = 360` or the
default, as it is in `main`), and concurrently executing modules will
see something weird happen with `getNextAdjacentEdge`.
From all the smoke I believe this happens only when we are doing a *full
revolve*, *AND* we're executing other modules which are calling
`getNextAdjacentEdge`.
When the `revolve` is present, we can lose the race in *either*
`talk-button.kcl` OR `case.kcl`.
If I move back to single-threaded execution OR I add imports to sequence
things carefully, I can get the tests to pass. If the revolve is an
`extrude` or not a full revolve, it works fine.
My best guess is that it seems like the world got flipped upside down or
something, such that "next edge" has a different orentation for two
calls. My even further guess is that inside `revolve` we mutate
something connection-global such that it alters the intepretation of
calls made during the revolve implementation's "critical section".
2025-05-13 16:20:48 -04:00
|
|
|
166[Wall]
|
2025-05-15 20:14:31 -04:00
|
|
|
%% face_code_ref=Missing NodePath
|
Avoid using full revolve for now (#6912)
Avoid using revolve for now
When we moved to concurrent execution of KCL modules, we begun to see an
error we never fully understood, and because it was pretty hard to
trigger, we wound up never being able to fix it. Today we were able to
track it down to the `revolve` call here.
Specifically, the problem is triggered when we're doing a "Full Revolve"
(e.g., `angle = 359.999999` passes, but *not* `angle = 360` or the
default, as it is in `main`), and concurrently executing modules will
see something weird happen with `getNextAdjacentEdge`.
From all the smoke I believe this happens only when we are doing a *full
revolve*, *AND* we're executing other modules which are calling
`getNextAdjacentEdge`.
When the `revolve` is present, we can lose the race in *either*
`talk-button.kcl` OR `case.kcl`.
If I move back to single-threaded execution OR I add imports to sequence
things carefully, I can get the tests to pass. If the revolve is an
`extrude` or not a full revolve, it works fine.
My best guess is that it seems like the world got flipped upside down or
something, such that "next edge" has a different orentation for two
calls. My even further guess is that inside `revolve` we mutate
something connection-global such that it alters the intepretation of
calls made during the revolve implementation's "critical section".
2025-05-13 16:20:48 -04:00
|
|
|
167[Wall]
|
2025-05-15 20:14:31 -04:00
|
|
|
%% face_code_ref=Missing NodePath
|
Avoid using full revolve for now (#6912)
Avoid using revolve for now
When we moved to concurrent execution of KCL modules, we begun to see an
error we never fully understood, and because it was pretty hard to
trigger, we wound up never being able to fix it. Today we were able to
track it down to the `revolve` call here.
Specifically, the problem is triggered when we're doing a "Full Revolve"
(e.g., `angle = 359.999999` passes, but *not* `angle = 360` or the
default, as it is in `main`), and concurrently executing modules will
see something weird happen with `getNextAdjacentEdge`.
From all the smoke I believe this happens only when we are doing a *full
revolve*, *AND* we're executing other modules which are calling
`getNextAdjacentEdge`.
When the `revolve` is present, we can lose the race in *either*
`talk-button.kcl` OR `case.kcl`.
If I move back to single-threaded execution OR I add imports to sequence
things carefully, I can get the tests to pass. If the revolve is an
`extrude` or not a full revolve, it works fine.
My best guess is that it seems like the world got flipped upside down or
something, such that "next edge" has a different orentation for two
calls. My even further guess is that inside `revolve` we mutate
something connection-global such that it alters the intepretation of
calls made during the revolve implementation's "critical section".
2025-05-13 16:20:48 -04:00
|
|
|
168[Wall]
|
2025-05-15 20:14:31 -04:00
|
|
|
%% face_code_ref=Missing NodePath
|
2025-04-29 06:38:52 -07:00
|
|
|
169[Wall]
|
2025-05-15 20:14:31 -04:00
|
|
|
%% face_code_ref=Missing NodePath
|
2025-04-29 06:38:52 -07:00
|
|
|
170[Wall]
|
2025-05-15 20:14:31 -04:00
|
|
|
%% face_code_ref=Missing NodePath
|
2025-04-29 06:38:52 -07:00
|
|
|
171[Wall]
|
2025-05-15 20:14:31 -04:00
|
|
|
%% face_code_ref=Missing NodePath
|
2025-04-29 06:38:52 -07:00
|
|
|
172[Wall]
|
2025-05-15 20:14:31 -04:00
|
|
|
%% face_code_ref=Missing NodePath
|
2025-04-29 06:38:52 -07:00
|
|
|
173[Wall]
|
2025-05-15 20:14:31 -04:00
|
|
|
%% face_code_ref=Missing NodePath
|
2025-04-29 06:38:52 -07:00
|
|
|
174[Wall]
|
2025-05-15 20:14:31 -04:00
|
|
|
%% face_code_ref=Missing NodePath
|
2025-04-29 06:38:52 -07:00
|
|
|
175[Wall]
|
2025-05-15 20:14:31 -04:00
|
|
|
%% face_code_ref=Missing NodePath
|
2025-04-29 06:38:52 -07:00
|
|
|
176[Wall]
|
2025-05-15 20:14:31 -04:00
|
|
|
%% face_code_ref=Missing NodePath
|
2025-04-29 06:38:52 -07:00
|
|
|
177[Wall]
|
2025-05-15 20:14:31 -04:00
|
|
|
%% face_code_ref=Missing NodePath
|
2025-04-29 06:38:52 -07:00
|
|
|
178[Wall]
|
2025-05-15 20:14:31 -04:00
|
|
|
%% face_code_ref=Missing NodePath
|
2025-04-29 06:38:52 -07:00
|
|
|
179[Wall]
|
2025-05-15 20:14:31 -04:00
|
|
|
%% face_code_ref=Missing NodePath
|
2025-04-29 06:38:52 -07:00
|
|
|
180[Wall]
|
2025-05-15 20:14:31 -04:00
|
|
|
%% face_code_ref=Missing NodePath
|
2025-04-29 06:38:52 -07:00
|
|
|
181[Wall]
|
2025-05-15 20:14:31 -04:00
|
|
|
%% face_code_ref=Missing NodePath
|
2025-04-29 06:38:52 -07:00
|
|
|
182[Wall]
|
2025-05-15 20:14:31 -04:00
|
|
|
%% face_code_ref=Missing NodePath
|
2025-04-29 06:38:52 -07:00
|
|
|
183[Wall]
|
2025-05-15 20:14:31 -04:00
|
|
|
%% face_code_ref=Missing NodePath
|
2025-04-29 06:38:52 -07:00
|
|
|
184[Wall]
|
2025-05-15 20:14:31 -04:00
|
|
|
%% face_code_ref=Missing NodePath
|
2025-04-29 06:38:52 -07:00
|
|
|
185[Wall]
|
2025-05-15 20:14:31 -04:00
|
|
|
%% face_code_ref=Missing NodePath
|
2025-04-29 06:38:52 -07:00
|
|
|
186[Wall]
|
2025-05-15 20:14:31 -04:00
|
|
|
%% face_code_ref=Missing NodePath
|
2025-04-29 06:38:52 -07:00
|
|
|
187[Wall]
|
2025-05-15 20:14:31 -04:00
|
|
|
%% face_code_ref=Missing NodePath
|
2025-04-29 06:38:52 -07:00
|
|
|
188[Wall]
|
2025-05-15 20:14:31 -04:00
|
|
|
%% face_code_ref=Missing NodePath
|
2025-04-29 06:38:52 -07:00
|
|
|
189[Wall]
|
2025-05-15 20:14:31 -04:00
|
|
|
%% face_code_ref=Missing NodePath
|
2025-04-29 06:38:52 -07:00
|
|
|
190[Wall]
|
2025-05-15 20:14:31 -04:00
|
|
|
%% face_code_ref=Missing NodePath
|
2025-04-29 06:38:52 -07:00
|
|
|
191[Wall]
|
2025-05-15 20:14:31 -04:00
|
|
|
%% face_code_ref=Missing NodePath
|
2025-04-29 06:38:52 -07:00
|
|
|
192[Wall]
|
2025-05-15 20:14:31 -04:00
|
|
|
%% face_code_ref=Missing NodePath
|
2025-04-29 06:38:52 -07:00
|
|
|
193[Wall]
|
2025-05-15 20:14:31 -04:00
|
|
|
%% face_code_ref=Missing NodePath
|
2025-04-29 06:38:52 -07:00
|
|
|
194[Wall]
|
2025-05-15 20:14:31 -04:00
|
|
|
%% face_code_ref=Missing NodePath
|
2025-04-29 06:38:52 -07:00
|
|
|
195[Wall]
|
2025-05-15 20:14:31 -04:00
|
|
|
%% face_code_ref=Missing NodePath
|
2025-04-29 06:38:52 -07:00
|
|
|
196[Wall]
|
2025-05-15 20:14:31 -04:00
|
|
|
%% face_code_ref=Missing NodePath
|
2025-04-29 06:38:52 -07:00
|
|
|
197[Wall]
|
2025-05-15 20:14:31 -04:00
|
|
|
%% face_code_ref=Missing NodePath
|
2025-04-29 06:38:52 -07:00
|
|
|
198[Wall]
|
2025-05-15 20:14:31 -04:00
|
|
|
%% face_code_ref=Missing NodePath
|
2025-04-29 06:38:52 -07:00
|
|
|
199[Wall]
|
2025-05-15 20:14:31 -04:00
|
|
|
%% face_code_ref=Missing NodePath
|
2025-04-29 06:38:52 -07:00
|
|
|
200[Wall]
|
2025-05-15 20:14:31 -04:00
|
|
|
%% face_code_ref=Missing NodePath
|
2025-04-29 06:38:52 -07:00
|
|
|
201[Wall]
|
2025-05-15 20:14:31 -04:00
|
|
|
%% face_code_ref=Missing NodePath
|
2025-04-29 06:38:52 -07:00
|
|
|
202[Wall]
|
2025-05-15 20:14:31 -04:00
|
|
|
%% face_code_ref=Missing NodePath
|
2025-03-20 09:22:17 -07:00
|
|
|
203[Wall]
|
2025-05-15 20:14:31 -04:00
|
|
|
%% face_code_ref=Missing NodePath
|
2025-03-20 09:22:17 -07:00
|
|
|
204[Wall]
|
2025-05-15 20:14:31 -04:00
|
|
|
%% face_code_ref=Missing NodePath
|
2025-04-26 21:21:26 -07:00
|
|
|
205[Wall]
|
2025-05-15 20:14:31 -04:00
|
|
|
%% face_code_ref=Missing NodePath
|
2025-04-26 21:21:26 -07:00
|
|
|
206[Wall]
|
2025-05-15 20:14:31 -04:00
|
|
|
%% face_code_ref=Missing NodePath
|
2025-04-26 21:21:26 -07:00
|
|
|
207[Wall]
|
2025-05-15 20:14:31 -04:00
|
|
|
%% face_code_ref=Missing NodePath
|
2025-04-26 21:21:26 -07:00
|
|
|
208[Wall]
|
2025-05-15 20:14:31 -04:00
|
|
|
%% face_code_ref=Missing NodePath
|
2025-04-26 21:21:26 -07:00
|
|
|
209[Wall]
|
2025-05-15 20:14:31 -04:00
|
|
|
%% face_code_ref=Missing NodePath
|
2025-04-26 21:21:26 -07:00
|
|
|
210[Wall]
|
2025-05-15 20:14:31 -04:00
|
|
|
%% face_code_ref=Missing NodePath
|
2025-04-29 06:38:52 -07:00
|
|
|
211[Wall]
|
2025-05-15 20:14:31 -04:00
|
|
|
%% face_code_ref=Missing NodePath
|
2025-04-29 06:38:52 -07:00
|
|
|
212[Wall]
|
2025-05-15 20:14:31 -04:00
|
|
|
%% face_code_ref=Missing NodePath
|
2025-04-29 06:38:52 -07:00
|
|
|
213[Wall]
|
2025-05-15 20:14:31 -04:00
|
|
|
%% face_code_ref=Missing NodePath
|
2025-04-29 06:38:52 -07:00
|
|
|
214[Wall]
|
2025-05-15 20:14:31 -04:00
|
|
|
%% face_code_ref=Missing NodePath
|
2025-04-29 06:38:52 -07:00
|
|
|
215[Wall]
|
2025-05-15 20:14:31 -04:00
|
|
|
%% face_code_ref=Missing NodePath
|
2025-04-29 06:38:52 -07:00
|
|
|
216[Wall]
|
2025-05-15 20:14:31 -04:00
|
|
|
%% face_code_ref=Missing NodePath
|
2025-04-29 06:38:52 -07:00
|
|
|
217[Wall]
|
2025-05-15 20:14:31 -04:00
|
|
|
%% face_code_ref=Missing NodePath
|
Avoid using full revolve for now (#6912)
Avoid using revolve for now
When we moved to concurrent execution of KCL modules, we begun to see an
error we never fully understood, and because it was pretty hard to
trigger, we wound up never being able to fix it. Today we were able to
track it down to the `revolve` call here.
Specifically, the problem is triggered when we're doing a "Full Revolve"
(e.g., `angle = 359.999999` passes, but *not* `angle = 360` or the
default, as it is in `main`), and concurrently executing modules will
see something weird happen with `getNextAdjacentEdge`.
From all the smoke I believe this happens only when we are doing a *full
revolve*, *AND* we're executing other modules which are calling
`getNextAdjacentEdge`.
When the `revolve` is present, we can lose the race in *either*
`talk-button.kcl` OR `case.kcl`.
If I move back to single-threaded execution OR I add imports to sequence
things carefully, I can get the tests to pass. If the revolve is an
`extrude` or not a full revolve, it works fine.
My best guess is that it seems like the world got flipped upside down or
something, such that "next edge" has a different orentation for two
calls. My even further guess is that inside `revolve` we mutate
something connection-global such that it alters the intepretation of
calls made during the revolve implementation's "critical section".
2025-05-13 16:20:48 -04:00
|
|
|
218["Cap Start"]
|
2025-05-15 20:14:31 -04:00
|
|
|
%% face_code_ref=Missing NodePath
|
Avoid using full revolve for now (#6912)
Avoid using revolve for now
When we moved to concurrent execution of KCL modules, we begun to see an
error we never fully understood, and because it was pretty hard to
trigger, we wound up never being able to fix it. Today we were able to
track it down to the `revolve` call here.
Specifically, the problem is triggered when we're doing a "Full Revolve"
(e.g., `angle = 359.999999` passes, but *not* `angle = 360` or the
default, as it is in `main`), and concurrently executing modules will
see something weird happen with `getNextAdjacentEdge`.
From all the smoke I believe this happens only when we are doing a *full
revolve*, *AND* we're executing other modules which are calling
`getNextAdjacentEdge`.
When the `revolve` is present, we can lose the race in *either*
`talk-button.kcl` OR `case.kcl`.
If I move back to single-threaded execution OR I add imports to sequence
things carefully, I can get the tests to pass. If the revolve is an
`extrude` or not a full revolve, it works fine.
My best guess is that it seems like the world got flipped upside down or
something, such that "next edge" has a different orentation for two
calls. My even further guess is that inside `revolve` we mutate
something connection-global such that it alters the intepretation of
calls made during the revolve implementation's "critical section".
2025-05-13 16:20:48 -04:00
|
|
|
219["Cap Start"]
|
2025-05-15 20:14:31 -04:00
|
|
|
%% face_code_ref=Missing NodePath
|
Avoid using full revolve for now (#6912)
Avoid using revolve for now
When we moved to concurrent execution of KCL modules, we begun to see an
error we never fully understood, and because it was pretty hard to
trigger, we wound up never being able to fix it. Today we were able to
track it down to the `revolve` call here.
Specifically, the problem is triggered when we're doing a "Full Revolve"
(e.g., `angle = 359.999999` passes, but *not* `angle = 360` or the
default, as it is in `main`), and concurrently executing modules will
see something weird happen with `getNextAdjacentEdge`.
From all the smoke I believe this happens only when we are doing a *full
revolve*, *AND* we're executing other modules which are calling
`getNextAdjacentEdge`.
When the `revolve` is present, we can lose the race in *either*
`talk-button.kcl` OR `case.kcl`.
If I move back to single-threaded execution OR I add imports to sequence
things carefully, I can get the tests to pass. If the revolve is an
`extrude` or not a full revolve, it works fine.
My best guess is that it seems like the world got flipped upside down or
something, such that "next edge" has a different orentation for two
calls. My even further guess is that inside `revolve` we mutate
something connection-global such that it alters the intepretation of
calls made during the revolve implementation's "critical section".
2025-05-13 16:20:48 -04:00
|
|
|
220["Cap Start"]
|
2025-05-15 20:14:31 -04:00
|
|
|
%% face_code_ref=Missing NodePath
|
Avoid using full revolve for now (#6912)
Avoid using revolve for now
When we moved to concurrent execution of KCL modules, we begun to see an
error we never fully understood, and because it was pretty hard to
trigger, we wound up never being able to fix it. Today we were able to
track it down to the `revolve` call here.
Specifically, the problem is triggered when we're doing a "Full Revolve"
(e.g., `angle = 359.999999` passes, but *not* `angle = 360` or the
default, as it is in `main`), and concurrently executing modules will
see something weird happen with `getNextAdjacentEdge`.
From all the smoke I believe this happens only when we are doing a *full
revolve*, *AND* we're executing other modules which are calling
`getNextAdjacentEdge`.
When the `revolve` is present, we can lose the race in *either*
`talk-button.kcl` OR `case.kcl`.
If I move back to single-threaded execution OR I add imports to sequence
things carefully, I can get the tests to pass. If the revolve is an
`extrude` or not a full revolve, it works fine.
My best guess is that it seems like the world got flipped upside down or
something, such that "next edge" has a different orentation for two
calls. My even further guess is that inside `revolve` we mutate
something connection-global such that it alters the intepretation of
calls made during the revolve implementation's "critical section".
2025-05-13 16:20:48 -04:00
|
|
|
221["Cap Start"]
|
2025-05-15 20:14:31 -04:00
|
|
|
%% face_code_ref=Missing NodePath
|
Avoid using full revolve for now (#6912)
Avoid using revolve for now
When we moved to concurrent execution of KCL modules, we begun to see an
error we never fully understood, and because it was pretty hard to
trigger, we wound up never being able to fix it. Today we were able to
track it down to the `revolve` call here.
Specifically, the problem is triggered when we're doing a "Full Revolve"
(e.g., `angle = 359.999999` passes, but *not* `angle = 360` or the
default, as it is in `main`), and concurrently executing modules will
see something weird happen with `getNextAdjacentEdge`.
From all the smoke I believe this happens only when we are doing a *full
revolve*, *AND* we're executing other modules which are calling
`getNextAdjacentEdge`.
When the `revolve` is present, we can lose the race in *either*
`talk-button.kcl` OR `case.kcl`.
If I move back to single-threaded execution OR I add imports to sequence
things carefully, I can get the tests to pass. If the revolve is an
`extrude` or not a full revolve, it works fine.
My best guess is that it seems like the world got flipped upside down or
something, such that "next edge" has a different orentation for two
calls. My even further guess is that inside `revolve` we mutate
something connection-global such that it alters the intepretation of
calls made during the revolve implementation's "critical section".
2025-05-13 16:20:48 -04:00
|
|
|
222["Cap Start"]
|
2025-05-15 20:14:31 -04:00
|
|
|
%% face_code_ref=Missing NodePath
|
Avoid using full revolve for now (#6912)
Avoid using revolve for now
When we moved to concurrent execution of KCL modules, we begun to see an
error we never fully understood, and because it was pretty hard to
trigger, we wound up never being able to fix it. Today we were able to
track it down to the `revolve` call here.
Specifically, the problem is triggered when we're doing a "Full Revolve"
(e.g., `angle = 359.999999` passes, but *not* `angle = 360` or the
default, as it is in `main`), and concurrently executing modules will
see something weird happen with `getNextAdjacentEdge`.
From all the smoke I believe this happens only when we are doing a *full
revolve*, *AND* we're executing other modules which are calling
`getNextAdjacentEdge`.
When the `revolve` is present, we can lose the race in *either*
`talk-button.kcl` OR `case.kcl`.
If I move back to single-threaded execution OR I add imports to sequence
things carefully, I can get the tests to pass. If the revolve is an
`extrude` or not a full revolve, it works fine.
My best guess is that it seems like the world got flipped upside down or
something, such that "next edge" has a different orentation for two
calls. My even further guess is that inside `revolve` we mutate
something connection-global such that it alters the intepretation of
calls made during the revolve implementation's "critical section".
2025-05-13 16:20:48 -04:00
|
|
|
223["Cap Start"]
|
2025-05-15 20:14:31 -04:00
|
|
|
%% face_code_ref=Missing NodePath
|
Avoid using full revolve for now (#6912)
Avoid using revolve for now
When we moved to concurrent execution of KCL modules, we begun to see an
error we never fully understood, and because it was pretty hard to
trigger, we wound up never being able to fix it. Today we were able to
track it down to the `revolve` call here.
Specifically, the problem is triggered when we're doing a "Full Revolve"
(e.g., `angle = 359.999999` passes, but *not* `angle = 360` or the
default, as it is in `main`), and concurrently executing modules will
see something weird happen with `getNextAdjacentEdge`.
From all the smoke I believe this happens only when we are doing a *full
revolve*, *AND* we're executing other modules which are calling
`getNextAdjacentEdge`.
When the `revolve` is present, we can lose the race in *either*
`talk-button.kcl` OR `case.kcl`.
If I move back to single-threaded execution OR I add imports to sequence
things carefully, I can get the tests to pass. If the revolve is an
`extrude` or not a full revolve, it works fine.
My best guess is that it seems like the world got flipped upside down or
something, such that "next edge" has a different orentation for two
calls. My even further guess is that inside `revolve` we mutate
something connection-global such that it alters the intepretation of
calls made during the revolve implementation's "critical section".
2025-05-13 16:20:48 -04:00
|
|
|
224["Cap Start"]
|
2025-05-15 20:14:31 -04:00
|
|
|
%% face_code_ref=Missing NodePath
|
Avoid using full revolve for now (#6912)
Avoid using revolve for now
When we moved to concurrent execution of KCL modules, we begun to see an
error we never fully understood, and because it was pretty hard to
trigger, we wound up never being able to fix it. Today we were able to
track it down to the `revolve` call here.
Specifically, the problem is triggered when we're doing a "Full Revolve"
(e.g., `angle = 359.999999` passes, but *not* `angle = 360` or the
default, as it is in `main`), and concurrently executing modules will
see something weird happen with `getNextAdjacentEdge`.
From all the smoke I believe this happens only when we are doing a *full
revolve*, *AND* we're executing other modules which are calling
`getNextAdjacentEdge`.
When the `revolve` is present, we can lose the race in *either*
`talk-button.kcl` OR `case.kcl`.
If I move back to single-threaded execution OR I add imports to sequence
things carefully, I can get the tests to pass. If the revolve is an
`extrude` or not a full revolve, it works fine.
My best guess is that it seems like the world got flipped upside down or
something, such that "next edge" has a different orentation for two
calls. My even further guess is that inside `revolve` we mutate
something connection-global such that it alters the intepretation of
calls made during the revolve implementation's "critical section".
2025-05-13 16:20:48 -04:00
|
|
|
225["Cap Start"]
|
2025-05-15 20:14:31 -04:00
|
|
|
%% face_code_ref=Missing NodePath
|
2025-04-29 06:38:52 -07:00
|
|
|
226["Cap Start"]
|
2025-05-15 20:14:31 -04:00
|
|
|
%% face_code_ref=Missing NodePath
|
2025-04-29 06:38:52 -07:00
|
|
|
227["Cap Start"]
|
2025-05-15 20:14:31 -04:00
|
|
|
%% face_code_ref=Missing NodePath
|
2025-04-29 06:38:52 -07:00
|
|
|
228["Cap Start"]
|
2025-05-15 20:14:31 -04:00
|
|
|
%% face_code_ref=Missing NodePath
|
2025-04-29 06:38:52 -07:00
|
|
|
229["Cap Start"]
|
2025-05-15 20:14:31 -04:00
|
|
|
%% face_code_ref=Missing NodePath
|
Avoid using full revolve for now (#6912)
Avoid using revolve for now
When we moved to concurrent execution of KCL modules, we begun to see an
error we never fully understood, and because it was pretty hard to
trigger, we wound up never being able to fix it. Today we were able to
track it down to the `revolve` call here.
Specifically, the problem is triggered when we're doing a "Full Revolve"
(e.g., `angle = 359.999999` passes, but *not* `angle = 360` or the
default, as it is in `main`), and concurrently executing modules will
see something weird happen with `getNextAdjacentEdge`.
From all the smoke I believe this happens only when we are doing a *full
revolve*, *AND* we're executing other modules which are calling
`getNextAdjacentEdge`.
When the `revolve` is present, we can lose the race in *either*
`talk-button.kcl` OR `case.kcl`.
If I move back to single-threaded execution OR I add imports to sequence
things carefully, I can get the tests to pass. If the revolve is an
`extrude` or not a full revolve, it works fine.
My best guess is that it seems like the world got flipped upside down or
something, such that "next edge" has a different orentation for two
calls. My even further guess is that inside `revolve` we mutate
something connection-global such that it alters the intepretation of
calls made during the revolve implementation's "critical section".
2025-05-13 16:20:48 -04:00
|
|
|
230["Cap End"]
|
2025-05-15 20:14:31 -04:00
|
|
|
%% face_code_ref=Missing NodePath
|
Avoid using full revolve for now (#6912)
Avoid using revolve for now
When we moved to concurrent execution of KCL modules, we begun to see an
error we never fully understood, and because it was pretty hard to
trigger, we wound up never being able to fix it. Today we were able to
track it down to the `revolve` call here.
Specifically, the problem is triggered when we're doing a "Full Revolve"
(e.g., `angle = 359.999999` passes, but *not* `angle = 360` or the
default, as it is in `main`), and concurrently executing modules will
see something weird happen with `getNextAdjacentEdge`.
From all the smoke I believe this happens only when we are doing a *full
revolve*, *AND* we're executing other modules which are calling
`getNextAdjacentEdge`.
When the `revolve` is present, we can lose the race in *either*
`talk-button.kcl` OR `case.kcl`.
If I move back to single-threaded execution OR I add imports to sequence
things carefully, I can get the tests to pass. If the revolve is an
`extrude` or not a full revolve, it works fine.
My best guess is that it seems like the world got flipped upside down or
something, such that "next edge" has a different orentation for two
calls. My even further guess is that inside `revolve` we mutate
something connection-global such that it alters the intepretation of
calls made during the revolve implementation's "critical section".
2025-05-13 16:20:48 -04:00
|
|
|
231["Cap End"]
|
2025-05-15 20:14:31 -04:00
|
|
|
%% face_code_ref=Missing NodePath
|
Avoid using full revolve for now (#6912)
Avoid using revolve for now
When we moved to concurrent execution of KCL modules, we begun to see an
error we never fully understood, and because it was pretty hard to
trigger, we wound up never being able to fix it. Today we were able to
track it down to the `revolve` call here.
Specifically, the problem is triggered when we're doing a "Full Revolve"
(e.g., `angle = 359.999999` passes, but *not* `angle = 360` or the
default, as it is in `main`), and concurrently executing modules will
see something weird happen with `getNextAdjacentEdge`.
From all the smoke I believe this happens only when we are doing a *full
revolve*, *AND* we're executing other modules which are calling
`getNextAdjacentEdge`.
When the `revolve` is present, we can lose the race in *either*
`talk-button.kcl` OR `case.kcl`.
If I move back to single-threaded execution OR I add imports to sequence
things carefully, I can get the tests to pass. If the revolve is an
`extrude` or not a full revolve, it works fine.
My best guess is that it seems like the world got flipped upside down or
something, such that "next edge" has a different orentation for two
calls. My even further guess is that inside `revolve` we mutate
something connection-global such that it alters the intepretation of
calls made during the revolve implementation's "critical section".
2025-05-13 16:20:48 -04:00
|
|
|
232["Cap End"]
|
2025-05-15 20:14:31 -04:00
|
|
|
%% face_code_ref=Missing NodePath
|
Avoid using full revolve for now (#6912)
Avoid using revolve for now
When we moved to concurrent execution of KCL modules, we begun to see an
error we never fully understood, and because it was pretty hard to
trigger, we wound up never being able to fix it. Today we were able to
track it down to the `revolve` call here.
Specifically, the problem is triggered when we're doing a "Full Revolve"
(e.g., `angle = 359.999999` passes, but *not* `angle = 360` or the
default, as it is in `main`), and concurrently executing modules will
see something weird happen with `getNextAdjacentEdge`.
From all the smoke I believe this happens only when we are doing a *full
revolve*, *AND* we're executing other modules which are calling
`getNextAdjacentEdge`.
When the `revolve` is present, we can lose the race in *either*
`talk-button.kcl` OR `case.kcl`.
If I move back to single-threaded execution OR I add imports to sequence
things carefully, I can get the tests to pass. If the revolve is an
`extrude` or not a full revolve, it works fine.
My best guess is that it seems like the world got flipped upside down or
something, such that "next edge" has a different orentation for two
calls. My even further guess is that inside `revolve` we mutate
something connection-global such that it alters the intepretation of
calls made during the revolve implementation's "critical section".
2025-05-13 16:20:48 -04:00
|
|
|
233["Cap End"]
|
2025-05-15 20:14:31 -04:00
|
|
|
%% face_code_ref=Missing NodePath
|
Avoid using full revolve for now (#6912)
Avoid using revolve for now
When we moved to concurrent execution of KCL modules, we begun to see an
error we never fully understood, and because it was pretty hard to
trigger, we wound up never being able to fix it. Today we were able to
track it down to the `revolve` call here.
Specifically, the problem is triggered when we're doing a "Full Revolve"
(e.g., `angle = 359.999999` passes, but *not* `angle = 360` or the
default, as it is in `main`), and concurrently executing modules will
see something weird happen with `getNextAdjacentEdge`.
From all the smoke I believe this happens only when we are doing a *full
revolve*, *AND* we're executing other modules which are calling
`getNextAdjacentEdge`.
When the `revolve` is present, we can lose the race in *either*
`talk-button.kcl` OR `case.kcl`.
If I move back to single-threaded execution OR I add imports to sequence
things carefully, I can get the tests to pass. If the revolve is an
`extrude` or not a full revolve, it works fine.
My best guess is that it seems like the world got flipped upside down or
something, such that "next edge" has a different orentation for two
calls. My even further guess is that inside `revolve` we mutate
something connection-global such that it alters the intepretation of
calls made during the revolve implementation's "critical section".
2025-05-13 16:20:48 -04:00
|
|
|
234["Cap End"]
|
2025-05-15 20:14:31 -04:00
|
|
|
%% face_code_ref=Missing NodePath
|
Avoid using full revolve for now (#6912)
Avoid using revolve for now
When we moved to concurrent execution of KCL modules, we begun to see an
error we never fully understood, and because it was pretty hard to
trigger, we wound up never being able to fix it. Today we were able to
track it down to the `revolve` call here.
Specifically, the problem is triggered when we're doing a "Full Revolve"
(e.g., `angle = 359.999999` passes, but *not* `angle = 360` or the
default, as it is in `main`), and concurrently executing modules will
see something weird happen with `getNextAdjacentEdge`.
From all the smoke I believe this happens only when we are doing a *full
revolve*, *AND* we're executing other modules which are calling
`getNextAdjacentEdge`.
When the `revolve` is present, we can lose the race in *either*
`talk-button.kcl` OR `case.kcl`.
If I move back to single-threaded execution OR I add imports to sequence
things carefully, I can get the tests to pass. If the revolve is an
`extrude` or not a full revolve, it works fine.
My best guess is that it seems like the world got flipped upside down or
something, such that "next edge" has a different orentation for two
calls. My even further guess is that inside `revolve` we mutate
something connection-global such that it alters the intepretation of
calls made during the revolve implementation's "critical section".
2025-05-13 16:20:48 -04:00
|
|
|
235["Cap End"]
|
2025-05-15 20:14:31 -04:00
|
|
|
%% face_code_ref=Missing NodePath
|
Avoid using full revolve for now (#6912)
Avoid using revolve for now
When we moved to concurrent execution of KCL modules, we begun to see an
error we never fully understood, and because it was pretty hard to
trigger, we wound up never being able to fix it. Today we were able to
track it down to the `revolve` call here.
Specifically, the problem is triggered when we're doing a "Full Revolve"
(e.g., `angle = 359.999999` passes, but *not* `angle = 360` or the
default, as it is in `main`), and concurrently executing modules will
see something weird happen with `getNextAdjacentEdge`.
From all the smoke I believe this happens only when we are doing a *full
revolve*, *AND* we're executing other modules which are calling
`getNextAdjacentEdge`.
When the `revolve` is present, we can lose the race in *either*
`talk-button.kcl` OR `case.kcl`.
If I move back to single-threaded execution OR I add imports to sequence
things carefully, I can get the tests to pass. If the revolve is an
`extrude` or not a full revolve, it works fine.
My best guess is that it seems like the world got flipped upside down or
something, such that "next edge" has a different orentation for two
calls. My even further guess is that inside `revolve` we mutate
something connection-global such that it alters the intepretation of
calls made during the revolve implementation's "critical section".
2025-05-13 16:20:48 -04:00
|
|
|
236["Cap End"]
|
2025-05-15 20:14:31 -04:00
|
|
|
%% face_code_ref=Missing NodePath
|
2025-04-29 06:38:52 -07:00
|
|
|
237["Cap End"]
|
2025-05-15 20:14:31 -04:00
|
|
|
%% face_code_ref=Missing NodePath
|
2025-04-29 06:38:52 -07:00
|
|
|
238["Cap End"]
|
2025-05-15 20:14:31 -04:00
|
|
|
%% face_code_ref=Missing NodePath
|
Avoid using full revolve for now (#6912)
Avoid using revolve for now
When we moved to concurrent execution of KCL modules, we begun to see an
error we never fully understood, and because it was pretty hard to
trigger, we wound up never being able to fix it. Today we were able to
track it down to the `revolve` call here.
Specifically, the problem is triggered when we're doing a "Full Revolve"
(e.g., `angle = 359.999999` passes, but *not* `angle = 360` or the
default, as it is in `main`), and concurrently executing modules will
see something weird happen with `getNextAdjacentEdge`.
From all the smoke I believe this happens only when we are doing a *full
revolve*, *AND* we're executing other modules which are calling
`getNextAdjacentEdge`.
When the `revolve` is present, we can lose the race in *either*
`talk-button.kcl` OR `case.kcl`.
If I move back to single-threaded execution OR I add imports to sequence
things carefully, I can get the tests to pass. If the revolve is an
`extrude` or not a full revolve, it works fine.
My best guess is that it seems like the world got flipped upside down or
something, such that "next edge" has a different orentation for two
calls. My even further guess is that inside `revolve` we mutate
something connection-global such that it alters the intepretation of
calls made during the revolve implementation's "critical section".
2025-05-13 16:20:48 -04:00
|
|
|
239["SweepEdge Opposite"]
|
|
|
|
|
240["SweepEdge Opposite"]
|
|
|
|
|
241["SweepEdge Opposite"]
|
|
|
|
|
242["SweepEdge Opposite"]
|
|
|
|
|
243["SweepEdge Opposite"]
|
|
|
|
|
244["SweepEdge Opposite"]
|
2025-03-20 09:22:17 -07:00
|
|
|
245["SweepEdge Opposite"]
|
2025-04-29 06:38:52 -07:00
|
|
|
246["SweepEdge Opposite"]
|
2025-04-26 21:21:26 -07:00
|
|
|
247["SweepEdge Opposite"]
|
2025-04-29 06:38:52 -07:00
|
|
|
248["SweepEdge Opposite"]
|
2025-04-26 21:21:26 -07:00
|
|
|
249["SweepEdge Opposite"]
|
2025-04-29 06:38:52 -07:00
|
|
|
250["SweepEdge Opposite"]
|
|
|
|
|
251["SweepEdge Opposite"]
|
|
|
|
|
252["SweepEdge Opposite"]
|
|
|
|
|
253["SweepEdge Opposite"]
|
|
|
|
|
254["SweepEdge Opposite"]
|
|
|
|
|
255["SweepEdge Opposite"]
|
|
|
|
|
256["SweepEdge Opposite"]
|
|
|
|
|
257["SweepEdge Opposite"]
|
|
|
|
|
258["SweepEdge Opposite"]
|
|
|
|
|
259["SweepEdge Opposite"]
|
|
|
|
|
260["SweepEdge Opposite"]
|
|
|
|
|
261["SweepEdge Opposite"]
|
|
|
|
|
262["SweepEdge Opposite"]
|
|
|
|
|
263["SweepEdge Opposite"]
|
|
|
|
|
264["SweepEdge Opposite"]
|
|
|
|
|
265["SweepEdge Opposite"]
|
|
|
|
|
266["SweepEdge Opposite"]
|
|
|
|
|
267["SweepEdge Opposite"]
|
|
|
|
|
268["SweepEdge Opposite"]
|
|
|
|
|
269["SweepEdge Opposite"]
|
|
|
|
|
270["SweepEdge Opposite"]
|
|
|
|
|
271["SweepEdge Opposite"]
|
|
|
|
|
272["SweepEdge Opposite"]
|
|
|
|
|
273["SweepEdge Opposite"]
|
|
|
|
|
274["SweepEdge Opposite"]
|
|
|
|
|
275["SweepEdge Opposite"]
|
|
|
|
|
276["SweepEdge Opposite"]
|
|
|
|
|
277["SweepEdge Opposite"]
|
|
|
|
|
278["SweepEdge Opposite"]
|
|
|
|
|
279["SweepEdge Opposite"]
|
|
|
|
|
280["SweepEdge Opposite"]
|
|
|
|
|
281["SweepEdge Opposite"]
|
|
|
|
|
282["SweepEdge Opposite"]
|
|
|
|
|
283["SweepEdge Opposite"]
|
|
|
|
|
284["SweepEdge Opposite"]
|
|
|
|
|
285["SweepEdge Opposite"]
|
|
|
|
|
286["SweepEdge Opposite"]
|
2025-04-26 21:21:26 -07:00
|
|
|
287["SweepEdge Opposite"]
|
2025-04-29 06:38:52 -07:00
|
|
|
288["SweepEdge Opposite"]
|
2025-04-26 21:21:26 -07:00
|
|
|
289["SweepEdge Opposite"]
|
2025-04-29 06:38:52 -07:00
|
|
|
290["SweepEdge Opposite"]
|
2025-04-26 21:21:26 -07:00
|
|
|
291["SweepEdge Opposite"]
|
Avoid using full revolve for now (#6912)
Avoid using revolve for now
When we moved to concurrent execution of KCL modules, we begun to see an
error we never fully understood, and because it was pretty hard to
trigger, we wound up never being able to fix it. Today we were able to
track it down to the `revolve` call here.
Specifically, the problem is triggered when we're doing a "Full Revolve"
(e.g., `angle = 359.999999` passes, but *not* `angle = 360` or the
default, as it is in `main`), and concurrently executing modules will
see something weird happen with `getNextAdjacentEdge`.
From all the smoke I believe this happens only when we are doing a *full
revolve*, *AND* we're executing other modules which are calling
`getNextAdjacentEdge`.
When the `revolve` is present, we can lose the race in *either*
`talk-button.kcl` OR `case.kcl`.
If I move back to single-threaded execution OR I add imports to sequence
things carefully, I can get the tests to pass. If the revolve is an
`extrude` or not a full revolve, it works fine.
My best guess is that it seems like the world got flipped upside down or
something, such that "next edge" has a different orentation for two
calls. My even further guess is that inside `revolve` we mutate
something connection-global such that it alters the intepretation of
calls made during the revolve implementation's "critical section".
2025-05-13 16:20:48 -04:00
|
|
|
292["SweepEdge Adjacent"]
|
|
|
|
|
293["SweepEdge Adjacent"]
|
|
|
|
|
294["SweepEdge Adjacent"]
|
|
|
|
|
295["SweepEdge Adjacent"]
|
|
|
|
|
296["SweepEdge Adjacent"]
|
2025-04-29 06:38:52 -07:00
|
|
|
297["SweepEdge Adjacent"]
|
|
|
|
|
298["SweepEdge Adjacent"]
|
|
|
|
|
299["SweepEdge Adjacent"]
|
|
|
|
|
300["SweepEdge Adjacent"]
|
|
|
|
|
301["SweepEdge Adjacent"]
|
|
|
|
|
302["SweepEdge Adjacent"]
|
|
|
|
|
303["SweepEdge Adjacent"]
|
|
|
|
|
304["SweepEdge Adjacent"]
|
|
|
|
|
305["SweepEdge Adjacent"]
|
|
|
|
|
306["SweepEdge Adjacent"]
|
|
|
|
|
307["SweepEdge Adjacent"]
|
|
|
|
|
308["SweepEdge Adjacent"]
|
|
|
|
|
309["SweepEdge Adjacent"]
|
|
|
|
|
310["SweepEdge Adjacent"]
|
|
|
|
|
311["SweepEdge Adjacent"]
|
2025-04-26 21:21:26 -07:00
|
|
|
312["SweepEdge Adjacent"]
|
2025-04-29 06:38:52 -07:00
|
|
|
313["SweepEdge Adjacent"]
|
2025-04-26 21:21:26 -07:00
|
|
|
314["SweepEdge Adjacent"]
|
2025-04-29 06:38:52 -07:00
|
|
|
315["SweepEdge Adjacent"]
|
2025-04-26 21:21:26 -07:00
|
|
|
316["SweepEdge Adjacent"]
|
2025-04-29 06:38:52 -07:00
|
|
|
317["SweepEdge Adjacent"]
|
2025-04-26 21:21:26 -07:00
|
|
|
318["SweepEdge Adjacent"]
|
2025-04-29 06:38:52 -07:00
|
|
|
319["SweepEdge Adjacent"]
|
|
|
|
|
320["SweepEdge Adjacent"]
|
|
|
|
|
321["SweepEdge Adjacent"]
|
|
|
|
|
322["SweepEdge Adjacent"]
|
|
|
|
|
323["SweepEdge Adjacent"]
|
|
|
|
|
324["SweepEdge Adjacent"]
|
|
|
|
|
325["SweepEdge Adjacent"]
|
|
|
|
|
326["SweepEdge Adjacent"]
|
|
|
|
|
327["SweepEdge Adjacent"]
|
|
|
|
|
328["SweepEdge Adjacent"]
|
|
|
|
|
329["SweepEdge Adjacent"]
|
|
|
|
|
330["SweepEdge Adjacent"]
|
|
|
|
|
331["SweepEdge Adjacent"]
|
|
|
|
|
332["SweepEdge Adjacent"]
|
|
|
|
|
333["SweepEdge Adjacent"]
|
|
|
|
|
334["SweepEdge Adjacent"]
|
|
|
|
|
335["SweepEdge Adjacent"]
|
2025-04-26 21:21:26 -07:00
|
|
|
336["SweepEdge Adjacent"]
|
2025-04-29 06:38:52 -07:00
|
|
|
337["SweepEdge Adjacent"]
|
2025-04-26 21:21:26 -07:00
|
|
|
338["SweepEdge Adjacent"]
|
2025-04-29 06:38:52 -07:00
|
|
|
339["SweepEdge Adjacent"]
|
2025-04-26 21:21:26 -07:00
|
|
|
340["SweepEdge Adjacent"]
|
2025-04-29 06:38:52 -07:00
|
|
|
341["SweepEdge Adjacent"]
|
2025-04-26 21:21:26 -07:00
|
|
|
342["SweepEdge Adjacent"]
|
2025-04-29 06:38:52 -07:00
|
|
|
343["SweepEdge Adjacent"]
|
|
|
|
|
344["SweepEdge Adjacent"]
|
Avoid using full revolve for now (#6912)
Avoid using revolve for now
When we moved to concurrent execution of KCL modules, we begun to see an
error we never fully understood, and because it was pretty hard to
trigger, we wound up never being able to fix it. Today we were able to
track it down to the `revolve` call here.
Specifically, the problem is triggered when we're doing a "Full Revolve"
(e.g., `angle = 359.999999` passes, but *not* `angle = 360` or the
default, as it is in `main`), and concurrently executing modules will
see something weird happen with `getNextAdjacentEdge`.
From all the smoke I believe this happens only when we are doing a *full
revolve*, *AND* we're executing other modules which are calling
`getNextAdjacentEdge`.
When the `revolve` is present, we can lose the race in *either*
`talk-button.kcl` OR `case.kcl`.
If I move back to single-threaded execution OR I add imports to sequence
things carefully, I can get the tests to pass. If the revolve is an
`extrude` or not a full revolve, it works fine.
My best guess is that it seems like the world got flipped upside down or
something, such that "next edge" has a different orentation for two
calls. My even further guess is that inside `revolve` we mutate
something connection-global such that it alters the intepretation of
calls made during the revolve implementation's "critical section".
2025-05-13 16:20:48 -04:00
|
|
|
345["EdgeCut Chamfer<br>[657, 888, 2]"]
|
|
|
|
|
346["EdgeCut Chamfer<br>[657, 888, 2]"]
|
|
|
|
|
347["EdgeCut Chamfer<br>[657, 888, 2]"]
|
|
|
|
|
348["EdgeCut Chamfer<br>[657, 888, 2]"]
|
|
|
|
|
349["EdgeCut Fillet<br>[667, 873, 6]"]
|
Do multiple chamfer/fillet in one API call (#6750)
KCL's `fillet` function takes an array of edges to fillet. Previously this would do `n` fillet API commands, one per edge. This PR combines them all into one call, which should improve performance. You can see the effect in the artifact_commands snapshots, e.g. `rust/kcl-lib/tests/kcl_samples/axial-fan/artifact_commands.snap`
Besides performance, this should fix a bug where some KCL fillets would fail, when they should have succeeded. Example from @max-mrgrsk:
```kcl
sketch001 = startSketchOn(XY)
|> startProfile(at = [-12, -6])
|> line(end = [0, 12], tag = $seg04)
|> line(end = [24, 0], tag = $seg03)
|> line(end = [0, -12], tag = $seg02)
|> line(endAbsolute = [profileStartX(%), profileStartY(%)], tag = $seg01)
|> close()
extrude001 = extrude(
sketch001,
length = 12,
tagEnd = $capEnd001,
tagStart = $capStart001,
)
|> fillet(
radius = 5,
tags = [
getCommonEdge(faces = [seg02, capEnd001]),
getCommonEdge(faces = [seg01, capEnd001]),
getCommonEdge(faces = [seg03, capEnd001]),
getCommonEdge(faces = [seg04, capEnd001])
],
)
```
This program fails on main, but succeeds on this branch.
2025-05-22 16:25:55 -05:00
|
|
|
350["EdgeCut Fillet<br>[443, 512, 7]"]
|
|
|
|
|
351["EdgeCut Chamfer<br>[707, 853, 8]"]
|
|
|
|
|
352["EdgeCut Chamfer<br>[707, 853, 8]"]
|
|
|
|
|
353["EdgeCut Chamfer<br>[707, 853, 8]"]
|
Avoid using full revolve for now (#6912)
Avoid using revolve for now
When we moved to concurrent execution of KCL modules, we begun to see an
error we never fully understood, and because it was pretty hard to
trigger, we wound up never being able to fix it. Today we were able to
track it down to the `revolve` call here.
Specifically, the problem is triggered when we're doing a "Full Revolve"
(e.g., `angle = 359.999999` passes, but *not* `angle = 360` or the
default, as it is in `main`), and concurrently executing modules will
see something weird happen with `getNextAdjacentEdge`.
From all the smoke I believe this happens only when we are doing a *full
revolve*, *AND* we're executing other modules which are calling
`getNextAdjacentEdge`.
When the `revolve` is present, we can lose the race in *either*
`talk-button.kcl` OR `case.kcl`.
If I move back to single-threaded execution OR I add imports to sequence
things carefully, I can get the tests to pass. If the revolve is an
`extrude` or not a full revolve, it works fine.
My best guess is that it seems like the world got flipped upside down or
something, such that "next edge" has a different orentation for two
calls. My even further guess is that inside `revolve` we mutate
something connection-global such that it alters the intepretation of
calls made during the revolve implementation's "critical section".
2025-05-13 16:20:48 -04:00
|
|
|
354["EdgeCut Chamfer<br>[707, 853, 8]"]
|
|
|
|
|
355["EdgeCut Chamfer<br>[707, 853, 8]"]
|
|
|
|
|
356["EdgeCut Chamfer<br>[707, 853, 8]"]
|
|
|
|
|
357["EdgeCut Chamfer<br>[707, 853, 8]"]
|
|
|
|
|
358["EdgeCut Chamfer<br>[707, 853, 8]"]
|
2025-04-29 06:38:52 -07:00
|
|
|
1 --- 18
|
|
|
|
|
2 --- 22
|
|
|
|
|
3 --- 23
|
|
|
|
|
4 --- 24
|
|
|
|
|
5 --- 25
|
2025-05-02 10:41:14 -07:00
|
|
|
6 --- 26
|
2025-04-29 06:38:52 -07:00
|
|
|
7 --- 29
|
2025-05-02 10:41:14 -07:00
|
|
|
8 --- 27
|
2025-04-29 06:38:52 -07:00
|
|
|
9 --- 28
|
|
|
|
|
10 --- 30
|
|
|
|
|
11 --- 31
|
|
|
|
|
12 --- 32
|
|
|
|
|
13 --- 33
|
2025-05-13 21:07:24 -07:00
|
|
|
14 --- 37
|
2025-04-29 06:38:52 -07:00
|
|
|
15 --- 34
|
2025-05-13 21:07:24 -07:00
|
|
|
16 --- 35
|
|
|
|
|
17 --- 36
|
2025-04-29 06:38:52 -07:00
|
|
|
18 --- 38
|
|
|
|
|
18 --- 39
|
|
|
|
|
18 --- 40
|
|
|
|
|
18 --- 41
|
Avoid using full revolve for now (#6912)
Avoid using revolve for now
When we moved to concurrent execution of KCL modules, we begun to see an
error we never fully understood, and because it was pretty hard to
trigger, we wound up never being able to fix it. Today we were able to
track it down to the `revolve` call here.
Specifically, the problem is triggered when we're doing a "Full Revolve"
(e.g., `angle = 359.999999` passes, but *not* `angle = 360` or the
default, as it is in `main`), and concurrently executing modules will
see something weird happen with `getNextAdjacentEdge`.
From all the smoke I believe this happens only when we are doing a *full
revolve*, *AND* we're executing other modules which are calling
`getNextAdjacentEdge`.
When the `revolve` is present, we can lose the race in *either*
`talk-button.kcl` OR `case.kcl`.
If I move back to single-threaded execution OR I add imports to sequence
things carefully, I can get the tests to pass. If the revolve is an
`extrude` or not a full revolve, it works fine.
My best guess is that it seems like the world got flipped upside down or
something, such that "next edge" has a different orentation for two
calls. My even further guess is that inside `revolve` we mutate
something connection-global such that it alters the intepretation of
calls made during the revolve implementation's "critical section".
2025-05-13 16:20:48 -04:00
|
|
|
18 --- 149
|
|
|
|
|
18 ---- 153
|
2025-04-29 06:38:52 -07:00
|
|
|
19 --- 42
|
|
|
|
|
19 --- 43
|
|
|
|
|
19 --- 44
|
|
|
|
|
19 --- 45
|
|
|
|
|
19 --- 46
|
|
|
|
|
19 --- 47
|
|
|
|
|
19 --- 48
|
|
|
|
|
19 --- 49
|
2025-05-13 21:07:24 -07:00
|
|
|
19 --- 137
|
Avoid using full revolve for now (#6912)
Avoid using revolve for now
When we moved to concurrent execution of KCL modules, we begun to see an
error we never fully understood, and because it was pretty hard to
trigger, we wound up never being able to fix it. Today we were able to
track it down to the `revolve` call here.
Specifically, the problem is triggered when we're doing a "Full Revolve"
(e.g., `angle = 359.999999` passes, but *not* `angle = 360` or the
default, as it is in `main`), and concurrently executing modules will
see something weird happen with `getNextAdjacentEdge`.
From all the smoke I believe this happens only when we are doing a *full
revolve*, *AND* we're executing other modules which are calling
`getNextAdjacentEdge`.
When the `revolve` is present, we can lose the race in *either*
`talk-button.kcl` OR `case.kcl`.
If I move back to single-threaded execution OR I add imports to sequence
things carefully, I can get the tests to pass. If the revolve is an
`extrude` or not a full revolve, it works fine.
My best guess is that it seems like the world got flipped upside down or
something, such that "next edge" has a different orentation for two
calls. My even further guess is that inside `revolve` we mutate
something connection-global such that it alters the intepretation of
calls made during the revolve implementation's "critical section".
2025-05-13 16:20:48 -04:00
|
|
|
19 ---- 154
|
|
|
|
|
237 --- 19
|
2025-04-29 06:38:52 -07:00
|
|
|
20 --- 50
|
|
|
|
|
20 --- 51
|
|
|
|
|
20 --- 52
|
|
|
|
|
20 --- 53
|
|
|
|
|
20 --- 54
|
2025-05-13 21:07:24 -07:00
|
|
|
20 --- 148
|
Avoid using full revolve for now (#6912)
Avoid using revolve for now
When we moved to concurrent execution of KCL modules, we begun to see an
error we never fully understood, and because it was pretty hard to
trigger, we wound up never being able to fix it. Today we were able to
track it down to the `revolve` call here.
Specifically, the problem is triggered when we're doing a "Full Revolve"
(e.g., `angle = 359.999999` passes, but *not* `angle = 360` or the
default, as it is in `main`), and concurrently executing modules will
see something weird happen with `getNextAdjacentEdge`.
From all the smoke I believe this happens only when we are doing a *full
revolve*, *AND* we're executing other modules which are calling
`getNextAdjacentEdge`.
When the `revolve` is present, we can lose the race in *either*
`talk-button.kcl` OR `case.kcl`.
If I move back to single-threaded execution OR I add imports to sequence
things carefully, I can get the tests to pass. If the revolve is an
`extrude` or not a full revolve, it works fine.
My best guess is that it seems like the world got flipped upside down or
something, such that "next edge" has a different orentation for two
calls. My even further guess is that inside `revolve` we mutate
something connection-global such that it alters the intepretation of
calls made during the revolve implementation's "critical section".
2025-05-13 16:20:48 -04:00
|
|
|
20 ---- 155
|
2025-05-13 21:07:24 -07:00
|
|
|
227 --- 20
|
2025-04-29 06:38:52 -07:00
|
|
|
21 --- 55
|
|
|
|
|
21 --- 56
|
|
|
|
|
21 --- 57
|
|
|
|
|
21 --- 58
|
2025-05-13 21:07:24 -07:00
|
|
|
21 --- 138
|
Avoid using full revolve for now (#6912)
Avoid using revolve for now
When we moved to concurrent execution of KCL modules, we begun to see an
error we never fully understood, and because it was pretty hard to
trigger, we wound up never being able to fix it. Today we were able to
track it down to the `revolve` call here.
Specifically, the problem is triggered when we're doing a "Full Revolve"
(e.g., `angle = 359.999999` passes, but *not* `angle = 360` or the
default, as it is in `main`), and concurrently executing modules will
see something weird happen with `getNextAdjacentEdge`.
From all the smoke I believe this happens only when we are doing a *full
revolve*, *AND* we're executing other modules which are calling
`getNextAdjacentEdge`.
When the `revolve` is present, we can lose the race in *either*
`talk-button.kcl` OR `case.kcl`.
If I move back to single-threaded execution OR I add imports to sequence
things carefully, I can get the tests to pass. If the revolve is an
`extrude` or not a full revolve, it works fine.
My best guess is that it seems like the world got flipped upside down or
something, such that "next edge" has a different orentation for two
calls. My even further guess is that inside `revolve` we mutate
something connection-global such that it alters the intepretation of
calls made during the revolve implementation's "critical section".
2025-05-13 16:20:48 -04:00
|
|
|
21 ---- 156
|
2025-05-13 21:07:24 -07:00
|
|
|
227 --- 21
|
2025-04-29 06:38:52 -07:00
|
|
|
22 --- 59
|
|
|
|
|
22 --- 60
|
|
|
|
|
22 --- 61
|
|
|
|
|
22 --- 62
|
|
|
|
|
22 --- 63
|
2025-05-13 21:07:24 -07:00
|
|
|
22 --- 135
|
2025-04-29 06:38:52 -07:00
|
|
|
23 --- 64
|
|
|
|
|
23 --- 65
|
|
|
|
|
23 --- 66
|
|
|
|
|
23 --- 67
|
Avoid using full revolve for now (#6912)
Avoid using revolve for now
When we moved to concurrent execution of KCL modules, we begun to see an
error we never fully understood, and because it was pretty hard to
trigger, we wound up never being able to fix it. Today we were able to
track it down to the `revolve` call here.
Specifically, the problem is triggered when we're doing a "Full Revolve"
(e.g., `angle = 359.999999` passes, but *not* `angle = 360` or the
default, as it is in `main`), and concurrently executing modules will
see something weird happen with `getNextAdjacentEdge`.
From all the smoke I believe this happens only when we are doing a *full
revolve*, *AND* we're executing other modules which are calling
`getNextAdjacentEdge`.
When the `revolve` is present, we can lose the race in *either*
`talk-button.kcl` OR `case.kcl`.
If I move back to single-threaded execution OR I add imports to sequence
things carefully, I can get the tests to pass. If the revolve is an
`extrude` or not a full revolve, it works fine.
My best guess is that it seems like the world got flipped upside down or
something, such that "next edge" has a different orentation for two
calls. My even further guess is that inside `revolve` we mutate
something connection-global such that it alters the intepretation of
calls made during the revolve implementation's "critical section".
2025-05-13 16:20:48 -04:00
|
|
|
23 --- 146
|
2025-04-29 06:38:52 -07:00
|
|
|
24 --- 68
|
|
|
|
|
24 --- 69
|
|
|
|
|
24 --- 70
|
|
|
|
|
24 --- 71
|
|
|
|
|
24 --- 72
|
|
|
|
|
24 --- 73
|
|
|
|
|
24 --- 74
|
|
|
|
|
24 --- 75
|
2025-05-13 21:07:24 -07:00
|
|
|
24 --- 133
|
Avoid using full revolve for now (#6912)
Avoid using revolve for now
When we moved to concurrent execution of KCL modules, we begun to see an
error we never fully understood, and because it was pretty hard to
trigger, we wound up never being able to fix it. Today we were able to
track it down to the `revolve` call here.
Specifically, the problem is triggered when we're doing a "Full Revolve"
(e.g., `angle = 359.999999` passes, but *not* `angle = 360` or the
default, as it is in `main`), and concurrently executing modules will
see something weird happen with `getNextAdjacentEdge`.
From all the smoke I believe this happens only when we are doing a *full
revolve*, *AND* we're executing other modules which are calling
`getNextAdjacentEdge`.
When the `revolve` is present, we can lose the race in *either*
`talk-button.kcl` OR `case.kcl`.
If I move back to single-threaded execution OR I add imports to sequence
things carefully, I can get the tests to pass. If the revolve is an
`extrude` or not a full revolve, it works fine.
My best guess is that it seems like the world got flipped upside down or
something, such that "next edge" has a different orentation for two
calls. My even further guess is that inside `revolve` we mutate
something connection-global such that it alters the intepretation of
calls made during the revolve implementation's "critical section".
2025-05-13 16:20:48 -04:00
|
|
|
24 ---- 157
|
2025-04-29 06:38:52 -07:00
|
|
|
25 --- 76
|
|
|
|
|
25 --- 77
|
|
|
|
|
25 --- 78
|
|
|
|
|
25 --- 79
|
|
|
|
|
25 --- 80
|
|
|
|
|
25 --- 81
|
|
|
|
|
25 --- 82
|
|
|
|
|
25 --- 83
|
|
|
|
|
25 --- 84
|
|
|
|
|
25 --- 85
|
|
|
|
|
25 --- 86
|
|
|
|
|
25 --- 87
|
|
|
|
|
25 --- 88
|
|
|
|
|
25 --- 89
|
|
|
|
|
25 --- 90
|
|
|
|
|
25 --- 91
|
2025-05-13 21:07:24 -07:00
|
|
|
25 --- 136
|
2025-05-02 10:41:14 -07:00
|
|
|
26 --- 92
|
|
|
|
|
26 --- 95
|
|
|
|
|
26 --- 97
|
2025-04-29 06:38:52 -07:00
|
|
|
26 --- 99
|
Avoid using full revolve for now (#6912)
Avoid using revolve for now
When we moved to concurrent execution of KCL modules, we begun to see an
error we never fully understood, and because it was pretty hard to
trigger, we wound up never being able to fix it. Today we were able to
track it down to the `revolve` call here.
Specifically, the problem is triggered when we're doing a "Full Revolve"
(e.g., `angle = 359.999999` passes, but *not* `angle = 360` or the
default, as it is in `main`), and concurrently executing modules will
see something weird happen with `getNextAdjacentEdge`.
From all the smoke I believe this happens only when we are doing a *full
revolve*, *AND* we're executing other modules which are calling
`getNextAdjacentEdge`.
When the `revolve` is present, we can lose the race in *either*
`talk-button.kcl` OR `case.kcl`.
If I move back to single-threaded execution OR I add imports to sequence
things carefully, I can get the tests to pass. If the revolve is an
`extrude` or not a full revolve, it works fine.
My best guess is that it seems like the world got flipped upside down or
something, such that "next edge" has a different orentation for two
calls. My even further guess is that inside `revolve` we mutate
something connection-global such that it alters the intepretation of
calls made during the revolve implementation's "critical section".
2025-05-13 16:20:48 -04:00
|
|
|
26 --- 147
|
2025-05-02 10:41:14 -07:00
|
|
|
27 --- 93
|
|
|
|
|
27 --- 94
|
|
|
|
|
27 --- 96
|
2025-04-29 06:38:52 -07:00
|
|
|
27 --- 98
|
Avoid using full revolve for now (#6912)
Avoid using revolve for now
When we moved to concurrent execution of KCL modules, we begun to see an
error we never fully understood, and because it was pretty hard to
trigger, we wound up never being able to fix it. Today we were able to
track it down to the `revolve` call here.
Specifically, the problem is triggered when we're doing a "Full Revolve"
(e.g., `angle = 359.999999` passes, but *not* `angle = 360` or the
default, as it is in `main`), and concurrently executing modules will
see something weird happen with `getNextAdjacentEdge`.
From all the smoke I believe this happens only when we are doing a *full
revolve*, *AND* we're executing other modules which are calling
`getNextAdjacentEdge`.
When the `revolve` is present, we can lose the race in *either*
`talk-button.kcl` OR `case.kcl`.
If I move back to single-threaded execution OR I add imports to sequence
things carefully, I can get the tests to pass. If the revolve is an
`extrude` or not a full revolve, it works fine.
My best guess is that it seems like the world got flipped upside down or
something, such that "next edge" has a different orentation for two
calls. My even further guess is that inside `revolve` we mutate
something connection-global such that it alters the intepretation of
calls made during the revolve implementation's "critical section".
2025-05-13 16:20:48 -04:00
|
|
|
27 --- 152
|
2025-05-02 10:41:14 -07:00
|
|
|
28 --- 101
|
2025-04-29 06:38:52 -07:00
|
|
|
28 --- 103
|
2025-05-02 10:41:14 -07:00
|
|
|
28 --- 104
|
|
|
|
|
28 --- 106
|
2025-05-13 21:07:24 -07:00
|
|
|
28 --- 139
|
2025-05-02 10:41:14 -07:00
|
|
|
29 --- 100
|
2025-04-29 06:38:52 -07:00
|
|
|
29 --- 102
|
2025-05-02 10:41:14 -07:00
|
|
|
29 --- 105
|
|
|
|
|
29 --- 107
|
2025-05-13 21:07:24 -07:00
|
|
|
29 --- 142
|
2025-04-29 06:38:52 -07:00
|
|
|
30 --- 108
|
|
|
|
|
30 --- 109
|
|
|
|
|
30 --- 110
|
|
|
|
|
30 --- 111
|
2025-05-13 21:07:24 -07:00
|
|
|
30 --- 134
|
Avoid using full revolve for now (#6912)
Avoid using revolve for now
When we moved to concurrent execution of KCL modules, we begun to see an
error we never fully understood, and because it was pretty hard to
trigger, we wound up never being able to fix it. Today we were able to
track it down to the `revolve` call here.
Specifically, the problem is triggered when we're doing a "Full Revolve"
(e.g., `angle = 359.999999` passes, but *not* `angle = 360` or the
default, as it is in `main`), and concurrently executing modules will
see something weird happen with `getNextAdjacentEdge`.
From all the smoke I believe this happens only when we are doing a *full
revolve*, *AND* we're executing other modules which are calling
`getNextAdjacentEdge`.
When the `revolve` is present, we can lose the race in *either*
`talk-button.kcl` OR `case.kcl`.
If I move back to single-threaded execution OR I add imports to sequence
things carefully, I can get the tests to pass. If the revolve is an
`extrude` or not a full revolve, it works fine.
My best guess is that it seems like the world got flipped upside down or
something, such that "next edge" has a different orentation for two
calls. My even further guess is that inside `revolve` we mutate
something connection-global such that it alters the intepretation of
calls made during the revolve implementation's "critical section".
2025-05-13 16:20:48 -04:00
|
|
|
30 ---- 158
|
|
|
|
|
31 --- 150
|
|
|
|
|
31 x---> 158
|
|
|
|
|
31 x--> 239
|
|
|
|
|
31 x--> 240
|
|
|
|
|
31 x--> 241
|
|
|
|
|
31 x--> 242
|
2025-04-29 06:38:52 -07:00
|
|
|
32 --- 112
|
|
|
|
|
32 --- 113
|
|
|
|
|
32 --- 114
|
|
|
|
|
32 --- 115
|
Avoid using full revolve for now (#6912)
Avoid using revolve for now
When we moved to concurrent execution of KCL modules, we begun to see an
error we never fully understood, and because it was pretty hard to
trigger, we wound up never being able to fix it. Today we were able to
track it down to the `revolve` call here.
Specifically, the problem is triggered when we're doing a "Full Revolve"
(e.g., `angle = 359.999999` passes, but *not* `angle = 360` or the
default, as it is in `main`), and concurrently executing modules will
see something weird happen with `getNextAdjacentEdge`.
From all the smoke I believe this happens only when we are doing a *full
revolve*, *AND* we're executing other modules which are calling
`getNextAdjacentEdge`.
When the `revolve` is present, we can lose the race in *either*
`talk-button.kcl` OR `case.kcl`.
If I move back to single-threaded execution OR I add imports to sequence
things carefully, I can get the tests to pass. If the revolve is an
`extrude` or not a full revolve, it works fine.
My best guess is that it seems like the world got flipped upside down or
something, such that "next edge" has a different orentation for two
calls. My even further guess is that inside `revolve` we mutate
something connection-global such that it alters the intepretation of
calls made during the revolve implementation's "critical section".
2025-05-13 16:20:48 -04:00
|
|
|
32 --- 151
|
|
|
|
|
32 ---- 159
|
2025-04-29 06:38:52 -07:00
|
|
|
33 --- 116
|
2025-05-13 21:07:24 -07:00
|
|
|
33 --- 144
|
Avoid using full revolve for now (#6912)
Avoid using revolve for now
When we moved to concurrent execution of KCL modules, we begun to see an
error we never fully understood, and because it was pretty hard to
trigger, we wound up never being able to fix it. Today we were able to
track it down to the `revolve` call here.
Specifically, the problem is triggered when we're doing a "Full Revolve"
(e.g., `angle = 359.999999` passes, but *not* `angle = 360` or the
default, as it is in `main`), and concurrently executing modules will
see something weird happen with `getNextAdjacentEdge`.
From all the smoke I believe this happens only when we are doing a *full
revolve*, *AND* we're executing other modules which are calling
`getNextAdjacentEdge`.
When the `revolve` is present, we can lose the race in *either*
`talk-button.kcl` OR `case.kcl`.
If I move back to single-threaded execution OR I add imports to sequence
things carefully, I can get the tests to pass. If the revolve is an
`extrude` or not a full revolve, it works fine.
My best guess is that it seems like the world got flipped upside down or
something, such that "next edge" has a different orentation for two
calls. My even further guess is that inside `revolve` we mutate
something connection-global such that it alters the intepretation of
calls made during the revolve implementation's "critical section".
2025-05-13 16:20:48 -04:00
|
|
|
33 ---- 160
|
2025-05-13 21:07:24 -07:00
|
|
|
34 --- 120
|
|
|
|
|
34 --- 122
|
|
|
|
|
34 --- 125
|
Avoid using full revolve for now (#6912)
Avoid using revolve for now
When we moved to concurrent execution of KCL modules, we begun to see an
error we never fully understood, and because it was pretty hard to
trigger, we wound up never being able to fix it. Today we were able to
track it down to the `revolve` call here.
Specifically, the problem is triggered when we're doing a "Full Revolve"
(e.g., `angle = 359.999999` passes, but *not* `angle = 360` or the
default, as it is in `main`), and concurrently executing modules will
see something weird happen with `getNextAdjacentEdge`.
From all the smoke I believe this happens only when we are doing a *full
revolve*, *AND* we're executing other modules which are calling
`getNextAdjacentEdge`.
When the `revolve` is present, we can lose the race in *either*
`talk-button.kcl` OR `case.kcl`.
If I move back to single-threaded execution OR I add imports to sequence
things carefully, I can get the tests to pass. If the revolve is an
`extrude` or not a full revolve, it works fine.
My best guess is that it seems like the world got flipped upside down or
something, such that "next edge" has a different orentation for two
calls. My even further guess is that inside `revolve` we mutate
something connection-global such that it alters the intepretation of
calls made during the revolve implementation's "critical section".
2025-05-13 16:20:48 -04:00
|
|
|
34 --- 130
|
2025-05-13 21:07:24 -07:00
|
|
|
34 --- 140
|
|
|
|
|
34 ---- 161
|
|
|
|
|
35 --- 117
|
|
|
|
|
35 --- 123
|
|
|
|
|
35 --- 128
|
|
|
|
|
35 --- 132
|
|
|
|
|
35 --- 141
|
|
|
|
|
35 ---- 163
|
|
|
|
|
36 --- 118
|
|
|
|
|
36 --- 121
|
|
|
|
|
36 --- 127
|
|
|
|
|
36 --- 129
|
|
|
|
|
36 --- 143
|
|
|
|
|
36 ---- 162
|
|
|
|
|
37 --- 119
|
|
|
|
|
37 --- 124
|
|
|
|
|
37 --- 126
|
|
|
|
|
37 --- 131
|
|
|
|
|
37 --- 145
|
Avoid using full revolve for now (#6912)
Avoid using revolve for now
When we moved to concurrent execution of KCL modules, we begun to see an
error we never fully understood, and because it was pretty hard to
trigger, we wound up never being able to fix it. Today we were able to
track it down to the `revolve` call here.
Specifically, the problem is triggered when we're doing a "Full Revolve"
(e.g., `angle = 359.999999` passes, but *not* `angle = 360` or the
default, as it is in `main`), and concurrently executing modules will
see something weird happen with `getNextAdjacentEdge`.
From all the smoke I believe this happens only when we are doing a *full
revolve*, *AND* we're executing other modules which are calling
`getNextAdjacentEdge`.
When the `revolve` is present, we can lose the race in *either*
`talk-button.kcl` OR `case.kcl`.
If I move back to single-threaded execution OR I add imports to sequence
things carefully, I can get the tests to pass. If the revolve is an
`extrude` or not a full revolve, it works fine.
My best guess is that it seems like the world got flipped upside down or
something, such that "next edge" has a different orentation for two
calls. My even further guess is that inside `revolve` we mutate
something connection-global such that it alters the intepretation of
calls made during the revolve implementation's "critical section".
2025-05-13 16:20:48 -04:00
|
|
|
37 ---- 164
|
2025-05-13 21:07:24 -07:00
|
|
|
38 --- 181
|
Avoid using full revolve for now (#6912)
Avoid using revolve for now
When we moved to concurrent execution of KCL modules, we begun to see an
error we never fully understood, and because it was pretty hard to
trigger, we wound up never being able to fix it. Today we were able to
track it down to the `revolve` call here.
Specifically, the problem is triggered when we're doing a "Full Revolve"
(e.g., `angle = 359.999999` passes, but *not* `angle = 360` or the
default, as it is in `main`), and concurrently executing modules will
see something weird happen with `getNextAdjacentEdge`.
From all the smoke I believe this happens only when we are doing a *full
revolve*, *AND* we're executing other modules which are calling
`getNextAdjacentEdge`.
When the `revolve` is present, we can lose the race in *either*
`talk-button.kcl` OR `case.kcl`.
If I move back to single-threaded execution OR I add imports to sequence
things carefully, I can get the tests to pass. If the revolve is an
`extrude` or not a full revolve, it works fine.
My best guess is that it seems like the world got flipped upside down or
something, such that "next edge" has a different orentation for two
calls. My even further guess is that inside `revolve` we mutate
something connection-global such that it alters the intepretation of
calls made during the revolve implementation's "critical section".
2025-05-13 16:20:48 -04:00
|
|
|
38 x--> 228
|
2025-05-13 21:07:24 -07:00
|
|
|
38 --- 258
|
|
|
|
|
38 --- 311
|
|
|
|
|
39 --- 184
|
Avoid using full revolve for now (#6912)
Avoid using revolve for now
When we moved to concurrent execution of KCL modules, we begun to see an
error we never fully understood, and because it was pretty hard to
trigger, we wound up never being able to fix it. Today we were able to
track it down to the `revolve` call here.
Specifically, the problem is triggered when we're doing a "Full Revolve"
(e.g., `angle = 359.999999` passes, but *not* `angle = 360` or the
default, as it is in `main`), and concurrently executing modules will
see something weird happen with `getNextAdjacentEdge`.
From all the smoke I believe this happens only when we are doing a *full
revolve*, *AND* we're executing other modules which are calling
`getNextAdjacentEdge`.
When the `revolve` is present, we can lose the race in *either*
`talk-button.kcl` OR `case.kcl`.
If I move back to single-threaded execution OR I add imports to sequence
things carefully, I can get the tests to pass. If the revolve is an
`extrude` or not a full revolve, it works fine.
My best guess is that it seems like the world got flipped upside down or
something, such that "next edge" has a different orentation for two
calls. My even further guess is that inside `revolve` we mutate
something connection-global such that it alters the intepretation of
calls made during the revolve implementation's "critical section".
2025-05-13 16:20:48 -04:00
|
|
|
39 x--> 228
|
2025-05-13 21:07:24 -07:00
|
|
|
39 --- 257
|
|
|
|
|
39 --- 310
|
|
|
|
|
40 --- 183
|
Avoid using full revolve for now (#6912)
Avoid using revolve for now
When we moved to concurrent execution of KCL modules, we begun to see an
error we never fully understood, and because it was pretty hard to
trigger, we wound up never being able to fix it. Today we were able to
track it down to the `revolve` call here.
Specifically, the problem is triggered when we're doing a "Full Revolve"
(e.g., `angle = 359.999999` passes, but *not* `angle = 360` or the
default, as it is in `main`), and concurrently executing modules will
see something weird happen with `getNextAdjacentEdge`.
From all the smoke I believe this happens only when we are doing a *full
revolve*, *AND* we're executing other modules which are calling
`getNextAdjacentEdge`.
When the `revolve` is present, we can lose the race in *either*
`talk-button.kcl` OR `case.kcl`.
If I move back to single-threaded execution OR I add imports to sequence
things carefully, I can get the tests to pass. If the revolve is an
`extrude` or not a full revolve, it works fine.
My best guess is that it seems like the world got flipped upside down or
something, such that "next edge" has a different orentation for two
calls. My even further guess is that inside `revolve` we mutate
something connection-global such that it alters the intepretation of
calls made during the revolve implementation's "critical section".
2025-05-13 16:20:48 -04:00
|
|
|
40 x--> 228
|
2025-05-13 21:07:24 -07:00
|
|
|
40 --- 256
|
|
|
|
|
40 --- 309
|
|
|
|
|
41 --- 182
|
Avoid using full revolve for now (#6912)
Avoid using revolve for now
When we moved to concurrent execution of KCL modules, we begun to see an
error we never fully understood, and because it was pretty hard to
trigger, we wound up never being able to fix it. Today we were able to
track it down to the `revolve` call here.
Specifically, the problem is triggered when we're doing a "Full Revolve"
(e.g., `angle = 359.999999` passes, but *not* `angle = 360` or the
default, as it is in `main`), and concurrently executing modules will
see something weird happen with `getNextAdjacentEdge`.
From all the smoke I believe this happens only when we are doing a *full
revolve*, *AND* we're executing other modules which are calling
`getNextAdjacentEdge`.
When the `revolve` is present, we can lose the race in *either*
`talk-button.kcl` OR `case.kcl`.
If I move back to single-threaded execution OR I add imports to sequence
things carefully, I can get the tests to pass. If the revolve is an
`extrude` or not a full revolve, it works fine.
My best guess is that it seems like the world got flipped upside down or
something, such that "next edge" has a different orentation for two
calls. My even further guess is that inside `revolve` we mutate
something connection-global such that it alters the intepretation of
calls made during the revolve implementation's "critical section".
2025-05-13 16:20:48 -04:00
|
|
|
41 x--> 228
|
2025-05-13 21:07:24 -07:00
|
|
|
41 --- 255
|
|
|
|
|
41 --- 308
|
|
|
|
|
42 --- 200
|
Avoid using full revolve for now (#6912)
Avoid using revolve for now
When we moved to concurrent execution of KCL modules, we begun to see an
error we never fully understood, and because it was pretty hard to
trigger, we wound up never being able to fix it. Today we were able to
track it down to the `revolve` call here.
Specifically, the problem is triggered when we're doing a "Full Revolve"
(e.g., `angle = 359.999999` passes, but *not* `angle = 360` or the
default, as it is in `main`), and concurrently executing modules will
see something weird happen with `getNextAdjacentEdge`.
From all the smoke I believe this happens only when we are doing a *full
revolve*, *AND* we're executing other modules which are calling
`getNextAdjacentEdge`.
When the `revolve` is present, we can lose the race in *either*
`talk-button.kcl` OR `case.kcl`.
If I move back to single-threaded execution OR I add imports to sequence
things carefully, I can get the tests to pass. If the revolve is an
`extrude` or not a full revolve, it works fine.
My best guess is that it seems like the world got flipped upside down or
something, such that "next edge" has a different orentation for two
calls. My even further guess is that inside `revolve` we mutate
something connection-global such that it alters the intepretation of
calls made during the revolve implementation's "critical section".
2025-05-13 16:20:48 -04:00
|
|
|
42 x--> 237
|
2025-05-13 21:07:24 -07:00
|
|
|
42 --- 278
|
|
|
|
|
42 --- 331
|
|
|
|
|
43 --- 198
|
Avoid using full revolve for now (#6912)
Avoid using revolve for now
When we moved to concurrent execution of KCL modules, we begun to see an
error we never fully understood, and because it was pretty hard to
trigger, we wound up never being able to fix it. Today we were able to
track it down to the `revolve` call here.
Specifically, the problem is triggered when we're doing a "Full Revolve"
(e.g., `angle = 359.999999` passes, but *not* `angle = 360` or the
default, as it is in `main`), and concurrently executing modules will
see something weird happen with `getNextAdjacentEdge`.
From all the smoke I believe this happens only when we are doing a *full
revolve*, *AND* we're executing other modules which are calling
`getNextAdjacentEdge`.
When the `revolve` is present, we can lose the race in *either*
`talk-button.kcl` OR `case.kcl`.
If I move back to single-threaded execution OR I add imports to sequence
things carefully, I can get the tests to pass. If the revolve is an
`extrude` or not a full revolve, it works fine.
My best guess is that it seems like the world got flipped upside down or
something, such that "next edge" has a different orentation for two
calls. My even further guess is that inside `revolve` we mutate
something connection-global such that it alters the intepretation of
calls made during the revolve implementation's "critical section".
2025-05-13 16:20:48 -04:00
|
|
|
43 x--> 237
|
2025-05-13 21:07:24 -07:00
|
|
|
43 --- 277
|
|
|
|
|
43 --- 330
|
|
|
|
|
44 --- 197
|
Avoid using full revolve for now (#6912)
Avoid using revolve for now
When we moved to concurrent execution of KCL modules, we begun to see an
error we never fully understood, and because it was pretty hard to
trigger, we wound up never being able to fix it. Today we were able to
track it down to the `revolve` call here.
Specifically, the problem is triggered when we're doing a "Full Revolve"
(e.g., `angle = 359.999999` passes, but *not* `angle = 360` or the
default, as it is in `main`), and concurrently executing modules will
see something weird happen with `getNextAdjacentEdge`.
From all the smoke I believe this happens only when we are doing a *full
revolve*, *AND* we're executing other modules which are calling
`getNextAdjacentEdge`.
When the `revolve` is present, we can lose the race in *either*
`talk-button.kcl` OR `case.kcl`.
If I move back to single-threaded execution OR I add imports to sequence
things carefully, I can get the tests to pass. If the revolve is an
`extrude` or not a full revolve, it works fine.
My best guess is that it seems like the world got flipped upside down or
something, such that "next edge" has a different orentation for two
calls. My even further guess is that inside `revolve` we mutate
something connection-global such that it alters the intepretation of
calls made during the revolve implementation's "critical section".
2025-05-13 16:20:48 -04:00
|
|
|
44 x--> 237
|
2025-05-13 21:07:24 -07:00
|
|
|
44 --- 276
|
|
|
|
|
44 --- 329
|
|
|
|
|
45 --- 202
|
Avoid using full revolve for now (#6912)
Avoid using revolve for now
When we moved to concurrent execution of KCL modules, we begun to see an
error we never fully understood, and because it was pretty hard to
trigger, we wound up never being able to fix it. Today we were able to
track it down to the `revolve` call here.
Specifically, the problem is triggered when we're doing a "Full Revolve"
(e.g., `angle = 359.999999` passes, but *not* `angle = 360` or the
default, as it is in `main`), and concurrently executing modules will
see something weird happen with `getNextAdjacentEdge`.
From all the smoke I believe this happens only when we are doing a *full
revolve*, *AND* we're executing other modules which are calling
`getNextAdjacentEdge`.
When the `revolve` is present, we can lose the race in *either*
`talk-button.kcl` OR `case.kcl`.
If I move back to single-threaded execution OR I add imports to sequence
things carefully, I can get the tests to pass. If the revolve is an
`extrude` or not a full revolve, it works fine.
My best guess is that it seems like the world got flipped upside down or
something, such that "next edge" has a different orentation for two
calls. My even further guess is that inside `revolve` we mutate
something connection-global such that it alters the intepretation of
calls made during the revolve implementation's "critical section".
2025-05-13 16:20:48 -04:00
|
|
|
45 x--> 237
|
2025-05-13 21:07:24 -07:00
|
|
|
45 --- 275
|
|
|
|
|
45 --- 328
|
|
|
|
|
46 --- 204
|
Avoid using full revolve for now (#6912)
Avoid using revolve for now
When we moved to concurrent execution of KCL modules, we begun to see an
error we never fully understood, and because it was pretty hard to
trigger, we wound up never being able to fix it. Today we were able to
track it down to the `revolve` call here.
Specifically, the problem is triggered when we're doing a "Full Revolve"
(e.g., `angle = 359.999999` passes, but *not* `angle = 360` or the
default, as it is in `main`), and concurrently executing modules will
see something weird happen with `getNextAdjacentEdge`.
From all the smoke I believe this happens only when we are doing a *full
revolve*, *AND* we're executing other modules which are calling
`getNextAdjacentEdge`.
When the `revolve` is present, we can lose the race in *either*
`talk-button.kcl` OR `case.kcl`.
If I move back to single-threaded execution OR I add imports to sequence
things carefully, I can get the tests to pass. If the revolve is an
`extrude` or not a full revolve, it works fine.
My best guess is that it seems like the world got flipped upside down or
something, such that "next edge" has a different orentation for two
calls. My even further guess is that inside `revolve` we mutate
something connection-global such that it alters the intepretation of
calls made during the revolve implementation's "critical section".
2025-05-13 16:20:48 -04:00
|
|
|
46 x--> 237
|
2025-05-13 21:07:24 -07:00
|
|
|
46 --- 274
|
|
|
|
|
46 --- 327
|
|
|
|
|
47 --- 199
|
Avoid using full revolve for now (#6912)
Avoid using revolve for now
When we moved to concurrent execution of KCL modules, we begun to see an
error we never fully understood, and because it was pretty hard to
trigger, we wound up never being able to fix it. Today we were able to
track it down to the `revolve` call here.
Specifically, the problem is triggered when we're doing a "Full Revolve"
(e.g., `angle = 359.999999` passes, but *not* `angle = 360` or the
default, as it is in `main`), and concurrently executing modules will
see something weird happen with `getNextAdjacentEdge`.
From all the smoke I believe this happens only when we are doing a *full
revolve*, *AND* we're executing other modules which are calling
`getNextAdjacentEdge`.
When the `revolve` is present, we can lose the race in *either*
`talk-button.kcl` OR `case.kcl`.
If I move back to single-threaded execution OR I add imports to sequence
things carefully, I can get the tests to pass. If the revolve is an
`extrude` or not a full revolve, it works fine.
My best guess is that it seems like the world got flipped upside down or
something, such that "next edge" has a different orentation for two
calls. My even further guess is that inside `revolve` we mutate
something connection-global such that it alters the intepretation of
calls made during the revolve implementation's "critical section".
2025-05-13 16:20:48 -04:00
|
|
|
47 x--> 237
|
2025-05-13 21:07:24 -07:00
|
|
|
47 --- 273
|
|
|
|
|
47 --- 326
|
|
|
|
|
48 --- 201
|
Avoid using full revolve for now (#6912)
Avoid using revolve for now
When we moved to concurrent execution of KCL modules, we begun to see an
error we never fully understood, and because it was pretty hard to
trigger, we wound up never being able to fix it. Today we were able to
track it down to the `revolve` call here.
Specifically, the problem is triggered when we're doing a "Full Revolve"
(e.g., `angle = 359.999999` passes, but *not* `angle = 360` or the
default, as it is in `main`), and concurrently executing modules will
see something weird happen with `getNextAdjacentEdge`.
From all the smoke I believe this happens only when we are doing a *full
revolve*, *AND* we're executing other modules which are calling
`getNextAdjacentEdge`.
When the `revolve` is present, we can lose the race in *either*
`talk-button.kcl` OR `case.kcl`.
If I move back to single-threaded execution OR I add imports to sequence
things carefully, I can get the tests to pass. If the revolve is an
`extrude` or not a full revolve, it works fine.
My best guess is that it seems like the world got flipped upside down or
something, such that "next edge" has a different orentation for two
calls. My even further guess is that inside `revolve` we mutate
something connection-global such that it alters the intepretation of
calls made during the revolve implementation's "critical section".
2025-05-13 16:20:48 -04:00
|
|
|
48 x--> 237
|
2025-05-13 21:07:24 -07:00
|
|
|
48 --- 272
|
|
|
|
|
48 --- 325
|
Avoid using full revolve for now (#6912)
Avoid using revolve for now
When we moved to concurrent execution of KCL modules, we begun to see an
error we never fully understood, and because it was pretty hard to
trigger, we wound up never being able to fix it. Today we were able to
track it down to the `revolve` call here.
Specifically, the problem is triggered when we're doing a "Full Revolve"
(e.g., `angle = 359.999999` passes, but *not* `angle = 360` or the
default, as it is in `main`), and concurrently executing modules will
see something weird happen with `getNextAdjacentEdge`.
From all the smoke I believe this happens only when we are doing a *full
revolve*, *AND* we're executing other modules which are calling
`getNextAdjacentEdge`.
When the `revolve` is present, we can lose the race in *either*
`talk-button.kcl` OR `case.kcl`.
If I move back to single-threaded execution OR I add imports to sequence
things carefully, I can get the tests to pass. If the revolve is an
`extrude` or not a full revolve, it works fine.
My best guess is that it seems like the world got flipped upside down or
something, such that "next edge" has a different orentation for two
calls. My even further guess is that inside `revolve` we mutate
something connection-global such that it alters the intepretation of
calls made during the revolve implementation's "critical section".
2025-05-13 16:20:48 -04:00
|
|
|
49 --- 203
|
|
|
|
|
49 x--> 237
|
2025-05-13 21:07:24 -07:00
|
|
|
49 --- 271
|
|
|
|
|
49 --- 324
|
|
|
|
|
50 --- 177
|
|
|
|
|
50 x--> 227
|
|
|
|
|
50 --- 254
|
|
|
|
|
50 --- 307
|
|
|
|
|
51 --- 178
|
|
|
|
|
51 x--> 227
|
|
|
|
|
51 --- 253
|
|
|
|
|
51 --- 306
|
|
|
|
|
52 --- 180
|
|
|
|
|
52 x--> 227
|
|
|
|
|
52 --- 252
|
|
|
|
|
52 --- 305
|
|
|
|
|
53 --- 179
|
|
|
|
|
53 x--> 227
|
|
|
|
|
53 --- 251
|
|
|
|
|
53 --- 304
|
|
|
|
|
55 --- 195
|
|
|
|
|
55 x--> 227
|
|
|
|
|
55 --- 270
|
|
|
|
|
55 --- 323
|
|
|
|
|
56 --- 196
|
|
|
|
|
56 x--> 227
|
|
|
|
|
56 --- 269
|
|
|
|
|
56 --- 322
|
|
|
|
|
57 --- 194
|
|
|
|
|
57 x--> 227
|
|
|
|
|
57 --- 268
|
|
|
|
|
57 --- 321
|
|
|
|
|
58 --- 193
|
|
|
|
|
58 x--> 227
|
|
|
|
|
58 --- 267
|
|
|
|
|
58 --- 320
|
|
|
|
|
68 --- 192
|
|
|
|
|
68 x--> 234
|
|
|
|
|
68 --- 266
|
Avoid using full revolve for now (#6912)
Avoid using revolve for now
When we moved to concurrent execution of KCL modules, we begun to see an
error we never fully understood, and because it was pretty hard to
trigger, we wound up never being able to fix it. Today we were able to
track it down to the `revolve` call here.
Specifically, the problem is triggered when we're doing a "Full Revolve"
(e.g., `angle = 359.999999` passes, but *not* `angle = 360` or the
default, as it is in `main`), and concurrently executing modules will
see something weird happen with `getNextAdjacentEdge`.
From all the smoke I believe this happens only when we are doing a *full
revolve*, *AND* we're executing other modules which are calling
`getNextAdjacentEdge`.
When the `revolve` is present, we can lose the race in *either*
`talk-button.kcl` OR `case.kcl`.
If I move back to single-threaded execution OR I add imports to sequence
things carefully, I can get the tests to pass. If the revolve is an
`extrude` or not a full revolve, it works fine.
My best guess is that it seems like the world got flipped upside down or
something, such that "next edge" has a different orentation for two
calls. My even further guess is that inside `revolve` we mutate
something connection-global such that it alters the intepretation of
calls made during the revolve implementation's "critical section".
2025-05-13 16:20:48 -04:00
|
|
|
68 --- 319
|
2025-05-13 21:07:24 -07:00
|
|
|
69 --- 185
|
|
|
|
|
69 x--> 234
|
|
|
|
|
69 --- 265
|
|
|
|
|
69 --- 318
|
|
|
|
|
70 --- 186
|
|
|
|
|
70 x--> 234
|
|
|
|
|
70 --- 264
|
|
|
|
|
70 --- 317
|
|
|
|
|
71 --- 187
|
|
|
|
|
71 x--> 234
|
Avoid using full revolve for now (#6912)
Avoid using revolve for now
When we moved to concurrent execution of KCL modules, we begun to see an
error we never fully understood, and because it was pretty hard to
trigger, we wound up never being able to fix it. Today we were able to
track it down to the `revolve` call here.
Specifically, the problem is triggered when we're doing a "Full Revolve"
(e.g., `angle = 359.999999` passes, but *not* `angle = 360` or the
default, as it is in `main`), and concurrently executing modules will
see something weird happen with `getNextAdjacentEdge`.
From all the smoke I believe this happens only when we are doing a *full
revolve*, *AND* we're executing other modules which are calling
`getNextAdjacentEdge`.
When the `revolve` is present, we can lose the race in *either*
`talk-button.kcl` OR `case.kcl`.
If I move back to single-threaded execution OR I add imports to sequence
things carefully, I can get the tests to pass. If the revolve is an
`extrude` or not a full revolve, it works fine.
My best guess is that it seems like the world got flipped upside down or
something, such that "next edge" has a different orentation for two
calls. My even further guess is that inside `revolve` we mutate
something connection-global such that it alters the intepretation of
calls made during the revolve implementation's "critical section".
2025-05-13 16:20:48 -04:00
|
|
|
71 --- 263
|
2025-05-13 21:07:24 -07:00
|
|
|
71 --- 316
|
|
|
|
|
72 --- 188
|
|
|
|
|
72 x--> 234
|
|
|
|
|
72 --- 262
|
|
|
|
|
72 --- 315
|
|
|
|
|
73 --- 191
|
|
|
|
|
73 x--> 234
|
|
|
|
|
73 --- 261
|
|
|
|
|
73 --- 314
|
|
|
|
|
74 --- 189
|
|
|
|
|
74 x--> 234
|
|
|
|
|
74 --- 260
|
|
|
|
|
74 --- 313
|
|
|
|
|
75 --- 190
|
|
|
|
|
75 x--> 234
|
|
|
|
|
75 --- 259
|
|
|
|
|
75 --- 312
|
Avoid using full revolve for now (#6912)
Avoid using revolve for now
When we moved to concurrent execution of KCL modules, we begun to see an
error we never fully understood, and because it was pretty hard to
trigger, we wound up never being able to fix it. Today we were able to
track it down to the `revolve` call here.
Specifically, the problem is triggered when we're doing a "Full Revolve"
(e.g., `angle = 359.999999` passes, but *not* `angle = 360` or the
default, as it is in `main`), and concurrently executing modules will
see something weird happen with `getNextAdjacentEdge`.
From all the smoke I believe this happens only when we are doing a *full
revolve*, *AND* we're executing other modules which are calling
`getNextAdjacentEdge`.
When the `revolve` is present, we can lose the race in *either*
`talk-button.kcl` OR `case.kcl`.
If I move back to single-threaded execution OR I add imports to sequence
things carefully, I can get the tests to pass. If the revolve is an
`extrude` or not a full revolve, it works fine.
My best guess is that it seems like the world got flipped upside down or
something, such that "next edge" has a different orentation for two
calls. My even further guess is that inside `revolve` we mutate
something connection-global such that it alters the intepretation of
calls made during the revolve implementation's "critical section".
2025-05-13 16:20:48 -04:00
|
|
|
108 --- 166
|
2025-05-13 21:07:24 -07:00
|
|
|
108 x--> 225
|
Avoid using full revolve for now (#6912)
Avoid using revolve for now
When we moved to concurrent execution of KCL modules, we begun to see an
error we never fully understood, and because it was pretty hard to
trigger, we wound up never being able to fix it. Today we were able to
track it down to the `revolve` call here.
Specifically, the problem is triggered when we're doing a "Full Revolve"
(e.g., `angle = 359.999999` passes, but *not* `angle = 360` or the
default, as it is in `main`), and concurrently executing modules will
see something weird happen with `getNextAdjacentEdge`.
From all the smoke I believe this happens only when we are doing a *full
revolve*, *AND* we're executing other modules which are calling
`getNextAdjacentEdge`.
When the `revolve` is present, we can lose the race in *either*
`talk-button.kcl` OR `case.kcl`.
If I move back to single-threaded execution OR I add imports to sequence
things carefully, I can get the tests to pass. If the revolve is an
`extrude` or not a full revolve, it works fine.
My best guess is that it seems like the world got flipped upside down or
something, such that "next edge" has a different orentation for two
calls. My even further guess is that inside `revolve` we mutate
something connection-global such that it alters the intepretation of
calls made during the revolve implementation's "critical section".
2025-05-13 16:20:48 -04:00
|
|
|
108 --- 239
|
2025-05-13 21:07:24 -07:00
|
|
|
108 --- 292
|
Avoid using full revolve for now (#6912)
Avoid using revolve for now
When we moved to concurrent execution of KCL modules, we begun to see an
error we never fully understood, and because it was pretty hard to
trigger, we wound up never being able to fix it. Today we were able to
track it down to the `revolve` call here.
Specifically, the problem is triggered when we're doing a "Full Revolve"
(e.g., `angle = 359.999999` passes, but *not* `angle = 360` or the
default, as it is in `main`), and concurrently executing modules will
see something weird happen with `getNextAdjacentEdge`.
From all the smoke I believe this happens only when we are doing a *full
revolve*, *AND* we're executing other modules which are calling
`getNextAdjacentEdge`.
When the `revolve` is present, we can lose the race in *either*
`talk-button.kcl` OR `case.kcl`.
If I move back to single-threaded execution OR I add imports to sequence
things carefully, I can get the tests to pass. If the revolve is an
`extrude` or not a full revolve, it works fine.
My best guess is that it seems like the world got flipped upside down or
something, such that "next edge" has a different orentation for two
calls. My even further guess is that inside `revolve` we mutate
something connection-global such that it alters the intepretation of
calls made during the revolve implementation's "critical section".
2025-05-13 16:20:48 -04:00
|
|
|
109 --- 168
|
2025-05-13 21:07:24 -07:00
|
|
|
109 x--> 225
|
|
|
|
|
109 --- 240
|
|
|
|
|
109 --- 293
|
Avoid using full revolve for now (#6912)
Avoid using revolve for now
When we moved to concurrent execution of KCL modules, we begun to see an
error we never fully understood, and because it was pretty hard to
trigger, we wound up never being able to fix it. Today we were able to
track it down to the `revolve` call here.
Specifically, the problem is triggered when we're doing a "Full Revolve"
(e.g., `angle = 359.999999` passes, but *not* `angle = 360` or the
default, as it is in `main`), and concurrently executing modules will
see something weird happen with `getNextAdjacentEdge`.
From all the smoke I believe this happens only when we are doing a *full
revolve*, *AND* we're executing other modules which are calling
`getNextAdjacentEdge`.
When the `revolve` is present, we can lose the race in *either*
`talk-button.kcl` OR `case.kcl`.
If I move back to single-threaded execution OR I add imports to sequence
things carefully, I can get the tests to pass. If the revolve is an
`extrude` or not a full revolve, it works fine.
My best guess is that it seems like the world got flipped upside down or
something, such that "next edge" has a different orentation for two
calls. My even further guess is that inside `revolve` we mutate
something connection-global such that it alters the intepretation of
calls made during the revolve implementation's "critical section".
2025-05-13 16:20:48 -04:00
|
|
|
110 --- 165
|
2025-05-13 21:07:24 -07:00
|
|
|
110 x--> 225
|
|
|
|
|
110 --- 241
|
|
|
|
|
110 --- 294
|
Avoid using full revolve for now (#6912)
Avoid using revolve for now
When we moved to concurrent execution of KCL modules, we begun to see an
error we never fully understood, and because it was pretty hard to
trigger, we wound up never being able to fix it. Today we were able to
track it down to the `revolve` call here.
Specifically, the problem is triggered when we're doing a "Full Revolve"
(e.g., `angle = 359.999999` passes, but *not* `angle = 360` or the
default, as it is in `main`), and concurrently executing modules will
see something weird happen with `getNextAdjacentEdge`.
From all the smoke I believe this happens only when we are doing a *full
revolve*, *AND* we're executing other modules which are calling
`getNextAdjacentEdge`.
When the `revolve` is present, we can lose the race in *either*
`talk-button.kcl` OR `case.kcl`.
If I move back to single-threaded execution OR I add imports to sequence
things carefully, I can get the tests to pass. If the revolve is an
`extrude` or not a full revolve, it works fine.
My best guess is that it seems like the world got flipped upside down or
something, such that "next edge" has a different orentation for two
calls. My even further guess is that inside `revolve` we mutate
something connection-global such that it alters the intepretation of
calls made during the revolve implementation's "critical section".
2025-05-13 16:20:48 -04:00
|
|
|
111 --- 167
|
2025-05-13 21:07:24 -07:00
|
|
|
111 x--> 225
|
|
|
|
|
111 --- 242
|
|
|
|
|
111 --- 295
|
|
|
|
|
112 --- 170
|
|
|
|
|
112 x--> 222
|
|
|
|
|
112 --- 246
|
|
|
|
|
112 --- 299
|
|
|
|
|
113 --- 172
|
|
|
|
|
113 x--> 222
|
|
|
|
|
113 --- 245
|
|
|
|
|
113 --- 298
|
|
|
|
|
114 --- 169
|
|
|
|
|
114 x--> 222
|
|
|
|
|
114 --- 244
|
|
|
|
|
114 --- 297
|
|
|
|
|
115 --- 171
|
|
|
|
|
115 x--> 222
|
|
|
|
|
115 --- 243
|
|
|
|
|
115 --- 296
|
|
|
|
|
116 --- 209
|
|
|
|
|
116 x--> 218
|
|
|
|
|
116 --- 283
|
|
|
|
|
116 --- 336
|
|
|
|
|
117 --- 211
|
|
|
|
|
117 x--> 229
|
|
|
|
|
117 --- 284
|
|
|
|
|
117 --- 337
|
|
|
|
|
118 --- 207
|
|
|
|
|
118 x--> 220
|
|
|
|
|
118 --- 279
|
|
|
|
|
118 --- 332
|
|
|
|
|
119 --- 214
|
|
|
|
|
119 x--> 221
|
|
|
|
|
119 --- 288
|
|
|
|
|
119 --- 341
|
|
|
|
|
120 --- 176
|
|
|
|
|
120 x--> 226
|
|
|
|
|
120 --- 247
|
|
|
|
|
120 --- 300
|
|
|
|
|
121 --- 205
|
|
|
|
|
121 x--> 220
|
|
|
|
|
121 --- 280
|
|
|
|
|
121 --- 333
|
|
|
|
|
122 --- 173
|
|
|
|
|
122 x--> 226
|
|
|
|
|
122 --- 248
|
|
|
|
|
122 --- 301
|
|
|
|
|
123 --- 210
|
|
|
|
|
123 x--> 229
|
|
|
|
|
123 --- 285
|
|
|
|
|
123 --- 338
|
|
|
|
|
124 --- 215
|
|
|
|
|
124 x--> 221
|
|
|
|
|
124 --- 289
|
|
|
|
|
124 --- 342
|
|
|
|
|
125 --- 174
|
|
|
|
|
125 x--> 226
|
|
|
|
|
125 --- 249
|
|
|
|
|
125 --- 302
|
|
|
|
|
126 --- 216
|
|
|
|
|
126 x--> 221
|
|
|
|
|
126 --- 290
|
|
|
|
|
126 --- 343
|
|
|
|
|
127 --- 208
|
|
|
|
|
127 x--> 220
|
|
|
|
|
127 --- 281
|
|
|
|
|
127 --- 334
|
|
|
|
|
128 --- 212
|
Avoid using full revolve for now (#6912)
Avoid using revolve for now
When we moved to concurrent execution of KCL modules, we begun to see an
error we never fully understood, and because it was pretty hard to
trigger, we wound up never being able to fix it. Today we were able to
track it down to the `revolve` call here.
Specifically, the problem is triggered when we're doing a "Full Revolve"
(e.g., `angle = 359.999999` passes, but *not* `angle = 360` or the
default, as it is in `main`), and concurrently executing modules will
see something weird happen with `getNextAdjacentEdge`.
From all the smoke I believe this happens only when we are doing a *full
revolve*, *AND* we're executing other modules which are calling
`getNextAdjacentEdge`.
When the `revolve` is present, we can lose the race in *either*
`talk-button.kcl` OR `case.kcl`.
If I move back to single-threaded execution OR I add imports to sequence
things carefully, I can get the tests to pass. If the revolve is an
`extrude` or not a full revolve, it works fine.
My best guess is that it seems like the world got flipped upside down or
something, such that "next edge" has a different orentation for two
calls. My even further guess is that inside `revolve` we mutate
something connection-global such that it alters the intepretation of
calls made during the revolve implementation's "critical section".
2025-05-13 16:20:48 -04:00
|
|
|
128 x--> 229
|
2025-05-13 21:07:24 -07:00
|
|
|
128 --- 286
|
|
|
|
|
128 --- 339
|
|
|
|
|
129 --- 206
|
|
|
|
|
129 x--> 220
|
|
|
|
|
129 --- 282
|
|
|
|
|
129 --- 335
|
|
|
|
|
130 --- 175
|
|
|
|
|
130 x--> 226
|
|
|
|
|
130 --- 250
|
|
|
|
|
130 --- 303
|
|
|
|
|
131 --- 217
|
|
|
|
|
131 x--> 221
|
|
|
|
|
131 --- 291
|
|
|
|
|
131 --- 344
|
|
|
|
|
132 --- 213
|
Avoid using full revolve for now (#6912)
Avoid using revolve for now
When we moved to concurrent execution of KCL modules, we begun to see an
error we never fully understood, and because it was pretty hard to
trigger, we wound up never being able to fix it. Today we were able to
track it down to the `revolve` call here.
Specifically, the problem is triggered when we're doing a "Full Revolve"
(e.g., `angle = 359.999999` passes, but *not* `angle = 360` or the
default, as it is in `main`), and concurrently executing modules will
see something weird happen with `getNextAdjacentEdge`.
From all the smoke I believe this happens only when we are doing a *full
revolve*, *AND* we're executing other modules which are calling
`getNextAdjacentEdge`.
When the `revolve` is present, we can lose the race in *either*
`talk-button.kcl` OR `case.kcl`.
If I move back to single-threaded execution OR I add imports to sequence
things carefully, I can get the tests to pass. If the revolve is an
`extrude` or not a full revolve, it works fine.
My best guess is that it seems like the world got flipped upside down or
something, such that "next edge" has a different orentation for two
calls. My even further guess is that inside `revolve` we mutate
something connection-global such that it alters the intepretation of
calls made during the revolve implementation's "critical section".
2025-05-13 16:20:48 -04:00
|
|
|
132 x--> 229
|
2025-05-13 21:07:24 -07:00
|
|
|
132 --- 287
|
|
|
|
|
132 --- 340
|
|
|
|
|
153 --- 181
|
|
|
|
|
153 --- 182
|
|
|
|
|
153 --- 183
|
|
|
|
|
153 --- 184
|
Avoid using full revolve for now (#6912)
Avoid using revolve for now
When we moved to concurrent execution of KCL modules, we begun to see an
error we never fully understood, and because it was pretty hard to
trigger, we wound up never being able to fix it. Today we were able to
track it down to the `revolve` call here.
Specifically, the problem is triggered when we're doing a "Full Revolve"
(e.g., `angle = 359.999999` passes, but *not* `angle = 360` or the
default, as it is in `main`), and concurrently executing modules will
see something weird happen with `getNextAdjacentEdge`.
From all the smoke I believe this happens only when we are doing a *full
revolve*, *AND* we're executing other modules which are calling
`getNextAdjacentEdge`.
When the `revolve` is present, we can lose the race in *either*
`talk-button.kcl` OR `case.kcl`.
If I move back to single-threaded execution OR I add imports to sequence
things carefully, I can get the tests to pass. If the revolve is an
`extrude` or not a full revolve, it works fine.
My best guess is that it seems like the world got flipped upside down or
something, such that "next edge" has a different orentation for two
calls. My even further guess is that inside `revolve` we mutate
something connection-global such that it alters the intepretation of
calls made during the revolve implementation's "critical section".
2025-05-13 16:20:48 -04:00
|
|
|
153 --- 228
|
|
|
|
|
153 --- 237
|
2025-05-13 21:07:24 -07:00
|
|
|
153 --- 255
|
|
|
|
|
153 --- 256
|
|
|
|
|
153 --- 257
|
|
|
|
|
153 --- 258
|
|
|
|
|
153 --- 308
|
|
|
|
|
153 --- 309
|
|
|
|
|
153 --- 310
|
|
|
|
|
153 --- 311
|
|
|
|
|
154 --- 197
|
|
|
|
|
154 --- 198
|
|
|
|
|
154 --- 199
|
|
|
|
|
154 --- 200
|
Avoid using full revolve for now (#6912)
Avoid using revolve for now
When we moved to concurrent execution of KCL modules, we begun to see an
error we never fully understood, and because it was pretty hard to
trigger, we wound up never being able to fix it. Today we were able to
track it down to the `revolve` call here.
Specifically, the problem is triggered when we're doing a "Full Revolve"
(e.g., `angle = 359.999999` passes, but *not* `angle = 360` or the
default, as it is in `main`), and concurrently executing modules will
see something weird happen with `getNextAdjacentEdge`.
From all the smoke I believe this happens only when we are doing a *full
revolve*, *AND* we're executing other modules which are calling
`getNextAdjacentEdge`.
When the `revolve` is present, we can lose the race in *either*
`talk-button.kcl` OR `case.kcl`.
If I move back to single-threaded execution OR I add imports to sequence
things carefully, I can get the tests to pass. If the revolve is an
`extrude` or not a full revolve, it works fine.
My best guess is that it seems like the world got flipped upside down or
something, such that "next edge" has a different orentation for two
calls. My even further guess is that inside `revolve` we mutate
something connection-global such that it alters the intepretation of
calls made during the revolve implementation's "critical section".
2025-05-13 16:20:48 -04:00
|
|
|
154 --- 201
|
|
|
|
|
154 --- 202
|
|
|
|
|
154 --- 203
|
|
|
|
|
154 --- 204
|
2025-05-13 21:07:24 -07:00
|
|
|
154 --- 227
|
|
|
|
|
154 --- 271
|
|
|
|
|
154 --- 272
|
|
|
|
|
154 --- 273
|
|
|
|
|
154 --- 274
|
Avoid using full revolve for now (#6912)
Avoid using revolve for now
When we moved to concurrent execution of KCL modules, we begun to see an
error we never fully understood, and because it was pretty hard to
trigger, we wound up never being able to fix it. Today we were able to
track it down to the `revolve` call here.
Specifically, the problem is triggered when we're doing a "Full Revolve"
(e.g., `angle = 359.999999` passes, but *not* `angle = 360` or the
default, as it is in `main`), and concurrently executing modules will
see something weird happen with `getNextAdjacentEdge`.
From all the smoke I believe this happens only when we are doing a *full
revolve*, *AND* we're executing other modules which are calling
`getNextAdjacentEdge`.
When the `revolve` is present, we can lose the race in *either*
`talk-button.kcl` OR `case.kcl`.
If I move back to single-threaded execution OR I add imports to sequence
things carefully, I can get the tests to pass. If the revolve is an
`extrude` or not a full revolve, it works fine.
My best guess is that it seems like the world got flipped upside down or
something, such that "next edge" has a different orentation for two
calls. My even further guess is that inside `revolve` we mutate
something connection-global such that it alters the intepretation of
calls made during the revolve implementation's "critical section".
2025-05-13 16:20:48 -04:00
|
|
|
154 --- 275
|
|
|
|
|
154 --- 276
|
|
|
|
|
154 --- 277
|
|
|
|
|
154 --- 278
|
2025-05-13 21:07:24 -07:00
|
|
|
154 --- 324
|
|
|
|
|
154 --- 325
|
|
|
|
|
154 --- 326
|
|
|
|
|
154 --- 327
|
Avoid using full revolve for now (#6912)
Avoid using revolve for now
When we moved to concurrent execution of KCL modules, we begun to see an
error we never fully understood, and because it was pretty hard to
trigger, we wound up never being able to fix it. Today we were able to
track it down to the `revolve` call here.
Specifically, the problem is triggered when we're doing a "Full Revolve"
(e.g., `angle = 359.999999` passes, but *not* `angle = 360` or the
default, as it is in `main`), and concurrently executing modules will
see something weird happen with `getNextAdjacentEdge`.
From all the smoke I believe this happens only when we are doing a *full
revolve*, *AND* we're executing other modules which are calling
`getNextAdjacentEdge`.
When the `revolve` is present, we can lose the race in *either*
`talk-button.kcl` OR `case.kcl`.
If I move back to single-threaded execution OR I add imports to sequence
things carefully, I can get the tests to pass. If the revolve is an
`extrude` or not a full revolve, it works fine.
My best guess is that it seems like the world got flipped upside down or
something, such that "next edge" has a different orentation for two
calls. My even further guess is that inside `revolve` we mutate
something connection-global such that it alters the intepretation of
calls made during the revolve implementation's "critical section".
2025-05-13 16:20:48 -04:00
|
|
|
154 --- 328
|
|
|
|
|
154 --- 329
|
|
|
|
|
154 --- 330
|
|
|
|
|
154 --- 331
|
2025-05-13 21:07:24 -07:00
|
|
|
155 --- 177
|
|
|
|
|
155 --- 178
|
|
|
|
|
155 --- 179
|
|
|
|
|
155 --- 180
|
|
|
|
|
155 --- 219
|
|
|
|
|
155 --- 251
|
|
|
|
|
155 --- 252
|
|
|
|
|
155 --- 253
|
|
|
|
|
155 --- 254
|
|
|
|
|
155 --- 304
|
|
|
|
|
155 --- 305
|
|
|
|
|
155 --- 306
|
|
|
|
|
155 --- 307
|
|
|
|
|
156 --- 193
|
|
|
|
|
156 --- 194
|
|
|
|
|
156 --- 195
|
|
|
|
|
156 --- 196
|
|
|
|
|
156 --- 224
|
|
|
|
|
156 --- 267
|
|
|
|
|
156 --- 268
|
|
|
|
|
156 --- 269
|
|
|
|
|
156 --- 270
|
|
|
|
|
156 --- 320
|
|
|
|
|
156 --- 321
|
|
|
|
|
156 --- 322
|
|
|
|
|
156 --- 323
|
|
|
|
|
157 --- 185
|
|
|
|
|
157 --- 186
|
|
|
|
|
157 --- 187
|
|
|
|
|
157 --- 188
|
Avoid using full revolve for now (#6912)
Avoid using revolve for now
When we moved to concurrent execution of KCL modules, we begun to see an
error we never fully understood, and because it was pretty hard to
trigger, we wound up never being able to fix it. Today we were able to
track it down to the `revolve` call here.
Specifically, the problem is triggered when we're doing a "Full Revolve"
(e.g., `angle = 359.999999` passes, but *not* `angle = 360` or the
default, as it is in `main`), and concurrently executing modules will
see something weird happen with `getNextAdjacentEdge`.
From all the smoke I believe this happens only when we are doing a *full
revolve*, *AND* we're executing other modules which are calling
`getNextAdjacentEdge`.
When the `revolve` is present, we can lose the race in *either*
`talk-button.kcl` OR `case.kcl`.
If I move back to single-threaded execution OR I add imports to sequence
things carefully, I can get the tests to pass. If the revolve is an
`extrude` or not a full revolve, it works fine.
My best guess is that it seems like the world got flipped upside down or
something, such that "next edge" has a different orentation for two
calls. My even further guess is that inside `revolve` we mutate
something connection-global such that it alters the intepretation of
calls made during the revolve implementation's "critical section".
2025-05-13 16:20:48 -04:00
|
|
|
157 --- 189
|
|
|
|
|
157 --- 190
|
|
|
|
|
157 --- 191
|
|
|
|
|
157 --- 192
|
2025-05-13 21:07:24 -07:00
|
|
|
157 --- 223
|
|
|
|
|
157 --- 234
|
|
|
|
|
157 --- 259
|
|
|
|
|
157 --- 260
|
|
|
|
|
157 --- 261
|
|
|
|
|
157 --- 262
|
Avoid using full revolve for now (#6912)
Avoid using revolve for now
When we moved to concurrent execution of KCL modules, we begun to see an
error we never fully understood, and because it was pretty hard to
trigger, we wound up never being able to fix it. Today we were able to
track it down to the `revolve` call here.
Specifically, the problem is triggered when we're doing a "Full Revolve"
(e.g., `angle = 359.999999` passes, but *not* `angle = 360` or the
default, as it is in `main`), and concurrently executing modules will
see something weird happen with `getNextAdjacentEdge`.
From all the smoke I believe this happens only when we are doing a *full
revolve*, *AND* we're executing other modules which are calling
`getNextAdjacentEdge`.
When the `revolve` is present, we can lose the race in *either*
`talk-button.kcl` OR `case.kcl`.
If I move back to single-threaded execution OR I add imports to sequence
things carefully, I can get the tests to pass. If the revolve is an
`extrude` or not a full revolve, it works fine.
My best guess is that it seems like the world got flipped upside down or
something, such that "next edge" has a different orentation for two
calls. My even further guess is that inside `revolve` we mutate
something connection-global such that it alters the intepretation of
calls made during the revolve implementation's "critical section".
2025-05-13 16:20:48 -04:00
|
|
|
157 --- 263
|
|
|
|
|
157 --- 264
|
2025-05-02 10:41:14 -07:00
|
|
|
157 --- 265
|
|
|
|
|
157 --- 266
|
2025-05-13 21:07:24 -07:00
|
|
|
157 --- 312
|
|
|
|
|
157 --- 313
|
|
|
|
|
157 --- 314
|
|
|
|
|
157 --- 315
|
Avoid using full revolve for now (#6912)
Avoid using revolve for now
When we moved to concurrent execution of KCL modules, we begun to see an
error we never fully understood, and because it was pretty hard to
trigger, we wound up never being able to fix it. Today we were able to
track it down to the `revolve` call here.
Specifically, the problem is triggered when we're doing a "Full Revolve"
(e.g., `angle = 359.999999` passes, but *not* `angle = 360` or the
default, as it is in `main`), and concurrently executing modules will
see something weird happen with `getNextAdjacentEdge`.
From all the smoke I believe this happens only when we are doing a *full
revolve*, *AND* we're executing other modules which are calling
`getNextAdjacentEdge`.
When the `revolve` is present, we can lose the race in *either*
`talk-button.kcl` OR `case.kcl`.
If I move back to single-threaded execution OR I add imports to sequence
things carefully, I can get the tests to pass. If the revolve is an
`extrude` or not a full revolve, it works fine.
My best guess is that it seems like the world got flipped upside down or
something, such that "next edge" has a different orentation for two
calls. My even further guess is that inside `revolve` we mutate
something connection-global such that it alters the intepretation of
calls made during the revolve implementation's "critical section".
2025-05-13 16:20:48 -04:00
|
|
|
157 --- 316
|
|
|
|
|
157 --- 317
|
|
|
|
|
157 --- 318
|
|
|
|
|
157 --- 319
|
|
|
|
|
158 --- 165
|
|
|
|
|
158 --- 166
|
|
|
|
|
158 --- 167
|
|
|
|
|
158 --- 168
|
2025-05-13 21:07:24 -07:00
|
|
|
158 --- 225
|
|
|
|
|
158 --- 235
|
Avoid using full revolve for now (#6912)
Avoid using revolve for now
When we moved to concurrent execution of KCL modules, we begun to see an
error we never fully understood, and because it was pretty hard to
trigger, we wound up never being able to fix it. Today we were able to
track it down to the `revolve` call here.
Specifically, the problem is triggered when we're doing a "Full Revolve"
(e.g., `angle = 359.999999` passes, but *not* `angle = 360` or the
default, as it is in `main`), and concurrently executing modules will
see something weird happen with `getNextAdjacentEdge`.
From all the smoke I believe this happens only when we are doing a *full
revolve*, *AND* we're executing other modules which are calling
`getNextAdjacentEdge`.
When the `revolve` is present, we can lose the race in *either*
`talk-button.kcl` OR `case.kcl`.
If I move back to single-threaded execution OR I add imports to sequence
things carefully, I can get the tests to pass. If the revolve is an
`extrude` or not a full revolve, it works fine.
My best guess is that it seems like the world got flipped upside down or
something, such that "next edge" has a different orentation for two
calls. My even further guess is that inside `revolve` we mutate
something connection-global such that it alters the intepretation of
calls made during the revolve implementation's "critical section".
2025-05-13 16:20:48 -04:00
|
|
|
158 --- 239
|
|
|
|
|
158 --- 240
|
|
|
|
|
158 --- 241
|
|
|
|
|
158 --- 242
|
|
|
|
|
158 --- 292
|
|
|
|
|
158 --- 293
|
|
|
|
|
158 --- 294
|
|
|
|
|
158 --- 295
|
2025-05-13 21:07:24 -07:00
|
|
|
159 --- 169
|
|
|
|
|
159 --- 170
|
|
|
|
|
159 --- 171
|
|
|
|
|
159 --- 172
|
|
|
|
|
159 --- 222
|
|
|
|
|
159 --- 233
|
|
|
|
|
159 --- 243
|
|
|
|
|
159 --- 244
|
|
|
|
|
159 --- 245
|
|
|
|
|
159 --- 246
|
|
|
|
|
159 --- 296
|
|
|
|
|
159 --- 297
|
|
|
|
|
159 --- 298
|
|
|
|
|
159 --- 299
|
|
|
|
|
160 --- 209
|
|
|
|
|
160 --- 218
|
|
|
|
|
160 --- 230
|
|
|
|
|
160 --- 283
|
|
|
|
|
160 --- 336
|
|
|
|
|
161 --- 173
|
|
|
|
|
161 --- 174
|
|
|
|
|
161 --- 175
|
|
|
|
|
161 --- 176
|
|
|
|
|
161 --- 226
|
|
|
|
|
161 --- 236
|
|
|
|
|
161 --- 247
|
|
|
|
|
161 --- 248
|
|
|
|
|
161 --- 249
|
|
|
|
|
161 --- 250
|
|
|
|
|
161 --- 300
|
|
|
|
|
161 --- 301
|
|
|
|
|
161 --- 302
|
|
|
|
|
161 --- 303
|
|
|
|
|
162 --- 205
|
|
|
|
|
162 --- 206
|
|
|
|
|
162 --- 207
|
|
|
|
|
162 --- 208
|
|
|
|
|
162 --- 220
|
|
|
|
|
162 --- 231
|
|
|
|
|
162 --- 279
|
|
|
|
|
162 --- 280
|
|
|
|
|
162 --- 281
|
|
|
|
|
162 --- 282
|
|
|
|
|
162 --- 332
|
|
|
|
|
162 --- 333
|
|
|
|
|
162 --- 334
|
|
|
|
|
162 --- 335
|
|
|
|
|
163 --- 210
|
|
|
|
|
163 --- 211
|
|
|
|
|
163 --- 212
|
|
|
|
|
163 --- 213
|
|
|
|
|
163 --- 229
|
|
|
|
|
163 --- 238
|
|
|
|
|
163 --- 284
|
|
|
|
|
163 --- 285
|
|
|
|
|
163 --- 286
|
|
|
|
|
163 --- 287
|
|
|
|
|
163 --- 337
|
|
|
|
|
163 --- 338
|
|
|
|
|
163 --- 339
|
|
|
|
|
163 --- 340
|
Avoid using full revolve for now (#6912)
Avoid using revolve for now
When we moved to concurrent execution of KCL modules, we begun to see an
error we never fully understood, and because it was pretty hard to
trigger, we wound up never being able to fix it. Today we were able to
track it down to the `revolve` call here.
Specifically, the problem is triggered when we're doing a "Full Revolve"
(e.g., `angle = 359.999999` passes, but *not* `angle = 360` or the
default, as it is in `main`), and concurrently executing modules will
see something weird happen with `getNextAdjacentEdge`.
From all the smoke I believe this happens only when we are doing a *full
revolve*, *AND* we're executing other modules which are calling
`getNextAdjacentEdge`.
When the `revolve` is present, we can lose the race in *either*
`talk-button.kcl` OR `case.kcl`.
If I move back to single-threaded execution OR I add imports to sequence
things carefully, I can get the tests to pass. If the revolve is an
`extrude` or not a full revolve, it works fine.
My best guess is that it seems like the world got flipped upside down or
something, such that "next edge" has a different orentation for two
calls. My even further guess is that inside `revolve` we mutate
something connection-global such that it alters the intepretation of
calls made during the revolve implementation's "critical section".
2025-05-13 16:20:48 -04:00
|
|
|
164 --- 214
|
|
|
|
|
164 --- 215
|
|
|
|
|
164 --- 216
|
|
|
|
|
164 --- 217
|
2025-05-13 21:07:24 -07:00
|
|
|
164 --- 221
|
|
|
|
|
164 --- 232
|
Avoid using full revolve for now (#6912)
Avoid using revolve for now
When we moved to concurrent execution of KCL modules, we begun to see an
error we never fully understood, and because it was pretty hard to
trigger, we wound up never being able to fix it. Today we were able to
track it down to the `revolve` call here.
Specifically, the problem is triggered when we're doing a "Full Revolve"
(e.g., `angle = 359.999999` passes, but *not* `angle = 360` or the
default, as it is in `main`), and concurrently executing modules will
see something weird happen with `getNextAdjacentEdge`.
From all the smoke I believe this happens only when we are doing a *full
revolve*, *AND* we're executing other modules which are calling
`getNextAdjacentEdge`.
When the `revolve` is present, we can lose the race in *either*
`talk-button.kcl` OR `case.kcl`.
If I move back to single-threaded execution OR I add imports to sequence
things carefully, I can get the tests to pass. If the revolve is an
`extrude` or not a full revolve, it works fine.
My best guess is that it seems like the world got flipped upside down or
something, such that "next edge" has a different orentation for two
calls. My even further guess is that inside `revolve` we mutate
something connection-global such that it alters the intepretation of
calls made during the revolve implementation's "critical section".
2025-05-13 16:20:48 -04:00
|
|
|
164 --- 288
|
|
|
|
|
164 --- 289
|
|
|
|
|
164 --- 290
|
|
|
|
|
164 --- 291
|
|
|
|
|
164 --- 341
|
|
|
|
|
164 --- 342
|
|
|
|
|
164 --- 343
|
|
|
|
|
164 --- 344
|
2025-05-13 21:07:24 -07:00
|
|
|
165 --- 241
|
|
|
|
|
165 --- 294
|
|
|
|
|
295 <--x 165
|
|
|
|
|
166 --- 239
|
|
|
|
|
166 --- 292
|
|
|
|
|
293 <--x 166
|
|
|
|
|
167 --- 242
|
Avoid using full revolve for now (#6912)
Avoid using revolve for now
When we moved to concurrent execution of KCL modules, we begun to see an
error we never fully understood, and because it was pretty hard to
trigger, we wound up never being able to fix it. Today we were able to
track it down to the `revolve` call here.
Specifically, the problem is triggered when we're doing a "Full Revolve"
(e.g., `angle = 359.999999` passes, but *not* `angle = 360` or the
default, as it is in `main`), and concurrently executing modules will
see something weird happen with `getNextAdjacentEdge`.
From all the smoke I believe this happens only when we are doing a *full
revolve*, *AND* we're executing other modules which are calling
`getNextAdjacentEdge`.
When the `revolve` is present, we can lose the race in *either*
`talk-button.kcl` OR `case.kcl`.
If I move back to single-threaded execution OR I add imports to sequence
things carefully, I can get the tests to pass. If the revolve is an
`extrude` or not a full revolve, it works fine.
My best guess is that it seems like the world got flipped upside down or
something, such that "next edge" has a different orentation for two
calls. My even further guess is that inside `revolve` we mutate
something connection-global such that it alters the intepretation of
calls made during the revolve implementation's "critical section".
2025-05-13 16:20:48 -04:00
|
|
|
292 <--x 167
|
2025-05-13 21:07:24 -07:00
|
|
|
167 --- 295
|
|
|
|
|
168 --- 240
|
|
|
|
|
168 --- 293
|
|
|
|
|
294 <--x 168
|
|
|
|
|
169 --- 244
|
|
|
|
|
169 --- 297
|
|
|
|
|
298 <--x 169
|
|
|
|
|
170 --- 246
|
|
|
|
|
296 <--x 170
|
|
|
|
|
170 --- 299
|
|
|
|
|
171 --- 243
|
|
|
|
|
171 --- 296
|
2025-05-02 10:41:14 -07:00
|
|
|
297 <--x 171
|
2025-05-13 21:07:24 -07:00
|
|
|
172 --- 245
|
|
|
|
|
172 --- 298
|
Avoid using full revolve for now (#6912)
Avoid using revolve for now
When we moved to concurrent execution of KCL modules, we begun to see an
error we never fully understood, and because it was pretty hard to
trigger, we wound up never being able to fix it. Today we were able to
track it down to the `revolve` call here.
Specifically, the problem is triggered when we're doing a "Full Revolve"
(e.g., `angle = 359.999999` passes, but *not* `angle = 360` or the
default, as it is in `main`), and concurrently executing modules will
see something weird happen with `getNextAdjacentEdge`.
From all the smoke I believe this happens only when we are doing a *full
revolve*, *AND* we're executing other modules which are calling
`getNextAdjacentEdge`.
When the `revolve` is present, we can lose the race in *either*
`talk-button.kcl` OR `case.kcl`.
If I move back to single-threaded execution OR I add imports to sequence
things carefully, I can get the tests to pass. If the revolve is an
`extrude` or not a full revolve, it works fine.
My best guess is that it seems like the world got flipped upside down or
something, such that "next edge" has a different orentation for two
calls. My even further guess is that inside `revolve` we mutate
something connection-global such that it alters the intepretation of
calls made during the revolve implementation's "critical section".
2025-05-13 16:20:48 -04:00
|
|
|
299 <--x 172
|
2025-05-13 21:07:24 -07:00
|
|
|
173 --- 248
|
|
|
|
|
300 <--x 173
|
|
|
|
|
173 --- 301
|
|
|
|
|
174 --- 249
|
|
|
|
|
301 <--x 174
|
|
|
|
|
174 --- 302
|
|
|
|
|
175 --- 250
|
|
|
|
|
302 <--x 175
|
|
|
|
|
175 --- 303
|
|
|
|
|
176 --- 247
|
|
|
|
|
176 --- 300
|
|
|
|
|
303 <--x 176
|
|
|
|
|
177 --- 254
|
|
|
|
|
304 <--x 177
|
|
|
|
|
177 --- 307
|
|
|
|
|
178 --- 253
|
|
|
|
|
178 --- 306
|
Avoid using full revolve for now (#6912)
Avoid using revolve for now
When we moved to concurrent execution of KCL modules, we begun to see an
error we never fully understood, and because it was pretty hard to
trigger, we wound up never being able to fix it. Today we were able to
track it down to the `revolve` call here.
Specifically, the problem is triggered when we're doing a "Full Revolve"
(e.g., `angle = 359.999999` passes, but *not* `angle = 360` or the
default, as it is in `main`), and concurrently executing modules will
see something weird happen with `getNextAdjacentEdge`.
From all the smoke I believe this happens only when we are doing a *full
revolve*, *AND* we're executing other modules which are calling
`getNextAdjacentEdge`.
When the `revolve` is present, we can lose the race in *either*
`talk-button.kcl` OR `case.kcl`.
If I move back to single-threaded execution OR I add imports to sequence
things carefully, I can get the tests to pass. If the revolve is an
`extrude` or not a full revolve, it works fine.
My best guess is that it seems like the world got flipped upside down or
something, such that "next edge" has a different orentation for two
calls. My even further guess is that inside `revolve` we mutate
something connection-global such that it alters the intepretation of
calls made during the revolve implementation's "critical section".
2025-05-13 16:20:48 -04:00
|
|
|
307 <--x 178
|
2025-05-13 21:07:24 -07:00
|
|
|
179 --- 251
|
|
|
|
|
179 --- 304
|
|
|
|
|
305 <--x 179
|
|
|
|
|
180 --- 252
|
|
|
|
|
180 --- 305
|
|
|
|
|
306 <--x 180
|
|
|
|
|
181 --- 258
|
Avoid using full revolve for now (#6912)
Avoid using revolve for now
When we moved to concurrent execution of KCL modules, we begun to see an
error we never fully understood, and because it was pretty hard to
trigger, we wound up never being able to fix it. Today we were able to
track it down to the `revolve` call here.
Specifically, the problem is triggered when we're doing a "Full Revolve"
(e.g., `angle = 359.999999` passes, but *not* `angle = 360` or the
default, as it is in `main`), and concurrently executing modules will
see something weird happen with `getNextAdjacentEdge`.
From all the smoke I believe this happens only when we are doing a *full
revolve*, *AND* we're executing other modules which are calling
`getNextAdjacentEdge`.
When the `revolve` is present, we can lose the race in *either*
`talk-button.kcl` OR `case.kcl`.
If I move back to single-threaded execution OR I add imports to sequence
things carefully, I can get the tests to pass. If the revolve is an
`extrude` or not a full revolve, it works fine.
My best guess is that it seems like the world got flipped upside down or
something, such that "next edge" has a different orentation for two
calls. My even further guess is that inside `revolve` we mutate
something connection-global such that it alters the intepretation of
calls made during the revolve implementation's "critical section".
2025-05-13 16:20:48 -04:00
|
|
|
308 <--x 181
|
2025-05-13 21:07:24 -07:00
|
|
|
181 --- 311
|
|
|
|
|
182 --- 255
|
|
|
|
|
182 --- 308
|
|
|
|
|
309 <--x 182
|
|
|
|
|
183 --- 256
|
|
|
|
|
183 --- 309
|
|
|
|
|
310 <--x 183
|
|
|
|
|
184 --- 257
|
|
|
|
|
184 --- 310
|
2025-05-02 10:41:14 -07:00
|
|
|
311 <--x 184
|
2025-05-13 21:07:24 -07:00
|
|
|
185 --- 265
|
|
|
|
|
185 --- 318
|
|
|
|
|
319 <--x 185
|
|
|
|
|
186 --- 264
|
|
|
|
|
186 --- 317
|
|
|
|
|
318 <--x 186
|
|
|
|
|
187 --- 263
|
|
|
|
|
187 --- 316
|
|
|
|
|
317 <--x 187
|
|
|
|
|
188 --- 262
|
|
|
|
|
188 --- 315
|
|
|
|
|
316 <--x 188
|
|
|
|
|
189 --- 260
|
|
|
|
|
189 --- 313
|
|
|
|
|
314 <--x 189
|
|
|
|
|
190 --- 259
|
|
|
|
|
190 --- 312
|
|
|
|
|
313 <--x 190
|
|
|
|
|
191 --- 261
|
|
|
|
|
191 --- 314
|
|
|
|
|
315 <--x 191
|
|
|
|
|
192 --- 266
|
|
|
|
|
312 <--x 192
|
|
|
|
|
192 --- 319
|
|
|
|
|
193 --- 267
|
|
|
|
|
193 --- 320
|
|
|
|
|
321 <--x 193
|
|
|
|
|
194 --- 268
|
|
|
|
|
194 --- 321
|
|
|
|
|
322 <--x 194
|
|
|
|
|
195 --- 270
|
|
|
|
|
320 <--x 195
|
|
|
|
|
195 --- 323
|
|
|
|
|
196 --- 269
|
|
|
|
|
196 --- 322
|
|
|
|
|
323 <--x 196
|
|
|
|
|
197 --- 276
|
|
|
|
|
197 --- 329
|
|
|
|
|
330 <--x 197
|
|
|
|
|
198 --- 277
|
|
|
|
|
198 --- 330
|
|
|
|
|
331 <--x 198
|
|
|
|
|
199 --- 273
|
|
|
|
|
199 --- 326
|
Avoid using full revolve for now (#6912)
Avoid using revolve for now
When we moved to concurrent execution of KCL modules, we begun to see an
error we never fully understood, and because it was pretty hard to
trigger, we wound up never being able to fix it. Today we were able to
track it down to the `revolve` call here.
Specifically, the problem is triggered when we're doing a "Full Revolve"
(e.g., `angle = 359.999999` passes, but *not* `angle = 360` or the
default, as it is in `main`), and concurrently executing modules will
see something weird happen with `getNextAdjacentEdge`.
From all the smoke I believe this happens only when we are doing a *full
revolve*, *AND* we're executing other modules which are calling
`getNextAdjacentEdge`.
When the `revolve` is present, we can lose the race in *either*
`talk-button.kcl` OR `case.kcl`.
If I move back to single-threaded execution OR I add imports to sequence
things carefully, I can get the tests to pass. If the revolve is an
`extrude` or not a full revolve, it works fine.
My best guess is that it seems like the world got flipped upside down or
something, such that "next edge" has a different orentation for two
calls. My even further guess is that inside `revolve` we mutate
something connection-global such that it alters the intepretation of
calls made during the revolve implementation's "critical section".
2025-05-13 16:20:48 -04:00
|
|
|
327 <--x 199
|
2025-05-13 21:07:24 -07:00
|
|
|
200 --- 278
|
|
|
|
|
324 <--x 200
|
|
|
|
|
200 --- 331
|
|
|
|
|
201 --- 272
|
|
|
|
|
201 --- 325
|
|
|
|
|
326 <--x 201
|
|
|
|
|
202 --- 275
|
|
|
|
|
202 --- 328
|
|
|
|
|
329 <--x 202
|
|
|
|
|
203 --- 271
|
|
|
|
|
203 --- 324
|
|
|
|
|
325 <--x 203
|
|
|
|
|
204 --- 274
|
|
|
|
|
204 --- 327
|
|
|
|
|
328 <--x 204
|
|
|
|
|
205 --- 280
|
|
|
|
|
332 <--x 205
|
|
|
|
|
205 --- 333
|
|
|
|
|
206 --- 282
|
2025-05-02 10:41:14 -07:00
|
|
|
334 <--x 206
|
2025-05-13 21:07:24 -07:00
|
|
|
206 --- 335
|
|
|
|
|
207 --- 279
|
|
|
|
|
207 --- 332
|
|
|
|
|
335 <--x 207
|
|
|
|
|
208 --- 281
|
|
|
|
|
333 <--x 208
|
|
|
|
|
208 --- 334
|
|
|
|
|
209 --- 283
|
|
|
|
|
209 --- 336
|
|
|
|
|
210 --- 285
|
Avoid using full revolve for now (#6912)
Avoid using revolve for now
When we moved to concurrent execution of KCL modules, we begun to see an
error we never fully understood, and because it was pretty hard to
trigger, we wound up never being able to fix it. Today we were able to
track it down to the `revolve` call here.
Specifically, the problem is triggered when we're doing a "Full Revolve"
(e.g., `angle = 359.999999` passes, but *not* `angle = 360` or the
default, as it is in `main`), and concurrently executing modules will
see something weird happen with `getNextAdjacentEdge`.
From all the smoke I believe this happens only when we are doing a *full
revolve*, *AND* we're executing other modules which are calling
`getNextAdjacentEdge`.
When the `revolve` is present, we can lose the race in *either*
`talk-button.kcl` OR `case.kcl`.
If I move back to single-threaded execution OR I add imports to sequence
things carefully, I can get the tests to pass. If the revolve is an
`extrude` or not a full revolve, it works fine.
My best guess is that it seems like the world got flipped upside down or
something, such that "next edge" has a different orentation for two
calls. My even further guess is that inside `revolve` we mutate
something connection-global such that it alters the intepretation of
calls made during the revolve implementation's "critical section".
2025-05-13 16:20:48 -04:00
|
|
|
337 <--x 210
|
2025-05-13 21:07:24 -07:00
|
|
|
210 --- 338
|
|
|
|
|
211 --- 284
|
|
|
|
|
211 --- 337
|
|
|
|
|
340 <--x 211
|
|
|
|
|
212 --- 286
|
2025-04-29 06:38:52 -07:00
|
|
|
338 <--x 212
|
2025-05-13 21:07:24 -07:00
|
|
|
212 --- 339
|
|
|
|
|
213 --- 287
|
|
|
|
|
339 <--x 213
|
|
|
|
|
213 --- 340
|
|
|
|
|
214 --- 288
|
|
|
|
|
214 --- 341
|
|
|
|
|
344 <--x 214
|
|
|
|
|
215 --- 289
|
|
|
|
|
341 <--x 215
|
|
|
|
|
215 --- 342
|
|
|
|
|
216 --- 290
|
Avoid using full revolve for now (#6912)
Avoid using revolve for now
When we moved to concurrent execution of KCL modules, we begun to see an
error we never fully understood, and because it was pretty hard to
trigger, we wound up never being able to fix it. Today we were able to
track it down to the `revolve` call here.
Specifically, the problem is triggered when we're doing a "Full Revolve"
(e.g., `angle = 359.999999` passes, but *not* `angle = 360` or the
default, as it is in `main`), and concurrently executing modules will
see something weird happen with `getNextAdjacentEdge`.
From all the smoke I believe this happens only when we are doing a *full
revolve*, *AND* we're executing other modules which are calling
`getNextAdjacentEdge`.
When the `revolve` is present, we can lose the race in *either*
`talk-button.kcl` OR `case.kcl`.
If I move back to single-threaded execution OR I add imports to sequence
things carefully, I can get the tests to pass. If the revolve is an
`extrude` or not a full revolve, it works fine.
My best guess is that it seems like the world got flipped upside down or
something, such that "next edge" has a different orentation for two
calls. My even further guess is that inside `revolve` we mutate
something connection-global such that it alters the intepretation of
calls made during the revolve implementation's "critical section".
2025-05-13 16:20:48 -04:00
|
|
|
342 <--x 216
|
2025-05-13 21:07:24 -07:00
|
|
|
216 --- 343
|
|
|
|
|
217 --- 291
|
Avoid using full revolve for now (#6912)
Avoid using revolve for now
When we moved to concurrent execution of KCL modules, we begun to see an
error we never fully understood, and because it was pretty hard to
trigger, we wound up never being able to fix it. Today we were able to
track it down to the `revolve` call here.
Specifically, the problem is triggered when we're doing a "Full Revolve"
(e.g., `angle = 359.999999` passes, but *not* `angle = 360` or the
default, as it is in `main`), and concurrently executing modules will
see something weird happen with `getNextAdjacentEdge`.
From all the smoke I believe this happens only when we are doing a *full
revolve*, *AND* we're executing other modules which are calling
`getNextAdjacentEdge`.
When the `revolve` is present, we can lose the race in *either*
`talk-button.kcl` OR `case.kcl`.
If I move back to single-threaded execution OR I add imports to sequence
things carefully, I can get the tests to pass. If the revolve is an
`extrude` or not a full revolve, it works fine.
My best guess is that it seems like the world got flipped upside down or
something, such that "next edge" has a different orentation for two
calls. My even further guess is that inside `revolve` we mutate
something connection-global such that it alters the intepretation of
calls made during the revolve implementation's "critical section".
2025-05-13 16:20:48 -04:00
|
|
|
343 <--x 217
|
2025-05-13 21:07:24 -07:00
|
|
|
217 --- 344
|
|
|
|
|
251 <--x 219
|
|
|
|
|
252 <--x 219
|
|
|
|
|
253 <--x 219
|
|
|
|
|
254 <--x 219
|
|
|
|
|
259 <--x 223
|
|
|
|
|
260 <--x 223
|
|
|
|
|
261 <--x 223
|
|
|
|
|
262 <--x 223
|
|
|
|
|
263 <--x 223
|
|
|
|
|
264 <--x 223
|
|
|
|
|
265 <--x 223
|
|
|
|
|
266 <--x 223
|
|
|
|
|
267 <--x 224
|
|
|
|
|
268 <--x 224
|
|
|
|
|
269 <--x 224
|
|
|
|
|
270 <--x 224
|
|
|
|
|
271 <--x 227
|
|
|
|
|
272 <--x 227
|
|
|
|
|
273 <--x 227
|
|
|
|
|
274 <--x 227
|
|
|
|
|
275 <--x 227
|
|
|
|
|
276 <--x 227
|
|
|
|
|
277 <--x 227
|
|
|
|
|
278 <--x 227
|
|
|
|
|
283 <--x 230
|
|
|
|
|
279 <--x 231
|
|
|
|
|
280 <--x 231
|
|
|
|
|
281 <--x 231
|
|
|
|
|
282 <--x 231
|
|
|
|
|
288 <--x 232
|
|
|
|
|
289 <--x 232
|
|
|
|
|
290 <--x 232
|
|
|
|
|
291 <--x 232
|
|
|
|
|
243 <--x 233
|
|
|
|
|
244 <--x 233
|
|
|
|
|
245 <--x 233
|
|
|
|
|
246 <--x 233
|
|
|
|
|
239 <--x 235
|
|
|
|
|
240 <--x 235
|
|
|
|
|
241 <--x 235
|
|
|
|
|
242 <--x 235
|
|
|
|
|
247 <--x 236
|
|
|
|
|
248 <--x 236
|
|
|
|
|
249 <--x 236
|
|
|
|
|
250 <--x 236
|
|
|
|
|
255 <--x 237
|
|
|
|
|
256 <--x 237
|
|
|
|
|
257 <--x 237
|
|
|
|
|
258 <--x 237
|
|
|
|
|
284 <--x 238
|
|
|
|
|
285 <--x 238
|
|
|
|
|
286 <--x 238
|
|
|
|
|
287 <--x 238
|
Do multiple chamfer/fillet in one API call (#6750)
KCL's `fillet` function takes an array of edges to fillet. Previously this would do `n` fillet API commands, one per edge. This PR combines them all into one call, which should improve performance. You can see the effect in the artifact_commands snapshots, e.g. `rust/kcl-lib/tests/kcl_samples/axial-fan/artifact_commands.snap`
Besides performance, this should fix a bug where some KCL fillets would fail, when they should have succeeded. Example from @max-mrgrsk:
```kcl
sketch001 = startSketchOn(XY)
|> startProfile(at = [-12, -6])
|> line(end = [0, 12], tag = $seg04)
|> line(end = [24, 0], tag = $seg03)
|> line(end = [0, -12], tag = $seg02)
|> line(endAbsolute = [profileStartX(%), profileStartY(%)], tag = $seg01)
|> close()
extrude001 = extrude(
sketch001,
length = 12,
tagEnd = $capEnd001,
tagStart = $capStart001,
)
|> fillet(
radius = 5,
tags = [
getCommonEdge(faces = [seg02, capEnd001]),
getCommonEdge(faces = [seg01, capEnd001]),
getCommonEdge(faces = [seg03, capEnd001]),
getCommonEdge(faces = [seg04, capEnd001])
],
)
```
This program fails on main, but succeeds on this branch.
2025-05-22 16:25:55 -05:00
|
|
|
283 <--x 350
|
|
|
|
|
299 <--x 349
|
|
|
|
|
300 <--x 357
|
|
|
|
|
301 <--x 356
|
2025-05-13 21:07:24 -07:00
|
|
|
308 <--x 348
|
|
|
|
|
309 <--x 345
|
|
|
|
|
310 <--x 346
|
|
|
|
|
311 <--x 347
|
Do multiple chamfer/fillet in one API call (#6750)
KCL's `fillet` function takes an array of edges to fillet. Previously this would do `n` fillet API commands, one per edge. This PR combines them all into one call, which should improve performance. You can see the effect in the artifact_commands snapshots, e.g. `rust/kcl-lib/tests/kcl_samples/axial-fan/artifact_commands.snap`
Besides performance, this should fix a bug where some KCL fillets would fail, when they should have succeeded. Example from @max-mrgrsk:
```kcl
sketch001 = startSketchOn(XY)
|> startProfile(at = [-12, -6])
|> line(end = [0, 12], tag = $seg04)
|> line(end = [24, 0], tag = $seg03)
|> line(end = [0, -12], tag = $seg02)
|> line(endAbsolute = [profileStartX(%), profileStartY(%)], tag = $seg01)
|> close()
extrude001 = extrude(
sketch001,
length = 12,
tagEnd = $capEnd001,
tagStart = $capStart001,
)
|> fillet(
radius = 5,
tags = [
getCommonEdge(faces = [seg02, capEnd001]),
getCommonEdge(faces = [seg01, capEnd001]),
getCommonEdge(faces = [seg03, capEnd001]),
getCommonEdge(faces = [seg04, capEnd001])
],
)
```
This program fails on main, but succeeds on this branch.
2025-05-22 16:25:55 -05:00
|
|
|
332 <--x 354
|
|
|
|
|
333 <--x 355
|
|
|
|
|
337 <--x 353
|
|
|
|
|
338 <--x 358
|
|
|
|
|
341 <--x 352
|
|
|
|
|
342 <--x 351
|
2025-03-06 18:01:24 -05:00
|
|
|
```
|