00:02:25
| <bterlson> | tschneidereit: no argument there |
00:03:07
| <bterlson> | except minor perf wins I imagine |
00:04:46
| <aklein> | This is one of the oldest V8 bugs: https://bugs.chromium.org/p/v8/issues/detail?id=90 |
02:34:45
| * bdnugger | quit (Quit: Connection closed for inactivity) |
02:41:18
| * gibson042 | joined |
02:45:09
| * AtumT_ | quit (Remote host closed the connection) |
02:59:19
| * jwalden | quit (Quit: ChatZilla 0.9.92-rdmsoft [XULRunner 35.0.1/20150122214805]) |
03:12:00
| * Draggor | quit (Read error: No route to host) |
03:20:27
| * floatleft | quit (Ping timeout: 240 seconds) |
03:21:58
| * not-an-aardvark | joined |
03:24:17
| * floatleft | joined |
03:27:59
| <Domenic> | I don't see any way to lock down sort completely without specifying exactly what comparison algorithm everyone must use |
03:28:05
| <Domenic> | Which seems probably bad? |
03:38:05
| * Draggor | joined |
04:01:10
| <ljharb> | that seems like exactly the struggle; everyone wants to maximally lock down `sort`, and everyone also doesn't want to mandate a sorting algorithm :-/ |
04:01:16
| <ljharb> | also some people want stable sorts |
04:01:32
| * gibson042 | quit (Ping timeout: 255 seconds) |
04:42:44
| * caridy | quit (Remote host closed the connection) |
05:18:23
| * gcommer | quit (Remote host closed the connection) |
05:25:13
| * jmdyck | quit (Remote host closed the connection) |
05:25:52
| * gcommer | joined |
05:33:39
| * MisterAJ | joined |
06:12:19
| * MisterAJ | quit (Quit: Page closed) |
07:22:01
| * floatleft | quit (Read error: Connection reset by peer) |
07:24:02
| * floatleft | joined |
10:55:05
| <annevk> | What is the problem with locking down the sorting algorithm? It's bound to be somewhat inflexible at this point anyway due to web compat |
10:57:31
| <annevk> | Although reading the backlog it seems Edge does fun stuff and maybe gets away with it... |
11:25:10
| * mylesborins | quit (Quit: farewell for now) |
11:25:41
| * mylesborins | joined |
11:41:59
| * AtumT | joined |
12:41:38
| * not-an-aardvark | quit (Quit: Connection closed for inactivity) |
13:04:22
| * jmdyck | joined |
13:13:37
| * Wizek | joined |
13:31:26
| * bradleymeck | joined |
13:40:15
| * bradleymeck | quit (Quit: bradleymeck) |
14:11:55
| * gibson042 | joined |
14:39:23
| * AtumT_ | joined |
14:42:33
| * AtumT | quit (Ping timeout: 265 seconds) |
15:06:29
| * caridy | joined |
15:18:10
| * bradleymeck | joined |
15:23:14
| * Fishrock123 | joined |
16:00:08
| * floatleft | quit (Ping timeout: 240 seconds) |
17:07:03
| * caridy | quit (Remote host closed the connection) |
17:07:38
| * caridy | joined |
17:42:23
| * basicdays | quit (Ping timeout: 250 seconds) |
17:50:28
| <caitp> | v8 isn't "unstable", it's "unstable if there are > some number (25?) elements" |
17:50:53
| <caitp> | which I think is also done in other engines |
17:51:04
| <caitp> | probably with different stable/unstable thresholds |
18:25:56
| * AtumT | joined |
18:28:34
| * AtumT_ | quit (Ping timeout: 255 seconds) |
18:33:34
| * jwalden | joined |
18:44:52
| * caridy | quit (Read error: Connection reset by peer) |
18:45:52
| * jwalden | quit (Quit: back shortlyish) |
18:46:44
| * caridy | joined |
19:17:07
| * not-an-aardvark | joined |
19:17:13
| * basicdays | joined |
19:34:30
| * jwalden | joined |
19:34:32
| * jwalden | quit (Client Quit) |
19:34:50
| * jwalden | joined |
19:42:37
| * jwalden | quit (Remote host closed the connection) |
19:45:04
| * jwalden | joined |
20:19:40
| * jwalden | quit (Quit: back later sometime, or tomorrow at worst) |
22:15:07
| * Fishrock123 | quit (Remote host closed the connection) |
22:45:35
| * caridy | quit (Read error: Connection reset by peer) |
22:46:07
| * caridy | joined |
22:57:59
| * Fishrock123 | joined |
23:46:31
| * AtumT | quit (Remote host closed the connection) |
23:48:40
| * bradleymeck | quit (Quit: bradleymeck) |
23:57:37
| * bradleymeck | joined |
23:58:18
| * bradleymeck | quit (Client Quit) |