| 07:46 | <hsivonen> | MikeSmith: as you may have noticed from bugmail, I managed to restore bugzilla.validator.nu yesterday. |
| 07:47 | <MikeSmith> | yup |
| 07:47 | <MikeSmith> | thanks |
| 07:47 | <MikeSmith> | your server mostly back to normal now? |
| 07:47 | <hsivonen> | MikeSmith: yeah, except for s.validator.nu |
| 07:47 | <MikeSmith> | oh |
| 07:48 | <hsivonen> | also, html5.validator.nu needs to be updates to an operating system that gets security patches |
| 07:48 | <MikeSmith> | heh |
| 07:48 | <MikeSmith> | yeah that'd be good |
| 07:48 | <hsivonen> | but I intend to create a new VM for that and repoint the DNS once that's done |
| 07:48 | <hsivonen> | I'm not planning on even trying to run a distribution upgrade on html5.validator.nu |
| 07:48 | <MikeSmith> | OK |
| 07:49 | <hsivonen> | then I intend to stay on an LTS release for a couple of years without trying to upgrade |
| 07:49 | <MikeSmith> | that sounds prudent |
| 07:49 | <hsivonen> | the reason why the servers weren't on LTS in the first place was that last time the LTS didn't yet have openjdk |
| 07:50 | <MikeSmith> | ah yeah |
| 07:51 | <hsivonen> | my unhappiness with Ubuntu on both the desktop and on the server is growing, but so far, I haven't made the jump to another distro |
| 07:51 | <MikeSmith> | FreeBSD |
| 07:51 | <MikeSmith> | I guess I don't see what the value proposition is for running Ubuntu on the server |
| 07:53 | <hsivonen> | my thinking was that by running Ubuntu on the servers, I don't need to use a different package system on the server compared to the desktop |
| 07:53 | <MikeSmith> | ah |
| 07:53 | <hsivonen> | and openjdk came to Ubuntu sooner than it came to a stable Debian release, IIRC |
| 07:53 | <hsivonen> | might be a false optimization and maybe I'd be better off running CentOS |
| 07:53 | <MikeSmith> | maybe |
| 07:53 | <MikeSmith> | or you could run Debian testing |
| 07:55 | <hsivonen> | I think I don't want to run a non-stable release on the servers |
| 07:55 | <MikeSmith> | yeah |
| 07:55 | <hsivonen> | though I could start believing that Debian testing is more stable than Ubuntu "stable" releases |
| 07:56 | <MikeSmith> | that might not be so far from the truth |
| 07:56 | <MikeSmith> | and it's easy enough to revert individual packages when you need to |
| 07:56 | <MikeSmith> | e.g., when jackass Debian dev gets a brilliant idea like changing cron behavior so it generates nofications any time a process exits non-zero |
| 07:56 | <hsivonen> | for desktop, I've occasionally wondered if RHEL desktop came with better-working hardware drivers and support that actually helps |
| 07:58 | <hsivonen> | the problem with desktop is that home users don't use RHEL desktop, so proprietary packages like Skype, Spotify and Chrome aren't advertised to support RHEL Desktop |
| 07:58 | <MikeSmith> | ah |
| 07:59 | <hsivonen> | AFAICT, Ubuntu has the best 3rd-party package availability and is the only one of the distros officially supported by Skype and Chrome that has a paid support service available |
| 07:59 | <hsivonen> | but now that I've used the paid support service for over 6 months, I'm inclined to think it's useless |
| 07:59 | <MikeSmith> | I guess I've pretty much gave up on desktop LInux after 10 years of it seeming to find more and more ways of burning up inordinate amounts of my time, and I'm now just using OSX and macports stuff |
| 08:00 | <MikeSmith> | paid support for desktop? |
| 08:00 | <MikeSmith> | or with server support too? |
| 08:00 | <hsivonen> | MikeSmith: I pay for desktop support. For the servers, I usually don't need professional help. And when I do, the hosting provider helps me. |
| 08:00 | <MikeSmith> | ok |
| 08:01 | <hsivonen> | Canonical's paid desktop support has semi-solved a problem for me once. |
| 08:01 | <hsivonen> | but then the next distribution upgrade broke stuff even more so that the solution no longer works |
| 08:02 | <MikeSmith> | when they break stuff to that degree it can only seem to me that they just don't care enough to actually do complete testing |
| 08:02 | <hsivonen> | I think it's really sad that the paid support couldn't manage to successfully instruct me how to make a bootable clone of the system onto another disk |
| 08:03 | <MikeSmith> | people bitch about stable Debian releases taking forever, but at least you can be confident they've tested the hell out of it before releasing |
| 08:03 | <hsivonen> | and the latest was that the support analyst suggested buying another computer when I later figured that they are just shipping me super-leaky software and my problem is semi-solved if I kill nautilus every morning |
| 08:03 | <MikeSmith> | heh |
| 08:03 | <MikeSmith> | wonderful |
| 08:04 | <MikeSmith> | maybe he should have suggested you buy another OS with your new computer |
| 08:05 | <hsivonen> | maybe |
| 08:05 | <hsivonen> | this year, on my work computer, Ubuntu has regressed support for 3 pieces of hardware |
| 08:06 | <hsivonen> | on my grandfather's Ubuntu installation, Ubuntu has regressed support for 1 piece of hardware lately |
| 08:06 | <MikeSmith> | reminds me of previous job where I knew some apps we had sold to customers were just not what they should have been… felt like telling them, you shouldn't listen to our sales people |
| 08:06 | <hsivonen> | and on my girlfriend's, also one piece of hardware |
| 08:06 | <MikeSmith> | regressed? |
| 08:06 | <MikeSmith> | crazy |
| 08:06 | <MikeSmith> | seems like that should never happen |
| 08:06 | <hsivonen> | MikeSmith: hardware used to work. after distribution upgrade doesn't work at all or works worse |
| 08:07 | <MikeSmith> | geez |
| 08:07 | <MikeSmith> | that's the kind of thing that would make me want to find out who the guy is who caused that, and where he lives |
| 08:09 | <MikeSmith> | or their names and pictures should be published on a site somewhere |
| 08:09 | <MikeSmith> | wall of shame |
| 08:10 | <MikeSmith> | or dock their pay |
| 08:10 | <MikeSmith> | 1000 dollars for every regression that makes it into production |
| 08:11 | <MikeSmith> | 100 dollars for every time they break a build |
| 08:12 | <hsivonen> | as a developer, I sympathize with developers regressing stuff, but an OS distributor really ought to have serious hardware support regression testing with a wide array of hardware |
| 08:12 | <MikeSmith> | hsivonen: anyway, I plan on trying to go through open validator bugs over next two weeks and checking in some fixes |
| 08:12 | <hsivonen> | I realize that that's would be a significant capital investment and an ongoing personnel investment |
| 08:13 | <hsivonen> | MikeSmith: cool |
| 08:13 | <MikeSmith> | they could be doing it a lot better |
| 08:13 | <hsivonen> | MikeSmith: I intend to switch to a newer Jetty today |
| 08:13 | <hsivonen> | Jetty's security bugs generally aren't in the part that V.nu uses, but just to be sure |
| 08:13 | <MikeSmith> | they are cutting corners in order to get "stable" releases out more often |
| 08:14 | <MikeSmith> | well, "plan on trying"… I guess I should say I will make sure I do actually get at least a couple fixe in soonish |
| 08:16 | <phrearch> | hi |
| 08:17 | <MikeSmith> | lemme know when you do that Jetty upgrade |
| 08:17 | <MikeSmith> | I can try it out on several machines |
| 08:17 | <MikeSmith> | not sure what they all are running |
| 08:17 | MikeSmith | checks |
| 08:20 | <MikeSmith> | hsivonen: actually, I see that they're all 2.6.26-2-amd64 x86_64 GNU/Linux |
| 08:20 | <MikeSmith> | so that doesn't help much as far as variety of environments |
| 08:20 | <MikeSmith> | phrearch: hey |
| 08:20 | <phrearch> | hi MikeSmith |
| 08:21 | <phrearch> | i wonder if a contenteditable has the same events/properties as a textbox |
| 08:22 | <MikeSmith> | same events? |
| 08:22 | <phrearch> | yea, like when you click on a position, select some text, remove some, etc. |
| 08:23 | <phrearch> | this texteditor that i want to integrate in a wiki, has collaborative features showing who is typing and where with coloured text |
| 08:23 | <phrearch> | currently it uses a textbox for the typing, and some mechanism outside that to show the text with colour |
| 08:24 | <MikeSmith> | I think http://dev.w3.org/html5/spec/editing.html#user-editing-actions is a possibly relevant part of the spec |
| 08:24 | <phrearch> | http://img809.imageshack.us/f/snapshot1u.jpg/ |
| 08:24 | <phrearch> | thanks |
| 08:25 | <MikeSmith> | though not sure how interoperable behavior is across browsers with this stuff |
| 08:25 | <phrearch> | as long it works in webkit :) |
| 08:25 | <MikeSmith> | ah, don't say that |
| 08:25 | <phrearch> | im not really concerned about ie operability :) |
| 08:26 | <phrearch> | but yea, i prefer a crossbrowser solution |
| 08:26 | <MikeSmith> | I guess you should just write native apps then |
| 08:26 | <phrearch> | not really. its just that html5 stuff is better implemented in webkit browsers atm |
| 08:27 | <MikeSmith> | heh |
| 08:30 | <phrearch> | trying to implement http://www.jinfinote.com/ in a wiki |
| 08:30 | <phrearch> | pretty cool. its a javascript implementation of the infinote protocol |
| 08:31 | <hsivonen> | MikeSmith: I committed the Jetty update to the build script |
| 08:31 | <MikeSmith> | hsivonen: oh |
| 08:31 | <MikeSmith> | I'll sync up my workspace and try it |
| 08:32 | <hsivonen> | it seems that there are other libs that have had maintanance releases since whenever I last updated the jars |
| 08:32 | <MikeSmith> | hmm |
| 08:33 | <MikeSmith> | maybe would be good to update them one-by-one |
| 08:33 | <MikeSmith> | if you do update them |
| 08:33 | <hsivonen> | I really ought to be better at staying on top of library updates. I've been assuming that with the current setup, running in a managed environment keeps V.nu safe from bad stuff that one would be exposed to by running old C libs |
| 08:33 | <hsivonen> | MikeSmith: I have no idea if there's a true security or stability need to update anything |
| 08:34 | <MikeSmith> | I guess it's probably good to update them just to be safe |
| 08:34 | <MikeSmith> | eventually |
| 08:35 | <MikeSmith> | as long as they don't break stuff |
| 08:35 | <MikeSmith> | phrearch: is there an actual spec for infonote somewhere? |
| 08:36 | <MikeSmith> | hsivonen: "Bad MD5 hash for http://dist.codehaus.org/jetty/jetty-6.1.26/jetty-6.1.26.zip."; |
| 08:37 | <phrearch> | yea, at http://gobby.0x539.de/trac/wiki/Infinote/Protocol |
| 08:37 | <MikeSmith> | formatting of these pages smells kind of GNU info-like |
| 08:38 | <hsivonen> | MikeSmith: weird. I tried it before committing. :-( |
| 08:38 | <hsivonen> | MikeSmith: worked for me on two computers |
| 08:39 | <MikeSmith> | hsivonen: OK, I'll try again |
| 08:39 | <hsivonen> | MikeSmith: if you retrieve the URL manually, do you get a zip file or an error page? |
| 08:39 | <MikeSmith> | dunno |
| 08:39 | <MikeSmith> | whill try now |
| 08:39 | <hsivonen> | looks like updating HttpClient isn't worthwhile |
| 08:40 | <hsivonen> | it ain't broke |
| 08:40 | <MikeSmith> | ok |
| 08:40 | <hsivonen> | at least not in an obvious way |
| 08:40 | <hsivonen> | and 4.0 is a rewrite that fixes architectural flaws |
| 08:40 | <hsivonen> | to me that means API changes |
| 08:41 | <MikeSmith> | man, I am on a really sucky connection here… ~45 K/s |
| 08:41 | <MikeSmith> | stalled |
| 08:41 | <MikeSmith> | hsivonen: I think it probably just failed to download completely |
| 08:42 | <hsivonen> | MikeSmith: ok |
| 08:42 | <hsivonen> | Rhino is not worth updating |
| 08:42 | <MikeSmith> | oh |
| 08:42 | <MikeSmith> | that sounds not so good |
| 08:42 | <hsivonen> | Jena IRI lib seems to be stable as in almost dead, so no need to update |
| 08:43 | <hsivonen> | I guess I should update ICU4J in order to get up-to-date Unicode tables |
| 08:43 | <MikeSmith> | yeah |
| 08:44 | <MikeSmith> | what is slf4j? |
| 08:45 | <MikeSmith> | logging? |
| 08:45 | <hsivonen> | MikeSmith: it's yet another logging wrapper |
| 08:45 | <MikeSmith> | ok |
| 08:46 | <hsivonen> | log4j is the best and was there first, but still people feel compelled to write more and more logging system and logging system abstraction layers |
| 08:46 | <hsivonen> | it's quite sad, really |
| 08:48 | <MikeSmith> | seems in general like one of those kinds of things |
| 08:48 | <MikeSmith> | that developers seem to love to screw around with writing up |
| 08:48 | <MikeSmith> | whether anybody else really needs it or not |
| 08:49 | <hsivonen> | part of the problem is that Sun put the kitchen sink in the standard library badly and Apache has better versions of nearly everything |
| 08:49 | <hsivonen> | so then people feel compelled to abstract over the standard library stuff and the Apache stuff |
| 08:50 | <MikeSmith> | ah |
| 08:50 | <hsivonen> | everyone would be better off if the standard lib was smaller and everyone used the Apache stuff |
| 08:50 | <MikeSmith> | I see |
| 08:50 | <MikeSmith> | amen |
| 08:55 | <MikeSmith> | hsivonen: one thing there's been a couple of bug reports about recently is style/@scoped not supported where the spec says it should be |
| 08:56 | <MikeSmith> | i'm trying to remember if there was some complication involved with making that change |
| 08:56 | <MikeSmith> | I think there was but can't recall now |
| 08:56 | <hsivonen> | MikeSmith: no complication that I can remember |
| 08:56 | <MikeSmith> | ok |
| 08:57 | <hsivonen> | except, of course, that since <style scoped> isn't supported by browsers, it's a bit scary that users validate code with it |
| 08:57 | <MikeSmith> | true |
| 08:57 | <MikeSmith> | which makes it not such a huge priority I guess |
| 08:57 | <hsivonen> | aargh. validator.nu is down again |
| 08:57 | <MikeSmith> | oh |
| 08:59 | <hsivonen> | huh. my ~/.ssh/known_hosts on Ubuntu is not clear text for the host names as it is on Mac |
| 09:00 | <MikeSmith> | hsivonen: btw, you saw my note a couple days ago about the parser error message for rt outside of ruby? |
| 09:00 | MikeSmith | looks for link in logs |
| 09:00 | <hsivonen> | MikeSmith: I didn't |
| 09:01 | <MikeSmith> | lemme find it now |
| 09:02 | <MikeSmith> | hmm, weird |
| 09:02 | <MikeSmith> | maybe krijn was away |
| 09:02 | MikeSmith | checks local logs |
| 09:04 | <MikeSmith> | hsivonen: - |
| 09:04 | <MikeSmith> | 17:40 < MikeSmith > hsivonen: I think the parse-error messages that the validator.nu parser generates for the following case are not correct:17:40 < MikeSmith > <!DOCTYPE html> |
| 09:04 | <MikeSmith> | 17:40 < MikeSmith > <title>Ruby vs ins/del</title> |
| 09:04 | <MikeSmith> | 17:40 < MikeSmith > <p>X<rt>x</rt>Y<ins><rt>y</rt></ins></p> |
| 09:04 | <MikeSmith> | 17:41 < MikeSmith > it reports "Error: Unclosed children in ruby." |
| 09:04 | <MikeSmith> | 17:42 < MikeSmith > but there is no ruby element in the source, nor does one get created in the DOM |
| 09:04 | <MikeSmith> | 17:44 < MikeSmith > and it's not an unclosed-children error case |
| 09:04 | <MikeSmith> | 17:45 < MikeSmith > because it goes into the DOM just the way it is in the source, without any implied end tag being generated |
| 09:04 | <MikeSmith> | 17:46 < MikeSmith > it seems like the error reported for this case should instead be something like "rt start tag outside of ruby element" or "rt star |
| 09:04 | <MikeSmith> | t tag found by current node is not ruby element" |
| 09:05 | <hsivonen> | so it looks like the build script is bogus as far as deps.tar.gz deployment goes... |
| 09:05 | <MikeSmith> | eh? |
| 09:05 | <MikeSmith> | something changed? |
| 09:05 | <MikeSmith> | how could it be bogus if it was working previously? |
| 09:05 | <hsivonen> | MikeSmith: it seems it has been bogus for a long time |
| 09:05 | <hsivonen> | MikeSmith: the dependencies haven't changed in a long time... |
| 09:06 | <MikeSmith> | ah |
| 09:06 | <MikeSmith> | that python script is something else man |
| 09:07 | <MikeSmith> | but not sure using an actual make system would be better |
| 09:07 | <MikeSmith> | I guess not ant or maven at least |
| 09:07 | <hsivonen> | the script sucks, yeah, but I doubt we'd be better off with make or ant |
| 09:07 | <MikeSmith> | yeah |
| 09:08 | <MikeSmith> | not for building java at least |
| 09:08 | <hsivonen> | MikeSmith: I think the parsing algorithm just ignores </rt> tags |
| 09:09 | <hsivonen> | and INS is not special |
| 09:09 | <hsivonen> | so </ins> doesn't generate implied end tags |
| 09:09 | <MikeSmith> | yeah, I know that |
| 09:09 | <hsivonen> | MikeSmith: I blame the spec |
| 09:10 | <MikeSmith> | as I understand it, rt causes the implied end tag for ins to be generated |
| 09:10 | <MikeSmith> | but only if the rt element is a descendant of a ruby element |
| 09:10 | <MikeSmith> | if it's not a descendant of a ruby element, it ends up as a child of the ins as expected |
| 09:11 | <MikeSmith> | and it's a parse error in either case |
| 09:11 | <MikeSmith> | it's just a different parse error |
| 09:11 | <hsivonen> | oh, right, so what's needed is special-cased error message. |
| 09:11 | <MikeSmith> | yeah |
| 09:11 | <MikeSmith> | I think the parse error you are emitting there now is for the within-ruby case |
| 09:12 | <MikeSmith> | anyway, it's not a big deal |
| 09:12 | <MikeSmith> | but I can raise a bug for it somewhere if you want |
| 09:12 | <MikeSmith> | just wasn't sure where it should go |
| 09:13 | <hsivonen> | so, what's happening here is that I haven't put too much thought into the error messages |
| 09:13 | <MikeSmith> | oh, and bugzilla.validator.nu was down |
| 09:13 | <MikeSmith> | ok |
| 09:13 | <hsivonen> | the spec says "Parse Error" |
| 09:13 | <MikeSmith> | yeah |
| 09:13 | <MikeSmith> | so maybe that's something else I can help with |
| 09:13 | <hsivonen> | and I didn't realize the error needs different messages depending on what happened a couple of lines earlier |
| 09:13 | <MikeSmith> | ok |
| 09:14 | <MikeSmith> | well, I guess I can write patches for these when I find them |
| 09:14 | <MikeSmith> | the thing is they are reported by validator.nu, |
| 09:14 | <MikeSmith> | so they do get exposed to end users |
| 09:14 | <MikeSmith> | and some of them can confuse the hell out of people |
| 09:14 | <MikeSmith> | actually, the reason I noticed this one was because of a bug that James Clark raised |
| 09:15 | <hsivonen> | MikeSmith: I can fix this one today once I sort out the deployment and ICU4J problems |
| 09:15 | <MikeSmith> | ok |
| 09:15 | <MikeSmith> | well, no rush |
| 09:16 | <MikeSmith> | anyway, the bug from James was http://www.w3.org/Bugs/Public/show_bug.cgi?id=11363 |
| 09:16 | <benschwarz> | MikeSmith: ! Allo :) |
| 09:17 | <MikeSmith> | hsivonen: which is not directly related since it's about the within-ruby case, but just mentioning it |
| 09:17 | <MikeSmith> | benschwarz: hej |
| 09:18 | <hsivonen> | part of my problem is that I don't tweak build.py every day, so I nearly always fail to remember what dark corners there are |
| 09:19 | <MikeSmith> | hmm |
| 09:19 | <MikeSmith> | yeah |
| 09:19 | <hsivonen> | but at least it's Python and not Perl, so there's some chance of reading the code to find out |
| 09:19 | <MikeSmith> | heh |
| 09:20 | <MikeSmith> | it is quite readable |
| 09:20 | <MikeSmith> | I'll give you that at least |
| 09:21 | <hsivonen> | I'm quite ashamed of the support code for V.nu and the HTML5 parser |
| 09:21 | <hsivonen> | i.e. build.py and the C++ translator |
| 09:22 | <MikeSmith> | I wonder if wscript is any good or if it's as messed up as other build stuff |
| 09:22 | <MikeSmith> | hsivonen: ashamed? |
| 09:22 | <MikeSmith> | what's wrong with it? |
| 09:23 | <hsivonen> | MikeSmith: just now I discovered total bogosity in the "deploy" target of build.py |
| 09:23 | <MikeSmith> | oh |
| 09:23 | <MikeSmith> | well, I never use that :) |
| 09:24 | <hsivonen> | MikeSmith: and the code in the C++ translator that translated the fields of a class from Java to C++ is just terrible |
| 09:24 | <MikeSmith> | ah |
| 09:24 | <hsivonen> | s/translated/translates/ |
| 09:25 | <MikeSmith> | seems to get the job done, at least |
| 09:25 | <thiessenp> | newb question: just started with html5 geolocation and am using the W3C API with FF3 - when I try to get a position using window.navigator.geolocation.getCurrentPosition I get a JS error that "location is undefined". The error points to the WifiGeoCoordsObject. This odd because I'm on a desktop without Wifi, though I am behind a firewall. *Any ideas?* |
| 09:27 | <MikeSmith> | thiessenp: try FF4 and see if it fixes it? |
| 09:27 | <thiessenp> | MikeSmith: good idea - will do now :D |
| 09:29 | <hsivonen> | clearly, I should make the deploy target use rsync instead of scp |
| 09:30 | <hsivonen> | to move only the changed bits |
| 09:40 | <hsivonen> | MikeSmith: fix to the error message pushed to hg |
| 09:40 | <MikeSmith> | thanks |
| 09:41 | MikeSmith | syncs up his workspace |
| 09:56 | <jgraham> | abarth: Any chance of syncing the WebKit HTML parser tests with those in html5lib? |
| 10:02 | <hsivonen> | heh. the build number of Opera 11 beta is 1111 |
| 10:03 | hsivonen | wonders what exactly "Enhanced HTML5 support" means in the context of Opera 11 |
| 10:04 | <zcorpan> | faster javascript? :) |
| 10:04 | <hsivonen> | zcorpan: that's a different item on the list |
| 10:04 | <gsnedders> | There's faster JS in 11? |
| 10:04 | <hsivonen> | I'm guessing Web Socket but anything else? |
| 10:04 | <jgraham> | Maybe we are using "enhanced" to be "augmented with plastic surgery" |
| 10:05 | <zcorpan> | hsivonen: updated EventSource |
| 10:05 | jgraham | isn't actually sure which things made it into the beta |
| 10:06 | <hsivonen> | zcorpan: ok. |
| 10:06 | <zcorpan> | hsivonen: maybe small fixes like fixing the structured clone algorithm to be up-to-date (haven't tested if it's in the beta though) |
| 10:06 | <hsivonen> | jgraham: I gather Opera has a less linear release path than Mozilla |
| 10:06 | <gsnedders> | hsivonen: "linear" meaning in terms of how often, etc? |
| 10:07 | <jgraham> | hsivonen: Core is rather seperate, and core itself uses a rather branched development process |
| 10:07 | <hsivonen> | gsnedders: in terms of if feature X has landed in some repo at time t1, a realease made at t2 (where t1<t2) will have feature X |
| 10:08 | <gsnedders> | hsivonen: The answer, needless to say, is no comment. |
| 10:09 | <gsnedders> | hsivonen: But what is public is that Core development is separate from Desktop development. |
| 10:11 | <gsnedders> | (and separate from Devices SDK, from Mobile, from Mini, etc. development) |
| 10:15 | <hsivonen> | anyway, I'm generally impressed by Opera's ability to deal with multiple branches (at least as observed from the outside; dunno how terrible it feels on the inside) |
| 10:15 | zcorpan | sent http://lists.w3.org/Archives/Public/public-web-perf/2010Nov/0032.html Move window.performance to navigator.performance |
| 10:17 | <jgraham> | zcorpan: Why would that break scripts |
| 10:17 | <jgraham> | presumably the global would be shadowed? |
| 10:17 | <gsnedders> | hsivonen: http://www.opera.com/docs/changelogs/windows/1100b/ has more explaination for HTML5 support |
| 10:17 | <jgraham> | (although maybe not if you have <div id=performance> or so on) |
| 10:20 | <hsivonen> | gsnedders: thanks |
| 10:21 | <hsivonen> | btw, does Big5-HKSCS participate in any willful IANA violation alias resolution in Opera? |
| 10:25 | <zcorpan> | jgraham: maybe existing pages will still continue to work, but then it won't be possible to use script libraries that measure perf on those pages |
| 10:26 | <jgraham> | Indeed |
| 10:27 | <zcorpan> | jgraham: and it might break in subtle ways if pages expect window.performance == undefined until they insert the element |
| 10:27 | <zcorpan> | or whatever |
| 10:28 | <jgraham> | Yes, it is not impossible to break pages by adding things |
| 10:32 | <thiessenp> | MikeSmith: FF4 didn't help with the location error but oddly enough enabling Wifi on my desktop worked - just encase you were curious |
| 10:32 | <MikeSmith> | interesting |
| 11:54 | <zcorpan> | wow i didn't know navigator survived page transitions in gecko |
| 11:54 | <zcorpan> | doesn't seem like it does in opera |
| 11:55 | <zcorpan> | also not in chrome |
| 11:55 | <zcorpan> | or safari |
| 12:11 | <zcorpan> | oh navigator survives page transitions in ie too |
| 12:28 | <thiessenp> | Has anyone had success with IP based geolocation? |
| 12:29 | <thiessenp> | For example, my accuracy seams to be off by about a city length. So, yes NL is right by Leidschendam is wrong, I'm currently in Amsterdam :) |
| 12:29 | <thiessenp> | by=but |
| 12:35 | <hsivonen> | thiessenp: I guess it depends on your ISP, Google's databases, etc. |
| 12:35 | <hsivonen> | thiessenp: IP-based geolocation puts me in the right city |
| 12:36 | <thiessenp> | hsivonen: I feared this much. Hmm, can you point me to any JS code examples? (maybe I'm missing something - first attempt now for fun) |
| 12:36 | <hsivonen> | but then my ISP is also based in the same city and I don't know if their clients in other cities are also placed here |
| 12:36 | <hsivonen> | thiessenp: http://isgeolocationpartofhtml5.com/ |
| 12:38 | <hsivonen> | looks like Safari and Chrome aren't big enough in France, yet. |
| 12:38 | <thiessenp> | hsivonen: that example put me in the right coords (dead on) - looks like its my code :) thx will try this example |
| 12:38 | <thiessenp> | hmm noted |
| 12:39 | hsivonen | dealt with an evangelism bug where a French site no longer worked in Firefox 4 due to the AAA, but also didn't work in Safari or Chrome |
| 12:43 | <thiessenp> | hsivonen: interesting out of curiosity what part of WCAG-AAA was no longer compliant? |
| 12:43 | jgraham | seems to be either near Stockholm or somewhere near the West Coast according to IP based Geolocation |
| 12:44 | <jgraham> | (these are some hundreds of km wrong) |
| 12:44 | <jgraham> | (in roughly opposite directions) |
| 12:45 | <hsivonen> | thiessenp: not WCAG-AAA but the Adoption Agency Algorithm |
| 12:46 | <thiessenp> | hsivonen: oh ok - will look up what that is :) |
| 12:47 | <thiessenp> | hsivonen: btw: when I ran the code from the example you gave locally on my dev environment I ended up in the north pacific ocean. I love swimming but ... :) I think this may have something to do with a firewal or proxy? I know I'm asking vague questions. |
| 12:51 | <hsivonen> | thiessenp: the example randomizes the location on error |
| 12:51 | <thiessenp> | hsivonen: busted - guess I better take a closer look at the code (thx) |
| 12:56 | <annevk> | XMLHttpRequest Level 2 (aka AJAX 2) -- orly? |
| 12:56 | <annevk> | -- http://www.mobilexweb.com/blog/safari-ios-accelerometer-websockets-html5 |
| 13:16 | <hsivonen> | annevk: how does it feel to be the editor of the latest buzzword? |
| 13:20 | <MikeSmith> | buzzword? |
| 13:20 | <hsivonen> | MikeSmith: AJAX 2 |
| 13:22 | <Philip`> | That's not the latest buzzword, that's just the combination of the two previous now-obsolete buzzwords |
| 13:23 | <hsivonen> | scary. I got NS_ERROR_FAILURE from virtualbox |
| 13:23 | <hsivonen> | is virtualbox based on Mozilla code? |
| 13:24 | <Rik`> | hsivonen: isn't it NS as in NextStep ? |
| 13:25 | <Philip`> | http://www.virtualbox.org/wiki/Developer_FAQ |
| 13:25 | <hsivonen> | Rik`: I'm not aware of Next having used that exact error name |
| 13:25 | <Philip`> | "On Linux hosts, VirtualBox makes use of Mozilla XPCOM as its component model." |
| 13:26 | <hsivonen> | Philip`: wow. |
| 13:26 | <hsivonen> | that such a strange design decision |
| 13:26 | <hsivonen> | *that's |
| 13:26 | <jgraham> | Philip`: No point making a whole new buzzwoard when you can stitch together and reanimate two dead buzzwords, zombie style |
| 13:27 | <MikeSmith> | reCOMifying |
| 13:28 | <jcranmer> | wait, someone's seriously trying to use XPCOM? |
| 13:29 | <jcranmer> | mozlla's trying to use it less |
| 13:30 | <Philip`> | They say "For Windows hosts, we do not rely on XPCOM" so maybe the situation was that they relied heavily on Win32 COM and didn't care about portability, and then realised that actually it'd be nice to port to Linux |
| 13:31 | <Philip`> | but COM doesn't exist there so they just grabbed the closest thing they could find to emulate it |
| 14:03 | <hsivonen> | jgraham: do you recall implementing the scopingness the MathML elements that accept HTML children? |
| 14:07 | <hsivonen> | jgraham: I'm going to assume that the tests are stale per my reading of the spec and will update the tests that test the non-scopingness of <mi>, <mo>, <mn>, <ms> and <mtext> |
| 14:23 | <hsivonen> | jgraham: looks like Google Code put my code review comment on the wrong changeset for no apparent reason |
| 14:33 | <jgraham> | hsivonen: I think that html5lib should be up to date as per a few days ago, but it is possible I missed something |
| 14:33 | <gsnedders> | jgraham: html5lib/Py or the tests? |
| 14:34 | <jgraham> | gsnedders: Both, I think |
| 14:43 | <hsivonen> | jgraham: I pushed fixes to what I believe to be broken tests |
| 14:45 | <jgraham> | hsivonen: Great. I was going to suggest that as a good remedy :) |
| 16:18 | <Xano_> | Where do I find the geolocation specification? |
| 16:18 | <annevk> | http://dev.w3.org/geo/api/spec-source.html |
| 16:18 | <Xano_> | Oh, that's W3C, not WHATWG |
| 16:18 | <Xano_> | annevk: Heh, just found it. Thanks for the quick response |
| 16:19 | <jgraham> | Still a reasonable place to ask about it, all things considered |
| 16:19 | <Xano_> | Was googling for "Whatwg geolocation... " :') |
| 16:24 | <annevk> | http://www.aminutewithbrendan.com/pages/20101122 Karakan? It's Carakan! |
| 16:29 | <jgraham> | (that link is entirely bogus) |
| 16:31 | <jgraham> | http://my.opera.com/core/blog/2009/02/04/carakan is a much less bogus link if anyone wants to propogate the message |
| 16:32 | <annevk> | happy to hear Brendan does mostly agree with the WHATWG versioning message |
| 16:33 | <annevk> | and that he's not really in favor of having bytecode shipped to browsers |
| 16:44 | <annevk> | I tried posting a comment with that corrected link, but failed to get passed the images asking me to spell |
| 17:10 | jgraham | tries to avoid disqus based comment forms |
| 17:30 | <gsnedders> | http://www.vemihelvete.se/2010/10/en-nord-gor-musik.html (or <http://translate.google.com/translate?u=http%3A%2F%2Fwww.vemihelvete.se%2F2010%2F10%2Fen-nord-gor-musik.html&sl=sv&tl=en&hl=&ie=UTF-8>; for the Swedish challenged). JS music! |
| 17:44 | <gsnedders> | Who here has IE9? Can someone copy/paste results for Sputnik in IE9? |
| 18:05 | <TabAtkins> | Where's sputnik? |
| 18:06 | <TabAtkins> | Unrelated: it looks like canvas gradients are defined to transition in non-premultiplied space, right? If so, that's the only place on the platform where colors transition that way now. |
| 18:07 | <gsnedders> | TabAtkins: http://sputnik.googlelabs.com/run |
| 18:07 | <TabAtkins> | k, one sec then |
| 18:08 | <Philip`> | TabAtkins: Everything in canvas is non-premultiplied |
| 18:08 | <Philip`> | (except for implementations) |
| 18:09 | <TabAtkins> | Philip`: So implementations currently transition in pre-multiplied space? |
| 18:12 | <Philip`> | TabAtkins: No, I believe they behaviourally match the spec |
| 18:12 | <Philip`> | http://test.w3.org/html/tests/submission/PhilipTaylor/canvas/2d.gradient.interpolate.colouralpha.html |
| 18:12 | <Philip`> | I think that'd give different output if interpolating linearly in premultiplied colour space |
| 18:12 | <Philip`> | The implementations just store everything in premultiplied form in the backing store, then do whatever's necessary to get the right behaviour |
| 18:13 | <gsnedders> | http://www.reddit.com/r/IAmA/comments/eadq7/iama_person_with_zero_creative_talent_ill_draw/c16ln1w |
| 18:14 | <TabAtkins> | gsnedders: Oh. Man. AWESOME. |
| 18:17 | <gsnedders> | TabAtkins: Yeah, I'm having one of these moments where I can't help but think: I fucking love this company. |
| 18:39 | <annevk> | http://www.opera.com/?display=myopera omg lol |
| 18:40 | <Rik`> | sadly it only works in English |
| 18:41 | <virtuelv> | context to that link from annevk http://www.reddit.com/r/bestof/comments/eakz7/selfproclaimed_zerotalent_artist_creates_drawings/ |
| 18:41 | <gsnedders> | TabAtkins: Run it in IE9? |
| 18:43 | <TabAtkins> | Ah, I did, but on a screen that's hidden now so I forgot about it. What info do you want from it? |
| 18:43 | <gsnedders> | TabAtkins: The list of tests that fail |
| 18:48 | <TabAtkins> | gsnedders: http://pastebin.com/HusmnmTF |
| 18:48 | <gsnedders> | TabAtkins: thx |
| 19:53 | <jgraham> | Dear Wikipedia: if you are going to try and coerce me into donating with dramatically-lit photographs advertisting personal appeals, please try not to blow out the highlights on Jimmy Wales' nose |
| 19:54 | Philip` | clicked on the donation ad once, but only because he was clicking a link near the top of the page when the ad suddenly popped into existence under his mouse |
| 19:55 | <karlushi> | Dear wikipedia, I'm 10 years old, what is this old pervert looking at me all the time. |
| 20:42 | <annevk> | thanks TabAtkins for following up on the gradient stuff |
| 20:43 | <TabAtkins> | No problem, annevk. |
| 21:11 | <TabAtkins> | annevk: Now if you could get someone relevant from Opera to comment on the canvas gradient thread... |
| 21:13 | <annevk> | I probably can, tomorrow |
| 21:14 | <TabAtkins> | Cool. |
| 21:21 | karlcow | wonders if TabAtkins is hidden in Tab Stacking |
| 21:27 | <Philip`> | TabAtkins: If interpolating from (255,255,255,1) to (0,0,0,0) doesn't give the effect you want, why not simply interpolate to (255,255,255,0) instead? |
| 21:28 | <Philip`> | (in the non-premultiplied world) |
| 21:29 | <Philip`> | If you *do* want the effect of non-premultipliedly interpolating from (255,255,255,1) to (0,0,0,0), then I guess the only way to get it in the premultiplied world is interpolating to (0,0,0,0.01) which looks like a nasty hack |
| 22:03 | <aidan> | What is the format of the datetime attribute, and why can't I find it ANYWHERE? |
| 22:03 | <aidan> | I can find parsing instructions, but I can't find the actual name of the format |
| 22:03 | <aidan> | http://dev.w3.org/html5/spec/common-microsyntaxes.html#parse-a-date-component |
| 22:04 | <hober> | essentially, it's an RFC3339 timestamp |
| 22:05 | <beowulf> | http://www.whatwg.org/specs/web-apps/current-work/multipage/common-microsyntaxes.html#valid-global-date-and-time-string |
| 22:08 | <jacobolus> | anyone have an idea why opera renders   (from a font that doesn't have the character built in, I believe) about 5 times wider than expected? |
| 22:08 | <jacobolus> | it makes   effectively worthless |
| 22:09 | <jacobolus> | (also, does the same with   which is perhaps even worse as sometimes multiple   are used in a row to get the desired amount of space) |
| 22:10 | <jacobolus> | (by 5 times too wide I mean that   renders about 3x as wide as a regular space) |
| 22:11 | <beowulf> | if the font doesn't have a thin space glyph it may be using a regular space (which is 5 to 6 times the width of a space if a space is 1 em wide) |
| 22:11 | <jacobolus> | what's a "regular" space? |
| 22:11 | <jacobolus> | that's just what you get with the space bar? |
| 22:11 | <jacobolus> | it's using a space that's substantially *wider* than that |
| 22:12 | <beowulf> | by regular space i mean the one that appears when you press the space bar |
| 22:13 | <beowulf> | it's about an em wide, i think |
| 22:14 | <jacobolus> | let me put an image online |
| 22:14 | <jacobolus> | http://i.imgur.com/bxl6m.png |
| 22:14 | <beowulf> | my suggestion would be to use a font that has a &thinsp |
| 22:15 | <jacobolus> | the space before the % is   |
| 22:15 | <jacobolus> | the other spaces are regular spaces |
| 22:15 | <jacobolus> | beowulf: no other browser does this as far as I can tell |
| 22:16 | <jacobolus> | at least none on my machine |
| 22:16 | <jacobolus> | maybe it's trying to pick out some CJK font with a fixed-width very wide space? |
| 22:16 | <jacobolus> | (under the   code point) |
| 22:17 | <TabAtkins> | Philip`: I covered that in the email - it's extra work, and more importantly, it's exta work *you don't have to do* in other parts of the web stack. |
| 22:17 | <jacobolus> | completely unrelated question: does anyone know why javascript mod operator (%) returns a negative value with a negative dividend? who ever decided that was a good behavior? :) |
| 22:17 | <beowulf> | jacobolus: that is indeed a large space |
| 22:17 | <jacobolus> | beowulf: right? :) |
| 22:18 | <jacobolus> | beowulf: in case it's helpful, the font here is Delicious |
| 22:18 | <TabAtkins> | Yeah, *actually* transitioning from, say, white to transparent black, hitting partially-transparent gray along the way, isn't really possible. Even going to (0,0,0,.01) doesn't work right - that is, expectedly, almost the same thing as just going to (0,0,0,0). |
| 22:18 | <jacobolus> | (which does not have a  ) |
| 22:18 | <Philip`> | TabAtkins: Writing rgba(255,255,250,0) when you want transparent yellow doesn't seem significantly more work than writing rgba(0,0,0,0), and it does seem much clearer |
| 22:19 | <TabAtkins> | It's more work and less clear than writing "transparent". |
| 22:19 | <Philip`> | "transparent" doesn't mean transparent yellow |
| 22:19 | <Philip`> | It means transparent black |
| 22:19 | <TabAtkins> | Exactly. |
| 22:19 | <TabAtkins> | Which is rarely what is intended. |
| 22:19 | <Philip`> | If you want transparent yellow, "transparent" is about as appropriate as "peach" |
| 22:19 | <jacobolus> | beowulf: I guess a workaround might be to edit the font to add a   character; not sure if that violates the license, but I doubt the font's author would mind so terribly much |
| 22:19 | <Philip`> | so don't use it :-) |
| 22:19 | <TabAtkins> | The fact that fully transparent colors still have a "color" is a technical detail. |
| 22:20 | <Philip`> | (Did you see my email response, by the way?) |
| 22:20 | <TabAtkins> | Haven't read it yet - I just got back to my desk. |
| 22:22 | <beowulf> | jacobolus: fwiw another exljibris font, museo, has a thinsp |
| 22:23 | <jacobolus> | beowulf: maybe I should email Jos |
| 22:23 | <jacobolus> | I'm pretty sure if this one had a   it wouldn't be making such a giant space in opera |
| 22:23 | <jacobolus> | (looking to see now if it does or not) |
| 22:24 | <jacobolus> | seems not |
| 22:24 | <jacobolus> | just the bare basic characters |
| 23:04 | <annevk> | oh, Tyler Close replied to my CORS email |
| 23:04 | <annevk> | guess it's time to go to bed |
| 23:05 | <annevk> | nn |
| 23:08 | <bga_> | hi |
| 23:10 | <bga_> | anybody not zombie? :) |
| 23:10 | <TabAtkins> | Ask a question, not a meta-question, please. |
| 23:10 | <TabAtkins> | ^_^ |
| 23:10 | <bga_> | ok |
| 23:11 | <bga_> | i want to talk about future of web :) |
| 23:11 | <bga_> | i dream about multilanguage web |
| 23:12 | <bga_> | i mean multi programming language |
| 23:12 | <bga_> | we should split renderer and scripting engine |
| 23:12 | <bga_> | as google does in chome |
| 23:12 | <bga_> | webkit + v8 |
| 23:13 | <bga_> | but instead v8 we should use .NET |
| 23:13 | <bga_> | because it allows alot of languages |
| 23:14 | <bga_> | for example i can make my site usiing ADA or F# :) |
| 23:14 | <bga_> | not only js |
| 23:14 | <bga_> | also there is a very good feature |
| 23:14 | <bga_> | we do not need to compress source code |
| 23:15 | <TabAtkins> | We already have multi-language support a *tiny* bit, in that you can switch between different javascript engines in some browsers. The main problem with more langauges is defining a new DOM interface that respects the particular language's strengths and quirks. |
| 23:15 | <bga_> | browser download CRL binary code |
| 23:15 | <TabAtkins> | (We tried creating interfaces in a generic fashion so both javascript and java could use the same code, and that was a *massive* mistake.) |
| 23:16 | <TabAtkins> | Downloading binaries is also somewhat of a minus, because it kills the ability to view source, which a lot of us webdevs used to learn stuff (and still do). |
| 23:16 | <Rik`> | and we also have enough troubles with having interoperable JS implementations |
| 23:18 | <bga_> | yes but .NET declares classes in CRL level and all languages can uses it w/o troubles |
| 23:18 | <Rik`> | I'm not sure we want MS deciding for the future of the web either |
| 23:18 | <bga_> | TabAtkins yes but it reduces world`s traffic |
| 23:19 | <bga_> | Rik` yes but we have Mono |
| 23:19 | <TabAtkins> | bga_: I didn't say it was evil, just that it has minuses. |
| 23:19 | <Rik`> | TabAtkins: do you really view source on minified code ? |
| 23:21 | <bga_> | TabAtkins also we can have normal debug in IDE ^_^ |
| 23:21 | <TabAtkins> | Rik`: Yes, though I don't like it because I have to pass it through a beautifier first. |
| 23:21 | <Rik`> | bga_: Mono is financed by Microsoft and follow .NET choices so this is not relevant |
| 23:21 | <Rik`> | TabAtkins: I can't read a beautified minified code |
| 23:21 | <TabAtkins> | Rik`: It's not the same as the original code, but it's usually "good enough". |
| 23:21 | <Rik`> | this is not how you want to learn |
| 23:22 | <TabAtkins> | I'm just talking about minified by stripping whitespace. Renaming vars and such is too much. |
| 23:22 | <Rik`> | minifying by stripping whitespace is kind of useless |
| 23:23 | <Rik`> | gzip is just enough for that |
| 23:23 | <bga_> | TabAtkins i see its also good because now renderer developers do not need to develop scripting engine |
| 23:24 | <bga_> | and they can fix bugs faster |
| 23:24 | <bga_> | :) |
| 23:24 | <Rik`> | bga_: that's not true |
| 23:24 | <TabAtkins> | Separating the scripting engine from the rendering engine is a good idea anyway, but it's completely separate from using multiple languages. |
| 23:25 | <Rik`> | scripting and redering teams are already quite separated |
| 23:25 | <bga_> | but i understand. i should talk about this ideas with MS team |
| 23:25 | <Philip`> | Script performance gives browser developers something quantitative to compete on and use in marketing |
| 23:25 | <jcranmer> | crossing language barriers can hurt speed performance |
| 23:25 | <Philip`> | It'd be much harder if they all just embedded Mono and there was no difference between them |
| 23:26 | <jcranmer> | I remember speeding something up by a factor of 5% by not throwing cross-language barrier exceptions |
| 23:26 | <jcranmer> | maybe it was 20% |
| 23:26 | <bga_> | Philip` they can compare rendering speed |
| 23:27 | <jcranmer> | the way the web is going |
| 23:27 | <bga_> | and quality of output |
| 23:27 | <jcranmer> | it's scripting speed that is more important |
| 23:27 | <jcranmer> | since you have to script to make things that depend on speed |
| 23:27 | <jcranmer> | e.g., web games |
| 23:27 | <bga_> | i guess no |
| 23:27 | <jcranmer> | rendering happens about once per page |
| 23:27 | <bga_> | js 2% rendering 98% |
| 23:28 | <jcranmer> | script events happen many, many, many more times |
| 23:28 | <jcranmer> | bga_: let me put it like this |
| 23:28 | <gsnedders> | bga_: At a certain level, you have to go for some bytecode that works for a variety of languages, and you won't get one that works for all. Quite possibly JS isn't /that/ bad as a target, given JIT'ing compilers that have a relatively small number of typechecks |
| 23:28 | <jcranmer> | if you're talking about smallish webpages |
| 23:28 | <jcranmer> | well |
| 23:29 | <jcranmer> | in many cases, network overhead outperforms rendering speed |
| 23:29 | <TabAtkins> | Google uses several languages that compile to JS. ^_^ |
| 23:29 | <Philip`> | Has anyone made a JIT that targets JS? |
| 23:29 | <bga_> | yes |
| 23:29 | <gsnedders> | TabAtkins: And don't get any JS engine QA started on the output :) |
| 23:29 | <jcranmer> | so the initial rendering speed really isn't all that important, as long as it's not super-slow |
| 23:29 | <TabAtkins> | gsnedders: Oh god, I know. I'm just saying. |
| 23:29 | <bga_> | i know haskell -> js c# -> js java -> python -> js list -> js translators |
| 23:29 | <jcranmer> | on the other hand, some JS events need to be fired hundreds of times a second |
| 23:29 | <bga_> | even basic %) |
| 23:30 | <jcranmer> | in that case, I need fast JS speed |
| 23:30 | <bga_> | ppl wants more languages |
| 23:30 | <jcranmer> | I don't care about rendering speed, that happens fast enough |
| 23:30 | <jcranmer> | what I need is to driver the renderer fast enough |
| 23:30 | <bga_> | *lisp |
| 23:31 | <gsnedders> | bga_: The thing is ultimately something is going to be the target, and is the cost of introducing a new language (which effectively it is, even if only binary bytecode) bigger than the perf benefit you'd get by introducing something with strict typing? |
| 23:31 | <jcranmer> | I'll also note that there have been active proposals to introduce static typing to JS |
| 23:32 | <bga_> | yes |
| 23:32 | <bga_> | in es6 |
| 23:32 | <gsnedders> | Nothing is really certain for Harmony (what will presumably be ES6) yet though |
| 23:32 | <jcranmer> | I thought harmony was es5 |
| 23:32 | <TabAtkins> | We're treating harmony as es5. |
| 23:32 | <gsnedders> | Harmony itself is what will follow ES5 |
| 23:33 | <gsnedders> | ES5 is really just a minor update to ES3, a stepping stone before Harmony |
| 23:33 | <gsnedders> | (Thus why it for the longest time was called ES3.1) |
| 23:33 | <bga_> | jcranmer http://wiki.ecmascript.org/doku.php?id=strawman:types |
| 23:34 | <bga_> | gsnedders you know than each language is best in own category of tasks |
| 23:35 | <bga_> | Haskell in parralell calcalations |
| 23:35 | <jcranmer> | adding new language backends introduces extremely high security risks |
| 23:35 | <bga_> | C in low level code |
| 23:35 | <TabAtkins> | jcranmer: Not necessarily. Chrome has NaCl, which you can run arbitrary languages in. |
| 23:35 | <TabAtkins> | (Because it's just running x86 bytecode.) |
| 23:35 | <TabAtkins> | It's sandboxed, though. |
| 23:36 | <jcranmer> | TabAtkins: well, Mozilla theoretically lets you run different languages |
| 23:36 | <bga_> | jcranmer CRL is absolutely safe |
| 23:36 | <jcranmer> | there's more than just the language itself |
| 23:36 | <jcranmer> | you have to do the cross-language glue |
| 23:36 | <bga_> | yes |
| 23:36 | <bga_> | .NET does it |
| 23:36 | <jcranmer> | that's where security holes can come into play |
| 23:37 | <bga_> | by desing |
| 23:37 | <jcranmer> | yes, but most people don't use .NET interfaces internally |
| 23:37 | <gsnedders> | bga_: Will MS grant a RF license for everything in .NET? |
| 23:37 | <jcranmer> | the other really big issue is compatibility |
| 23:38 | <jcranmer> | ECMAScript is supported by everybody |
| 23:38 | <jcranmer> | any other scripting language would not be |
| 23:39 | <bga_> | i guess embeding Mono to renderer is 2-3 years |
| 23:39 | <jcranmer> | that will probably never happen, I suppose |
| 23:39 | <bga_> | ie ff5 opera12 chrome11 safari6 will have it |
| 23:39 | <jcranmer> | mono is too far beyond in terms of .NET support, last I checked |
| 23:40 | <bga_> | yes |
| 23:40 | <jcranmer> | at this point |
| 23:41 | <jcranmer> | you'd need something that could realistically run on Windows, Mac OS X, Linux, and probably Android and iOS as well |
| 23:41 | <bga_> | but part of mozilla`s google`s etc can contribute mono |
| 23:41 | <bga_> | *+ team |
| 23:41 | <jcranmer> | why should they? |
| 23:41 | <TabAtkins> | bga_: Speaking completely unofficially, I doubt Google would ever touch Mono. We already spent significant resources developing NativeClient, which fills the same niche. |
| 23:42 | <bga_> | contibute to common scripting engine |
| 23:42 | <jcranmer> | why should they expend valuable effort to support implementation for features that no one is using? |
| 23:42 | <jcranmer> | bga_: they don't use the same JS engine |
| 23:42 | <gsnedders> | And have a spec for it that actually defines it (the base classes for example are unspecified) to allow other impls, and have a patent grant, etc. |
| 23:42 | <bga_> | i know |
| 23:43 | <jcranmer> | if they're not contributing to a common scripting engine now, what makes you think they would contribute to a common one later? |
| 23:43 | <jcranmer> | to a common one for another language, that is |
| 23:43 | <gsnedders> | Multiple impls drives competition, which is benefical to the market |
| 23:43 | <jcranmer> | what the market is asking for is not support for another language |
| 23:43 | <jcranmer> | they're asking for improved speed on the JS engine |
| 23:44 | <jcranmer> | you're more likely to get traction on compiling other languages to *JS* than getting browsers to support other scripting languages |
| 23:44 | <bga_> | but mozilla has python as alternative scripting language :) |
| 23:44 | <jcranmer> | not really |
| 23:44 | <jcranmer> | you have to install an extension, which is at best semi-official |
| 23:45 | <jcranmer> | in that "if PyXPCOM crashes and burns, we don't really care" |
| 23:47 | <bga_> | too bad |
| 23:48 | <bga_> | may be in future we will have multilanguage web |
| 23:49 | <jcranmer> | perhaps |
| 23:49 | <jcranmer> | but to my knowledge, it's not a feature people have been clamoring for |
| 23:49 | TabAtkins | points against to NaCl, which you can compile any language towards. It just only works in Chrome right now. |
| 23:50 | <bga_> | they want |
| 23:50 | <bga_> | but they do not talks about it |
| 23:51 | <jcranmer> | https://bugzilla.mozilla.org/show_bug.cgi?id=255942 |
| 23:51 | <bga_> | alot of %language% -> js translators says about it |
| 23:51 | <jcranmer> | 34 votes |
| 23:52 | <jcranmer> | that's a really high number, you know... |
| 23:52 | <jcranmer> | I mean, restore mng only had 600 or so votes |
| 23:53 | <jcranmer> | oh, 700 votes as of now |
| 23:53 | <bga_> | http://twitter.com/bga_/status/7221442764611585 :) |
| 23:53 | <bga_> | wait 2000 :) |
| 23:54 | <jcranmer> | supporting XInclude has even more votes |
| 23:55 | Philip` | doesn't like how NaCl seems to be using x86 as probably the worst imaginable bytecode format, just because it happens to have a trivial mapping from bytecode to machine code on the current dominant desktop platform |
| 23:56 | jcranmer | is suprised that more of these aren't WONTFIX'd |
| 23:56 | <jcranmer> | Philip`: it makes more sense to do ARM |
| 23:56 | <jcranmer> | considering that there are already a not-insignificant number of ARM emulators |
| 23:56 | <jcranmer> | on x86 |
| 23:56 | <jcranmer> | seeing as how the GBA is implemented in ARM ;-) |
| 23:57 | <jcranmer> | heck, I think someone even did a GBA emulator in JS |
| 23:57 | <gsnedders> | It's a question of how large and complex you want your bytecode to be. :) |
| 23:58 | <jcranmer> | ah, no, it's only the original GameBoy |
| 23:58 | <Philip`> | Hmm, looks like the current NaCl approach to portability is that you should compile your application three times (for x86, amd64 and ARM), which seems a bit of a step backwards compared to the current state of the web |
| 23:59 | <jcranmer> | . . . |
| 23:59 | <Philip`> | (and the future NaCl approach is to use the LLVM bytecode format instead, in which case I'm not sure how it's Native any more) |
| 23:59 | <gsnedders> | Unsurprisingly for the vendor that probably ships on more platforms than any of the other major browser vendors, we don't want to do that. |
| 23:59 | <bga_> | btw i`ll planning open source project which will translate CRL -> js |
| 23:59 | <bga_> | :) |
