00:16
<othermaciej>
I think the success of Web Audio is because it's good at serving important use cases
00:16
<othermaciej>
not just because of evangelism
00:18
<othermaciej>
and Apple is in favor mainly because it's viable on mobile devices, unlike the "do all your audio processing in JS" approach
00:18
<othermaciej>
not just because our arch-nemesis / co-engine-developer Google proposed it
00:19
<jamesr_>
roc, is the difficulty with WebAudio's node-based approach that it's hard to write all of the nodes in C++?
00:19
<jamesr_>
and we really need a second implementation of that bit?
00:19
<TabAtkins_>
I think it's that it's hard to write all of the nodes interoperably, given the current spec state.
00:19
<roc>
that is an issue, but it's not a big issue
00:19
<roc>
it's certainly solvable
00:20
<othermaciej>
all they do is math, so it should be straightforward to spec with precision, given enough effort
00:20
<roc>
like I said above, I don't think whether or not we should have a big library of built-in nodes is the sticking point
00:20
<jamesr_>
so it's about the glue?
00:20
<othermaciej>
WebKit's WebAudio node implementations are 4958 lines of C++ and IDL code
00:21
<othermaciej>
(including comments)
00:21
<jamesr_>
othermaciej, not the easiest 5k lines to write
00:21
<roc>
I'm more concerned about whether it
00:21
<jamesr_>
but it's no sqlite beast, either
00:21
<roc>
's a good idea to have 2 (or more) abstractions for real-time media processing, or just one
00:22
<othermaciej>
it would be nice for MediaStream and Web Audio's data processing to be aligned
00:22
<othermaciej>
(and Media Source)
00:22
<othermaciej>
but MediaStream as designed doesn't really allow significant processing of media data, beyond letting you send it from point A to point B
00:23
<othermaciej>
so it's not like there's two rich interfaces to reconcile
00:23
<roc>
that's why I've proposed MediaStreams Processing
00:23
<roc>
(and implemented most of it)
00:23
<othermaciej>
MediaStreams Processing is the thing that causes there to be "2 (or more) abstractions for real-time media processing"
00:23
<roc>
no
00:24
<othermaciej>
I am not sure I understand your concern then
00:25
<othermaciej>
(or more specifically, what specifically you meant by "2 (or more) abstractions for real-time media processing")
00:26
<roc>
I shouldn't have said "processing" there
00:28
<roc>
MediaStreams and AudioNodes are two different abstractions for real-time media streams
00:28
<othermaciej>
oh, in that case I would agree that there should not be, presuming there's a reasonable way to have a unified abstraction
00:29
<roc>
and I'm assuming that in the future we'll want to process video streams, and other kinds of data such as Kinect-style depth buffers
00:29
<zewt>
(that's the sort of thing languages like GLSL are good for...)
00:29
<roc>
I think, of course, that MediaStreams Processing is a reasonable way to have a unified abstraction
00:29
<othermaciej>
that's possible, but audio processing has some specialized requirements
00:30
<othermaciej>
you need to make sure that things aren't so abstracted that it gets in the way of doing the required audio-specific things
00:31
<roc>
yes, and I think I've demonstrated that. At least, that doesn't seem to be the issue right now.
00:32
<MikeSmith>
othermaciej: about the group description, lemme know what you want and I will change it right now
00:33
<othermaciej>
MikeSmith: s/living standard/living specification/
00:33
<MikeSmith>
OK, gimme a minute
00:34
<MikeSmith>
about the Contact Group link, I have yet to find where that is stored in the DB, so not sure if I can change it. I think unfortunately it might be generated/constructed just by concatenating public- with the CG name ("whatwg"). I will find out tomorrow
00:36
<othermaciej>
roc: with just your API as proposed, I don't think it would be feasible to run equivalents of the various Web Audio demos on an iPad
00:36
<othermaciej>
roc: I think your spec takes the position that processing audio with JS in a Worker is the core feature, and specialized native code audio processing modules are fluff, whereas I would take the converse view
00:36
<MikeSmith>
othermaciej, OK, description now changed at least
00:36
<roc>
that may well be true, so I agree we should have a library of native effects
00:36
<othermaciej>
MikeSmith: thanks!
00:37
<othermaciej>
roc: of course, I say that based on just a quick read-through and from the position of not being an expert on media or audio
00:37
<othermaciej>
so apply liberal dose of salt
00:40
<roc>
I don't think I have ever described "native code audio processing" as "fluff" or anything like that. I have some concerns about trying to support every effect anyone would ever want as a built-in primitive, so I have always felt strongly that first-class JS support is important, and because that's strictly more demanding on the infrastructure than native effects, that's what I focused on
00:41
<othermaciej>
you can do a lot of useful audio effects efficiently through composition of suitable parameterized primitives
00:41
<othermaciej>
a lot of pro audio software adopts that model
00:41
<roc>
yes. (you may lose your efficiency advantage over doing it directly in JS though)
00:41
<othermaciej>
as do a lot of platform-native audio apis
00:42
<roc>
anyway, this is not the contentious part. This is easy to compromise on. We can all agree (and I think do all agree) that there should be first-class JS support and a native effects library that's as big as it needs to be. And even if it gets bigger than it needs to be, that's not a big deal.
00:43
<othermaciej>
so what is the contentious part, if any?
00:43
<roc>
Whether to build on MediaStreams or have a separate AudioNode/AudioContext abstraction
00:44
<othermaciej>
an AudioNode doesn't really represent the same thing as a stream
00:44
<othermaciej>
it's a unit with inputs and outputs
00:44
<roc>
and related to that, some questions exactly what semantics of the streams should be supported.
00:44
<othermaciej>
it might be logical to be able to get a MediaStream into or out of one
00:44
<roc>
a ProcessedMediaStream is a MediaStream with inputs
00:44
<othermaciej>
that seems like it would be simple
00:45
<othermaciej>
is it actually practically useful to represent an effects unit as a stream?
00:46
<othermaciej>
certainly in signal processing terms a signal and a system are not the same thing (though in some cases a system can be sufficiently defined by its impulse response)
00:47
<roc>
A specific AudioNode instance produces a stream of audio output
00:47
<othermaciej>
when I plug my guitar into a distortion pedal and the pedal into the amp, the pedal effects unit takes a signal in and sends a signal out, but it is not itself a signal
00:48
<othermaciej>
it certainly makes sense to me that an AudioNode should be able to take input as a MediaStream and send output as a MediaStream
00:48
<othermaciej>
I don't understand why it would *be* a MediaStream
00:48
<roc>
I don't see any real utility in distinguishing an AudioNode from its output, as separate objects
00:48
<roc>
in the graph
00:48
<othermaciej>
it may be that connecting them directly can be more efficient than producing output in a form consumable by non-AudioNodes
00:49
<othermaciej>
(which a MediaStream would have to be, in the general case)
00:49
<othermaciej>
and also it's a design that matches the domain
00:49
<roc>
I don't see any implementation issues there
00:51
<othermaciej>
in that a signal and a signal processor are distinct entities
00:51
<othermaciej>
I don't see how making a single object represent a signal processor and its output stream is clarifying
00:52
<othermaciej>
and if you don't make that assumption, it seems a lot easier to get Web Audio and Media Streams to play nice
00:53
<othermaciej>
all that being said, I do hope these APIs get aligned nicely and I'm not much of a domain expert, so I should probably leave the architecture here to the more informed
00:54
<zewt>
the audio APIs i've implemented simply have output nodes; some of them happen to input from other nodes, some of them input from audio files, etc. but they're all the same type of object
00:55
<roc>
I don't feel that having separate objects for signal processors and output streams is clarifying, and it's definitely more objects than are needed, which at least means overhead.
00:56
<othermaciej>
perhaps if changing the names and APIs of the various AudioNode classes is no longer feasible, then AudioNode could subclass MediaStream
00:56
<othermaciej>
(assuming that was even a good idea; don't really know the intersection between the APIs)
00:58
<othermaciej>
in general it only means one more object (the final output), assuming signal processors can be chained without reifying the signals between them
01:02
<roc>
there's also a semantic issue which is that we will probably need to add the ability to pause MediaStreams (MSP does, and there are use-cases outside of MSP too, like live but non-interactive peer-to-peer transmission), and Chris doesn't want to add that to AudioNodes
01:04
<roc>
zewt: yeah, Web Audio has AudioNodes presenting the playback of resources too, but you can see those as signal processors if you squint hard enough
03:08
<JVoracek>
05:24
<annevk>
Velmont: hey, where are you staying next week?
05:25
<annevk>
I realized I only have plane ticket...
05:27
<annevk>
MikeSmith: Bugzilla is offline again...
05:46
<zcorpan>
not specifying the list of tag names seems like a good way to introduce differences between impls
05:55
<zcorpan>
zewt: having things spoken by different persons at different times in the same cue is pretty common i think
08:45
<jgraham>
Read spec. Think "this would be much clearer if it was written as X". Reread spec. Realise it is written as X. Sigh.
08:47
<Ms2ger>
Canvas in SVG, really?
08:49
<jgraham>
Then you can implement SVG in canvas.
08:50
<jgraham>
Then you have a meme.
08:56
jgraham
wonders how to test things that are supposed to be racy
08:56
<jgraham>
One option is to allow multiple pass conditions
08:57
<jgraham>
And then have special tests where the results of the race are well controlled
08:57
<jgraham>
So, I guess it would be useful if testharness.js supported multiple pass conditions
09:09
<MikeSmith>
annevk: looks like they re-fixed the db problem and bugzilla is back up
09:09
<MikeSmith>
db is getting corrupted for some reason
09:09
<annevk>
thanks
09:10
<jgraham>
MikeSmith: Maybe if you paid it better, it wouldn't be so open to bribery
09:10
<jgraham>
Ahem
09:10
<jgraham>
Anyway what I actually wanted to say was
09:10
<MikeSmith>
heh
09:11
<jgraham>
Ms2ger: Any thoughts on multiple pass condition syntax
09:11
<jgraham>
I can think of assert_equals(foo, any(a, b, c))
09:12
<Ms2ger>
How assert_in(foo, [a, b, c])?
09:12
<Ms2ger>
s//about/
09:12
<jgraham>
Or assert_any(assert_equals, foo, a, b, c)
09:12
<Ms2ger>
Hmm
09:12
<jgraham>
Ms2ger: assert_in doesn't really work for non-assert_equals cases
09:14
<Ms2ger>
assert_any(assert_equals, foo, [a, b, c])?
09:14
<jgraham>
Yeah, I think that's better
09:17
<annevk>
MikeSmith: you staying in a hotel next week?
09:17
<MikeSmith>
yeah
09:17
<annevk>
pointer?
09:17
<Ms2ger>
Or just on the street?
09:19
<jgraham>
Set up a tent and call it "Occupy Microsoft"
09:20
<annevk>
I considered hiding in their bathroom and then finding a couch once everyone left the building, but I'm sure they have some kind of annoying security thing that'd prevent that
09:21
<MikeSmith>
Best Western Plus Mountain View Inn
09:22
<MikeSmith>
http://www.bestwesternmountainviewinn.com/
09:22
<MikeSmith>
book it through the GOogle Maps thing and it will be cheaper
09:23
<annevk>
thanks
09:23
<jgraham>
Ms2ger: Although that syntax doesn't really work if the assert isn't of the form assert_foo(actual, expected)
09:24
<MikeSmith>
http://maps.google.com/maps/place?q=Best+Western+Plus+Mountain+View+Inn&hl=en&cid=8890994076595056279
09:24
<annevk>
btw, I'm in SFO 11:50AM coming Sunday
09:25
<annevk>
if anyone else is there...
09:25
<jgraham>
assert_approx_equals seems like a special case that could have a use there
09:26
<jgraham>
assert_any(assert_func, [[arg11, arg12], [arg21, arg22]], description) is getting kind of ugly
09:26
<jgraham>
especially with assert_array_equals
09:27
<jgraham>
assert_any(assert_array_equals, actual, [[[1,2,3]], [[4,5,6]]])
09:33
<Ms2ger>
jgraham, assert_any(assert_approx_equals, actual, [1, 2, 3], 0.1)?
09:35
<jgraham>
Ms2ger: With the possibility to s/0.1/[0.1, 0.1, 0.2]/ ?
09:36
<Ms2ger>
When I see the use case :)
09:38
<jgraham>
Well I don't have one :) The only problem with not allowing that at first would be an assertion with a third argument that is an array
09:39
<jgraham>
Also this whole idea doesn't work for assert_throws, but I think I don't want it to
09:39
<MikeSmith>
annevk: me an plh not arriving til Monday evening
09:40
<MikeSmith>
annevk: will you have a Notifications meeting on Monday?
09:57
<annevk>
MikeSmith: could not get a place there
09:57
<annevk>
staying other side of town now
09:58
<annevk>
crappy hotel situation is crappy
09:58
<MikeSmith>
annevk: you got a car?
09:58
<annevk>
mine should be walking distance
09:59
<annevk>
"Quality Inn & Suites-Mountain View"
09:59
<annevk>
but you never know with all the highways
10:03
<MikeSmith>
annevk: yeah
10:03
<MikeSmith>
it can look like a few hundred meters on map but take you 40 minutes to walk it because of that
10:06
<annevk>
a review for a hotel next door said it was doable; guess I'll find out or otherwise find out if they have some kind of shuttle or just take a taxi each day ...
10:06
<annevk>
or arrange someone to pick me up
10:07
<annevk>
which reminds me, I have to get to Cupertino on Monday...
10:07
<annevk>
MikeSmith: are you going to that?
10:07
<MikeSmith>
to what?
10:07
<MikeSmith>
Notifications meeting?
10:07
<annevk>
yeah
10:07
<MikeSmith>
nope
10:07
<annevk>
k
10:07
<MikeSmith>
won't get there in time
10:08
<MikeSmith>
I think we land at 19:30 or something
10:08
<annevk>
oh that's late
10:08
<MikeSmith>
other days, plh can probably give you a ride if you want to instead of walking
10:12
<annevk>
ooh, my hotel is next to Nasa
10:12
<Ms2ger>
<glazou> there is no css wg
10:12
<Ms2ger>
[Actual quote]
10:14
<annevk>
but there is a CSS WG?
10:14
<annevk>
more context?
10:15
<Ms2ger>
http://krijnhoetmer.nl/irc-logs/developers/20120427#l-1090
10:17
<jgraham>
Nothing like a little light blame deflecting to start the day
10:17
<annevk>
karlcow often brings up the same point about the W3C
10:17
<annevk>
in both cases though, browser vendors did put their concerns and problems forward, they were just dismissed
10:18
<annevk>
and if you dismiss a problem it'll be solved elsewhere
10:18
<MikeSmith>
every groups has leaders
10:19
<MikeSmith>
the people who are responsible for addressing the problems
10:19
<annevk>
(it'll also be solved elsewhere if you acknowledge the problem and take no appropriate action)
10:19
<karlcow>
hmm too sleepy still to enter into the rationales ☺ about social groups. just woke up
10:20
<annevk>
we need a bot that gives people coffee
10:20
<annevk>
or tea, I don't drink coffee
10:20
Ms2ger
passes karlcow the coffee
10:20
Ms2ger
passes annevk a beer
10:21
<jgraham>
WGs can be echo chambers. This affects the perception of what the most critical problems are
10:22
<MikeSmith>
cough TC39 cough
10:22
<annevk>
jgraham: heh yeah, CSS focused on print/text for years when everyone was having layout problems
10:22
<jgraham>
Aslo CSS WG hasn't really considered shipping to be a critical problem
10:23
<annevk>
in a way, but in a way shipping and process dominates every discussion
10:23
<jgraham>
Right, but not, afaict, in a "how can we make this much much faster?" way
10:24
<jgraham>
Perhaps I am wrong, but it feels like the tendency is to go in the "how can we add process and delay shipping" way
10:25
<jgraham>
(I suppose this is changing now)
10:26
<annevk>
dunno if it's changing, everything is now split over several drafts instead
10:26
<annevk>
if a feature has some kind of issue it's moved to another draft, but I've no idea who makes sure the whole thing still makes sense
10:27
<annevk>
probably nobody
10:44
<annevk>
MikeSmith: btw, ij said you might know about archiving whatwg⊙wo on lists.w3.org
10:44
<MikeSmith>
yeah, I know something
10:44
<MikeSmith>
I need to re-start that discussion with others
10:45
<annevk>
kk
10:45
<MikeSmith>
it seems like everything thinks it's a good idea, I just need to follow up on it
10:46
<zcorpan>
you discuss it with things?
10:46
<zcorpan>
i guess that's a good way to do it
10:47
<jgraham>
First you ask your cat, then you ask your beer
10:47
<jgraham>
Then that is everything
10:48
<MikeSmith>
I meant we need to everythink things
10:48
<MikeSmith>
that's my new motto
10:50
<MikeSmith>
as T.S. Eliot used it in the last line of The Wasteland
10:50
<karlcow>
"everythink things"
10:50
<MikeSmith>
"Everythanks. Everythanks. Peace out."
10:58
<jgraham>
Hmm, so if I have <script src="data:text/html,document.write('foo')"></script>[rest of file] pretending that data URLs take finite time to fetch, is it now racy-by-default if foo is ever inserted (and where)?
10:59
<jgraham>
Uh, that script should be inserted by a DOM method
11:00
<jgraham>
If it's parser-insered, it's not racy
11:00
<hasather>
jgraham: is that CORE-32270?
11:01
<jgraham>
hasather: That's not the case I had in mind
11:01
<hasather>
jgraham: ok
11:02
<jgraham>
I am looking at some of hallvord's script scheduling tests and reworking them to be spec compliant
11:02
<jgraham>
And eventually adding all the new tests needed to cover all the extra complexity people wanted here
11:03
<zcorpan>
data:text/html,<script>var s=document.createElement('script');s.src="data:text/html,document.write('foo')"; document.head.appendChild(s);</script>[rest of file]
11:03
<zcorpan>
?
11:03
<jgraham>
Yes
11:03
<zcorpan>
i get foo in opera but not in gecko or chrome
11:03
<jgraham>
Where we engage in the fiction that the data URL is actually the equivalent HTTP url
11:04
<jgraham>
Right
11:04
<jgraham>
Opera isn't very spec-compliant here
11:05
<jgraham>
Per-spec, I think that foo is written if the insertion point is defined at the time that the script is run
11:05
<zcorpan>
i guess you need to write a test that delays the external script and another that delays the outer document
11:05
<jgraham>
Indeed
11:06
<zcorpan>
and the script runs when it is fetched without blocking the parser
11:06
<zcorpan>
does it delay the load event?
11:07
<jgraham>
Yes, but the insertion point is already undefined by then
11:07
<zcorpan>
ah
11:07
<jgraham>
See "The End"
11:07
<jgraham>
(my favourite spec subsection)
11:08
<jgraham>
I was kind of hoping I could just fix up the simple case to have multiple possible pass conditions and then come back and write all the delayed-resource tests at the end
11:08
<jgraham>
I guess I still can
11:09
<zcorpan>
i think i'd skip writing the "simple" test with multiple pass conditions
11:09
<zcorpan>
delaying resources is easy enough :)
11:09
<jgraham>
Well that test already exists, it justhas the wrong pass condition(s)
11:09
<zcorpan>
ah
11:10
<zcorpan>
carry on :)
11:10
<jgraham>
And keep calm?
11:11
<zcorpan>
depends on the circumstances
11:14
<Velmont>
07:26 < annevk> Velmont: hey, where are you staying next week?
11:14
<Velmont>
Uhh. Dunno! Actually. Should fix that.
11:22
<annevk>
Velmont: I'm staying at "Quality Inn & Suites-Mountain View" prolly not so much quality given it's in the name
11:24
<gsnedders>
hsivonen: Before you start mass-buying TVs to test big-endian WebGL, none of them do, contrary to what I said before.
11:26
<Ms2ger>
Hmm
11:27
<Velmont>
annevk: OK. Goodie. I'll look at it then :P I did not see it because my search was for cheapest.
11:27
Ms2ger
dumps a couple of tvs on gsnedders's doorstep
11:27
<gsnedders>
Ms2ger: Not sure I have space in my flat :P
11:28
<zcorpan>
gsnedders: hang it in the ceiling
11:29
<Ms2ger>
*In* the ceiling?
11:29
<Ms2ger>
For ceiling cat?
11:29
<zcorpan>
yeah
11:30
zcorpan
should work a bit on his swenglish
11:43
<gsnedders>
It's so sad when major sites refuse to support non-WebKit mobile browsers :(
11:44
<smaug____>
it is
11:44
<smaug____>
gsnedders: btw, Opera doesn't have a browser for N9 ?
11:44
smaug____
would like to replace the crappy default browser
11:45
<jgraham>
http://dev.opera.com/articles/view/a-treat-for-nokia-n9-users-opera-mobile-labs-11-5/
11:46
<jgraham>
It's not a real release
11:46
<jgraham>
But it exists
11:46
<smaug____>
oh,
11:47
smaug____
tries
11:50
<Velmont>
smaug____: It's not A+...
11:50
<Velmont>
Sadly. -- We should get the native keyboard working.
11:51
<Velmont>
But other than that it works very well, and I use it on my N9.
11:51
<smaug____>
crashed :(
11:52
<smaug____>
but the UI looks better than in the default
11:52
<smaug____>
panning is a bit slow
11:52
<Velmont>
Oh, I never got it to crash.
11:52
<smaug____>
but I'll play around with it
11:53
<smaug____>
jgraham: thanks
11:54
<hsivonen>
gsnedders: none of them are big-endian or none support WebGL?
11:55
<gsnedders>
hsivonen: None are both big-endian *and* support WebGL
11:55
<Philip`>
Do they lack WebGL support because they are big-endian, or is that just a coincidence?
11:56
<hsivonen>
just what I was about to ask
11:56
<gsnedders>
Philip`: Coincidence.
11:57
<hsivonen>
were the TVs Opera demoed WebGL on little-endian or did they end up shipping without the demoed feature?
11:59
<gsnedders>
hsivonen: LE
11:59
<hsivonen>
hmm. Opera uses .tar.xz. I haven't seen that before.
11:59
<hsivonen>
gsnedders: ok
11:59
<gsnedders>
hsivonen: Almost all the TVs we ship on are LE to start with.
11:59
<hsivonen>
is this .xz a new thing or have I been living under a rock?
12:00
<Philip`>
hsivonen: It's not that uncommon - http://ftp.gnu.org/gnu/libc/ has some since two years ago
12:00
<Philip`>
hsivonen: Modern versions of tar will automatically decompress it (via 'tar xJf foo.tar.xz')
12:01
<hsivonen>
Philip`: ok.
12:02
<charlvn>
http://en.wikipedia.org/wiki/Xz
12:02
<charlvn>
i have to be honest, i have never encountered this myself yet either
12:02
<Philip`>
(It's the same compression algorithm 7-Zip uses)
12:02
<Philip`>
(or near enough)
12:04
<charlvn>
ah yes, that makes sense
12:05
<charlvn>
http://en.wikipedia.org/wiki/Lempel%E2%80%93Ziv%E2%80%93Markov_chain_algorithm
12:05
<charlvn>
.xz uses the LZMA2 algorithm
12:06
<charlvn>
it offers very good compression - i know it from 7z
12:07
<charlvn>
ubuntu offers a package: http://packages.ubuntu.com/precise/xz-utils
12:09
<Philip`>
The latest glibc looks like half the size as .xz vs .gz, so it can make a significant difference
12:12
<jgraham>
hsivonen: Am I missing something? Why is there only one load event in http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1499 ? (In gecko)
12:12
<jgraham>
(also in webkit)
12:13
<charlvn>
Philip`: that sounds typical from my experience even with the "older" 7z format
12:13
<charlvn>
it should take at least a third off from text-based documents
12:14
<charlvn>
when the content is images, that can be different of course, can't recall testing that
12:14
<hsivonen>
jgraham: shouldn't you assign a function instead of a string to .onload?
12:14
<hsivonen>
jgraham: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1500
12:15
<jgraham>
Oh that does make a difference
12:15
<jgraham>
I thought that event handler IDL attributes were magically compiled to a funcction body
12:15
<jgraham>
If they were a string
12:16
<jgraham>
And it seems that in Opera theey are!
12:16
<zcorpan>
yeah that's just a funny bug in opera
12:16
<zcorpan>
or feature...
12:16
<Ms2ger>
A test!
12:17
<jgraham>
Well it was enough of a feature that these tests were relying on it
12:17
jgraham
removes that
12:22
<Philip`>
charlvn: As another data point: Compressing data files for some game (largely DDS textures, and Ogg Vorbis audio, and various XML/JS files) got 346MB .tar.gz vs 281MB .tar.xz
12:23
<Philip`>
Since people can afford the CPU cost and memory usage nowadays, and most Linuxes support .xz about as well as .gz, there's not much value in sticking with .gz any more
12:23
<jgraham>
Is it faster/better than bz2?
12:24
<Philip`>
Both, usually
12:24
<Ms2ger>
Hmm, Opera wants to collect statistics about the features I use
12:25
<Philip`>
Ms2ger: You're weird and would pollute their data
12:26
<Ms2ger>
I said no :)
12:26
Philip`
wonders if they make any attempts to filter out people who do strange things like run test cases
12:29
<Ms2ger>
Velmont!
12:29
<Ms2ger>
How is the assert_throws thing? :)
12:31
<Philip`>
jgraham: (Oh, actually it seems at the default settings xz is several times slower to compress than bzip2, though it's also several times faster to decompress, and compresses much better)
12:33
<Philip`>
jgraham: (and "xz -0" is both faster than "bzip2 -1" and compressier than the default "bzip2 -9")
12:38
<hsivonen>
aargh. where have the gstreamer -dev packages gone in Ubuntu 12.04?
12:39
<hsivonen>
prefixed with "lib" how logical
13:11
<zewt>
zcorpan: if it's at different times, it should be different cues, since the time is different
13:13
<zcorpan>
zewt: not if the time between is short enough
13:13
<zcorpan>
zewt: spoken words are also at different times, but you don't put every word in different cues :)
13:14
<zcorpan>
e.g. "let's go!" "OK!" seems reasonable to put the same cue, for instance
13:14
<zcorpan>
s/, for instance//
13:15
<zewt>
zcorpan: it's definitely separate in my experience, and I'd put them separately even if they were speaking over each other (why would they not be?)
13:16
<zewt>
seems strange to merge separate lines of dialogue into a single cue just because they're close in time; seems inconsistent and I can't think of any point
13:18
<zcorpan>
i don't see what's strange about it
13:18
<zcorpan>
in fact webvtt has tags for this use case, if you want to style them differently
13:18
<zcorpan>
<v Bob>Wassup?
13:18
<zcorpan>
<v Alice>Nothin'
13:19
<zewt>
that would be a very poorly-timed caption
13:19
<zcorpan>
i see this all the time with swedish subtitles
13:20
<zewt>
maybe swedish subtitles are bad? heh
13:20
<zewt>
can't recall ever seeing it myself
13:20
<zcorpan>
i could run a grep on the srt data to find cues that start with a dash
13:21
<zewt>
dashes in subtitles? sounding even worse :)
13:23
<thiessenp>
Can anyone point me to a great PDF or offline reference that is not as dense as the ECMAScript documentation? I often use the MDC JS reference but it would be nice to have an offline ref as well.
13:23
<zewt>
"great PDF" is a peculiar turn of phrase
13:32
<zewt>
awesome, now somebody's posting with a name that shows up as "w3c" in gmail
13:33
<Ms2ger>
Use thunderbird ;)
13:33
<zewt>
"this pit of snakes sucks, I need to move into a live volcano" D:
13:33
<Ms2ger>
:D
13:36
<zewt>
cool, somebody else at moz decided to bang his head against the typed array endianness thing
13:36
zewt
*peanuts*
13:37
<Ms2ger>
He expects push-back ;)
13:39
<zcorpan>
zewt: grep -aPhrB2 "^\s*-\s*[^\s\-]+(\r\n|\r|\n)^\s*-\s*[^\s\-]+" srt-samples > srt-dialogue.txt resulted in a 40MB file (srt-samples is 4GB)
13:40
<zcorpan>
zewt: http://simon.html5.org/dump/srt-dialogue.txt.zip
13:47
<zewt>
zcorpan: at a quick look these look like *really* bad subtitles
13:48
<zewt>
captions should appear timed to the dialogue they correspond to; these will appear earlier, out of sync, breaking the intuitive connection between them
13:50
<zewt>
afk, off to work
14:30
<karlcow>
https://twitter.com/#!/masinter/status/195880829946314753
15:32
<kennyluck>
i don't think the prefix problem can be solved anywhere.
15:39
<Hixie>
MikeSmith: my plan is to update the "is this html5" section in a few weeks once we have an editor for the rec spec
15:39
<Hixie>
MikeSmith: i'm leaving it until then to avoid churn
15:39
<Hixie>
MikeSmith: i've saved your suggestions though
15:39
<MikeSmith>
thanks man
15:39
<MikeSmith>
that sounds like a reasonable plan
15:50
<Ms2ger>
A rec spec?
16:11
<dglazkov>
good morning, Whatwg!
16:15
<Ms2ger>
Bonsoir
17:33
<JVoracek>
17:38
<rniwa>
AryehGregor: yt?
17:51
<jgraham>
A good clue that you don't have a cognet argument: you find yourself making arguments of the form "Y would be bad, therefore X is bad" when there is no explicit or implicit relationship between X and Y
17:52
<Ms2ger>
Godwin
17:52
<jgraham>
er cognizant
18:01
<Philip`>
jgraham: Surely you meant cogent?
18:02
<Philip`>
That seems much closer in Levenshtein distance, and also seems to make more sense in the sentence
18:14
<jgraham>
I think I meant "cognizant argument", in the sense of "an argument that you had fully thought through", but though cognet. And then misspelt it.
18:14
<jgraham>
*thought
18:15
<jgraham>
Perhaps that is an abuse of the word
18:25
<MikeSmith>
cognizant argument rings true to me
18:27
<MikeSmith>
though it seems far more common for it to be used in the pattern "be cognizant of" <something>
18:29
<Philip`>
The arbiter of truth (Google) says "cognizant argument" scores 4,090 on the correctEnglishometer while "cogent argument" scores 265,000, which is a clear victory
18:30
arunranga
mumbles something about cognizant semantics.
18:30
Philip`
would tend to interpret cognizant as meaning merely "aware", not "fully thought through"
18:31
<Philip`>
(and it's weird to say that an argument is aware of anything)
18:32
<TabAtkins_>
Yeah, I'm thinking "cognizant" isn't the word you want here.
18:32
<arunranga>
zewt, ping
21:40
<gsnedders>
So if I'm right, the easiest way to get big-endian WebGL is run Linux on a PPC Mac using Nouveau 3D?
22:12
<Hixie>
heycam|away: there's no way to give an argument list of the form (arg1, [arg2, arg3, [arg4]]) right?
22:12
<Hixie>
where square brackets denote optional segments
22:12
<Hixie>
as in the equivalent of an overload list of (arg1), (arg1, arg2, arg3), (arg1, arg2, arg3, arg4)
22:13
<Hixie>
heycam|away: the reason i ask is that it'd be nice to be able to give defaults to arg2 and arg3 in a case such as this
22:13
<Hixie>
so that i don't have to cover the case of them being omitted in prose
22:13
<TabAtkins_>
What's the specific reason why (arg1, arg2) isn't allowed?
22:14
<Hixie>
args 2 and 3 are typically an x,y coordinate pair, or start,end index pair
22:15
<TabAtkins_>
Ah.
22:15
<TabAtkins_>
Most computer languages are annoying due to their inability to easily represent multi-part data like that.
22:16
<TabAtkins_>
I alwasy appreciate CSS when I design a function that just takes a <position> or something. ^_^
22:16
<Hixie>
yeah
22:36
<zewt>
well, arrays are usually fine for that
22:36
<zewt>
python has tuples, but they're really little more than an optimization of arrays
22:41
<Hixie>
sane languages have structs or records
22:41
<Hixie>
similar to webidl dicts
22:44
<zewt>
well, every high-level language has a native dictionary/mapping type
22:48
<Hixie>
i meant something with declared fields
22:48
<Hixie>
not like perl hashes or JS objects
22:48
<Hixie>
i guess i'm really talking about typed vs untyped
22:48
Hixie
misses strong typing
22:48
<zewt>
those are pretty out of place in dynamically-typed languages
22:49
<Hixie>
right
22:54
<TabAtkins_>
If it wasn't for the fact that all the canvas APIs already accept their x,y pairs as separate arguments, I'd argue that you should accept a 2-array.
22:54
<TabAtkins_>
foo(bar, [x,y], baz)
22:54
<TabAtkins_>
The syntax is lightweight in JS, and more understandable.
22:56
<Hixie>
is there away to define default values for optional arrays?
22:56
<Hixie>
cause if not, my original question stands :-)
22:57
<TabAtkins_>
In IDL? I dunno.