code logs -> 2007 -> Mon, 22 Oct 2007< code.20071021.log - code.20071023.log >
--- Log opened Mon Oct 22 00:00:39 2007
00:50 You're now known as TheWatcher[T-2]
00:57 You're now known as TheWatcher[zZzZ]
01:15 Thaqui [~Thaqui@Nightstar-13312.jetstream.xtra.co.nz] has quit [Quit: This computer has gone to sleep]
01:36 gnolam [lenin@Nightstar-10613.8.5.253.static.se.wasadata.net] has quit [Quit: Z?]
02:04 Thaqui [~Thaqui@Nightstar-13312.jetstream.xtra.co.nz] has joined #code
02:04 mode/#code [+o Thaqui] by ChanServ
03:32 DiceBot [~Reiver@Nightstar-3001.ubs-dsl.xnet.co.nz] has joined #Code
03:32 mode/#code [+v DiceBot] by ChanServ
04:37 GeekSoldier is now known as GeekSoldier|work
06:46 McMartin [~mcmartin@Nightstar-15024.dsl.pltn13.sbcglobal.net] has quit [Quit: Moving IRC to Spiff]
06:48 McMartin [~mcmartin@Nightstar-15024.dsl.pltn13.sbcglobal.net] has joined #code
06:48 mode/#code [+o McMartin] by ChanServ
09:19 You're now known as TheWatcher
09:57 gnolam [lenin@Nightstar-10613.8.5.253.static.se.wasadata.net] has joined #Code
09:57 mode/#code [+o gnolam] by ChanServ
10:27 Thaqui [~Thaqui@Nightstar-13312.jetstream.xtra.co.nz] has quit [Quit: This computer has gone to sleep]
10:30 GeekSoldier|work [~Rob@Nightstar-5650.pools.arcor-ip.net] has quit [Ping Timeout]
10:34 MyCatSchemes [~rb6822@Nightstar-18281.cs.bris.ac.uk] has joined #code
10:34 GeekSoldier|work [~Rob@Nightstar-4056.pools.arcor-ip.net] has joined #code
10:41 Vornicus is now known as Vornicus-Latens
11:51 MyCatSchemes [~rb6822@Nightstar-18281.cs.bris.ac.uk] has quit [Quit: Swim, swim, hungry!]
12:09 Attilla [~The.Attil@194.72.70.ns-11849] has quit [Quit: <Insert Humorous and/or serious exit message here>]
13:51 Attilla [~The.Attil@194.72.70.ns-11849] has joined #code
14:01 MyCatSchemes [~rb6822@Nightstar-18573.cs.bris.ac.uk] has joined #code
15:21 MyCatSchemes [~rb6822@Nightstar-18573.cs.bris.ac.uk] has quit [Quit: Swim, swim, hungry!]
15:32 GeekSoldier|work is now known as GeekSoldier
15:48 MyCatSchemes [~rb6822@Nightstar-23335.cs.bris.ac.uk] has joined #code
16:42
< MyCatSchemes>
I'm starting to seriously hate pthreads.
16:42
< MyCatSchemes>
I've yet to ever manage to get the most ridiculously trivial things to actually -work- with pthreads.
16:43
< MyCatSchemes>
Also, debugging? No chance. :(
16:53
<@ToxicFrog>
...
16:53
<@ToxicFrog>
pthreads is easy for small stuff.
16:54
<@ToxicFrog>
And for large stuff, you just implement something more appropriate on top of it.
16:54
<@ToxicFrog>
What's giving you trouble?
16:54
<@ToxicFrog>
(debugging is a pain in the ass, though)
16:57
<@ToxicFrog>
...also, have you used any other preemptive threading systems before?
17:02
< MyCatSchemes>
Nope. I'm having trouble getting so much as circular cat working.
17:02
<@ToxicFrog>
"circular cat"?
17:03
<@ToxicFrog>
And is the problem in concept, or implementation?
17:03
< MyCatSchemes>
Four buffers, mutexes and condition variables. One thread reads data from stdin into each buffer, one by one, the other thread writes data to stdout.
17:04
< Attilla>
Circular cat is circular cat is circular cat is
17:04
< MyCatSchemes>
The writing thread locks the mutex of the buffer it's working on, if the buffer is marked empty waits on the condition variable until it's full, then fwrite()s the contents of the buffer to stdout, unlocks and moves on to the next buffer.
17:04
< MyCatSchemes>
The reading thread locks the mutex, waits on a condition variable until it's empty, fread()s into the buffer, unlocks and moves on.
17:05
<@ToxicFrog>
Starting with something simpler would, I think, be advisable.
17:05
<@ToxicFrog>
In particular, condition variables are nasty.
17:06
<@ToxicFrog>
And you don't need them for this anyways, you can do it with semaphores
17:07
< MyCatSchemes>
How? Can't see any way to do that that doesn't waste CPU time spinning.
17:07
<@ToxicFrog>
...
17:07
<@ToxicFrog>
Do you know how semaphores work?
17:08
<@ToxicFrog>
Anyways, you do it with two for each buffer, a full one and an empty one. This also means you can omit the mutexes.
17:09
< MyCatSchemes>
Y-wait. Pthreads doesn't have semaphores, it only offers mutexes.
17:10
<@ToxicFrog>
Yes it damn well does.
17:10
<@ToxicFrog>
man sem_post sem_wait
17:10
<@ToxicFrog>
Or just man -k sem_
17:11
<@ToxicFrog>
sem_overview might be a good place to start.
17:11
< MyCatSchemes>
Yow. Didn't know those were in there.
17:11
< MyCatSchemes>
I thought the only semaphore implementation in Linux was depreciated.
17:12
<@ToxicFrog>
Anyways, each buffer has two semaphores, an "empty" one and a "full" one. If it's empty, the ES is 1 and the FS and 0.
17:12
<@ToxicFrog>
The reader waits on the ES before filling a buffer, and posts the FS when it's finished; the writer waits on FS and posts ES.
17:13
<@ToxicFrog>
SYSV semaphores are deprecated, but only because they were replaced with pthreads semaphores.
17:13
< MyCatSchemes>
Ah.
17:14
< MyCatSchemes>
...pthreads semaphones aren't actually referred to anywhere in pthreads(7). :(
17:14
< MyCatSchemes>
ToxicFrog: that ensures that both threads get woken up when appropriate, right?
17:15
<@ToxicFrog>
Hmm. They're mentioned in passing in mine, but that's it. They may not actually be part of pthreads proper, but a POSIX.2 extension or something.
17:15
<@ToxicFrog>
Yes. The reader will go until it hits a full buffer, at which point it'll block on the ES until the writer finishes emptying it and posts that semaphore.
17:15
<@ToxicFrog>
Similarly, the writer will go until it hits an empty one; it'll block on the FS until the reader finishes filling it, and posts that.
17:16
< MyCatSchemes>
POSIX.1-2001, my man pages say.
17:16 * ToxicFrog shrugs
17:16
<@ToxicFrog>
Anyways, class ends, back in an hour or so. Good luck.
17:17
< MyCatSchemes>
Thank you.
17:17
< MyCatSchemes>
Wait, quickly....
17:17
< MyCatSchemes>
Do you need to worry about spurious wakeups with using semaphores like that?
17:19 You're now known as TheWatcher[afk]
17:42 * MyCatSchemes fails, tries again.
17:48
< GeekSoldier>
there's got to be a better way to do this:
17:49
< GeekSoldier>
I'm running a program in Python, but I want to be able to hit something to get a quick readout of what's going on...
17:49
< GeekSoldier>
my solution, a try: except KeyboardInterrupt block.
17:50
< GeekSoldier>
better solution: infinitely many, I am sure.
17:50
< GeekSoldier>
it's cool as long as I don't hit it in the wrong part of the loop.
17:53
< GeekSoldier>
then it just counts as a normal keyboard interrupt and breaks.
18:13
< MyCatSchemes>
Gah. That fails in all sorts of odd ways, too.
18:13 AnnoDomini [AnnoDomini@Nightstar-29106.neoplus.adsl.tpnet.pl] has quit [Ping Timeout]
18:13
< GeekSoldier>
wish I knew something of pthreads to help you. :(
18:20 AbuDhabi [AnnoDomini@Nightstar-29544.neoplus.adsl.tpnet.pl] has joined #Code
18:20 mode/#code [+o AbuDhabi] by ChanServ
18:20
< MyCatSchemes>
Still failing. Now about a thousand bytes of output get lo... ah, no wonder. No worries, then.
18:25
<@ToxicFrog>
MyCatSchemes: no, you don't need to worry about spurious wakeups
18:26
<@ToxicFrog>
I still think that if you're having trouble with threads, something complicated is not a good place to start
18:29
< MyCatSchemes>
ToxicFrog: cloning cat doesn't really seem like the most complicated starting point. :/
18:29
< MyCatSchemes>
ToxicFrog: but anyhoo, what you suggested seems to work perfectly.
18:30
<@ToxicFrog>
Has it helped you grok semaphores?
18:30 Forj [~Forj@Nightstar-2310.ue.woosh.co.nz] has joined #code
18:30 mode/#code [+o Forj] by ChanServ
18:31
< MyCatSchemes>
ToxicFrog: yes, a little. I hadn't realised you could actually do things like that with them.
18:32
< MyCatSchemes>
ToxicFrog: the only use I had known of for semaphores above mutexes was many-reader one-writer locking.
18:34
< MyCatSchemes>
BRB, b0rken speakers.
18:34 MyCatSchemes [~rb6822@Nightstar-23335.cs.bris.ac.uk] has quit [Quit: Swim, swim, hungry!]
18:36 MyCatSchemes [~rb6822@Nightstar-23457.cs.bris.ac.uk] has joined #code
18:37 * MyCatSchemes hugs ToxicFrog.
18:38 * ToxicFrog leaks acids
18:40
< MyCatSchemes>
Thank goodness for lime. So anyway.
18:40
<@AbuDhabi>
ToxicFrog is made of poison.
18:40
<@gnolam>
ToxicFrog is poison running through your veins?
18:41
<@AbuDhabi>
Not the reference I was aiming for, but yes. :P
18:41
<@ToxicFrog>
Anyways, so now you have semaphores, and mutexes are pretty easy to understand.
18:41
<@ToxicFrog>
Condition variables are goddamn nasty and I normally implement message passing before getting that far~
18:43
< MyCatSchemes>
AbuDhabi: wigu! ^^
18:43
<@AbuDhabi>
Correct.
18:45
<@ToxicFrog>
What're you planning to do next?
18:47 Forj [~Forj@Nightstar-2310.ue.woosh.co.nz] has quit [Quit: Gone]
18:48
<@ToxicFrog>
...hmm. This fitness function doesn't just need a chromosome, but the entire population.
18:48
< MyCatSchemes>
ToxicFrog: possibly nothing. I *think* that's the only thing I actually need pthreads for, for the moment.
18:49
<@ToxicFrog>
Aah.
18:49
< MyCatSchemes>
Everything else for this project I believe I can manage with not much more than fork() and exec().
18:50
<@ToxicFrog>
(I note that semaphores are all you need to implement message passing, too, although I believe parts of it are clearer when implemented using barriers)
18:51
< MyCatSchemes>
Ohhhhhh, shit. Heehee.
18:51
<@ToxicFrog>
?
18:54
< MyCatSchemes>
The idea is that I'm repeatedly fopen()ing a pipe O_RDONLY, reading its contents into buffers, and dumping the buffers into a second pipe O_WRONLY.
18:54
< MyCatSchemes>
Er, open(2)ing O_RDONLY or fopen(3)int "rb", whatever.
18:55
< MyCatSchemes>
The idea is that I should be able to use the buffers to arrange gapless audio playback.
18:55
< MyCatSchemes>
Not... working, for some reason.
18:55
<@ToxicFrog>
...as opposed to just joining the pipes, but that seems conceptually ok.
18:57
<@ToxicFrog>
In what way is it not working?
18:57
< MyCatSchemes>
ToxicFrog: yeah, but I want a hefty buffer between them, since mplayer on the "decode mp3/wma/whatever" end might take a half a second to start up.
18:58 MyCatSchemes [~rb6822@Nightstar-23457.cs.bris.ac.uk] has left #code [Gone.]
18:58 MyCatSchemes [~rb6822@Nightstar-23457.cs.bris.ac.uk] has joined #code
18:58
< MyCatSchemes>
...damn you, xchat.
18:58
<@ToxicFrog>
...and this is a problem why?
18:58
< MyCatSchemes>
Not sure. Killing mplayer on the source end part way through a song and then restarting it (with the same, or a different song) causes weird behavoir.
18:59
< MyCatSchemes>
ToxicFrog: gapless playback. Plus I'll later want to put other things (possibly an equaliser) into the pipeline.
19:00
<@ToxicFrog>
But, how does a delay of half a second at startup not render the rest gapless?
19:01
< MyCatSchemes>
ToxicFrog: because it puts a short gap between the end of one song and the start of the next.
19:01
<@ToxicFrog>
You can't just cat 1.mp3 2.mp3 3.mp3 | mplayer?
19:02
< MyCatSchemes>
It might turn out to be 1.mp3, 2.wma, 3.flv (-vo null), 4.flac...
19:03
< MyCatSchemes>
pastie.caboo.se/109781 <--- can you see any stupid mistakes in this, please? Aside from, obviously, the blatant abuse of hardcoding and global variables.
19:03
<@ToxicFrog>
Hmm ok yes that is a potential problem
19:03
< MyCatSchemes>
(Can't prepend http :// on account of channel is +U for some reason.)
19:04
<@ToxicFrog>
Ok, so as I understand it: you have one mplayer doing the decode, you have this program sitting beteen them, and you have the other doing an encode?
19:04
<@ToxicFrog>
Or is it just playing them and you have something else encoding?
19:05
<@ToxicFrog>
...actually, it has to be the latter, otherwise gaps are not an issue
19:07
< MyCatSchemes>
I have: mkfifo foo.inpipe foo.outpipe; mplayer -ao pcm -aofile foo.inpipe -nowaveheader 1.mp3 2.wma 3.flac beegees/*.ogg # etc; mplayer -rawaudio on foo.outpipe
19:07
< MyCatSchemes>
And then ./fpipe to shunt data between the two. And, yarf, later I'll be adding another stage into that for the eq, if we have enough time to implement it.
19:08 You're now known as TheWatcher
19:08
<@ToxicFrog>
Hmm. And why do you need this intermediate program, again?
19:08
<@ToxicFrog>
...also, are you getting the gaps within tracks, or between them?
19:09
<@ToxicFrog>
Are you sure that the source mplayer is itself generating gapless audio
19:13
< MyCatSchemes>
The intermediate program is going to be an equaliser, so that we can shut off absolutely everything except the bass 'n' drums. ;)
19:14
< MyCatSchemes>
"Gaps between tracks" is the problem I get when calling mplayer foo1.mp3; mplayer foo2.mp3; mplayer foo3.mp3...
19:14
< MyCatSchemes>
I don't *think* mplayer puts out any spurious output or padding on the end of each track when outputting raw pcm.
19:15
<@ToxicFrog>
So what happens if you just go mplayer -ao pcm ... | mplayer -rawaudio?
19:16
< MyCatSchemes>
Exactly the same thing as if I go mplayer foo.mp3.
19:16
<@AbuDhabi>
http://pastie.caboo.se/109784 <- This is what they require for the first project in the Microprocessor Technology laboratories. When just last semester's final exam was "add two numbers" in the same assembler. Gah.
19:16
< MyCatSchemes>
The gap is introduced at the point where mplayer foo1.mp3 terminates and mplayer foo2.mp3 hasn't started playing back.
19:17
< MyCatSchemes>
And I think I just spotted and murdered the bug in that program. *tries again*
19:18
< MyCatSchemes>
Perfect! No wonder.
19:19 * MyCatSchemes had "int cbuf = 0;" in readerroutine in the wrong scope - should've been declared just outside the for loop, instead of inside it. Ooops.
19:20
<@ToxicFrog>
Aah. Heh.
19:21
<@ToxicFrog>
I was wondering if the gap was the decoder open()ing the next file
19:22
< MyCatSchemes>
No, it's the initialisation overhead for mplayer. fork()-exec() and all of its various config files being read in.
19:22
< MyCatSchemes>
As is now, there's a full three seconds buffer at any one time between the decoding mplayer and the pcm-playing mplayer. Wheeee!
19:23 * MyCatSchemes flips it back and forth a few times, with sweet, joyful success.
19:25
< MyCatSchemes>
Also awesome is watching the time-elapsed counter on the decoding end.
19:25
< MyCatSchemes>
Always jumps by *exactly* one second at a time, since that's how I sized the buffers. :)
19:26
< MyCatSchemes>
Also, thank Algol-60 for lexical scoping.
19:27
< MyCatSchemes>
I cannot even imagine how much harder that bug could've bitten me in a dynamically scoped environment, heh. :)
19:49 GeekSoldier is now known as GeekSoldier|bed
19:52
< MyCatSchemes>
Bwahahahahha, Numa Numa.
19:53
<@EvilDarkLord>
MyCatSchemes: That was a bit random. Elaborate?
19:59
< MyCatSchemes>
EvilDarkLord: my brain hurts, so I looked up the Numa Numa video on youtube.
20:00
<@EvilDarkLord>
Fair enough.
20:00
< MyCatSchemes>
Hrmn. Can I get a +v, please?
20:00 mode/#code [+v MyCatSchemes] by EvilDarkLord
20:00
<@EvilDarkLord>
Huh. I have ops. Never noticed those.
20:16
<+MyCatSchemes>
Thanks.
20:17
<+MyCatSchemes>
EvilDarkLord: yeah, default policy on most (non-drama) nightstar channels is to op anyone who's well-known and sane.
20:17 * gnolam should really ask his dad if he's found his old Algol book yet.
20:17
<+MyCatSchemes>
EvilDarkLord: AFAIK that means most channels except #s-m, #tsc and #nightstar, since those tend to be dramahives for various reasons.
20:18
<+MyCatSchemes>
EvilDarkLord: but channels like #code, where most people are regular and sane? Might as well op everyone to make /kb'ing losers a quicker process.
20:18
<+MyCatSchemes>
Contrast with freenode, where most channels have *no* overt operator presence. :)
20:19
<@EvilDarkLord>
True.
20:19 mode/#code [+o MyCatSchemes] by EvilDarkLord
20:19 mode/#code [+oooo Attilla GeekSoldier|bed Reiver Syloqs-AFH] by MyCatSchemes
20:19 mode/#code [+v MyCatVerbs] by MyCatSchemes
20:19
<@MyCatSchemes>
Heehee.
20:20
<@gnolam>
Yech. Freenode.
20:20
<@MyCatSchemes>
gnolam: it works. *shrug*
20:20
<@EvilDarkLord>
Speaking of the sanity clause... toaster.
20:20
<@Reiver>
OMG TOASTER
20:20 * Reiver dives for cover.
20:20
<@MyCatSchemes>
Not as well as here, but still. This place doesn't have the scalability constraints that freenode has.
20:20
<@gnolam>
Possibly. Doesn't help that 90% of the people who hang on Freenode are complete asshats.
20:21
<@gnolam>
s/help/excuse
20:21
<@MyCatSchemes>
gnolam: precisely that. Whereas, nightstar? zoo.nightstar.net's political boards, for example, are scary as Hell. Communists and fascists in the same discussions and not a flamewar in sight as far as the eye can see. :)
20:22
<@gnolam>
Political boards? AFAIK there's only D&E, which hasn't seen any activity in ages.
20:23
<@gnolam>
In other news, some people should be taken out and shot as soon as even they /think/ about writing a specification.
20:23 * gnolam had a 6h Meeting of Doom today.
20:24
<@gnolam>
(At least) one of those hours was about one. Single. Line. Of the specification.
20:26
<@MyCatSchemes>
gnolam: bloody Hell.
20:27
<@MyCatSchemes>
gnolam: yah, but what I'm trying to get across is that nightstar is (more or less) a big ol' gang of friends whose identities are long-standing enough that many of the usual effects of anonymity don't apply as normal.
20:27
<@MyCatSchemes>
gnolam: freenode is a gigantic community of random nobodies.
20:28
<@MyCatSchemes>
Er, s/community/horde/
20:28
<@MyCatSchemes>
What works for a small, civilised community isn't neccessarily going to work so well for gigantic hordes, y'know?
20:28 AbuDhabi is now known as AnnoDomini
20:31 MyCatSchemes [~rb6822@Nightstar-23457.cs.bris.ac.uk] has quit [Client exited]
20:52 GeekSoldier|bed [~Rob@Nightstar-4056.pools.arcor-ip.net] has quit [Ping Timeout]
21:12 Vornicus-Latens is now known as Vornicus
21:25 Otto_Flick [lenin@Nightstar-10613.8.5.253.static.se.wasadata.net] has joined #Code
21:28 gnolam [lenin@Nightstar-10613.8.5.253.static.se.wasadata.net] has quit [Ping Timeout]
21:28 gnolam [lenin@Nightstar-10613.8.5.253.static.se.wasadata.net] has joined #Code
21:29 mode/#code [+o gnolam] by ChanServ
21:31 Otto_Flick [lenin@Nightstar-10613.8.5.253.static.se.wasadata.net] has quit [Ping Timeout]
22:13 Chalcedon [~Chalcedon@Nightstar-2310.ue.woosh.co.nz] has joined #code
22:13 mode/#code [+o Chalcedon] by ChanServ
23:28 Chalcedon [~Chalcedon@Nightstar-2310.ue.woosh.co.nz] has quit [Quit: Gone]
--- Log closed Tue Oct 23 00:00:46 2007
code logs -> 2007 -> Mon, 22 Oct 2007< code.20071021.log - code.20071023.log >