| 00:00 | <zewt> | for the window.onerror example, are we talking about parsing an error log later on, or programmatically doing something with the magic string? |
| 00:01 | <Hixie> | TabAtkins: why 60 million, btw? |
| 00:01 | <Hixie> | TabAtkins: what's your definition of "expect"? |
| 00:02 | <TabAtkins> | 36^5, the sqrt of 36^10. |
| 00:02 | <TabAtkins> | 50% expectation |
| 00:02 | <Hixie> | oh, i see |
| 00:02 | <Hixie> | the alphabet only actually has 16 characters |
| 00:02 | <Hixie> | so 16^5 |
| 00:02 | <TabAtkins> | Oh, you're only genning hex? |
| 00:02 | <TabAtkins> | I didnt' notice that |
| 00:03 | <TabAtkins> | That's only about 1M then. |
| 00:03 | <Hixie> | er wait |
| 00:03 | <Hixie> | not 16... |
| 00:04 | <Hixie> | oops |
| 00:04 | <Hixie> | it is 16 |
| 00:04 | <Hixie> | but it's supposed to be more |
| 00:04 | <Hixie> | 26 or so |
| 00:04 | <Hixie> | 2346789abcdefghjkmnpqrtwxy |
| 00:04 | <TabAtkins> | Ah, the easy-to-distinguish alphanums. |
| 00:05 | <Hixie> | yeah, that's the idea |
| 00:05 | <Hixie> | hm |
| 00:05 | <Hixie> | i need this to be a power of 2 for the logic to work better |
| 00:05 | Hixie | wonders whether to add or remove |
| 00:06 | <TabAtkins> | What's your logic? |
| 00:07 | <Hixie> | geenerate hmax sha 512 of increasing number, use the first n bits to generate a 10 character string |
| 00:07 | <TabAtkins> | Interesting. |
| 00:08 | <Hixie> | i can add z5suv back in but i'm still short a character... |
| 00:08 | <zewt> | just reading /dev/urandom will probably give you equally non-repeating results, without depending on a last-used-number state |
| 00:08 | <TabAtkins> | Why not just generate a num between 0 and 26^10, then encode it in base 26? |
| 00:08 | <Hixie> | really don't want to add il1o0 |
| 00:08 | <TabAtkins> | And yes, the lowercase z/s aren't really confusable for 2/5. |
| 00:09 | <zewt> | (since /dev/urandom these days is basically just a crypto hash on top of entropy) |
| 00:09 | <Hixie> | i like to avoid actual randomness in my code |
| 00:09 | <TabAtkins> | You're effectively grabbing randomness by taking an arbitrary chunk of a hash. |
| 00:10 | <Hixie> | right |
| 00:10 | <Hixie> | reproducible "randomness" |
| 00:10 | <zewt> | i prefer to avoid state that has to be persisted, myself |
| 00:12 | <zewt> | also a bunch of new complexity if two clients might race and generate from the same index |
| 00:13 | <TabAtkins> | Yup. |
| 00:14 | <zewt> | (which itself can be really hard to write tests for; i hate writing tests for things like locking and atomicity) |
| 00:14 | <Hixie> | locking files is a solved problem :-) |
| 00:15 | <zewt> | with a solution that's much more complex than open('/dev/urandom').read(16) :----------) |
| 00:15 | <zewt> | i guess it comes down to what your environment provides, and how much you trust it |
| 00:16 | <zewt> | (i don't include "make sure /dev/urandom is really random" in my tests, after all) |
| 00:17 | <zewt> | ("really random" as in "not /dev/zero") |
| 00:17 | <zewt> | (in case someone was going to nit about PRNGs) |
| 00:17 | <TabAtkins> | Any system that doesn't implement a decent /dev/urandom would be *super* insecure anyway. |
| 00:18 | <zewt> | i tend to suspect security inexperience in people who still use /dev/random because it's "more secure", heh |
| 00:18 | <Hixie> | locking files is like lines of code including importing the relevant constants and unlocking... |
| 00:19 | <Hixie> | like three lines, even |
| 00:19 | <Hixie> | ok, now using a 32 character alphabet. |
| 00:20 | <Hixie> | using the first 5 bits of each of the first ten bytes of the hmac sha 512 of numbers in sequential order. |
| 00:20 | <Hixie> | bbiab |
| 00:21 | <zewt> | maybe your environment has additional helpers for the busywork (blocking if the lockfile already exists, cleaning up if the pid contained in the lockfile doesn't exist, etc) |
| 00:22 | <TabAtkins> | It's perl, so that's plausible. |
| 00:22 | <zewt> | also the need to atomically write the state file containing the last-used index (write new file, sync, rename), which is something all languages really should provide, but few do |
| 00:24 | <TabAtkins> | While you're locked, that works anyway, right? |
| 00:27 | <zewt> | if the machine crashes, you don't want to reboot and come back up with a zero-byte file |
| 00:27 | <TabAtkins> | Ah, right. |
| 00:27 | <zewt> | (restore from backup and you lose that day's index delta) |
| 00:28 | <zewt> | ''.join('23456789abcdefghijkmnpqrstuvwxyz'[ord(x) >> 3] for x in hashlib.sha512(open('/dev/urandom').read(32)).digest()[0:10]) # one-liners are evil, even in python |
| 03:59 | <Hixie> | i ended up testing 30,058,310 codes with the new algorithm, no dupes. |
| 04:00 | <Hixie> | (by tab's maths, there would be a 50% chance of a dupe at about 33 million, if i understand it right) |
| 05:25 | <Hixie> | man, the tokeniser sure does have a lot of states |
| 06:53 | <sangwhan> | TabAtkins: is unprefixing transitions *and* transforms both covered under the umbrella of this bug? https://code.google.com/p/chromium/issues/detail?id=154772 |
| 07:12 | <Domenic_> | Hixie: sounds like a plan, will devote some time to it eventually. I need to do a write up with use cases, possibilities (e.g. generated vs. human readable), impact on existing/future specs, etc. |
| 10:00 | <a-ja> | TabAtkins: ping |
| 10:07 | <a-ja> | TabAtkins: unping....will catch you later |
| 10:07 | <Ms2ger> | The new css spec style sheet is so funny... |
| 10:22 | <hsivonen> | looks like the support status markers on CSS specs haven't been updated to reflect the demise of Presto and Blink forking off of WebKit |
| 10:41 | <hsivonen> | MikeSmith: I don't know what to do about bugzilla.validator.nu cookies. The urlbase and cookiepath settings look right to me. |
| 10:52 | <smaug____> | oh, hsivonen is alive |
| 10:53 | <hsivonen> | is this where I'm supposed to say that rumors of my demise have been exaggerated? |
| 10:58 | <Ms2ger> | There were rumours? |
| 11:32 | <Ms2ger> | hsivonen, oh, better news than your death, congratulations :) |
| 11:32 | <hsivonen> | Ms2ger: thanks |
| 11:34 | <zcorpan> | what's the news? |
| 11:35 | <hsivonen> | zcorpan: a baby (that is, I'm now back from paternity leave) |
| 11:35 | <zcorpan> | hsivonen: ok, congrats! |
| 11:35 | <hsivonen> | zcorpan: thanks |
| 11:37 | <smaug____> | congratulations |
| 11:38 | <hsivonen> | smaug____: thanks |
| 13:57 | <hsivonen> | wow. there's now a community group for MPEG-2 in-band captioning in <video> |
| 13:59 | <darobin> | there's a community group for everything |
| 14:00 | <Ms2ger> | Sounds more like a business group |
| 14:16 | <zcorpan> | heycam|away: maybe we should drop support for webidl in blink |
| 16:15 | <yoav> | SimonSapin: Around? |
| 16:15 | <SimonSapin> | yes |
| 16:16 | <yoav> | Got a Q regarding http://dev.w3.org/csswg/css-syntax/#consume-an-escaped-code-point |
| 16:16 | <yoav> | Also: OMG WUT IS THIS BG |
| 16:16 | <SimonSapin> | It’s the new spec design :) |
| 16:17 | TabAtkins | is also here. TabAtkins is so alone... |
| 16:17 | <yoav> | TabAtkins: Hey |
| 16:17 | <yoav> | I'm assuming the design is your fault |
| 16:17 | <yoav> | Is '\r' an escaped code point? |
| 16:18 | <TabAtkins> | \r is a carriage return? |
| 16:18 | <SimonSapin> | yoav: yes, it represents 'r' |
| 16:18 | <SimonSapin> | in CSS |
| 16:18 | <Ms2ger> | Wat |
| 16:18 | <SimonSapin> | "anything else : Return the current input code point. " |
| 16:19 | <TabAtkins> | Oh, yeah, if you literally type \r in a CSS document, it's the same as just typing r. |
| 16:20 | <yoav> | So why is "(max-width: \r6000px)" is parsed OK in anything that's not my MQ parser? |
| 16:20 | <yoav> | Is the \r getting pre processed? |
| 16:20 | <TabAtkins> | Because browsers' existing MQ parsers are usually crazy-stupid. |
| 16:20 | <TabAtkins> | And/or yeah, they're stupidly interpreting \r as a CR, which is just whitespace. |
| 16:20 | <SimonSapin> | yoav: do you have a test case? |
| 16:21 | <SimonSapin> | if a JS literal string is involved, it does its own backslash-unescaping first |
| 16:21 | <yoav> | SimonSapin: Ahh |
| 16:22 | <yoav> | That explains it |
| 16:22 | <TabAtkins> | Layers upon layers of escapes. |
| 16:22 | <TabAtkins> | I like that HTML has a completely different escape syntax. It avoids the stacked-escapes problem. |
| 16:22 | <yoav> | "The escaped onion" would make a good children's book title |
| 16:24 | <yoav> | SimonSapin: OK, cool. That's what was messing me up |
| 16:25 | <yoav> | So, '\r' is 'r' and everything works fine |
| 16:25 | <SimonSapin> | try "\\r" in a JS string |
| 16:27 | <yoav> | Any cool examples for escaped MQs I can use for testing? |
| 16:30 | <SimonSapin> | hum, replace an character on an identifier with '\' + hex value of the code point + ' ' |
| 16:30 | <SimonSapin> | add leading zeros to go up to 6 hex digits |
| 16:30 | <SimonSapin> | add leading zeros to go up to 6 hex digits and omit the space |
| 16:30 | <yoav> | SimonSapin: Trying "(max-width:6000px \u0020 )" and getting nothing |
| 16:31 | <SimonSapin> | omit the space if the next char is not an hex digit |
| 16:31 | <SimonSapin> | there is no u |
| 16:31 | <SimonSapin> | and escapes (unless in a quoted string) give you identifiers |
| 16:32 | <SimonSapin> | also: replace any non-hex-digit character in an identifier by '\' followed by itself |
| 16:32 | <SimonSapin> | and see https://github.com/SimonSapin/css-parsing-tests |
| 16:33 | <SimonSapin> | eg. https://github.com/SimonSapin/css-parsing-tests/blob/101c330cb06b3e6de7f30509b4237421b94e3f28/component_value_list.json#L25-L38 |
| 16:33 | <SimonSapin> | https://github.com/SimonSapin/css-parsing-tests/blob/101c330cb06b3e6de7f30509b4237421b94e3f28/component_value_list.json#L25-L52, actually |
| 16:35 | <yoav> | SimonSapin & TabAtkins: Is it normal that neither Firefox nor Chrome actually match MQs with that? Or am I doing it wrong? |
| 16:36 | <SimonSapin> | yoav: with what? (Test case please) |
| 16:37 | <TabAtkins> | "(max-width:6000px \0020)" *should* match nothing, because you've got an ident hanging out there. |
| 16:37 | <yoav> | http://jsbin.com/texaqabu/3/edit |
| 16:37 | <TabAtkins> | An ident whose value is a single U+0020 character. |
| 16:37 | <TabAtkins> | yoav: What characters are those?\ |
| 16:38 | <SimonSapin> | yoav: CSS numeric escapes are always hex |
| 16:38 | <SimonSapin> | a 0 prefix does not make it octal |
| 16:38 | <yoav> | I was going with "px" |
| 16:39 | <SimonSapin> | that’d be \70\78 in hex |
| 16:39 | <yoav> | That's dumb of me |
| 16:39 | <TabAtkins> | ^_^ |
| 16:40 | <yoav> | OK! |
| 16:40 | <yoav> | Breakthrough |
| 16:40 | <yoav> | Working in Firefox |
| 16:40 | <yoav> | No dice in Chrome tho, but that gives me something to fix! |
| 16:41 | <TabAtkins> | Yeah, as mentioned previously, our MQ parser is mega-broken. |
| 18:14 | <SamB> | hmm, should I alias mediawiki's UTF-8 tracking bug as "UTF-8", "utf-8", or "utf8" ... practically all existing aliases are lowercase ... |
| 18:18 | <SamB> | oh, wait, it's also about Unicode so I'll just alias it as "unicode" ... |
| 18:31 | <Hixie> | annevk: yt? |
| 18:31 | <annevk> | Hixie: yes |
| 18:31 | <Hixie> | annevk: how do you feel about putting document.title in DOM |
| 18:31 | <annevk> | Hixie: your timezone for the next seven days |
| 18:31 | <Hixie> | annevk: it needs to interact with SVG and HTML <title> |
| 18:31 | <annevk> | Hixie: can't HTML just do that? |
| 18:32 | <annevk> | Hixie: or does the SVG WG still pretend it can have SVG without HTML? (because they cannot, they don't have an event loop and things) |
| 18:32 | <Hixie> | annevk: i could, but it seems weird for HTML to be defining some SVG-specific stuff, so i was thinking HTML and SVG would hook into something DOM specifies |
| 18:32 | <Hixie> | maybe i should just do it and not worry about it though |
| 18:32 | <annevk> | Hixie: I'm happy to blur the lines further, either way |
| 18:33 | SamB | has always found html <title> rather magical |
| 18:34 | <SamB> | (Well, ever since I discovered that you can't get the same results with custom XML and CSS) |
| 18:37 | <Hixie> | well all the useful elements in HTML are "magical" by that definition |
| 18:39 | <SamB> | in the sense that they have semantics as well as presentation, sure |
| 18:40 | <Hixie> | in the sense that the user agent is required to do stuff with them more than you can do with custom XML and CSS |
| 18:40 | <Hixie> | e.g. <form>, <a>, <input>, <video>, ... |
| 18:41 | <SamB> | you are clearly using a different sense of the term "useful" than I am |
| 18:41 | <Hixie> | why? |
| 18:42 | <SamB> | well, mine includes stuff like <h2> |
| 18:43 | <Hixie> | s/useful/interesting/? |
| 18:48 | <SamB> | anyway, it might have been 15 years ago that I got the idea "<title> is magical" into my head ... |
| 18:49 | <Hixie> | well, i'm not a fan of the word "magical", but <title> has non-mundane behaviour, certainly |
| 18:49 | <Hixie> | like <details>, <output>, <progres>, <canvas>, etc |
| 19:05 | <manu-> | TabAtkins: I totally love what you've done w/ the non-element selectors spec: http://dev.w3.org/csswg/selectors-nonelement/ |
| 19:06 | <manu-> | (W3C Stylesheets hacked) https://twitter.com/jirkakosek/status/451067752703197184/photo/1 |
| 19:06 | <Ms2ger> | manu-, *all dev.w3.org/csswg/ specs |
| 19:07 | <manu-> | It really is a step in the right direction... the dot-com bubble just messed everything up, glad to see a move back to fundamentals. |
| 19:08 | <Ms2ger> | It's kinda unimaginative... Same thing from last year |
| 19:08 | <manu-> | oooh, right... April fools - forgot about that... had turned off all of my news feeds waiting for it to blow over. |
| 19:23 | <TabAtkins> | Ms2ger: Yeah, I'd forgotten to prepare anything new. I'll actually do a new joke next year, I promise. ^_^ |
| 19:51 | <annevk> | TabAtkins: but will it resolve? |
| 19:58 | <TabAtkins> | annevk: It'll take a year, but yeah. |
| 19:58 | <dglazkov> | Hixie: with MessagePort, how does one side realize that the other side is no longer listening (due to untimely demise, for instance) |
| 19:58 | <dglazkov> | ? |
| 19:58 | <annevk> | dglazkov: you don't, you need to implement ping |
| 19:59 | <annevk> | dglazkov: reason is GC |
| 19:59 | <dglazkov> | okay |
| 19:59 | <annevk> | Which reminds me, at some point we need to figure out the SW story around garbage collection |
| 20:00 | <SamB> | SW? |
| 20:00 | <dglazkov> | why is GC being detectable a problem? |
| 20:00 | <annevk> | dglazkov: there have been some proposals on the position to not expose GC / make memory leaks likelier |
| 20:00 | SamB | does not like memory leaks |
| 20:00 | <annevk> | dglazkov: exposing the details of GC is bad as it might lead to having to define GC |
| 20:01 | <annevk> | dglazkov: ask TC39 |
| 20:01 | <dglazkov> | annevk: that doesn't seem bad, just hard |
| 20:01 | <annevk> | dglazkov: why not, we have changed GC strategies many many times over the years due to it not being exposed |
| 20:01 | <annevk> | dglazkov: if it's exposed we cannot change strategies |
| 20:01 | <dglazkov> | that's not necessarily true, right? |
| 20:02 | <annevk> | I'm not sure I can speak much to all of the constraints here. I do know it's been one of the things we have tried very hard to avoid ever doing. |
| 20:02 | <SamB> | hmm, that sounds kind of like a silly reason to have no way to detect a broken socket |
| 20:03 | <SamB> | just make sure the GC is already sufficiently hard to predict |
| 20:03 | <annevk> | "just" |
| 20:04 | <SamB> | what, you mean it isn't? |
| 20:04 | <SamB> | it's not like there's refcounting involved like in CPython ... |
| 20:04 | <dglazkov> | annevk: totally understand. It seems though the times are changing. With where asm.js is going, exposing GC in one way or another looks inevitable. |
| 20:06 | <annevk> | dglazkov: I don't know, would have to ask dherman, but exposing to asm.js does not necessarily mean we want to expose it higher-level too |
| 20:06 | <dglazkov> | yup |
| 20:10 | <SamB> | annevk: I guess you must be worried about exposing what happens when a whole compartment goes away? |
| 20:11 | <annevk> | SamB: exposing GC in general |
| 20:12 | <SamB> | what else is there that's presently deterministic enough that stuff might grow to depend on it? |
| 20:13 | <annevk> | Anything? Content has a tendency to rely on anything we expose, whether intentional or not |
| 20:16 | <SamB> | I mean, what other situations can cause objects to be collected more-or-less immediately, rather than whenever the GC finally kicks in? |
| 20:18 | <annevk> | Depends on your GC |
| 20:24 | <smaug____> | dglazkov: what has asm.js to do with gc? |
| 20:25 | <smaug____> | asm.js makes such js that gc doesn't have to run at all |
| 20:28 | <smaug____> | SamB: you might implement the whole system using a cycle collector and traditional refcounting |
| 20:28 | <smaug____> | SamB: then objects would usually die when the last ref goes away |
| 20:29 | <smaug____> | and in case of cycles, when the collector runs |
| 20:29 | <SamB> | smaug____: who would be stupid enough to actually do it that way |
| 20:29 | <smaug____> | what is wrong with that? |
| 20:30 | <SamB> | refcounting is actually pretty slow |
| 20:30 | <smaug____> | there are algorithms to optimize out most of it |
| 20:30 | <smaug____> | and GC is hard if you have lots of objects |
| 20:30 | <smaug____> | since GC deals with live objects and CC only possible garbage objects |
| 20:31 | <SamB> | hmm |
| 20:32 | <jsbell> | annevk FWIW: dbh = indexedDB.open('db', 1); indexedDB.open('db', 2).onsuccess = function(){alert('GC-or-equivalent must have happened');}; dbh = null; |
| 20:32 | <smaug____> | best performing systems are, at least per certain literature and research, combination of gc and cc |
| 20:32 | <SamB> | I guess refcounting *does* at least only do the extra work on objects that are probably of interest |
| 20:32 | <annevk> | jsbell: you don't define that in terms of event loops and lifetimes? |
| 20:34 | <jsbell> | annevk: The spec says "If the connection is GCed .... the connection is closed", which unblocks the second connection. |
| 20:35 | <annevk> | Oh my |
| 20:35 | <smaug____> | whaaat? |
| 20:35 | smaug____ | files a spec bug |
| 20:36 | <jsbell> | Yeah. I was poking around for precedent for "what if a transaction could waitUntil() a Promise, but the Promise was never resolved" |
| 21:01 | <annevk> | https://www.youtube.com/watch?v=_eT7sl7bR1A oh man |
| 21:01 | <annevk> | I wonder if there's a 2048 homescreen |
| 21:08 | <jgraham> | annevk: Higher score == better apps you can launch? |
| 21:08 | <jgraham> | And 2048 gives you the browser |
| 21:08 | <annevk> | jgraham: yeah, maybe one screen has the game, and another has the apps available thus far |
| 21:09 | <jgraham> | No, the game tiles are the launchers |
| 21:11 | <annevk> | oh man |
| 21:11 | <annevk> | so at some point you can no longer access 1024 until you hit it again? |
| 21:12 | <Ms2ger> | Hmm? |
| 21:13 | <annevk> | the app corresponding to 1024 if that was unclear |
| 21:13 | <annevk> | I still haven't hit 8192 btw |
| 21:13 | <annevk> | got 4096 several times |
| 21:13 | <annevk> | I get sloppy after a while :/ |
| 21:23 | <hober> | threes ftw :) |
| 21:27 | <zewt> | refcounting is comparatively slow, but in most layers it doesn't matter today |
| 21:28 | <zewt> | in systems where you can get away with not breaking cycles (eg. not the web), it also has the huge advantage of being deterministic |
| 21:28 | <Hixie> | slow relative to what? managed memory and walking the entire heap every few seconds? |
| 21:29 | <Hixie> | or slow relative to a defined ownership model? |
| 21:29 | <zewt> | relative to mark and sweep, since you don't have to adjust refcounts all the time (though I guess that also depends on how smart you can be about optimizing those out) |
| 21:29 | <Hixie> | really? do you have data on that? |
| 21:29 | <zewt> | no, just my recollection |
| 21:30 | <Hixie> | refcounting is like 2 extra instructions per assignment |
| 21:30 | <zewt> | but if true, I still think it's irrelevant today, except maybe for really performance-sensitive stuff |
| 21:30 | <Hixie> | compared to walking the entire heap, that seems cheap. |
| 21:30 | <jgraham> | hober: There you are again promoting iOS rather than the open web ;) |
| 21:30 | <SamB> | Hixie: that doesn't happen every assignment though ... |
| 21:30 | <Hixie> | true, but still |
| 21:31 | <zewt> | it's an extra two writes, and in some (also non-web) cases an atomic write (don't know how expensive those are today) |
| 21:31 | <Hixie> | i have no data one way or the other, i just find it surprising |
| 21:31 | <Hixie> | i would have thought refcounting would win hands down in terms of raw cpu cycles spent on memory management over the lifetime of a task |
| 21:31 | <zewt> | i'm sure it depends massively on the access patterns and language, so I'm overgeneralizing for sure |
| 21:32 | <Hixie> | i mean, wouldn't a GC model require at least as many instructions per assignment as well? |
| 21:32 | <zewt> | not following |
| 21:32 | <Hixie> | i guess you could just know where the pointers are |
| 21:33 | <Hixie> | if it's a strongly typed system |
| 21:33 | <Hixie> | and walk it that way |
| 21:33 | <zewt> | if you have a memory model where you can walk around and look at pointers (like you need for that), "x = y" is simply what it says, set the storage for x to a pointer to y |
| 21:34 | Hixie | usually just uses a defined ownership model, which seems faster than either :-) |
| 21:34 | <zewt> | for refcounting, you have to say "if x was set to something, decrease its refcount" and then "increase y's refcount" after the assignment |
| 21:34 | <zewt> | which might also mean a branch |
| 21:34 | <zewt> | definitely faster, it just tends to lose on other fronts :P |
| 21:35 | <Hixie> | yeah, it's definitely not a perfect solution :-) |
| 21:35 | <Hixie> | i find it makes me think more about the design though |
| 21:35 | <Hixie> | which is a win |
| 21:36 | <zewt> | i grew up on C++, i guess I should be a little sad that I almost never use it these days |
| 21:39 | <Hixie> | i spent a decade or more writing lots of perl |
| 21:40 | <zewt> | i avoided that trap |
| 21:40 | <Hixie> | but recently i've come to realise that for anything serious, I really prefer a strongly typed non-GCed true OO natively compiled modern language |
| 21:40 | <zewt> | is there such a thing? |
| 21:40 | <Hixie> | http://ian.hixie.ch/programming/ |
| 21:40 | <jgraham> | (I think this is where someone says that there is no strongly typed OO language) |
| 21:40 | <jgraham> | (which indeed zewt did) |
| 21:40 | <zewt> | i've spent enough time at a high level to find things like closures hard to live without, and closures essentially require GC |
| 21:41 | <zewt> | jgraham: what I meant is "modern" |
| 21:41 | <jgraham> | Rust has closures |
| 21:41 | <Hixie> | C++ does closures without GC |
| 21:41 | <Hixie> | as do some variants of ObjectPascal (sadly not the variant i'm using, yet.) |
| 21:41 | <zewt> | i haven't touched any of the "C++digitdigit" things (since I don't think they'll go anywhere, not to the level of availability of real C++) |
| 21:41 | <jgraham> | (it doesn't do OO but unless you are implementing the DOM it doesn't seem to matter. And for implementing the DOM we will probably get single inheritance) |
| 21:41 | <Ms2ger> | Hixie, Rust might be interesting to you |
| 21:42 | <gsnedders> | Rust is an odd type of OO, though |
| 21:42 | <Hixie> | Ms2ger: i find the rust language to be a bit weird to read. |
| 21:42 | <jgraham> | Rust currently has typeclasses rather than inheritance |
| 21:43 | <Hixie> | Ms2ger: (too much like perl in its liberal use of unusual punctuation) |
| 21:43 | <zewt> | i have trouble visualizing closures without GC to handle the locals attached to the closure |
| 21:43 | <gsnedders> | zewt: I dunno, I thought this a few years ago, yet now almost all embedded platforms with a C++ compiler support C++11. |
| 21:43 | <jgraham> | Most of the punctuation is gone |
| 21:43 | <Ms2ger> | Hixie, that's been improved a little... @ is gone, at least |
| 21:43 | <gsnedders> | zewt: When a decade ago many didn't support stuff as basic as namespaces. |
| 21:43 | <zewt> | gsnedders: msvc? |
| 21:43 | <jgraham> | Well @ at least |
| 21:43 | <gsnedders> | jgraham: Is it really typecalsses? They didn't seem to quite be typeclasses last time I looked. |
| 21:44 | <Hixie> | Ms2ger: still has a long way to go. consider that my favourite language has so little punctuation it doesn't even use { } for blocks :-P |
| 21:44 | <zewt> | pascal? :P |
| 21:44 | <zewt> | (don't say yes) |
| 21:44 | <gsnedders> | zewt: They support most of it now |
| 21:44 | <Ms2ger> | Yes |
| 21:44 | <Hixie> | (old python was pretty good in this regard, though modern python has taken a bit of a turn for the punctuationy) |
| 21:44 | <Hixie> | zewt: modern variants thereof, but yeah |
| 21:44 | <zewt> | my only major, fundamental issue with python is the indentation block gimmick |
| 21:45 | <jgraham> | I have used perl (and lived to tell the tale) and Rust, and Rust doesn't use punctuation like Perl |
| 21:45 | <Hixie> | zewt: that and it's just not a fast language |
| 21:45 | <Hixie> | jgraham: yeah, it's not at the level of perl. |
| 21:45 | <zewt> | which means it structurally has no way to do inline functions, and it can't do the inverted-template thing of php and ruby |
| 21:45 | <Ms2ger> | Hixie, it does tend to follow C conventions for that, to avoid scaring the C programmers too much :) |
| 21:45 | <gsnedders> | jgraham: At least most things claim traits aren't quite type classes. |
| 21:45 | <jgraham> | Like the usage in Rust generally follows straightforward patterns |
| 21:45 | <zewt> | Hixie: it's extremely fast to develop in; fast to execute I don't know (except that it's never been a problem for me) |
| 21:46 | <jgraham> | gsnedders: Well I don't exactly know |
| 21:46 | <Hixie> | the problem with rust is that i look at some random rust and i can't tell what it's doing off the top of my head |
| 21:46 | <Hixie> | in that respect it's like perl |
| 21:46 | <Hixie> | e.g. code like: fn ascending<M: MutableMap<uint, uint>>(map: &mut M, n_keys: uint) { ... } |
| 21:47 | <zewt> | :| |
| 21:47 | <Ms2ger> | That's not the most readable of rust :) |
| 21:47 | gsnedders | finds that perfectly readable… |
| 21:47 | <Hixie> | the "map: &mut M" part in particular |
| 21:47 | <Ms2ger> | Argument map of type &mut M |
| 21:47 | <gsnedders> | (And I've not touched that much Rust) |
| 21:47 | <Ms2ger> | For M a type parameter that fulfills MutableMap<uint, uint> |
| 21:47 | <Hixie> | what is "&mut M" ? |
| 21:47 | <Ms2ger> | Mutable pointer to M |
| 21:48 | <Ms2ger> | (non-owning) |
| 21:48 | <jgraham> | A mutable borrowed pointer to M |
| 21:48 | <Hixie> | mutable pointer? |
| 21:48 | <Hixie> | as opposed to? |
| 21:48 | <Ms2ger> | Immutable |
| 21:48 | <jgraham> | An immutable pointer |
| 21:48 | <gsnedders> | Ms2ger: Oh, then I misunderstood what it meant, so maybe not so readable :) |
| 21:48 | <Hixie> | is an immutable pointer just a constant reference? |
| 21:48 | <Ms2ger> | Stronger |
| 21:48 | <zewt> | "immutable pointer" sounds like "reference" (c++) |
| 21:48 | <jgraham> | You can only have one mutable pointer to an object in scope at a time so that the compiler can reason about lifetimes |
| 21:48 | <Ms2ger> | It also guarantees that there are no mutable pointers to that value |
| 21:49 | <jgraham> | (that might be wrong) |
| 21:49 | <Ms2ger> | You can only have one mutable pointer to an object in scope at a time so that you don't have data races |
| 21:49 | <jgraham> | Yeah, that makes more sense |
| 21:49 | <SimonSapin> | Hixie: yes. Rust makes stuff constant by default, you need the 'mut' keyword to change that. (Opposite of C/C++ and the 'const' keyword.) |
| 21:49 | <zewt> | mutable pointer as in const foo *x or mutable pointer as in foo *const x? |
| 21:50 | <Ms2ger> | You can mutate what's behind it |
| 21:50 | <jgraham> | zewt: As in the thing it points to is mutable using that reference |
| 21:50 | <Hixie> | so "mut" is more like the opposite of C++ const than it is like pascal argument "var" or the opposite of pascal argument "const"? |
| 21:50 | <jgraham> | Rust doesn't have pointer arithmetic |
| 21:50 | Hixie | always thought the C++ "const" thing was a bit weird |
| 21:50 | <Ms2ger> | I haven't done pascal in 6 years or so, no idea :) |
| 21:50 | <gsnedders> | zewt: foo *const x if I remember which way around they are. :P |
| 21:51 | <zewt> | yeah I have to think about it too heh |
| 21:51 | <gsnedders> | zewt: i.e., &x is constant |
| 21:51 | <Hixie> | another line of random rust, no idea what this does at all: vec!(~"", ~"20") |
| 21:51 | <zewt> | looks like a smiley |
| 21:51 | <jgraham> | The ! means that vec is a macro |
| 21:51 | <zewt> | if a peculiar one |
| 21:51 | <jgraham> | ~"" is an owned pointer to the empty string |
| 21:52 | <jgraham> | No idea what the vec macro does |
| 21:52 | <gsnedders> | zewt: essentially all you have is foo * const and const foo * const in Rust |
| 21:53 | <Ms2ger> | vec!() is like [] |
| 21:53 | <Hixie> | anyway. i haven't studied rust much yet. i will eventually. i expect it'll be similar to Go, though, which is to say, a lot of interesting ideas, some really bad decisions, and odd syntax, the total of which isn't really interesting enough to me :-) |
| 21:53 | <Ms2ger> | It constructs a new Vec, which is a growable vector |
| 21:54 | <Ms2ger> | I hope we're getting better syntax for that at some point |
| 21:54 | <zewt> | how about [] |
| 21:54 | <zewt> | just saying :P |
| 21:55 | <zewt> | i'm skeptical of any language I can't read intuitively, without having to study first |
| 21:55 | <Ms2ger> | Yeah, that's used for a type that's currently being transitioned to being a non-growable vector |
| 21:55 | <Ms2ger> | It's confusing right now :) |
| 21:56 | <zewt> | (not to say read every nuance of, but to a reasonable level) |
| 21:56 | <zewt> | afk |
| 22:22 | <SimonSapin> | Hixie: we’d be interested in knowing what you consider bad decisions, with 1.0 coming soon |
| 22:23 | SamB | wonders: 1.0 of what? |
| 22:24 | <SimonSapin> | Rust |
| 22:24 | <SimonSapin> | http://www.rust-lang.org/ |
| 22:24 | SamB | does know roughly what rust is, even if he can't remember who is working on it |
| 22:24 | <SamB> | it's a better name than, uh, Go |
| 22:25 | <SimonSapin> | we try not to brand it as such, but it’s lead mostly by Mozilla Research |
| 22:25 | <SamB> | though admittedly still seems awfully common of a word to use for a software product's name |
| 22:25 | <SimonSapin> | worse than Perl, Java, Ruby, and Python? :) |
| 22:26 | <SimonSapin> | or C |
| 22:26 | <SamB> | I don't know why Perl is in that list |
| 22:26 | <SamB> | though you have a point |
| 22:26 | <SimonSapin> | oh, it’s spelled pearl in english, sorry |
| 22:26 | <SamB> | not that I've personally seen/heard Java used of the coffee all that often |
| 22:27 | SamB | is amused by VERA's first entry for perl |
| 22:29 | <zewt> | none as bad as calling a browser "chrome" |
| 22:29 | <zewt> | thus making it forever impossible to search for anything regarding firefox's chrome |
| 22:34 | <zewt> | just saw firefox's current fullscreen implementation for the first time, it's ... pretty terrible :| |
| 22:34 | <zewt> | every time i focus firefox on the other monitor a giant thing pops up FIREFOX IS NOW FULLSCREEN (which it already told me the first time) |
| 23:34 | <Hixie> | SimonSapin: using abbreviations like "fn" and "mod" instead of "function" and "module", using non-standard punctuation like || and !, having multiple string syntaxes, non-standard attribute syntax, that kind of thing |
| 23:34 | <Hixie> | SimonSapin: also i don't understand some decisions, which, unless they have good reasons, would also fall into that bucket, like needing to explicitly give the type name before a { } struct literal |
| 23:41 | <Hixie> | SimonSapin: (the non-standard punctuation thing extends to e.g. the way ~ is used. I'd personally think it'd be much more readable if it was keywords rather than punctuation.) |
| 23:41 | <Hixie> | hth |
| 23:50 | <smaug____> | zewt: file a bug |
| 23:50 | <smaug____> | zewt: not too many users have several monitors |
| 23:50 | <smaug____> | nor developers |
| 23:52 | <smaug____> | SimonSapin: btw looks like I agree with Hixie on bad design decisions of Rust. It is just too alien comparing to other languages, and mostly without any good reason. |
| 23:53 | <Hixie> | i should add that i have zero experience writing rust, so, you know, take what i said with a grain of salt ;-) |
| 23:54 | <Hixie> | but in general, where the language isn't being innovative, i would recommend sticking with what people know |
| 23:54 | <Hixie> | it'll make it easier for people to pick up the actually new stuff |
| 23:55 | <Hixie> | on a different note, i don't understand the difference between https://developer.mozilla.org/en-US/docs/NSS_Certificate_Download_Specification and https://wiki.mozilla.org/index.php?title=CA:Certificate_Download_Specification&action=history |
| 23:55 | <Hixie> | uh |
| 23:56 | <Hixie> | https://developer.mozilla.org/en-US/docs/NSS_Certificate_Download_Specification and https://wiki.mozilla.org/CA:Certificate_Download_Specification |
| 23:57 | <annevk> | Hixie: file a bug? |
| 23:57 | <Hixie> | on? |
| 23:57 | <annevk> | Hixie: MDN I suspect |
| 23:57 | <Hixie> | i don't really know what the bug is |
| 23:58 | <annevk> | Hixie: duplication of content |
| 23:59 | <annevk> | Hixie: without clarity on what is canonical |
| 23:59 | <Hixie> | it's not quite duplicate |
| 23:59 | <Hixie> | :-) |
| 23:59 | <annevk> | Not sure that makes it better |
| 23:59 | <TabAtkins> | Hixie: The "fn" abbreviation, at least, has a pretty good pedigree. Several languages use it. |