updating irc logs

git-svn-id: svn://svn.rockbox.org/rockbox/trunk@996 a1c6a512-1295-4272-9138-f99709370657

1 files changed, 421 insertions, 0 deletions

diff --git a/www/irc/rockbox-20020605.log b/www/irc/rockbox-20020605.log
new file mode 100644
index 0000000000..c28cd86bf6
--- /dev/null
+++ b/www/irc/rockbox-20020605.log
@@ -0,0 +1,421 @@
+**** BEGIN LOGGING AT Tue Jun  4 23:37:03 2002
+
+-->     adiamas (~adiamas@216.194.26.223) has joined #rockbox
+---     Topic for #rockbox is Version 1.0 released! http://bjorn.haxx.se/rockbox/
+---     Topic for #rockbox set by adi|home at Tue Jun  4 04:41:56
+<xtac[z]>       hm
+<xtac[z]>       the archos is a bit heavy
+<xtac[z]>       i need to find a light hd
+<xtac[z]>       bb tom
+<--     xtac[z] has quit ("i focus on the pain the only thing that's real")
+---     You are now known as adi|home
+---     dw|gone is now known as dwihno
+-->     Bagder (~daniel@as3-3-2.ras.s.bonet.se) has joined #rockbox
+<Bagder>        morning fellas
+<dwihno>        Good morning!
+<dwihno>        And it's a wonderful morning indeed.
+<Bagder>        oh sure
+<dwihno>        Although my headphones haven't been fixed yet
+<adi|home>      morning
+<dwihno>        hellö hellö
+<adi|home>      Bagder.. my email is shot right now.. can't see commits... did you work on the m3u reader?
+<Bagder>        yes
+<Bagder>        it might even work a bit now
+<dwihno>        :O
+<Bagder>        I'm more or less waiting for Zagor/Linus to try this and/or comment it
+<Bagder>        or anyone else of course
+<adi|home>      hmm.. ill take a look
+<Bagder>        the read function should take larger peaces each time it does a read() of course...
+<adi|home>      pieces
+<adi|home>      not peaces
+<adi|home>      :)
+<Bagder>        oops
+<Bagder>        :-)
+<Bagder>        peace to everyone ;-)
+<adi|home>      except Al-Queda
+<adi|home>      they can burn...
+<Bagder>        hehe
+<adi|home>      them and their virgins
+*       adi|home gets down off his soapbox 
+<adi|home>      can i access the m3u reader from the uisim?
+<Bagder>        yes
+<adi|home>      home
+<Bagder>        name the file .m3u
+<Bagder>        browse to it and press play on it
+<adi|home>      k
+<Bagder>        I mean, it should have a .m3u extension
+<adi|home>      i get We instruct the MPEG thread to play Ani Difranco - Back Back Back.mp3 for us
+<adi|home>      correct?
+<Bagder>        yes
+<Bagder>        I haven't made the playlist do any shuffle or anything yet
+<adi|home>      k
+<Bagder>        it plays it from start to end
+<Bagder>        and then restarts again
+<adi|home>      k
+<Bagder>        however, not all that is possible to see in the simulator
+<adi|home>      heheh you and i have such diff code styles :)
+<adi|home>      fd = open()
+<adi|home>      if (-1 != fd)
+<adi|home>      hehe
+<adi|home>      id do: if ((fd = open()) < 0)
+<Bagder>        I never do the assignment inside the condition if I can move it outside without penalty
+<adi|home>      any particular reason?
+<Bagder>        for readability
+<adi|home>      ahh..
+<adi|home>      i wold agree with that..
+<Bagder>        the generated code will be exactly the same anyway
+<adi|home>      but in the same vein.. comparing against -1 specifically is a bad habit to me :)
+<Bagder>        perhaps
+<adi|home>      != 0 is failure in unix
+<Bagder>        not if open() is documented to return -1 on error ;-)
+<adi|home>      never know what functions return...
+<adi|home>      heheh true..
+<adi|home>      but what if it was to return -2 as well?
+<adi|home>      ;)
+<Bagder>        then it would be a silly check ;-)
+<adi|home>      hehehe
+<adi|home>      neither way is better.. just diff like i said ;)
+<Bagder>        yeah
+<adi|home>      besides.. i know when i become supreme overlord you will have to do it my way ...
+<adi|home>      im patient.. i can wait ;)
+<Bagder>        haha, you just let me know when you get your super powers and I'll fix my code then before you turn me into something unpleasant :-P
+<adi|home>      no worries.. id never turn you into a canadian ;)
+<adi|home>      the read/open/lseek
+*       Bagder sighs ffom relief
+<adi|home>      are they the ones we implimented
+<adi|home>      or part of the newlib?
+<Bagder>        yes
+<Bagder>        newlib is not needed anymore
+<Bagder>        not used
+<Hadaka>        well if this would be posix stuff - I'd definitely advice to test explictly against -1 and then do errno stuff after that
+<adi|home>      okay... that case, can read fail?
+<Bagder>        yes, read can fail
+<Bagder>        so yes, I should check for that
+<adi|home>      nods
+*       Bagder hides
+<Bagder>        we in fact set errno too, posix-fake-mode enabled ;-)
+<adi|home>      lol
+<adi|home>      would use of registers be of any use on the Archos?
+<adi|home>      just wondering if there is a faster way to run throught that while loop of yours..
+<Bagder>        modern gcc versions more or less ignore the register keyword
+<adi|home>      k
+<Bagder>        I/ew should read() larger chunks instead
+<Hadaka>        premature optimization is the root of all beer
+<Bagder>        I/we
+<Bagder>        reading single-bytes like that is plain silly
+<adi|home>      there is nothing wrong with premature optimization.. so long as you odn't go overboard
+<adi|home>      can you give me a rough idea of how we are managing the playlists?
+<adi|home>      i missed that convo
+<Bagder>        pretty simple:
+<Bagder>        we have the playlist on disk as a m3u file
+<Bagder>        we store only indexes to the file names in memory
+<Bagder>        that is, to the entry names within the m3u
+<dwihno>        The m3u is in the memory?
+<Bagder>        no
+<Bagder>        never
+<adi|home>      can i assume the index is the seek used by lseek
+<adi|home>      then you read in the filename?
+<Bagder>        exactly
+<adi|home>      i guess that makes sense.. you ahve to spin the drive up to read in the mp3 anyway.
+<Bagder>        yes
+<adi|home>      so doing it to get each index is no big deal.
+<Bagder>        we can even cache a few indexes before and after if we think that'll improve things
+<adi|home>      nods
+<Bagder>        so when we run "random"
+<Bagder>        we shuffle the arrat with all the seek-positions
+<Bagder>        array
+<adi|home>      makes sense
+<adi|home>      okay.. so we run from start to finish on the indices right?
+<Bagder>        yes
+<adi|home>      then having an int index that reps the "index of *NEXT* track to play' makes no sense
+<adi|home>      you only want to know the current file being played
+<adi|home>      don't you?
+<Bagder>        it doesn't really matter
+<adi|home>      i guess
+<Bagder>        I chose "next" just so that zero would make sense already when initing the struct
+<adi|home>      nod
+<Bagder>        the mpeg thread will id3-read the file and allow others to get that info
+<adi|home>      ?
+<Bagder>        thing is
+<Bagder>        we deliver the track to the mpeg thread long before we hear it
+<Bagder>        so we need the mpeg thread to tell the world which song that is actually playing right now
+<adi|home>      nod
+-->     Linus (~linus@labb.contactor.se) has joined #rockbox
+<Bagder>        morning Linus
+<Linus> morning!
+<adi|home>      hen you init the structure.. would you want to reset the seed for rand?
+<Bagder>        yes
+<Hadaka>        oh btw - random and shuffle play in my mind are different things - and both are nice, depending on situation
+<adi|home>      are you editing that file at all? if not ill fix this stuff as i go
+<Bagder>        adi|home: I'm not, feel free to improve
+<adi|home>      ki
+<Bagder>        Linus: spotted my id3-fix?
+<Linus> Hadaka: you want "true" random in some cases? That is, same song may be played twice?
+<adi|home>      okay... what happens if we barf on playlist processing?
+<adi|home>      ie: file read fails
+<adi|home>      open fails
+<Linus> Bagder: havent't come to the Rockbox-CVS folder yet... :-)
+<Bagder>        adi|home: just return, do nothing
+<adi|home>      k
+<Bagder>        Linus: hehe :-)
+<adi|home>      i think we eventually want a message to the user no
+<adi|home>      ?
+<Hadaka>        Linus: yes - or at times ofcourse a simple limit of not ever picking the next song to be the same song as the one exactly before would be sufficient
+<Hadaka>        Linus: but for example when using mpg123 - I do use true random play for some stuff
+<Linus> what is mp123?
+<dwihno>        mpg123?
+<dwihno>        you don't know what it is? :)
+<dwihno>        alnmighty mp3 thingy
+<Linus> an mp3 player?
+<Hadaka>        Mpg123 is a fast and portable MPEG audio player for Unix.
+<Linus> Ah.
+<Hadaka>        very, very common
+<Linus> That must mean that I'm ver very unaware of things. :-)
+<adi|home>      Bagder: its your code.. so let me ask.. on checking the open... is if(fd >= 0) acceptable to you?
+<adi|home>      or rather i leave it -l != fd?
+-->     nayr (~ryan@ip68-2-171-8.ph.ph.cox.net) has joined #rockbox
+<Linus> hi nayr!
+<Hadaka>        most jukebox softwares on unix use that as a backend - also there's a free replacement for it, mpg321, which is compatible
+<nayr>  Hello!
+<adi|home>      hey nayr
+<adi|home>      do we have stat in our api now?
+<adi|home>      or maybe it just makes more sense to lseek to a files end to get its size?
+<Linus> The ID3 code seeks to the end
+<adi|home>      heheh okay "static unsigned int playlist_seed = 0xdeadcafe"
+<adi|home>      is just wrong
+<Linus> why do you need the file length?
+<adi|home>      right now we are reading in the m3u file a byte at a time
+<adi|home>      that makes no sense.
+<Linus> no it doesn't
+<Linus> ...and...
+<adi|home>      so get the file size
+<adi|home>      define a static buffer of say 100 bytes
+<adi|home>      and read in at a better increment.
+<adi|home>      so you kno when you hit the file end
+<adi|home>      your still not mallocing..
+<adi|home>      so life is okay
+<Linus> why do you need the file size for that?
+<adi|home>      i guess i could just keep lseeking?
+<Linus> you could just read until end-of-file
+<adi|home>      are we gaurenteed to have an end-of-file?
+<Linus> of course
+<Linus> otherwise you wouldn't be able to lseek(9 to find out the end-of-file...
+<adi|home>      right, thats what im saying...
+*       adi|home now that i have my head outta my ass
+<adi|home>      lets say char buf[100]
+<adi|home>      then we do successive lseeks of 100 till we fail
+<adi|home>      then we just grab the rest of the file when we fail
+<Linus> you don't need a buffer to do lseek()
+<adi|home>      i know that
+<adi|home>      but where are you putting the data from the m3u file?
+<Linus> Maybe I'm not understanding what you want to accomplish
+<adi|home>      read/parse an m3u file
+<adi|home>      to store in our playlist structure
+<Linus> So get the data, one row at a time (it's a text file, right?)
+<adi|home>      right
+<Linus> why seek()?
+<adi|home>      how do you know when a line ense?
+<adi|home>      ends?
+<adi|home>      you search for CRLF
+<Linus> CR/LF or just LF?
+<Linus> whatever
+<adi|home>      im just going by what we have right now
+<adi|home>      nods
+<adi|home>      so to do that you need to read from the file into a buffer
+<Linus> so read into a 100 byte buffer, and look for EOL's
+<adi|home>      thats what im saying :)
+<adi|home>      thus the char buf[100]
+<Linus> but I still don't understand the seek() part
+<adi|home>      are just going to read until read fails?
+<Linus> exactly
+<adi|home>      so how do you tell the dif between "we reached the end of file: failed" and "archos is fucked: failed"/
+<adi|home>      ?
+<--     trillback has quit (zahn.openprojects.net irc.openprojects.net)
+<--     adi|work has quit (zahn.openprojects.net irc.openprojects.net)
+<--     webmind has quit (zahn.openprojects.net irc.openprojects.net)
+<--     datazone has quit (zahn.openprojects.net irc.openprojects.net)
+<--     gd has quit (zahn.openprojects.net irc.openprojects.net)
+<--     PiotR has quit (zahn.openprojects.net irc.openprojects.net)
+<--     PsycoXul has quit (zahn.openprojects.net irc.openprojects.net)
+<Linus> -1 means failure, 0 means end-of-file
+<Linus> still there?
+<--     Linus (~linus@labb.contactor.se) has left #rockbox
+-->     Linus (~linus@labb.contactor.se) has joined #rockbox
+<adi|home>      yeah.. just giant brain fart...
+<adi|home>      i see what your getting at
+<Linus> great
+<adi|home>      im not changing this now.. im bound to fsck it up.. to tired.. i ll hit it in the morning
+<adi|home>      night all
+<adi|home>      thanks for helping me pull my head from my ass Linus ;)
+-->     gd (~chatzilla@dns.agssmf.com) has joined #rockbox
+-->     PiotR (~piotr@212-170-21-172.uc.nombres.ttd.es) has joined #rockbox
+-->     PsycoXul (psyco@adsl-63-205-43-243.dsl.lsan03.pacbell.net) has joined #rockbox
+<Hadaka>        hmm, one should make a feature checklist of what the archos (recorder) can do - and what is implemented in rockbox
+<Linus> night, adi|home!
+<Hadaka>        how does the resume work on the original archos btw? does it save the current song/directory somewhere when it starts playing it or?
+<Linus> The Player saves that info on the hard drive
+<Linus> when it starts playing a song
+<nayr>  ?? I could never get resume to work anyway.
+<Linus> but not when the battery is too low
+<Linus> I guess it's a safety feature not to write on the hard disk when low on batteries
+<Linus> nayr: how come?
+<Hadaka>        ookkay
+<nayr>  Well, maybe I'm not understanding what it's supposed to do.  I was thinking it would resume a song where it left off between power cycles (ala iPod)
+<Linus> The recorder, OTOH saves that data in internal RAM
+<Linus> nayr: it only remembers which song it played
+<Linus> nayr: we will try to implement mid-song resume in Rockbox
+<nayr>  Hmmm... OK.  Well, I became overly excited when I heard about this project on /. 
+<nayr>  I figure there's a much better chance of getting the features I want by working with you folks than working with archos. :-)
+<Linus> nayr: nice. i hope you still feel that way.
+<Linus> nayr: are you a programmer?
+<Hadaka>        yeah, mid-song resume (and keeping of the current playlist) would be just dandy
+<nayr>  I used to pretend to be.  But if I can code at all, it's high-level stuff (RAD/UI, 4GL, etc.)  C/ASM really isn't my forte.  I can read it, but I can't code it :(
+<Linus> ok. you can still be very useful
+<nayr>  But I kick ass at QA, especially when I've got a personal stake in the project. =)
+<Linus> may god help us :-)
+<Linus> the QA department!
+<nayr>  Programmers tend to hate me pretty quickly. =)
+<Linus> :-)
+<nayr>  bedtime now.  I'm sure I'll be bouncing back in here again soon.  Thanks for all the work you folks have done so far, and I look forward to good things in the future!
+<--     nayr (~ryan@ip68-2-171-8.ph.ph.cox.net) has left #rockbox
+<--     Hadaka has quit (zahn.openprojects.net irc.openprojects.net)
+-->     Hadaka (naked@graywolf.onnanifujiyuu.org) has joined #rockbox
+-->     trillback (~trillian@sdn-ar-001ncraleP254.dialsprint.net) has joined #rockbox
+-->     adi|work (~adiamas@pool-151-204-140-140.ny325.east.verizon.net) has joined #rockbox
+-->     webmind (webmind@seal.student.utwente.nl) has joined #rockbox
+-->     datazone ([sm5Ow6WK8@207.136.36.203) has joined #rockbox
+<Bagder>        Linus: anyway, the id3 code should be reentrant now
+<Linus> Bagder: great
+<Bagder>        and if you get time, I'd appreciate if you tried the playlist code on target
+<Bagder>        I realize time is a shortage here ;-)
+<Linus> So the MP3 thread should use the ID3 code to dig some info from the file it plays
+<Bagder>        yes
+<Linus> and pass it to the GUI somehow
+<Bagder>        and "export" that info
+<Bagder>        right
+<Linus> I'll try to find out a good way to report the current playing pos as well
+<Linus> I'll look into Lion's suggestion and see what I can do.
+<Bagder>        about using a timer?
+<Linus> I didn't follow the playlist discussion. Do we have a working version?
+<Bagder>        we do
+<Linus> Bagder: timer?
+<Bagder>        somewhat "naive" and simple still thugh
+<Bagder>        Linus: forget it, I didn't follow that talk so closely ;-)
+<Linus> AFAICS, there is no good way to determine the song length
+<Linus> does the ID3 tag contain such info?
+<Bagder>        no, not without scanning the whole file
+<Bagder>        VBR is hell
+---     Linus is now known as Linus|meeting
+<dwihno>        :/
+<dwihno>        VBR is evil stuff
+<Bagder>        I can't believe I work in a project without gdb on target, when even rockbox has it :-/
+<dwihno>        gdb?
+<dwihno>        <-- sucks, tell me what gdb is good for
+<Bagder>        debugger
+<Bagder>        you've not developed seriously when you say that
+<dwihno>        ah
+<dwihno>        I used the visual c debugger
+<Bagder>        right
+<dwihno>        How hard is gdb to learn?
+<Bagder>        gdb is much more powerful, if somewhat more crude interface
+<Bagder>        the basics are simple
+<Bagder>        using it from within emacs makes it even easier
+<dwihno>        You got some basic introduction stuff?
+<Bagder>        'b [symbol]' for breakpoints
+<Bagder>        'c' for continue
+<Bagder>        'run' to start
+<Bagder>        'n' for next
+<Bagder>        's' for step-in 
+<Bagder>        that's it ;-)
+<Bagder>        'p [variable]' display variable contents
+<Bagder>        'info locals' display all local variables
+<dwihno>        does it require some extra stuff compiled into the binary?
+<Bagder>        yes, it requires that it was compiled with -g for maximum use
+<dwihno>        mkay
+-->     Zagor (~bjst@labb.contactor.se) has joined #rockbox
+<Bagder>        hey Z
+<Zagor> hi
+<Bagder>        Zagor: I added some playlist code yday
+<Bagder>        not very fancy or anything, but it could work 
+<Zagor> ok, nice
+<Bagder>        it's still basic and slightly "naive"
+<Bagder>        but a start
+<Bagder>        Zagor: I made 'playing' hold a play "mode" instead of just a boolean
+<Bagder>        so that play-all-dir should still work too
+<Zagor> in tree.c you mean?
+<Bagder>        yes
+<Zagor> ok
+<Bagder>        they're just digits now, but we should remake it into some enum or somthing
+<Zagor> yup
+<Zagor> 152 subscribers today
+<Bagder>        wow
+<--     Smari has quit (Read error: 110 (Connection timed out))
+*       ironi has returned, [gone/11h 49m 47s]
+<ironi> hello ppl
+<Zagor> hi ironi
+<Bagder>        hey ho
+<ironi> just came home
+<ironi> I'm thinking on working on my persolan homepage
+<ironi> It needs a facelift
+<Bagder>        time to go and get a visa ;-)
+---     Bagder is now known as Bagder|away
+<ironi> hehe
+<ironi> apt-get dist-upgrade is my favourite command ever
+<Zagor> yeah, debian rocks
+<ironi> it does.
+<Zagor> hehe, nice peak yesterday.
+<Zagor> 3rd june: 4700 accesses
+<Zagor> 4th june: 60196 accesses
+<Zagor> pages, not accesses
+<Zagor> 04:00-05:00 on the 4th: 25 pages
+<Zagor> 05:00-06:00 on the 4th: 3279 pages :)
+<ironi> has there been a post on slashdot?
+<ironi> =)
+<Zagor> quite so
+<dwihno>        Is there some way to make directories invisible using the archos firmware? I'd like to have a folder to store documents and stuff and I don't want it being displayed :)
+<Zagor> not that I know of
+<ironi> dwihno: well maybe hidden directories could be excluded in the archos
+<ironi> that is perhaps an easy solution
+<dwihno>        yeah
+<dwihno>        I'll test that later
+<dwihno>        I sold my last computer last night
+<dwihno>        So now I have ZERO computers
+<dwihno>        Zero, zip, nada!
+<ironi> heh
+<dwihno>        INGA!
+<ironi> when is the dell coming?
+<dwihno>        No jävla datorer! :)
+<dwihno>        I haven't ordered it yet
+<ironi> oh ok
+<dwihno>        I'm awaiting a faktura to be betalad by the evil customer
+<ironi> it doesn't take long for themto ship it though, i thiok.
+<ironi> you din't take cash, thats bad.
+<ironi> =)
+<dwihno>        Nah, it will probably take less than 1 week
+<dwihno>        Are there any good ways to install some really kickass boot loader?
+<dwihno>        I want to have Win98, Win2k and linux on the same box :)
+<Zagor> i'm sure the guys in #linuxhelp knows all about that. :)
+<ironi> dwihno: grub is nice
+<dwihno>        ironi: never tried it... :) 
+*       dwihno goes on a google streak
+<ironi> if you want windows gui easy-to-install-bla-bla-mumbo-jumbo there is powerquest bootmagic
+<dwihno>        Eww
+<ironi> grub is cool though because you can edit the options in the boot loader
+<ironi> at boot
+<dwihno>        That's what I like!
+<dwihno>        I like configurability
+<ironi> i tried when using gentoo
+<ironi> i really find it better than lilo for me
+<dwihno>        Hmm, how come?
+<ironi> i just like it more
+<dwihno>        Is it cute? :)
+<ironi> you dont edit a config file, you instead enter a grub console where you supply commands
+<ironi> you can enter this console at boot too
+<ironi> if you want
+<dwihno>        ah
+<dwihno>        Damn DNS server!
+<dwihno>        GIVE ME THE LOOKUP YOU EVIL DNS STUFF! :)
+<dwihno>        ah, now it works
+---     Disconnected (Connection timed out).
+**** ENDING LOGGING AT Wed Jun  5 06:14:13 2002
+