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-19 08:41:32 -05:00
|
|
|
19["Path<br>[983, 1100, 2]"]
|
|
|
|
|
42["Segment<br>[1106, 1164, 2]"]
|
|
|
|
|
43["Segment<br>[1170, 1287, 2]"]
|
|
|
|
|
44["Segment<br>[1293, 1351, 2]"]
|
|
|
|
|
45["Segment<br>[1357, 1477, 2]"]
|
|
|
|
|
46["Segment<br>[1483, 1544, 2]"]
|
|
|
|
|
47["Segment<br>[1550, 1671, 2]"]
|
|
|
|
|
48["Segment<br>[1677, 1737, 2]"]
|
|
|
|
|
49["Segment<br>[1743, 1750, 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-19 08:41:32 -05:00
|
|
|
20["Path<br>[1905, 1959, 2]"]
|
|
|
|
|
50["Segment<br>[1965, 2006, 2]"]
|
|
|
|
|
51["Segment<br>[2012, 2041, 2]"]
|
|
|
|
|
52["Segment<br>[2047, 2077, 2]"]
|
|
|
|
|
53["Segment<br>[2083, 2139, 2]"]
|
|
|
|
|
54["Segment<br>[2145, 2152, 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-19 08:41:32 -05:00
|
|
|
21["Path<br>[2295, 2332, 2]"]
|
|
|
|
|
55["Segment<br>[2338, 2369, 2]"]
|
|
|
|
|
56["Segment<br>[2375, 2408, 2]"]
|
|
|
|
|
57["Segment<br>[2414, 2446, 2]"]
|
|
|
|
|
58["Segment<br>[2452, 2459, 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]"]
|
2025-05-19 08:41:32 -05:00
|
|
|
153["Sweep Extrusion<br>[621, 648, 2]"]
|
|
|
|
|
154["Sweep Extrusion<br>[1764, 1807, 2]"]
|
|
|
|
|
155["Sweep Extrusion<br>[2166, 2209, 2]"]
|
|
|
|
|
156["Sweep Extrusion<br>[2461, 2494, 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
|
|
|
157["Sweep Extrusion<br>[3037, 3068, 3]"]
|
|
|
|
|
158["Sweep Loft<br>[994, 1037, 5]"]
|
|
|
|
|
159["Sweep Extrusion<br>[609, 661, 6]"]
|
2025-05-19 08:41:32 -05:00
|
|
|
160["Sweep Extrusion<br>[406, 434, 7]"]
|
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
|
|
|
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"]
|
2025-05-19 08:41:32 -05:00
|
|
|
345["EdgeCut Chamfer<br>[654, 885, 2]"]
|
|
|
|
|
346["EdgeCut Chamfer<br>[654, 885, 2]"]
|
|
|
|
|
347["EdgeCut Chamfer<br>[654, 885, 2]"]
|
|
|
|
|
348["EdgeCut Chamfer<br>[654, 885, 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
|
|
|
349["EdgeCut Fillet<br>[667, 873, 6]"]
|
|
|
|
|
350["EdgeCut Fillet<br>[667, 873, 6]"]
|
|
|
|
|
351["EdgeCut Fillet<br>[667, 873, 6]"]
|
|
|
|
|
352["EdgeCut Fillet<br>[667, 873, 6]"]
|
2025-05-19 08:41:32 -05:00
|
|
|
353["EdgeCut Fillet<br>[440, 509, 7]"]
|
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]"]
|
|
|
|
|
359["EdgeCut Chamfer<br>[707, 853, 8]"]
|
|
|
|
|
360["EdgeCut Chamfer<br>[707, 853, 8]"]
|
|
|
|
|
361["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
|
|
|
|
|
283 <--x 353
|
|
|
|
|
296 <--x 352
|
|
|
|
|
297 <--x 351
|
|
|
|
|
298 <--x 349
|
|
|
|
|
299 <--x 350
|
|
|
|
|
300 <--x 360
|
|
|
|
|
301 <--x 359
|
|
|
|
|
308 <--x 348
|
|
|
|
|
309 <--x 345
|
|
|
|
|
310 <--x 346
|
|
|
|
|
311 <--x 347
|
|
|
|
|
332 <--x 357
|
|
|
|
|
333 <--x 358
|
|
|
|
|
337 <--x 356
|
|
|
|
|
338 <--x 361
|
|
|
|
|
341 <--x 355
|
|
|
|
|
342 <--x 354
|
2025-03-06 18:01:24 -05:00
|
|
|
```
|