--- Log for 25.04.105 Server: brown.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 5 days and 15 hours ago 00.00.02 # i can't leave stuff unfinished 00.00.03 # it haunts me 00.00.09 # :) 00.01.15 # meh 00.01.35 # amiconn: take a break? 00.01.45 Quit noclue2 (Read error: 60 (Operation timed out)) 00.02.23 Join noclue2 [0] (noclue2@24.177.161.77.up.mi.chartermi.net) 00.05.52 # but no, the odds of me doing the gnuboy asm core are slim anyway, once i'm done with codecs, i'd probably like to move on to dsp stuff 00.05.56 # like eqs and stuff 00.06.02 # * HCl nods 00.06.36 # my dreams of transforming my h120 to a portable vocoder must also see fulfilment :P 00.07.53 # ambitious 00.08.22 Quit keith ("Leaving") 00.08.29 # not really, i don't think it should be too hard 00.08.35 # vocoder? 00.08.37 # whats that? 00.08.56 # it makes you speak like darth vader :P 00.08.59 # those boxes that make you sound like a friggin robot ;) 00.09.08 # ah. right. 00.09.13 # to use on phones 00.09.16 # when blackmailing people 00.09.22 # nah, not really, just because it sounds cool, heh 00.09.22 # right preglow ? XD 00.09.31 # it's better for scaring people 00.10.08 Quit _n2_ (Read error: 60 (Operation timed out)) 00.11.41 # HCl: http://www.rockbox.org/mail/archive/rockbox-archive-2005-04/0190.shtml 00.15.15 # rasher: awake? 00.16.54 # just 00.16.55 Quit t0mas ("goodnight") 00.20.36 # preglow: replied 00.22.08 # * HCl wonders why he typed just o.o. 00.22.53 # heh 00.23.12 *** Saving seen data "./dancer.seen" 00.24.37 # hm 00.24.46 # maybe i should've signed my email with my name XD 00.24.49 # ah well. 00.26.03 # i think he gets it 00.26.39 # i order my collection like \artist - album\, and no artist\album, if someone plans on making stats ;) 00.26.46 # either the mailinglist is slow or mutt is slow with checking email.. 00.27.25 # CoCoLUS: yea, eventually we should make it some form of regex, really *forces a smile* 00.27.54 # i used to have them ordered artist - album myself 00.28.05 # till it became much more practical to put them artist/album 00.28.45 # HCl: it is slow 00.28.52 # sending mail via smtp does take a while 00.28.55 # it's a very slow protocol 00.29.02 # mk 00.29.28 # >. darnit 00.29.38 # bugs landing on my hand in the dark scaring me 00.29.46 # whats that thing doing here anyways 00.30.16 # think i'll indulge in one hour of rockbox now 00.30.43 # ganbatte 00.31.08 # aiii 00.31.50 # ? XD 00.31.53 # haha 00.31.55 # i think you forgot an h 00.31.57 # enthusiastic 'hai' 00.32.00 Join _n2_ [0] (noclue2@24.177.161.77.up.mi.chartermi.net) 00.32.05 # otherwise you just yelled out "lovvveee! 00.32.05 # XD 00.32.27 # was thinking of edo out of cowboy bebop 00.32.31 # she always does that 00.32.33 # and in rocks 00.32.33 # haha 00.32.40 # in, it, bleh 00.32.46 Nick _n2_ is now known as ehntoo (noclue2@24.177.161.77.up.mi.chartermi.net) 00.33.25 Join gromit` [0] (~gromit`@ras75-5-82-234-244-69.fbx.proxad.net) 00.33.58 # :P 00.35.07 Join _n2_ [0] (noclue2@24.177.161.77.up.mi.chartermi.net) 00.35.52 # CoCoLUS: still, wouldn't you think "artist - album" is better than "" ? 00.36.17 # the problem with is that every song without a tag gets stuck into one album named "" 00.36.21 # i order stuff like genre/artist/album 00.36.32 # unless i've just got one album, then it's genre/artist - album 00.36.35 # when you can easily split them into directories 00.36.35 # :> 00.36.51 Quit ehntoo (Nick collision from services.) 00.36.55 Nick _n2_ is now known as ehntoo (noclue2@24.177.161.77.up.mi.chartermi.net) 00.37.11 # preglow: same, pretty much. without the genre bit 00.37.47 # that's how i do it on the mp3 player, at least, to minimize scrolling 00.37.52 # i've got no genre on my 'puter 00.38.24 Quit asdsd_ (Read error: 104 (Connection reset by peer)) 00.44.50 Join asdsd_ [0] (asdsd@h-67-100-25-21.miatflad.dynamic.covad.net) 00.48.49 Quit asdsd_ (Client Quit) 00.48.50 Quit noclue2 (Read error: 110 (Connection timed out)) 00.53.57 Join asdsd_ [0] (asdsd@h-67-100-31-50.miatflad.dynamic.covad.net) 01.18.03 # * HCl guesses he'll go sleep 01.19.55 # * preglow still has ten minutes left of rockbox! 01.26.55 # go go go go go! 01.27.32 # yeaaaaa 01.29.06 # there 01.29.11 # think i'll finish it tomorrow 01.29.20 # now, if it'd only work... 01.29.24 # that'd be so very great 01.30.11 # we pray for you:) 01.36.20 Quit TCK (Read error: 110 (Connection timed out)) 01.36.21 Quit MoosCamaro (Read error: 104 (Connection reset by peer)) 01.36.39 Join MoosCamaro [0] (MoosCamaro@m214.net81-66-158.noos.fr) 01.38.22 # * amiconn has a suspicion 01.38.25 Quit cYmen ("zZz") 01.39.25 # ? 01.42.50 # it's time to bed 01.43.04 # 1:43AM here in Paris 01.43.24 Join noclue2 [0] (noclue2@24.177.161.77.up.mi.chartermi.net) 01.43.31 # good night all 01.44.22 Part MoosCamaro 01.44.51 # grr, %$作, you won't belive that... 01.45.45 # yeehah! touchdown! :-) 01.46.46 Join _ferenczy [0] (ferenczy@a3brn-104.dialup.vol.cz) 01.46.53 # The Ondio reads the 2 GB card :) 01.48.34 # Still Really Hacky Code (tm), but at least I'll sleep well... 01.50.30 # :) 01.50.30 # yay. 01.50.43 # * HCl goes to sleep 01.51.20 # Now for the reason: Would you expect that that default read block size is different from the hardware block size? 01.51.54 # hardware block size is 1024, but the default read block size is 512... 01.53.02 # heh. 01.53.22 # i'm very happy i don't have to deal with stuff like that 01.53.23 # heh 01.53.25 # sounds a bit like the database code, having to change code all around the file to alter sizes. 01.54.14 # preglow: Imho it's similarly lowlevel as your emac (i)(m)dct stuff, and I am happy I don't have to deal with such stuff 01.54.34 # I'm good at bit manipulation, but bad at that kind of mathematics 01.54.39 # well, yes, really, it all boils down to what floats your boat, i guess 01.54.43 # * HCl is glad that the database is fairly easy :P 01.54.47 # gnight 01.54.53 # night 01.54.53 # nitey 01.55.52 # what i'm doing now is more or less direct translation of arm code 01.58.13 # Sounds like tedious work 01.58.43 # sure is 01.58.53 # I remember reverse engineering the Ondio MMC part. Reading several pages of disassemblies was no fun 01.59.00 # but i don't think i can get this routine as tightly down as the guy who wrote the arm code already has got it 01.59.32 # heh, at least this code is commented 01.59.34 # ..even though SH1 asm is fairly simple 01.59.41 # how many registers has it got, again? 01.59.53 # It's a straight & simply RISC machine 02.00.07 Quit ehntoo (Read error: 110 (Connection timed out)) 02.00.08 # 16 registers 02.00.50 # plus a special MAC register, which is 40 bits 02.00.57 # hmm 02.01.05 # (not used in any code I've seen so far) 02.01.08 # would be fun to try using it for something ;) 02.01.22 # coldfire macs are also 40 bit wide 02.01.30 # yup... I think it might be possible to speed up jpeg loading 02.01.31 # well, 48, actually, but you seldom use more than 32 anyway 02.01.57 # The bad thing is that the hardware multiplier is only 16x16->32 bit 02.02.07 # doesn't matter much for jpeg 02.02.12 # i think the coefs are 16 bits anyway 02.02.21 # So the MAC instruction does 16x16+42->42 02.02.27 # yup 02.02.32 # more then ample for lots of stuff 02.02.44 # you can choose to "clamp" the result to 32 bits 02.02.59 # the block dct in jpeg should be pretty mac-ifiable 02.03.14 # If I only knew how.... 02.03.55 # Plus, I have the impression that the huffman decode needs more time than the dct 02.04.42 Quit _ferenczy () 02.05.10 # probably 02.05.11 # hmm 02.05.22 # the dct you use is one of those decomposed types 02.05.28 # with tons of butterflies instead of accumulates 02.05.33 Part Yono 02.06.12 # libmad also has one of those, i decided to ignore it on the grounds that a cpu with a fast mac instruction probably does it faster using that 02.07.05 # Yes, probably. I googled around a bit for info about jpeg & dct 02.09.23 # Still, I don't think I can write that kind of stuff, let alone write it in asm 02.10.54 # i'm pretty sure you can, having been told the basics 02.11.16 # getting the data out of the accumulator, is that a slow business?= 02.11.51 # If you're only interested in the lower 32 bits, it's a simple mov-like instruction (1 clk) 02.12.23 # they'll do nicely 02.12.30 # all jpeg coefs fit in 16 bits 02.13.00 # The SH1 MAC is probably much less flexible than the coldfire EMAC. There is no fractional mode, and the accumulate operation is always add 02.13.40 # ..and no parallel move etc 02.13.53 # ahh, it's always add 02.13.59 # that's a bummer 02.14.10 # It is? 02.14.40 # yeah, like i said, there are a lot of butterflies (c = a + b; d = a - b) 02.15.09 # not having to negate b all the time would be nice 02.15.16 # then again 02.15.21 # you wouldn't use mac for that 02.15.22 # doh 02.15.53 # well, like it is, i don't think there'd be much benefit 02.16.08 # the sh1 programmers manual is really confusing :D 02.17.04 Join _n2_ [0] (~noclue2@24.177.161.77.up.mi.chartermi.net) 02.17.15 # preglow: In what way? 02.17.34 # I think it is fairly good (but then I'm already used to it) 02.18.29 # never mind me, i found the interesting parts 02.18.35 # wow, sh-2 has a 64 bit accumulator 02.18.48 # yup 02.19.17 # oh well, the emac isn't that bad, since it's capable of saving the high bits of a 32x32->64 bit multiplication 02.19.39 # you seldom need so much precision that the low bits are important 02.20.44 Join ehntoo [0] (noclue2@24.177.161.77.up.mi.chartermi.net) 02.23.13 *** Saving seen data "./dancer.seen" 02.24.26 Quit noclue2 (Read error: 60 (Operation timed out)) 02.26.21 Quit ehntoo (Nick collision from services.) 02.26.43 Join ehntoo [0] (noclue2@24.177.161.77.up.mi.chartermi.net) 02.27.44 Quit _n2_ (Read error: 60 (Operation timed out)) 02.33.03 # has the sh1 got stuff like relative addressing? 02.33.08 # seems like arm doesn't have anything like that 02.34.10 # Depends on what you mean with relative addressing 02.34.55 # (1) (r+r) 02.35.27 # like 02.35.44 # (2)( r+offset*width), where offset is 0..15 and width is 1/2/4 depending on the access type 02.35.44 # i thought most things have that, but looks like you have to calculate it by hand on arm 02.36.23 # it also has which is a pretty cisc like construct, i guess 02.36.26 # i use it very seldom 02.36.37 # Plus, there is a "general base register" than can be used for (r + GBR) 02.37.01 # We need to keep GBR at zero in rockbox though 02.37.46 # ...because some operations are _only_ possible with that addressing mode, which we do use 02.38.36 # The worst thing with the register + offset addressing is that the offset is always positive 02.38.59 # hah 02.39.06 # what about auto-increment/decrement? 02.39.40 # that's a feature i've grown to like, i think 68k is the first arch i've coded for that has it 02.39.46 # no, avr has it as well 02.39.51 # That's implemented, but unfortunately the directions are also hardwired. Auto-increment is only possible with loads, auto-decrement only with stores 02.40.12 # sounds like risc indeed 02.40.22 # That's why my asm-optimised memset() works backward... 02.41.02 # hah 02.41.11 # why, we need a bunch of those in asm for m68k as well, i guess 02.41.32 # using movem.l for memory access is a must 02.41.43 # yup 02.41.46 # I know 02.42.14 # at least i think most memcpy/set/etc deal with enough memory that the register saving overhead is going to be worth it 02.42.30 # I also utilise an interesting effect in memcpy() 02.43.14 # The archos devices have fast page dram, so it's beneficial to stay within the page as long as possible 02.43.53 # memcpy() alternates between source & destination page (if src & dst differ more than 1024 bytes) 02.44.19 # So I optimised it to do read-read-write-write instead of read-write-read-write 02.44.39 Join ashridah [0] (ashridah@220-253-123-225.VIC.netspace.net.au) 02.44.51 # how? where do you save the extra data in between? 02.44.57 # register 02.45.49 # The loops (for both long & word alignment) copy 2 longs per iteration 02.46.05 # ahh 02.46.05 # The byte aligned loop only does one long per iteration though 02.46.35 # The source is always long aligned (after copying the head bytes) 02.46.39 # because you have to use an entire register for a byte? 02.46.45 # Nope 02.47.36 # memcpy() is somewhat tricky because you have to deal with 2 alignments, one of them you can't adjust 02.47.53 # ..and the SH can't do unaligned accesses 02.48.25 # long->long alignment is easy. Simpy read 2 long and write them to the destination 02.49.36 # long->word is somewhat trickier. (1) Read 2 longs (2) write high word of first long (3) compose low word of first long and high word of second long, and write that as a long. The SH1 has a special instruction for this extraction 02.49.45 # (4) write low word of second long 02.49.54 # hah 02.50.16 # weird instruction 02.50.20 # but useful, apparently 02.50.21 # long->byte is most tricky. (1) Read a long (2) write top byte (3) write 2 middle bytes as word (4) write low byte 02.50.56 # If I would extend this to do 2 longs at a time, there would be 2 problems 02.51.25 # (1) I would have to combine bytes from both words in a way for which there is no special instruction 02.52.14 # (2) The case would split in 2 if I would go to the max (byte/long/word/byte and byte/word/long/byte) 02.52.43 # Btw, the weird instruction is called xtrct 02.53.16 # guess they anticipated it, can't see much other use for it 02.53.23 # some fixed point applications, perhaps 02.53.27 # it's a cheap two register shift 02.53.27 # yup 02.54.02 # Useful for 32 bit fixed point with 16 bit fractional part 02.54.18 # Exactly the kind of shift necessary after a multiplication 02.55.00 # exactly 02.55.32 # so it has a 32x32->64 bit mul? 02.55.48 # Unfortunately not 02.55.53 # 16x16->32 02.56.33 # I also tried extending this memcpy() concept to do 4 longs per iteration, but that wasn't worth it. Only a few percent speedup for large blocks, at the expense of slower operation for short blocks 02.56.35 # then how does a fixed point result ever end up in two registers? 02.57.02 # The only case where this may happen is the MAC instruction 02.57.23 # (but you first need to fetch the 2 registers from the mac registers) 02.58.21 # ok 03.06.04 # but i think i'll call it a night 03.06.07 # see you later 03.06.29 Quit preglow ("-") 04.05.51 Join QT_ [0] (as@area51.users.madwifi) 04.17.31 Quit QT (Read error: 110 (Connection timed out)) 04.20.18 Quit XShocK (" HydraIRC -> http://www.hydrairc.com <- IRC for those that like to be different") 04.23.15 *** Saving seen data "./dancer.seen" 04.31.18 Quit Stryke` (Read error: 54 (Connection reset by peer)) 05.20.36 Quit Rick (Read error: 104 (Connection reset by peer)) 05.21.10 Join Rick [0] (rick@pool-71-108-2-79.lsanca.dsl-w.verizon.net) 05.37.51 Quit silencer_ (Read error: 110 (Connection timed out)) 05.45.01 Join StrathAFK [0] (~mike@dgvlwinas01pool0-a198.wi.tds.net) 06.03.33 Quit Strath (Read error: 110 (Connection timed out)) 06.23.19 *** Saving seen data "./dancer.seen" 06.46.04 Join LinusN [0] (~linus@labb.contactor.se) 06.56.50 Quit asdsd_ (Read error: 104 (Connection reset by peer)) 07.48.23 Quit hile ("jos taas menis") 08.10.37 # Good morning 08.23.23 *** Saving seen data "./dancer.seen" 08.29.12 # mooooooooning 08.34.09 # ew. dude. we don't need to see that end of you 08.39.17 # :-) 08.44.22 Quit edx (Read error: 110 (Connection timed out)) 08.45.16 Join Lost-ash [0] (ashridah@220-253-121-52.VIC.netspace.net.au) 08.49.33 Join Zagor [0] (foobar@h63n1fls31o265.telia.com) 08.53.27 Join Harpy [0] (7GYdEXbuEv@dsl-hkigw7wbb.dial.inet.fi) 09.07.38 Quit ashridah (Read error: 113 (No route to host)) 09.25.37 Quit Ka_ (Read error: 104 (Connection reset by peer)) 09.26.43 Join Ka_ [0] (~tkirk@pcp0010733332pcs.howard01.md.comcast.net) 09.29.38 Join bobTHC [0] (~foo@l03m-38-92.d1.club-internet.fr) 09.30.58 # hi folks ! 10.04.42 Nick Lost-ash is now known as ashridah (ashridah@220-253-121-52.VIC.netspace.net.au) 10.11.46 Join cYmen [0] (~cymen@nat-ph3-wh.rz.uni-karlsruhe.de) 10.16.20 Join edx [0] (edx@pD9522C69.dip.t-dialin.net) 10.23.27 *** Saving seen data "./dancer.seen" 10.25.09 Join B4gder [0] (~50d8ae51@labb.contactor.se) 10.26.32 # good day sirs 10.26.51 # helo B4gder 10.28.35 Join webguest90 [0] (~c31ce021@labb.contactor.se) 10.28.43 # * ashridah bounces. sort of. 10.34.27 # LinusN: I'm curious who will be #100 10.35.26 # ? 10.35.39 # ah, webguest 10.35.40 # You added contributor #99 10.35.44 # ahaaa 10.35.57 # I wonder about your last commit though 10.36.10 # No mpeg_get_last_header() for the 3507? 10.36.22 # hmmm 10.36.41 # guess i'm wrong there 10.37.08 # Plus, you forgot to bump the api version 10.37.55 # #ifdef SIMULATOR 10.37.58 # #elif CONFIG_HWCODEC != MASNONE 10.45.01 # why should i bump the api version? 10.47.35 # Erm, because the struct changes because the function is no longer included on all platforms? 10.47.46 # yesterday i declined being added to the contributer list...had i know i would be no. 100 ;) 10.48.55 # s/know/known/ 10.50.22 # amiconn: sure, but i don't think it's necessary to bump it more that once a day 10.51.21 # Doh, didn't think about that. I agree. 10.52.40 Join preglow [0] (thomj@s183a.studby.ntnu.no) 10.52.54 # i'll change the #ifdefs according to your sugestion 10.54.03 # The #ifdefs were from mpeg.c, No mpeg_get_last_header() 10.55.19 # And it seems I can't read correctly :( In fact you corrected the inclusion of this function in the right direction, just not completely... 10.56.05 # Anyway, if it compiled correctly before, the function wasn't used in plugins for non-3587 platforms 10.56.23 # almost true 10.56.34 # Almost? 10.56.38 # splitedit.c was compiled for iriver 10.56.50 # i'm fixing this as well 10.57.35 # I think that including functions in the api for a platform where they're unused is just wasting resources, but then that's my opinion... 10.58.08 # i think they should be included if the function is supported 10.58.51 # For what reason? 10.59.59 # so we don't have to revise the api when we start using the function 11.01.07 # to simplify for (3rd party) plugin writers 11.01.16 # Hmm. There are many functions which might be useful in plugins, but are not part of the api. What about these? ;-) 11.01.37 # I agree with Linus 11.01.45 # surely there are lots of functions not used by any plugin 11.02.23 # but the already exported functions should exist on all platforms that support them 11.02.59 # Hmm, okay. That policy should be documented somewhere... 11.03.45 # lots of things should be documented somewhere 11.04.22 # i don't find anything particularly odd with that policy 11.04.51 # we export functions on a "need-to-use" basis, and then we export it for all platforms that support it 11.05.59 # Okies. Need to obey that when I start working on the graphics api 11.06.13 # What is a reasonable price for a IHP-140? 11.06.23 # dwihno: New? 11.06.28 # amiconn: yup 11.06.38 # I'd say ~350 EUR 11.07.09 # (That's for germany, with 16% VAT) 11.07.17 # amiconn is an experienced H140 buyer :-) 11.07.40 # :) 11.07.48 # How many have you gotten this far, amiconn? 11.07.51 # still not H140 owner though :-) :-) 11.08.04 # is not? :) 11.09.34 # meh :( 11.10.54 # * preglow strokes his h120 11.12.11 # Bagder: 'feature requests', 'bug reports' and 'patches' are still broken 11.12.12 # Is a 40 gbyte model overkill? 11.12.24 # I might as well get a 20 gbyte model and replace the disk whenever it wears out 11.12.33 # ok, I better investigate 11.13.36 # dwihno: in 1.8" land, that is not as easy 11.13.45 # as in 2.5" land 11.14.06 # the 40gb disk is thicker 11.14.11 # at least the current one 11.17.02 # you should buy from your current needs 11.17.14 # you can't count on getting anything bigger than a 30 gig as a replacement for a while 11.17.59 # i've managed to fill up my iriver on many an occasion. usually using it to store large chunks of non-music data, mind youi 11.18.47 # LinusN: The new bmp reader adds 2 warnings to the gmini build because it doesn't obey the long policy 11.18.55 # ouch 11.19.05 # Line 74: int readlong(void* value) 11.19.10 # should of course be 11.19.12 # hehe 11.19.13 # long readlong(void* value) 11.21.17 # what does the long policy dictate? use longs for 32 bit, int for stuff that doesn't need to be 32 bit? 11.21.30 # yes 11.21.42 # since the calmrisc has 16bits ints 11.21.42 # "should be documented somewhere" :-) 11.21.58 # CONTRIBUTING, maybe? 11.22.00 # i hate 16 bit archs 11.22.05 # they need to go away 11.22.25 # tell that to jyp :-) 11.22.48 # i can tolerate even 8 bit archs, but not in friggin' mp3 players 11.24.17 # I wonder why tomas rewrote so much of the bmp code 11.24.59 # but I'll leave it 11.27.29 # but there is room for quite serious speed improvemts in it 11.28.58 # i thought it was best to put it in cvs and improve it later 11.29.04 # indeed 11.29.29 # there aren't that many users of the code yet anyway ;-) 11.30.58 # preglow: Calmrisc is 16 bit, but on the other hand it's harvard. I thought you like that ;) 11.34.32 # haha 11.34.40 # no, not when i thought about it 11.37.10 # it's good for stuff you design yourself, heh 11.39.43 # LinusN: Strange... the warning is still there 11.40.14 # maybe it should be unsigned? 11.41.00 # i guess so 11.41.05 # nah 11.41.31 # i think all calculations are made on the default type 11.41.38 # Maybe an explicit cast is necessary before the shifts 11.41.41 # and then casted to the return type 11.41.49 # amiconn: exactly 11.47.16 Join muesli- [0] (muesli_tv@brsg-d9b8e18d.pool.mediaWays.net) 11.47.44 # morning mates 11.51.26 # hi 11.52.32 # thc? well ;) 11.53.14 # as usual, stoned ;) 11.53.31 # too early for that stuff...its just 12 ;) 11.53.46 # not really in fact, but why not a 12 ? ;) 11.53.50 # the earlier the better 11.54.35 # lol 11.59.01 # :D 12.01.45 # LinusN: I'll try to apply the long policy to the mmc driver while adding variable blocksize support 12.02.08 Join ripnetuk [0] (~george@82-70-100-230.dsl.in-addr.zen.co.uk) 12.02.15 # While it's not really used for a 16 bit arch yet, maybe it will at some time... 12.02.17 # amiconn: don't bother unless mmc is used on the gmini 12.02.50 # Btw, reading my 2 GB card already works :) I listened to some music on that card last night 12.03.14 # cool 12.03.17 # Next thing is to implement writing, and correct error handling 12.05.27 # Hackish Code Inside (r) 12.07.43 # best kind of code 12.20.32 # I see I broke the songdb.pl *blushes* 12.21.01 # rasher: yo, did you notice anything out of the ordinary at all in your breezy update? mine stops completely in a /lib64 collide :/ 12.21.50 # Hm.. nothing like that happened to me 12.22.00 # but then, I haven't upgraded for a while 12.23.31 *** No seen item changed, no save performed. 12.25.47 # might be a amd64 specific thing 12.29.07 # sounds reasonable 12.30.03 # omfg! 12.30.04 # no milk! 12.30.12 # ALERT! 12.30.35 # your cornflakes will be very dull now :( 12.30.49 # my using acronyms is an indicator of my seriousnes 12.31.17 # oh well, shop's just 50 metres away, off i go 12.38.24 Join kurzhaarrocker [0] (~Phil@p50908AEA.dip0.t-ipconnect.de) 12.39.49 # Is there a reason why the playlist context menu is not available when you browse the id3 db? 12.40.01 # hello 12.40.10 # hello 12.40.34 # * HCl reads up 12.45.15 # mmm. 12.46.57 Quit muesli- (Read error: 60 (Operation timed out)) 12.48.18 # hi kurzhaarrocker 12.50.21 # compiler creation class is fun.. 12.50.45 # wish my course still included a subject on that :( 12.51.02 # closest we do is grammars :/ 12.51.24 # * HCl is planning on saving all sheets of all courses of his university soon since he's most likely gonna move down to college next year 12.51.37 # bit of a "grab what you can" idea :p 12.52.32 # got AI class in 40 min 12.53.55 # ah, the beauty of mandatory partner-based projects 12.54.03 # :P 12.54.06 # i have that. 12.54.08 # with markun 12.54.20 # we're doing both compiler creation and AI together 12.54.44 # * ashridah watches the frequency of "i'm looking for XYZ" type newsgroup postings because people a) don't read their email b) don't go to lectures and c) don't bother to find their partner before their partner has to tear apart the uni looking for them 12.55.07 # yeah, well, it's okay if you do it with a mate. too bad if you get assigned a complete stranger who never turns up 12.55.16 # fortunately, i'm not in that position :) 12.55.19 # hehe. 12.55.22 # i know that idea. 12.55.34 # i once had Operating Systems with a person who was very very slow. 12.55.46 # i pretty much ended up doing the practical bit on my own with him watching 12.55.51 # we still finished 3 weeks early :P 12.55.59 # ahead of everyone else :P 12.56.27 # unfortunately for me, i didn't realise my partner wasn't really motivated. (of course, since i have real-world experience, and next to no social life, it's hard to find ANYONE as motivated as i am) 12.57.10 # but yeah, keeping clear of him next time :) 12.58.03 # i'm definently looking forward to my operating systems subject next semester. 12.58.16 # preglow: still chugging along after a dist-upgrade just now 12.58.27 # :P 12.58.42 # my operating systems course was boringish :/ 12.58.53 # it was mostly about creating a (unix) shell 12.59.16 # multithreading, communication between processes, deadlock avoidance.. 13.02.02 # true, but i enjoy working with complicated crap like that. leaves me lots of room for practical experience 13.03.47 # the sad part is that this slow person will get the same degree as you, while you have twice the knowledge and experience 13.04.29 # LinusN: heh. one thiing i like about my software engineering subject is we submit a CVS tree. it's fairly easy to see who's committed the most then :) 13.04.48 # :-) 13.05.18 # but yeah, it's often hard to find another partner who's very motivated, particularly at the undergraduate level :( 13.05.26 # LinusN: well.. most courses have both a practical grade and a test 13.05.42 # but yes, for the courses with only practical grades, the person is literally hitch hiking on your grade 13.05.54 # exactly 13.06.04 # ashridah: heh, i remember this person who refused to work together with anyone cause of that exact reason :P 13.06.22 #