00:08:41 | | Quit unionpeak (Read error: 110 (Connection timed out)) |
00:10:09 | *** | Saving seen data "./dancer.seen" |
00:10:29 | | Quit uski ("Leaving") |
00:31:40 | | Quit NibbIer (Read error: 104 (Connection reset by peer)) |
00:31:41 | | Quit Threshold (Read error: 104 (Connection reset by peer)) |
01:00 |
01:24:56 | | Quit gromit`` (Read error: 110 (Connection timed out)) |
01:25:05 | | Part amiconn |
01:31:30 | | Join unionpeak [0] (polirc@d47-69-178-178.try.wideopenwest.com) |
01:38:02 | | Join dstar5 [0] (~lee@IC104.library.oregonstate.edu) |
02:00 |
02:10:11 | *** | Saving seen data "./dancer.seen" |
02:15:41 | | Join NibbIer [0] (~nibbler@port-212-202-78-112.dynamic.qsc.de) |
02:20:42 | dstar5 | anyone have some rockbox movies to share? |
02:34:19 | | Quit unionpeak (Read error: 110 (Connection timed out)) |
02:49:17 | | Quit elinenbe (" HydraIRC -> http://www.hydrairc.com <- s0 d4Mn l33t |t'z 5c4rY!") |
02:49:45 | | Join elinenbe [0] (elinenbe_@207-237-224-177.c3-0.nyr-ubr1.nyr.ny.cable.rcn.com) |
02:57:09 | | Join midk_ [0] (~midk@c66-235-14-120.sea2.cablespeed.com) |
02:57:47 | | Quit midk_ (Remote closed the connection) |
02:57:49 | | Quit scott666_ (Read error: 60 (Operation timed out)) |
02:57:50 | | Join midk_ [0] (~midk@c66-235-14-120.sea2.cablespeed.com) |
02:58:53 | | Join scott666_ [0] (~scott666@c-24-245-58-48.mn.client2.attbi.com) |
03:00 |
03:01:48 | | Quit midk (Nick collision from services.) |
03:01:53 | | Nick midk_ is now known as midk (~midk@c66-235-14-120.sea2.cablespeed.com) |
03:07:42 | dstar5 | lol <−− midk has quit (Nick collision from services.) those always get to me :) |
03:08:17 | midk | get to you? |
03:08:32 | dstar5 | they are funy. |
03:08:37 | midk | k |
03:09:16 | dstar5 | midk, How do crazy people go through the forest? |
03:09:22 | midk | not sure. |
03:09:31 | dstar5 | They take the psycho path. |
03:09:40 | dstar5 | How do you get holy water? |
03:10:01 | dstar5 | Boil the hell out of it. |
03:10:49 | dstar5 | midk, i have a joke for you |
03:10:56 | dstar5 | Two gay guys were in the shower together when one looked down and saw a puddle of white liquid. |
03:11:02 | dstar5 | He said to the other man What did I tell you about farting in the shower? |
03:11:11 | midk | that's just sick |
03:11:48 | dstar5 | nasty nasty! |
03:13:13 | dstar5 | time to go home |
03:13:15 | dstar5 | bye |
03:13:24 | midk | later |
03:13:30 | | Quit dstar5 ("Leaving") |
03:30:37 | | Quit NibbIer (Read error: 104 (Connection reset by peer)) |
03:39:09 | | Quit scott666_ (Read error: 60 (Operation timed out)) |
03:39:48 | | Join scott666_ [0] (~scott666@c-24-245-58-48.mn.client2.attbi.com) |
04:00 |
04:10:14 | *** | Saving seen data "./dancer.seen" |
04:14:15 | | Join Treyqae [0] (~Treyqae@adsl-8-40-172.mia.bellsouth.net) |
04:14:43 | | Part Treyqae |
04:20:54 | | Join elinenbe_ [0] (elinenbe_@207-237-224-177.c3-0.nyr-ubr1.nyr.ny.cable.rcn.com) |
04:24:18 | | Quit midk ("Leaving") |
04:38:43 | | Quit elinenbe (Read error: 110 (Connection timed out)) |
04:38:43 | | Nick elinenbe_ is now known as elinenbe (elinenbe_@207-237-224-177.c3-0.nyr-ubr1.nyr.ny.cable.rcn.com) |
05:00 |
05:09:23 | | Quit AciD ("www.acid.ht.st") |
05:14:18 | | Join NibbIer [0] (~nibbler@port-212-202-78-112.dynamic.qsc.de) |
05:37:39 | | Quit scott666_ ("i'll be back...eventually...") |
05:37:39 | | Quit NibbIer (Read error: 54 (Connection reset by peer)) |
06:00 |
06:10:18 | *** | Saving seen data "./dancer.seen" |
06:37:50 | | Join elinenbe_ [0] (elinenbe_@207-237-224-177.c3-0.nyr-ubr1.nyr.ny.cable.rcn.com) |
06:41:37 | | Join midk [0] (~midk@c66-235-14-120.sea2.cablespeed.com) |
06:45:47 | | Quit elinenbe (Read error: 60 (Operation timed out)) |
06:45:48 | | Nick elinenbe_ is now known as elinenbe (elinenbe_@207-237-224-177.c3-0.nyr-ubr1.nyr.ny.cable.rcn.com) |
07:00 |
07:15:01 | | Join NibbIer [0] (~nibbler@port-212-202-78-112.dynamic.qsc.de) |
07:31:44 | | Join LinusN [200] (~linus@labb.contactor.se) |
07:31:45 | | Quit NibbIer (Read error: 54 (Connection reset by peer)) |
07:33:45 | midk | hey LinusN |
07:33:54 | midk | i noticed a small error in your cross-compiler doc |
07:35:00 | midk | early on you say you need "gcc-3.4.1.tar.gz (find it at your closest GNU FTP site)", but under "Build GCC" you say "/home/linus/gcc> ../../gcc-3.0.4/configure −−target=sh-elf −−prefix=/home/linus/sh1 −−enable-languages=c" |
07:35:45 | midk | apparently, you made a version typo with gdb too. |
07:40:38 | LinusN | oops |
07:40:47 | LinusN | thanks for noticing |
07:40:54 | midk | np |
07:40:59 | midk | i forgive you. :) |
07:41:15 | midk | i'll have to try it again - it didn't work for me the first time around |
07:42:01 | LinusN | building the cross compiler? |
07:42:12 | midk | yeah |
07:42:25 | LinusN | what went wrong? |
07:42:47 | midk | everything seemed to go just fine.. rockbox just didn't build. iirc, it kept re-making apps |
07:43:07 | LinusN | strange |
07:43:07 | midk | i tried it again, and that time there was no sh-elf-gcc to be found |
07:43:29 | LinusN | you are aware that you have to chagne the PATH? |
07:43:35 | midk | yeah.. 'leaving directory 'apps'' then right afterwards, 'entering directory 'apps'' |
07:43:48 | midk | yeah, i did.. |
07:44:00 | midk | with your export PATH line, no? |
07:44:17 | LinusN | yeah, or add in in .bash_profile |
07:44:23 | midk | did both. |
07:44:39 | midk | in the /home/midk/sh1 folder i found a folder 'sh-elf' |
07:44:58 | midk | but there was only 'gcc' in there, |
07:45:59 | LinusN | there should be a "bin" directory too |
07:46:21 | midk | yep, there was |
07:46:32 | midk | along with about 6 others |
07:46:42 | LinusN | the PATH should point to the bin dir |
07:47:01 | midk | export PATH=/home/midk/sh1/bin:$PATH ? |
07:47:08 | LinusN | perhaps you forgot to "make install" gcc? |
07:47:15 | midk | no, i did that too. |
07:47:20 | LinusN | weird |
07:47:36 | midk | oh well. i'll try it again soon |
07:49:48 | LinusN | did you use the same prefix for both binutils and gcc? |
07:50:18 | midk | yeah. could have been a typo but i'm quite sure i did it right |
07:50:28 | midk | i'll try it later tonight or tomorrow |
07:53:00 | midk | all right. time to reboot and, hopefully, successfully resize some partitions. be back sooner or later. |
07:53:14 | | Join Guest [0] (~jirc@adsl-10-228-157.mia.bellsouth.net) |
07:53:34 | LinusN | midk: may the source be with you |
07:53:52 | midk | :D |
07:54:04 | midk | (it's an iso) :) |
07:54:11 | midk | bbs |
07:54:13 | | Quit midk ("Leaving") |
08:00 |
08:02:29 | | Join midk [0] (~midk@c66-235-14-120.sea2.cablespeed.com) |
08:02:51 | midk | yay. |
08:05:09 | Guest | Hi midk - got to play with the stuff we did last night. Works great. |
08:06:04 | Guest | Got ID3v2.3 reading and writing working today, so that piece of the puzzle is a no-brainer. |
08:06:35 | midk | oh, good |
08:08:57 | * | LinusN is curious |
08:09:47 | midk | we were talking about a feature in f2 or f3 that would add your currently playing file to one of five playlists. the we could have a 5-star rating system like the iPod. |
08:10:06 | | Join amiconn [0] (~jens@pD9E7F862.dip.t-dialin.net) |
08:10:19 | *** | Saving seen data "./dancer.seen" |
08:10:57 | amiconn | G'morning everyone |
08:11:04 | LinusN | amiconn: hola, amigo |
08:11:17 | Guest | Thanks midk |
08:11:43 | Guest | Downloaded the devkit setup from Cyborg systems - looks like an easier way to set up the dev environment |
08:11:43 | midk | Guest, for? |
08:11:51 | LinusN | midk: how about extending the "add-to-playlist" plugin so that you get to choose the categories/playlists via settings? |
08:11:52 | amiconn | LinusN: Although I like the new soft shitdown feature, I have to tell you about 2 quirks I found |
08:12:07 | LinusN | shitdown, thanks a lot :-) |
08:12:09 | Guest | Responding to LinusN faster than I could.. |
08:12:35 | amiconn | oops, shutdown of course :-) |
08:12:38 | midk | haha! |
08:12:39 | midk | :D |
08:12:50 | midk | Guest, if you were serious, np :) |
08:13:00 | Guest | Anyway, is Cyborg's a good way to set up the dev? |
08:13:10 | LinusN | it works, afaik |
08:13:25 | Guest | Good. |
08:13:42 | amiconn | (1) While the sutdown is correctly suppressed from OFF-OFF if the charger is connected, it is not if triggered from the menu |
08:13:50 | amiconn | *shutdown, grr |
08:13:56 | LinusN | amiconn: not? |
08:14:36 | amiconn | It says "Shutting down...", then goes back to the menu |
08:14:39 | LinusN | amiconn: ah, my bad |
08:15:05 | LinusN | i put the charger check too late in the code |
08:15:22 | LinusN | hmmm, i had a reason to do that, but i can't remember what it was... |
08:15:30 | amiconn | (2) Why calling "Shutdown" triggers a disk spinup first if the disk was already quiet is beyond me |
08:15:45 | LinusN | because it saves the settings |
08:15:55 | LinusN | what else would a clean shutdown do? |
08:17:02 | LinusN | i could of course add a check for changes settings... |
08:17:05 | LinusN | changed |
08:17:12 | amiconn | It does that also when I just switch on the unit, wait until the disk spins down, then hit OFF-OFF. No setting changed in between... |
08:17:22 | LinusN | see above |
08:17:40 | Guest | Different topic: I was playing with the voice feature, got the Crystal voice working for menus. I used joerg hohensohn's vbs script to generate directory names. It worked but it used Microsoft's Sam voice. What's the right way to get some other voice to work with the script? |
08:17:41 | amiconn | Ok, thanks. |
08:18:29 | amiconn | Guest: The script uses whatever defaulkt voice is set in your windows speech control panel (as long as it is an Englsih one) |
08:18:31 | midk | LinusN, so holding off isn't really supported anymore? |
08:18:35 | amiconn | *default |
08:18:56 | midk | or is safe shutdown "in addition to" holding stop/off? |
08:19:11 | LinusN | midk: we can't do anything about holding off, it's hardware controlled |
08:19:26 | LinusN | that's the whole thing |
08:19:37 | midk | right. but i'm saying, you used to detect an off hold before you merged safe shutoff, right? |
08:19:54 | LinusN | otherwise i wouldn't have to goo all this way to put a clean shutdown on the double-off click |
08:20:21 | LinusN | we detect a held off key on the fm, yes, and that is still there |
08:20:25 | midk | the hardware off on the FM is five seconds. but if you held it and rockbox was operating fine it was only 2-3 seconds, doesn't that mean that rockbox controls poweroff? |
08:20:26 | midk | ah. |
08:20:56 | midk | you should show the logo and "shutting off" text as the disk spins and saves settings. if it doesn't already. |
08:21:10 | LinusN | it does |
08:21:18 | LinusN | but not when you hold off |
08:21:32 | midk | of course not. but also that would be a good feature on the FMs. |
08:21:42 | midk | since we do control poweroff there |
08:21:55 | LinusN | yes, but it requires MAJOR changes to the code |
08:21:58 | amiconn | LinusN: Another small one for the safe poweroff: For holding off, it says "Battery: charging" if the charger is connected. It does give no feedback at all if you click OFF-OFF |
08:22:19 | LinusN | i should probably say the same thing |
08:22:24 | LinusN | it |
08:22:36 | midk | oh, i once wrote a patch that, when you hold off in the dir browser with charger plugged it went to the charger screen - imo this was a good idea. do you agree? |
08:23:43 | LinusN | why is it a good idea? |
08:24:17 | midk | i just thought it was.. although it'd appear that when i see a good idea it's usually a not-so-good one |
08:24:27 | Guest | amiconn, that's what I thought. I loaded some other voices and the SAPI control panel add-on (spchapi.exe). The other voices show up as SAPI 4 voices in the "Other->SAPI 4 Control Panel" pane, but there's no way to change the default voice. I'm on XP - what am I doing wrong? |
08:24:31 | amiconn | I'd agree to midk, both shutdown methods should go to the charging screen if you use them with the charger connected. It would look much more logical to the average user |
08:24:54 | amiconn | Guest: The script is only able to use SAPI 5 voices |
08:24:57 | LinusN | midk: there is no difference between charging in the charging screen than in the "normal" mode |
08:25:01 | midk | you could even extend that idea to idle-poweroff. if the idle time reaches the set poweroff time it would "power down" to the charging screen. |
08:25:11 | midk | LinusN, it's just, like amiconn said, a cosmetic thing. |
08:25:44 | amiconn | yep |
08:26:25 | midk | i think holding off should result in the charging screen instead of "battery charging" - it just seems more logical |
08:27:16 | amiconn | In adition, it would protect from accidentally pressed keys (other than ON) |
08:27:20 | amiconn | *addition |
08:27:29 | * | LinusN is experiencing a serious deja-vu |
08:27:33 | midk | true |
08:27:59 | LinusN | who pushes keys by accident when charging? |
08:28:24 | midk | uhh |
08:28:27 | * | midk looks at amiconn |
08:28:33 | midk | :) |
08:29:58 | Guest | OK - that explains a lot. Is the only way to get other SAPI 5 voices to download the whole SAPI 5 SDK (132MB)? I downloaded the Mike and Mary redistributable, but the exe download only contains an msm installer merge module, no msi install. What a pain. |
08:30:01 | amiconn | I didn't say that it happens to me (I even don't use keylock at all), but it may happen to others. Of course the "risk" is low :-) |
08:30:45 | amiconn | Guest: Iirc, unfortunately you have to download the whole SAPI 5 SDK |
08:30:53 | LinusN | we once rebooted when off/stop was held |
08:31:01 | midk | i simply see "charging screen" replacing "powered off" status when charger is plugged. |
08:31:12 | midk | idle poweroff or shutdown would lead to it. |
08:31:22 | midk | not necessarily idle poweroff, though. |
08:31:27 | midk | actually, no, not idle poweroff. |
08:31:32 | LinusN | absolutely not |
08:31:54 | midk | quiet, it was just a stroke of brilliance :) |
08:32:14 | LinusN | felt good, didn't it? |
08:32:14 | Guest | OK, thanks. Don't mind doing it, so long as I know it's worthwhile and not going to mess up the voice stuff that already works. D/Ling now. |
08:32:45 | midk | LinusN, yeah. but then i realized it'd be rejected because some people may actually use this thing to play music. |
08:32:49 | midk | :] |
08:33:50 | Guest | brb - D/L hogging my router... |
08:35:08 | amiconn | Guest: I *could* extend the script to be able to use SAPI 4 as well the same way as my voice file generation script does, but SAPI 4 is slooow from a script, has to do everything in realtime |
08:37:07 | amiconn | LinusN: Still I think going to the charging screen if a poweroff event is triggered is most logical to the user: If he hits OFF, he wants the unit to shut off, so going to the charging screen instead if the charger is connected is "as OFF as possible" in that case |
08:38:18 | amiconn | You have to check for that anyway (saying battery: charging" atm), so code size increase should be neglectible |
08:40:36 | midk | right, that reminds me, why do you have a seperate function for simply splashing "Battery: Charging"? |
08:42:57 | LinusN | that's because we don't want to enter the charging screen, but people kep asking why it didn't "shut off" when the charger is attached |
08:43:31 | midk | right, but why a seperate function? |
08:43:39 | LinusN | so the "charging" splash informs the user that it is charging and there is no need to go to the charging screen |
08:43:42 | midk | you call it, instead you could just call splash instead |
08:44:04 | LinusN | yes, but i think there were plans to extend it |
08:44:25 | LinusN | and it might be called from several places |
08:45:12 | midk | well i think when a user holds off with charger plugged they probably want it to turn off.. isn't the charging screen as off as possible? |
08:45:45 | LinusN | i guess it is |
08:49:31 | LinusN | damn, the exit-from-viewer poweroff bug is hard to fix |
08:50:39 | midk | booo |
08:50:45 | midk | i have an idea. let's give up! |
08:50:51 | midk | <YAAAAYs> |
08:50:53 | * | LinusN has a better idea |
08:51:06 | midk | let's FIX IT! |
08:51:10 | LinusN | yeaaaaah! |
08:51:12 | midk | <BOOOOOs> |
08:51:26 | amiconn | LinusN: Empty the button queue when a plugin has exited? (Of course this would prevent plugins from deliberately injecting button events on exit, but no plugin does that so far) |
08:52:41 | LinusN | it already does |
08:52:43 | Guest | Got the 5.1SDK, it works - thanks, amiconn. |
08:52:56 | LinusN | the problem is that the plugin exits before the user has released the key |
08:53:26 | amiconn | Ah oops, yes |
08:53:46 | LinusN | i have solved it now |
08:54:03 | LinusN | i don't have to act on the release event |
08:55:05 | | Quit c0utta (Read error: 60 (Operation timed out)) |
08:56:32 | LinusN | hmmm, i had a reason to do that in the beginning of the development of this patch... |
08:56:33 | amiconn | LinusN: I thought this is necessary to distinguish a short press from a long one? |
08:57:38 | LinusN | yes, but i wonder why i wanted that |
08:59:07 | LinusN | hmm, i have an idea |
08:59:18 | amiconn | Hmm, imho it shouldn't be necessary. If you react on keydown, the poweroff? question would also kick in when the user holds down OFF, but that should make no difference, since the hw powerdown catches it anyway |
08:59:58 | LinusN | i should just ignore the OFF repeat event, so the splash isn't cancelled |
09:00 |
09:00:23 | LinusN | and on the FM, i could save the settings when holding OFF as well...hmmm... |
09:00:29 | LinusN | nah |
09:00:30 | amiconn | Perhaps it is even better to react on keydown, because the pop-up question may remind a user to use OFF-OFF now instead of holding OFF |
09:00:44 | LinusN | yup |
09:01:10 | amiconn | On the v2/fm, holding OFF should also trigger the safe poweroff |
09:01:19 | LinusN | yes, but that's hard to implement |
09:01:21 | midk | that's what i suggested! |
09:01:27 | midk | and that's the response i got. |
09:01:31 | midk | carry on. |
09:01:47 | LinusN | the poweroff is triggered by the button driver, in the interrupt context |
09:02:58 | midk | yes. the interrupt. and the context. triggered. driver. yeah. |
09:03:30 | amiconn | Perhaps convert it to a special button event (BUTTON_POWEROFF) and place it into the button queue? |
09:03:43 | LinusN | of course |
09:04:08 | LinusN | but that will force us to change all button_get() loops |
09:04:17 | LinusN | like for the USB connection |
09:04:54 | LinusN | but that may be a Good Thing in the end |
09:05:33 | LinusN | because then i finally have a reason to implement the system_handler() idea |
09:07:19 | LinusN | in all button loops, add a call to system_handler() in the default: case |
09:07:35 | | Join c0utta [0] (~c0utta@17.cust9.sa.dsl.ozemail.com.au) |
09:07:36 | LinusN | which checks for USB and for the OFF event |
09:07:55 | amiconn | That could even save some code space... |
09:08:03 | LinusN | probably, yes |
09:08:10 | amiconn | Sounds like a good idea |
09:08:17 | LinusN | i'll do that |
09:10:13 | amiconn | Another option would be to implement something like an event system |
09:10:53 | amiconn | Each thread/ plugin may "register" for those events it wants to handle itself. |
09:11:27 | amiconn | All other events would be handled by the thread that registered it earlier |
09:12:10 | LinusN | problem is that the usb event should be handled by the same thread |
09:12:45 | amiconn | Events/ event groups could be EVENT_BUTTON, EVENT_USB, EVENT_POWEROFF, EVENT_TIMERTICK etc. |
09:13:06 | LinusN | timertick? |
09:13:19 | amiconn | Yes, occuring every 1/100 s |
09:13:30 | LinusN | why? |
09:14:33 | amiconn | It may even be possible to generate some "soft" events to register for plugins that are interested in them. EVENT_MPEG_TRACKCHANGE comes to mind |
09:14:46 | LinusN | why timertick? |
09:15:45 | | Join NibbIer [0] (~nibbler@port-212-202-78-112.dynamic.qsc.de) |
09:16:02 | amiconn | Timertick may be of interest for plugins. |
09:16:37 | LinusN | maybe we should export tick_add_task() |
09:16:37 | LinusN | instead? |
09:19:02 | amiconn | Maybe (didn't know about this function until now!). Imho an event system would be an clean & elegant replacement for a number of api functions |
09:20:11 | LinusN | events, as in pseudo button codes? |
09:20:16 | LinusN | (i hope) |
09:21:20 | amiconn | It would work in a similar way as the button codes do now. |
09:21:23 | LinusN | having timer ticks posted to the button queue will probably cause problems with overflown button queues |
09:21:32 | amiconn | No. |
09:21:45 | amiconn | It could work like this: |
09:21:58 | amiconn | We have a global event queue. |
09:22:27 | amiconn | Any thread, irq routine etc. that generates events posts them there |
09:22:38 | LinusN | in addition to the button queue? |
09:23:02 | amiconn | No, instead of it, since the button events would be part of the event system then |
09:23:41 | LinusN | what if noone reads the event queue? |
09:23:58 | amiconn | Any thread that is interested in them would "register" for them (e.g. with a callback function) |
09:24:08 | LinusN | button events too? |
09:24:12 | amiconn | Yup. |
09:24:35 | amiconn | The receiving of events could be destructive or non-destructive |
09:24:46 | amiconn | (decided by the thread that wants them) |
09:25:10 | LinusN | destructive, as in removing it from the queue? |
09:25:15 | amiconn | yup |
09:25:49 | LinusN | let's say, for the sake of argument, that we "register" for the timer_tick event |
09:26:02 | amiconn | The default registration (by the initial thread) for all events would be to discard them all |
09:26:06 | LinusN | (and the obvious button event) |
09:26:34 | LinusN | then we handle a button event which triggers a disk read |
09:26:36 | amiconn | Then the usual threads of rockbox would register for those events that they want to receive |
09:27:05 | LinusN | during the disk spinup we receive between 200-500 timer events |
09:27:49 | LinusN | which are stored in the queue because we are busy waiting for the drive |
09:28:30 | LinusN | most events are only interesting for the main thread |
09:28:31 | amiconn | Triggering a disk spinup doesn't cause a yield()? |
09:29:21 | LinusN | of course it does, but should the main thread throw away the timer tick events? |
09:29:38 | LinusN | in every sleep(), yield() etc? |
09:29:50 | LinusN | then you can't depend on them for timing |
09:30:04 | LinusN | my point is that the timer tick events are useless |
09:30:56 | amiconn | Maybe that timer events are useless, this was only one suggestion of an event |
09:31:04 | LinusN | and i don't like the registering scheme, because it clutters up the code |
09:31:25 | amiconn | (Sorry, gotta hurry) |
09:31:33 | LinusN | ok, cu around |
09:31:48 | LinusN | TRACK_CHANGE is a good event, though |
09:32:15 | LinusN | we wanted to make an event of it in the beginning |
09:32:33 | LinusN | but code structure issues made it a little difficult |
09:32:57 | LinusN | so i like the event idea |
09:33:12 | LinusN | but i don't want the registering scheme |
09:34:50 | LinusN | i should document the kernel in wiki... |
09:34:57 | midk | hostile. |
09:35:01 | midk | hostility. |
09:35:14 | midk | posterity! |
09:35:23 | LinusN | stupidity |
09:36:42 | midk | :[ |
09:36:45 | midk | thanks. |
09:36:57 | midk | idioticrity. |
09:40:30 | | Join Doehni_ [0] (~Doensen@108.190-200-80.adsl.skynet.be) |
10:00 |
10:10:21 | *** | Saving seen data "./dancer.seen" |
10:15:57 | | Quit NibbIer (Read error: 104 (Connection reset by peer)) |
10:15:59 | | Join Ich|bett [0] (~blabla@p508C73C2.dip.t-dialin.net) |
10:16:14 | | Nick Ich|bett is now known as NibbIer (~blabla@p508C73C2.dip.t-dialin.net) |
10:34:06 | amiconn | (back) |
10:34:26 | LinusN | i'm implementing the default_button_handler() as we speak |
10:34:32 | amiconn | LinusN: Iirc the mpeg thread uses something like an event system internally |
10:34:52 | LinusN | yes it used a message queue |
10:34:54 | LinusN | uses |
10:35:15 | LinusN | i think we should use the existing button queue for events |
10:35:33 | | Quit Guest (Read error: 110 (Connection timed out)) |
10:36:06 | amiconn | The registering scheme would have the advantage that it is extendable without touching things that wouldn't have use for the new events |
10:36:24 | LinusN | why? |
10:36:38 | LinusN | if the button switch doesn't handle it, it ends up in the default case |
10:37:07 | LinusN | so you won't have to change anything |
10:37:10 | amiconn | The system_handler approach does this as well, yes |
10:37:23 | LinusN | it works even without the default handler |
10:37:33 | | Join uski [0] (~uski@gandalf.digital-network.org) |
10:38:21 | amiconn | The current button queue isn't exactly a pure button queue anyway, as it passes e.g. SYS_USB_CONNECTED |
10:38:32 | LinusN | exactly |
10:38:56 | LinusN | in fact, every thread is supposed to have a queue |
10:39:08 | LinusN | and the main thread queue is the button queue |
10:39:30 | LinusN | (well, every thread that is interested in the SYS_USB_CONNECTED event, that is) |
10:40:19 | LinusN | the SYS_USB_CONNECTED event is broadcast to all queues |
10:41:07 | amiconn | The registration scheme would have the advantage that a thread/ plugin doesn't receive events it is not interested in |
10:41:23 | LinusN | why is it important that it doesn't receive them? |
10:41:58 | amiconn | There wouldn't have to be a default case calling the system_handler |
10:42:19 | LinusN | it works even without the system handler |
10:42:52 | amiconn | How? |
10:43:20 | LinusN | i see what you mean |
10:43:33 | LinusN | you expect some magic to take care of the USB_CONNECTED event? |
10:44:01 | LinusN | the main thread must handle the USB event |
10:44:12 | LinusN | be it in the default handler or anywhere else |
10:44:50 | LinusN | and the plugin runs in the main thread |
10:45:16 | amiconn | Yes, of course one thread has to handle it. But if a plugin doesn't use the hd, it could ignore the USB_CONNECTED event, and go on executing. |
10:45:18 | LinusN | all threads must respond to the event if they have a message queue |
10:45:46 | amiconn | Of course in order to exploit the advantages of an event system, plugins should always run in an own thread |
10:46:10 | LinusN | and what does the main thread do in the mean time? |
10:46:52 | LinusN | in your example, you would enter USB mode with the plugin still running? |
10:47:10 | LinusN | kind of confusing to the user, don't you think? |
10:48:01 | LinusN | i think you over-complicate things |
10:51:26 | amiconn | Maybe that a full event system isn't necessary atm, but it may be the case if Rockbox gets ported to another player one day |
10:51:44 | LinusN | why would it? |
10:52:50 | LinusN | imho, the only case when a registration would be necessary is when there is a risk of flooding the queue |
10:53:17 | LinusN | look at the Windows message system for example |
10:53:47 | LinusN | (i can't believe i said that, using windows as a model example) |
10:54:05 | LinusN | you get tons of messages that you don't "want" |
10:54:17 | LinusN | and they are all taken care of by the default message handler |
10:55:04 | amiconn | I didn't deal much with Windows messaging yet |
10:55:56 | LinusN | well, it works much like rockbox today |
10:56:14 | amiconn | Of course you are right if there is always a default handler handling all events you do not want to deal with yourself |
10:56:29 | LinusN | you get messages in a queue, and you deal with those you are interested in, and pass the rest back to the system default handler |
10:56:46 | amiconn | ..only needing to register for events that may otherwise flood the queue (e.g. timertick) |
10:56:52 | LinusN | exactly |
10:57:03 | LinusN | much simpler code |
10:57:20 | LinusN | and you don't need to bother with unregistering all the time |
10:57:27 | amiconn | But a full event system may give you some advantages |
10:57:41 | LinusN | "full" == register/unregister? |
10:58:20 | amiconn | Using one global queue (well, it would be more complex than a simple queue then) |
10:58:46 | amiconn | - The ability to handle events with or without removing them from the queue |
10:59:20 | LinusN | ... with lots of problems when several threads decide to to a "destructive read" |
10:59:24 | amiconn | - The ability to inject events as well (possibly using this system for the mpeg thread as well) |
11:00 |
11:00:03 | amiconn | - The ability to define priorities, i.e. with thread should receive an event first |
11:00:21 | LinusN | what is it that you gain with this approach? |
11:00:36 | LinusN | i see nothing but compilcated code |
11:03:41 | LinusN | for example, which thread is responsible for removing the events? |
11:04:16 | LinusN | you would probably need to have a separate thread with the lowest priority, to mop up the unhandled events |
11:04:34 | LinusN | and when should it do it? |
11:05:04 | LinusN | a thread could be in sleep() at the time, and miss the event |
11:10:39 | amiconn | If an event occurs that is registered by no thread, it should simply be discarded |
11:11:32 | amiconn | Or, if there is no registration scheme for simple events, it has to be removed at the lowest priority, yes |
11:12:18 | LinusN | so with the global queue, registration will probably be a necessity |
11:12:59 | LinusN | ok, so which thread is responsible for removing the event from the queue? |
11:13:03 | amiconn | The sleep() approach wouldn't work anymore like it does now. It could be replaced by a one-time registration for a wake up event. |
11:13:33 | uski | or maybe you could use some kiond of "interrupt" system ? |
11:13:52 | amiconn | So, either this or another event for that thread would break the sleep() |
11:13:52 | uski | sleep() would be running, but a event handler would be called in the thread, as an interrupt vectore |
11:13:53 | uski | -e |
11:14:09 | LinusN | back to the main question, what does this approach buy us? |
11:17:26 | amiconn | Imho it may provide more flexibility |
11:17:35 | LinusN | for what? |
11:17:46 | LinusN | what flexibility are we missing today? |
11:17:51 | | Quit NibbIer () |
11:20:10 | | Join [IDC]Dragon [0] (~c2af7556@reladm.kharkov.net) |
11:20:50 | amiconn | Imho it may make extending the system easier. For instance, if you introduce a BUTTON_POWEROFF now, and a plugin doesn't handle that in its default case, what does happen? |
11:20:52 | [IDC]Dragon | hi guys |
11:21:12 | LinusN | [IDC]Dragon: hi |
11:21:31 | [IDC]Dragon | I peeked in the logs a bit |
11:21:38 | LinusN | amiconn: it will not save the settings before shutting down |
11:21:54 | [IDC]Dragon | probably I come too late |
11:22:00 | midk | hm, probably a horrid idea.. but... what about a function for plugins that saves the screenbuffer to a char so you can recall it later - sort of the opposite of lcd_bitmap? |
11:22:30 | LinusN | midk: do you need it? |
11:22:35 | [IDC]Dragon | are you trying to get rid of the USB check everywhere, or what? |
11:22:46 | LinusN | no |
11:23:06 | midk | LinusN, it'd prove useful in my opinion. and yeah, i'd use it in my rockblox update more than likely. |
11:23:12 | midk | for a confirmation to restart screen |
11:23:12 | LinusN | well, amiconns idea might head in that direction |
11:23:42 | midk | void lcd_savebitmap(unsigned char *location); ? |
11:23:46 | LinusN | midk: but can't you just redraw the screen? |
11:24:05 | midk | i have to clear it to show my screen, and rockblox doesn't remember the position of the blocks |
11:24:21 | LinusN | then have it remember them |
11:24:39 | midk | or i could just forget the confirmation screen. |
11:24:40 | LinusN | how does it check the collisions then? |
11:24:57 | LinusN | for a complete row |
11:25:06 | midk | erm, it doesn't keep them drawn. |
11:25:22 | LinusN | yes, but how does it know that it has a full row? |
11:25:54 | midk | i'm actually not sure, i never understood "to_virtual" and "from_virtual" which is involved in the process |
11:26:14 | midk | and i don't feel the need to learn it. i really didn't expect anything more than "no" |
11:26:28 | midk | i was just looking to be rejected i guess :) |
11:26:29 | LinusN | imho, if you need to save and restore the screen, you might need to rework the code |
11:26:37 | midk | right. i don't want to do that |
11:26:42 | midk | saving a bitmap would do fine but.. |
11:26:47 | midk | there is no such function. |
11:27:19 | LinusN | i sound like a jedi:-) "you don't want to sell me death sticks" |
11:27:49 | midk | :D |
11:29:18 | LinusN | amiconn: which problem can't be solved with the current event approach? |
11:37:14 | [IDC]Dragon | or is this some poweroff concept? |
11:37:24 | * | [IDC]Dragon is off track |
11:39:06 | LinusN | well, i am restructuring the SYS_USB_CONNECTED handling |
11:39:39 | LinusN | so all button switch loops call default_button_handler() in the default case |
11:39:40 | midk | YAAY. |
11:39:52 | LinusN | instead of handling the SYS_USB_CONNECTED event |
11:40:18 | LinusN | this will later on allow for a SYS_POWER_OFF event |
11:40:40 | midk | it would seem my shout outs are not needed. so i will stop shouting out. |
11:40:43 | LinusN | the discussion kind of spun off from there |
11:41:07 | LinusN | midk: the project depends on your shout outs :-) |
11:41:32 | | Join HenrikB [0] (~HenrikB@as4-2-2.sjom.b.bonet.se) |
11:41:44 | LinusN | wooo, HenrikB! |
11:41:58 | LinusN | what an honour |
11:42:18 | LinusN | if you are Henrik Backe that is :-) |
11:42:20 | [IDC]Dragon | imho it would be great if this USB "exception" is transparent to the application world, but this perhaps has been discussed to death |
11:42:53 | LinusN | yes, but it is hard to hide alltogether |
11:42:53 | * | [IDC]Dragon should make myself more rare, to be greeted like such |
11:43:02 | LinusN | :-) |
11:43:09 | midk | LinusN, :) ok i'll continue |
11:43:22 | HenrikB | Sure am, I'm on vacation so know I'm able to chat during the day. |
11:43:30 | midk | yeah. stay with us HenrikB! |
11:43:36 | LinusN | [IDC]Dragon: there are two issues with USB mode: |
11:43:55 | midk | yeah.. usb mode. |
11:43:56 | midk | :)) |
11:44:09 | LinusN | 1) we must respond to the event and show the USB screen |
11:44:28 | LinusN | 2) we should reload the browser buffer afterwards |
11:44:48 | LinusN | issue 1) is hidden in the default handler |
11:44:56 | LinusN | issue 2) is not |
11:44:59 | midk | yeah. handle that.. handler. |
11:45:02 | midk | you go linus |
11:45:16 | [IDC]Dragon | 2) could be a callback, event, whatever |
11:45:44 | LinusN | yes, today all functions return a SYS_USB_CONNECTED value, or "true" |
11:46:01 | LinusN | maybe the dir browser could check a flag instead |
11:46:11 | midk | YAY |
11:46:52 | [IDC]Dragon | perhaps 3) messing with a file/dir which is in use by the box is more of a problem |
11:47:12 | LinusN | huh? |
11:47:38 | [IDC]Dragon | what if I delete the file/dir currently playing? |
11:47:53 | midk | oooooohhhh.. |
11:48:26 | LinusN | well, then it resumes with the next file in the playlist |
11:49:51 | [IDC]Dragon | I was just dreaming: in USB mode, all threads could carry on until they do disk I/O, which would cause the OS to suspend them. After USB removal, they can proceed and won't know |
11:52:23 | LinusN | interesting idea |
11:53:11 | LinusN | although the main thread would still have to act on the event, showing the usb screen |
11:53:24 | midk | yay, usb mode. |
11:53:34 | [IDC]Dragon | screen ownership is an issue, because of the USB logo |
11:53:57 | LinusN | yes, that's why the main thread does it |
11:53:58 | [IDC]Dragon | if we reqally need one, that is |
11:54:27 | [IDC]Dragon | it could be a little status bar icon like the plug |
11:54:28 | LinusN | we need a good confirmation that rockbox has released the drive |
11:55:14 | LinusN | and what do you want to do in rockbox while in USB mode? |
11:55:19 | LinusN | play a game? |
11:55:38 | [IDC]Dragon | maybe |
11:55:51 | HenrikB | Rocks=io |
11:56:01 | LinusN | exactly |
11:56:21 | [IDC]Dragon | but my main thinking is if we can make application land simpler |
11:56:21 | midk | YES |
11:56:23 | midk | pong |
11:56:25 | midk | :) |
11:56:46 | midk | is it possible to flash the red led on hd access even in usb mode? |
11:56:47 | midk | it should be. |
11:57:13 | LinusN | [IDC]Dragon: actually, most of the USB application problems are because the dir browser wants to know that the buffer needs reloading |
11:57:21 | LinusN | midk: no |
11:57:46 | | Join NibbIer [0] (~nibbler@port-212-202-78-112.dynamic.qsc.de) |
11:57:49 | midk | :[ |
11:58:03 | LinusN | and because we want to go back to the initial state after USB mode, to be safe |
11:59:09 | LinusN | so all functions are expected to return after being in usb mode |
12:00 |
12:01:39 | LinusN | and most of the time, we want to know if it returned because of USB mode |
12:05:15 | amiconn | There could be an event SYS_USB_DISCONNECTED the same way as there is SYS_USB_CONNECTED now, triggering the dir browser to reload its buffer |
12:06:25 | HenrikB | I've got a question, is mkdir("/.rockbox") added to the startup yet? |
12:06:30 | amiconn | And, iirc a plugin doesn't need to return if usb is connected, it could continue after the usb_screen() call returns |
12:06:43 | amiconn | (Off to lunch) |
12:07:15 | LinusN | HenrikB: no |
12:07:25 | LinusN | and i think it shouldn't do that |
12:07:45 | LinusN | it should instead warn the user that he hasn't installed rockbox properly |
12:09:12 | LinusN | amiconn: hmmm, interesting idea |
12:10:22 | *** | Saving seen data "./dancer.seen" |
12:12:34 | uski | a question: anyone is used to go to club ? if yes, do you know how much they sell glowsticks ? |
12:13:03 | HenrikB | If there is no .rockbox the playlist returns some nasty errors, |
12:13:40 | LinusN | HenrikB: yes, that's why we should warn |
12:14:08 | LinusN | there are more things that won't work, like the viewers, rocks etc |
12:14:18 | HenrikB | also if there is an ampty .rockbox dir all the essential function would work |
12:14:37 | HenrikB | empty |
12:15:09 | LinusN | why would the user want a crippled installation? |
12:17:09 | HenrikB | My thinking is that a crippled installation is better than non working installation |
12:17:54 | LinusN | perhaps, but i still think the warning is in place |
12:18:09 | LinusN | it could do both, but then the warning will not reappear |
12:19:02 | HenrikB | Sure is, and a big red one it should be, but if we check for the existence of .rockbox |
12:19:08 | LinusN | uski: i have no idea what glowsticks are, so my answer is no :-) |
12:19:11 | HenrikB | we might as well create it. |
12:19:37 | LinusN | that's probably the best |
12:19:49 | LinusN | HenrikB: you fix? |
12:20:20 | LinusN | a warning + create the dir |
12:20:53 | HenrikB | I'll do it, but not until next week, going to denmark for the rest of the week. |
12:21:04 | LinusN | ok, i'll do it then |
12:21:05 | | Join lImbus [0] (~manuel@kernel.cycos.net) |
12:21:36 | uski | LinusN, glowsticks are the small "tubes" that emit light when you bend them |
12:22:08 | midk | you bend them to fracture the capsule inside |
12:22:09 | uski | did u see the movie Ocean Eleven ? |
12:22:12 | uski | yea |
12:22:25 | uski | midk, do u know how much they usually sell them ? |
12:22:40 | midk | hmm, not sure. maybe 25 cents? |
12:23:01 | uski | wow, damn cheap |
12:23:09 | midk | could be 50 cents |
12:23:13 | midk | i haven't used any lately :D |
12:23:19 | uski | :) |
12:23:22 | midk | it shouldn't be any more than that. |
12:23:29 | uski | ok :\ |
12:23:39 | midk | i should write a glowsticks manpage-type thing |
12:23:44 | midk | How Glowsticks Work. |
12:23:49 | HenrikB | Time for lunch, I'll be back! |
12:23:57 | midk | see you, HenrikB |
12:24:10 | uski | midk, why ? it would be interesting if you have some chemicals equations :) |
12:24:14 | | Quit HenrikB ("Lämnar") |
12:24:41 | midk | uski: i'd just say something like "you bend them and then magic happens to light the thing up colory!" :]] |
12:24:43 | LinusN | howstuffworks.com? |
12:24:50 | midk | i considered it. |
12:25:15 | midk | i watched their "what happens if you shoot your computer monitor" video |
12:25:18 | midk | it was quite good. |
12:25:47 | uski | lol |
12:26:00 | midk | aha |
12:26:00 | midk | http://entertainment.howstuffworks.com/what-if-shoot-tv.htm |
12:26:02 | uski | hmmm i think i'll open my glowsticks and put the liquid in a transparent box |
12:26:04 | midk | good, good video. |
12:26:10 | midk | once i put it on my face |
12:26:12 | midk | it buuuuurned. |
12:26:15 | midk | i mean... |
12:26:17 | midk | :D |
12:33:31 | | Part lImbus |
12:34:36 | uski | blah i opened a glowstick :D |
12:34:51 | uski | the liquid in it is extremely bright |
12:35:21 | uski | now, i'll "paint" a paper sheet with it (it's written on the box: non toxic liquid ;)) |
12:37:56 | midk | it's fun |
12:37:57 | midk | I EAT IT |
12:37:59 | midk | i mean.. |
12:38:00 | midk | er |
12:38:24 | midk | hmm you should make a big bowl full of glow liquid and dump it on a cat. then the cat glows evilly |
12:38:37 | midk | and you can run around screaming "MY CAT IS RADIOACTIVE!!! HELP!!!!" |
12:38:38 | midk | :D:D:D |
12:39:34 | uski | lllllllllllllllllooooooooooooooooooollllllllllllllll |
12:39:52 | midk | OH |
12:40:03 | midk | bring him into the pet place |
12:40:05 | midk | the vet's |
12:40:08 | uski | i now have a glowing paper sheet :) |
12:40:12 | uski | lol |
12:40:13 | midk | and be like.. my cat is radioactive can you fix him |
12:40:13 | midk | :D |
12:46:18 | | Join lImbus [0] (~manuel@kernel.cycos.net) |
12:47:42 | midk | libmy. |
12:47:43 | midk | er |
12:47:44 | midk | limby. |
12:53:37 | lImbus | hi mikd, err mitg, err imkd, err imdk, err whatever. not talinkg about the permutations of midk2k3 and midknight2003 |
12:53:39 | lImbus | ;-) |
12:54:00 | midk | uhh. |
12:54:13 | midk | :D |
13:00 |
13:10:44 | amiconn | (back) |
13:15:19 | | Quit midk (Read error: 110 (Connection timed out)) |
13:35:40 | uski | time to break a glowstick ! :D |
13:40:44 | [IDC]Dragon | hi amiconn, u there? |
13:43:10 | amiconn | yup |
13:48:41 | [IDC]Dragon | ROMbox results are not tooo exiting |
13:48:58 | [IDC]Dragon | but at least, it doesn't need more power |
13:49:08 | [IDC]Dragon | ;-) |
13:49:37 | amiconn | No, but this was expectable. First, the upper limit would be the 10% more free RAM, as you said in your mail. |
13:51:05 | amiconn | Second, the harddisk isn't the only part drawing power. The results show that the gained runtime percentage gets smaller with longer runtimes |
13:54:21 | [IDC]Dragon | where the results of your 2 rounds somewhat close? |
13:54:43 | [IDC]Dragon | (for the same setup, I mean) |
13:56:08 | amiconn | Yes, they were, but the uncertainty was in the same range as the gained runtime (~4 %) |
13:56:33 | [IDC]Dragon | hmm, this sortof invalidates it |
13:57:28 | amiconn | Furthermore, the 10:03 runtime I measured in the very first cycle was obviously a glitch (either caused by the elevated temperature or by the fact that the cells didn't undergo a full discharge/charge cycle in the box before) |
13:59:01 | amiconn | As I wrote, the results are somewhat uncertain (and doing statistics with only 2 rounds is neither) |
13:59:58 | [IDC]Dragon | I know, but thanks a lot still |
14:00 |
14:00:38 | [IDC]Dragon | that's why you've been so quiet last days, your box was occupied by the tests ;-) |
14:00:40 | amiconn | Doing these test the proper way would either need a larger number of boxes, or much much time... |
14:01:09 | [IDC]Dragon | or some equipment to measure the energy consumption over time |
14:01:39 | | Join Guest [0] (~jirc@c66-235-14-120.sea2.cablespeed.com) |
14:01:46 | | Part Guest |
14:02:50 | amiconn | [IDC]Dragon: Yes, my box was occupied by the tests for some days. Plus, I was in a place where I did have only dialup available, which is no real fun ;-) |
14:02:59 | [IDC]Dragon | LinusN is/was working on gcc 3.4.1 |
14:03:28 | | Join _AciD [0] (~acid@longchamp44-1-82-67-133-87.fbx.proxad.net) |
14:03:42 | [IDC]Dragon | I even fail to install gcc 3.3.1 :-( |
14:04:10 | [IDC]Dragon | somehow incompatible with my cygwin |
14:04:29 | LinusN | since the battery runtime can change between charges, it is probably better to measure the actual current than the runtime |
14:04:53 | LinusN | the 3.3 series is a bitch to compile |
14:05:17 | LinusN | it has a bug where it requires libc headers for no reason |
14:05:26 | [IDC]Dragon | I didn't even copile it, was trying to use a binary |
14:05:33 | LinusN | oh |
14:05:43 | amiconn | LinusN: Yes, but this had to be done with a high time resolution, then integrated |
14:05:52 | LinusN | amiconn: yes |
14:06:11 | [IDC]Dragon | I can check for suitable equipment here |
14:06:19 | | Join AciD` [0] (~acid@longchamp44-1-82-67-133-87.fbx.proxad.net) |
14:06:56 | amiconn | [IDC]Dragon: For me, installing gcc 3.3.1 as described on the rockbox site worked without problems. Of course you have to update your cygwin installation first especially if your cygwin1.dll is rather old |
14:07:17 | amiconn | Updating cygwin with the cygwin installer is rather easy imho |
14:07:58 | [IDC]Dragon | I haven't found an installer in my setup |
14:09:00 | amiconn | How did you install cygwin without the installer? |
14:09:25 | amiconn | Btw: the installer is _not_ placed within the cygwin directory, and doesn't need to be |
14:09:32 | [IDC]Dragon | it was long ago... |
14:09:45 | [IDC]Dragon | I think it was the installer |
14:10:01 | [IDC]Dragon | it downloaded tons of stuff |
14:10:25 | *** | Saving seen data "./dancer.seen" |
14:10:27 | amiconn | Yes, and it keeps track of what it downloaded and installed |
14:10:38 | amiconn | That way, updating an installation is simple |
14:10:47 | [IDC]Dragon | but my cygwin group shows no installer now, and I didn't find an executable in the files which looks like so |
14:11:45 | LinusN | the installer is the program you used to install cygwin in the first place |
14:12:00 | LinusN | it isn't moved anywhere, it stays where you put it |
14:12:28 | [IDC]Dragon | so, it doesn't get into the installation? |
14:12:34 | LinusN | no |
14:12:47 | LinusN | you can download it again if you wish |
14:12:59 | [IDC]Dragon | I'll try that |
14:13:29 | LinusN | but you should also try to find the directory with the installation info that setup.exe created when you installed it |
14:13:41 | LinusN | in the same dir as the instellr |
14:13:47 | | Join midk [0] (~midk@c66-235-14-120.sea2.cablespeed.com) |
14:13:51 | LinusN | but i don't think it's necessary |
14:14:11 | [IDC]Dragon | for the versioning, it may |
14:15:08 | [IDC]Dragon | is gcc 3.4.1 "officially" supported now? |
14:15:27 | amiconn | LinusN: I found a glitch in the wiki web statistics when updating the voice files last night: The wiki "credits" me two changes for each file upload |
14:15:42 | LinusN | [IDC]Dragon: in rockbox? yes |
14:16:02 | LinusN | amiconn: cool! now i know how to boost my stats! :-) |
14:16:13 | amiconn | LinusN: Does gcc 3.4.1 generate better code than 3.3.1 ? |
14:16:30 | LinusN | i don't know, i have never succeeded in compiling 3.3.1 :-) |
14:16:37 | [IDC]Dragon | I think you two have to try a gcc "shootout" |
14:17:34 | amiconn | That requires me to compile 3.4.1 myself, or is there a cygwin package available now? |
14:17:44 | LinusN | i don't know |
14:18:04 | LinusN | check with eric lassauge |
14:18:22 | LinusN | nope, only 3.3.1 |
14:18:26 | LinusN | just checked |
14:19:34 | LinusN | i have now completed my first step in the default handler project |
14:20:24 | LinusN | all (or most) "case SYS_USB_CONNECTED:" have been moved to the default case instead, with a call to default_event_handler() |
14:21:05 | [IDC]Dragon | Linus, Jens, you could compile todays tarball, Linus with 3.4.1, Jens with 3.3.1, and compare |
14:21:36 | | Quit _AciD (Connection timed out) |
14:21:44 | LinusN | i can compile the current cvs |
14:22:19 | | Quit midk ("Leaving") |
14:22:20 | amiconn | [IDC]Dragon: Iirc, gcc 3.3.1 is also what you get when you install BlueChip's devkit |
14:23:57 | LinusN | which one should i build? |
14:24:00 | LinusN | fm recorder? |
14:24:20 | | Join midk [0] (~midk@c66-235-14-120.sea2.cablespeed.com) |
14:25:02 | amiconn | LinusN: As you like, just tell me |
14:25:16 | LinusN | took 26 seconds to build |
14:25:20 | LinusN | fm recorder |
14:25:39 | LinusN | ajbrec.ajz: 188108 bytes |
14:29:38 | amiconn | fm recorder, current cvs, 2 MB, normal, english: took 70 seconds to build, ajbrec.ajz: 185884 bytes |
14:30:12 | amiconn | (Of course the build times are in no way comparable) |
14:30:41 | LinusN | interesting |
14:31:14 | LinusN | your is a lot smaller |
14:32:30 | LinusN | i wonder what 3.3.1 does to make it that small |
14:32:31 | [IDC]Dragon | hmm, lesson is don't use 3.4 ? |
14:33:02 | LinusN | amiconn: are you sure that you built a clean current cvs? |
14:33:17 | | Quit midk (Remote closed the connection) |
14:33:26 | [IDC]Dragon | without geek bitswap? |
14:33:35 | LinusN | a clean current cvs |
14:33:44 | LinusN | no changes at all |
14:33:47 | amiconn | [IDC]Dragon: That lesson is definitely valid on other platforms, as reported by numerous users. E.g. gcc 3.4.x has a number of "new" bugs at least on ppc |
14:33:54 | | Join midk [0] (~midk@c66-235-14-120.sea2.cablespeed.com) |
14:34:45 | amiconn | LinusN: Yes, that was plain current cvs. I have two local cvs copies, one of them being a plain unmodified one. |
14:34:53 | | Quit midk (Remote closed the connection) |
14:34:55 | | Join midk [0] (~midk@c66-235-14-120.sea2.cablespeed.com) |
14:35:03 | LinusN | wow |
14:39:48 | amiconn | If I compile with oldish gcc 3.0.4, fm recorder, same settings otherwise: build time 51 seconds, ajbrec.ajz: 190824 bytes |
14:43:17 | LinusN | i wonder what -Os would yield... |
14:44:26 | | Quit [IDC]Dragon ("no fate but what we make (EOF)") |
14:46:33 | lImbus | will my rockbox use rombox if I flash a todays build ? |
14:47:08 | lImbus | I plan to record this evening and the next days, but want to update (for sorting and soft-off). |
14:47:28 | LinusN | lImbus: rombox is not official |
14:49:39 | lImbus | but in cvs, isn't it ? |
14:54:52 | LinusN | no |
15:00 |
15:01:07 | amiconn | lImbus: For building rombox, you need to link with a special linker script after compiling, then create an .ucl from rockbox.bin with a special version of uclpack with understands the −−none option |
15:01:42 | lImbus | ok. |
15:02:01 | lImbus | could there be any interference that get's my ucl-file 5 KB small ? |
15:02:05 | amiconn | I updated the rombox build last night, and there is now a build for the v2 which _should_ work |
15:02:09 | lImbus | i won't try to flash with that |
15:03:21 | amiconn | The .ucl should be a few bytes larger than the rockbox.bin, around 180 KB for v1, 184 KB for v2 |
15:04:33 | lImbus | yeah, but it's not, so where could be the problem. havn't played/tampered with my local cvs for a while. |
15:06:41 | amiconn | A normal .ucl (not rombox) is usually around 110 KB |
15:12:05 | lImbus | mine is 5 bytes long |
15:12:18 | lImbus | it contains the word "fake" in simple ascii chars |
15:12:54 | elinenbe | lImbus: you need to have the uclpack binary in your path. |
15:13:02 | lImbus | even with a new build-dir and ../tools/configure |
15:13:06 | lImbus | I had all the time |
15:13:21 | lImbus | BASH: ucl: command not found |
15:13:33 | lImbus | what the hell went wrong ? |
15:17:35 | LinusN | simple, you don't have ucl.exe |
15:19:05 | lImbus | with windows explorer, I see about 25 files with touch, uclpack, patch, cvs and so on. |
15:19:24 | lImbus | w:\rockbox\usr\bin that is |
15:19:53 | lImbus | in cygwin I see a lot files more, but nothing like ucl in /usr/bin> |
15:20:20 | lImbus | and it worked before ! |
15:21:58 | | Quit midk ("Leaving") |
15:22:04 | | Join midk [0] (~midk@c66-235-14-120.sea2.cablespeed.com) |
15:25:19 | | Quit midk (Remote closed the connection) |
15:25:27 | | Join midk [0] (~midk@c66-235-14-120.sea2.cablespeed.com) |
15:25:44 | | Quit midk (Read error: 104 (Connection reset by peer)) |
15:26:43 | LinusN | i guess uclpack.exe is what you want |
15:27:15 | LinusN | the special −−none version, that is |
15:27:20 | | Join midk [0] (~midk@c66-235-14-120.sea2.cablespeed.com) |
15:27:31 | lImbus | I think so. but I can't get access to it. can't call it with ./uclpack if I sit in the directory where windows says it's in. |
15:28:33 | lImbus | I just verified it's installed. cygwin-setups says I got version 1.01 or something like that. |
15:29:00 | LinusN | so you cd to the directory and type ./uclpack.exe and nothing happens? |
15:29:45 | midk | am i the only one that finds this line *really* funny? |
15:29:47 | midk | "Make sure you have sh-elf-gcc and siblings in the PATH." |
15:30:04 | LinusN | you mean "siblings"? |
15:30:25 | midk | it's just funny. |
15:30:26 | lImbus | LinusN: yes. it says BASH: uclpack.exe not found |
15:30:45 | LinusN | and if you type "ls" it is there? |
15:32:04 | lImbus | no. it's not there, but windows says it is, along with other files |
15:32:38 | lImbus | how to see what's inside %path% in cygwin ? |
15:35:00 | | Quit midk (Remote closed the connection) |
15:35:05 | | Join midk [0] (~midk@c66-235-14-120.sea2.cablespeed.com) |
15:35:29 | lImbus | midk: are you ok ? |
15:35:39 | midk | a bit tired. |
15:35:47 | midk | but yes. |
15:38:20 | | Nick midk is now known as midk|sleep (~midk@c66-235-14-120.sea2.cablespeed.com) |
15:38:27 | midk|sleep | nite |
15:38:31 | * | midk|sleep is away: sleep. |
15:38:46 | lImbus | nite |
15:39:08 | lImbus | LinusN: ls in /usr/bin shows the same content as ls in /bin |
15:39:39 | lImbus | but /usr/bin is really existing on my windows-fs and there is no indication for a symlink |
15:40:01 | lImbus | should I copy the contect of /usr/bin to /bin ? *wonder* |
15:42:25 | LinusN | lImbus: as long as it's in your PATH, everything should be ok |
15:42:54 | LinusN | lImbus: don't rely on what Windows says |
15:43:19 | lImbus | hey, I am running cygwin in windows, not the other way round |
15:43:21 | lImbus | :-) |
15:43:25 | lImbus | copyied uclpack to /bin and to /bin/ucl.exe to be sure. |
15:43:25 | LinusN | put the executable somewhere in your cygwin path |
15:43:54 | lImbus | now I can call ucl and uclpack from the ~/build-dir/ but make does not pack it yet. |
15:44:03 | lImbus | it's still 5 bytes long |
15:44:12 | LinusN | is it in the PATH? |
15:44:22 | lImbus | Imbushow to see what's inside %path% in cygwin ? |
15:44:35 | LinusN | echo $PATH |
15:44:48 | lImbus | ouch |
15:45:07 | lImbus | path seems to be very empty. but I can call ucl from the build-dir ?!? |
15:45:21 | LinusN | remove rockbox.ucl and make again |
15:45:49 | lImbus | ahh. well. |
15:45:55 | lImbus | nice. now I got one |
15:46:10 | lImbus | nobody knows how that could work if my $path is empty |
15:46:36 | LinusN | did you type "echo $path" or "echo $PATH"? |
15:46:49 | lImbus | argl. case sensitive |
15:47:03 | LinusN | why do you think i wrote echo $PATH? |
15:47:33 | | Join HenrikB [0] (~HenrikB@as4-2-2.sjom.b.bonet.se) |
15:47:35 | LinusN | i don't write anything else in upper case when i'm in irc |
15:47:41 | lImbus | hehe. sorry, not used to that thingy. |
15:48:02 | HenrikB | Hi again |
15:48:14 | lImbus | $PATH contains pretty much everything needed. as well as both /usr/bin and /bin |
15:48:52 | LinusN | hi HenrikB |
15:49:02 | | Join quelsaruk [0] (~notca@ZN165209.ppp.dion.ne.jp) |
15:49:11 | LinusN | quelsaruk: welcome! |
15:49:13 | quelsaruk | hi good morning |
15:49:18 | quelsaruk | or good night here in japan |
15:49:20 | quelsaruk | :) |
15:49:24 | lImbus | hi |
15:49:24 | LinusN | ah |
15:49:35 | LinusN | where in japan? |
15:49:37 | HenrikB | morning |
15:49:42 | quelsaruk | just wanted to say hello |
15:49:54 | quelsaruk | right now in Kyushu |
15:50:20 | quelsaruk | tomorrow im going to Kyoto |
15:50:34 | quelsaruk | see you linus... and everyone |
15:54:02 | | Part quelsaruk |
15:55:10 | HenrikB | LinusN, I've got a small codesaver, I've replaced the id3_browse() with the id3edit rock patch. |
15:56:11 | HenrikB | but the patch must have my onplay() patch for wps applied first. |
16:00 |
16:00:05 | LinusN | HenrikB: yeah, lifting out the id3 browser might be a good idea |
16:09:16 | HenrikB | LinusN, it saves ~750 bytes with gcc 3.3.1 |
16:10:26 | *** | Saving seen data "./dancer.seen" |
16:20:20 | | Join [IDC]Dragon [0] (~c2af7555@reladm.kharkov.net) |
16:20:43 | [IDC]Dragon | ah, CGIIRC works again |
16:20:52 | [IDC]Dragon | I got kicked out |
16:23:24 | | Quit AciD` (Read error: 104 (Connection reset by peer)) |
16:40:19 | | Join elinenbe_ [0] (elinenbe_@207-237-224-177.c3-0.nyr-ubr1.nyr.ny.cable.rcn.com) |
16:45:59 | | Join dstar5 [0] (~Lee@ACC55472.ipt.aol.com) |
16:50:27 | | Join Ericgoh [0] (~kapipo@p6147-adsau14honb7-acca.tokyo.ocn.ne.jp) |
16:58:22 | | Quit elinenbe (Read error: 110 (Connection timed out)) |
16:58:23 | | Nick elinenbe_ is now known as elinenbe (elinenbe_@207-237-224-177.c3-0.nyr-ubr1.nyr.ny.cable.rcn.com) |
16:58:28 | dstar5 | LinusN: compiling for target is giving me an error at linking |
16:59:35 | LinusN | dstar5: and the error is...? |
17:00 |
17:00:31 | dstar5 | i amg getting to it |
17:00:34 | dstar5 | it is about ld |
17:02:39 | dstar5 | LinusN: |
17:02:40 | dstar5 | ox-devel/build/rockbox.map |
17:02:40 | dstar5 | collect2: cannot find `ld' |
17:02:40 | DBUG | Enqueued KICK dstar5 |
17:02:40 | dstar5 | make[1]: *** [/home/Lee/rockbox-devel/build/rockbox.elf] Error 1 |
17:02:40 | dstar5 | make[1]: Leaving directory `/home/Lee/rockbox-devel/apps' |
17:02:40 | *** | Alert Mode level 1 |
17:02:40 | dstar5 | make: *** [apps] Error 2 |
17:02:41 | *** | Alert Mode level 2 |
17:02:41 | dstar5 | Lee@home ~/rockbox-devel/build |
17:02:47 | dstar5 | $ ld |
17:02:49 | dstar5 | ld: no input files |
17:03:44 | | Join mecraw___ [0] (~lmarlow@69.2.235.2) |
17:04:52 | dstar5 | LinusN: any ideas? |
17:08:27 | LinusN | dstar5: are you using bc:s devkit or what? |
17:08:40 | dstar5 | no |
17:08:49 | dstar5 | standard cygwin install |
17:09:16 | dstar5 | with gcc 3.4 and binutils 1.15 for sh-elf built myself |
17:09:37 | LinusN | i find it odd that it tries to use ld and not sh-elf-ld |
17:10:19 | LinusN | did you use the same prefix for both gcc and binutils? |
17:12:42 | *** | Alert Mode OFF |
17:12:53 | dstar5 | yes |
17:13:17 | LinusN | type this: |
17:13:23 | LinusN | sh-elf-gcc −−version |
17:13:30 | LinusN | sh-elf-ld −−version |
17:14:19 | dstar5 | umm for some reason sh-elf-ld says command not found |
17:14:33 | dstar5 | sh-elf-gcc (GCC) 3.4.0 |
17:15:52 | dstar5 | thats strange... |
17:16:27 | dstar5 | i have all the other binutils tools i think |
17:16:32 | dstar5 | ar, as... |
17:17:53 | LinusN | sh-elf-ar? |
17:18:33 | LinusN | if sh-elf-ld is missing, your installation of binutils must have failed |
17:18:58 | dstar5 | GNU ar 2.15... |
17:20:07 | dstar5 | ill just rebuild |
17:24:10 | dstar5 | i get patch for gcc 3.4.1 also... |
17:28:07 | [IDC]Dragon | cu, folks |
17:28:14 | | Quit [IDC]Dragon ("no fate but what we make") |
17:32:42 | | Quit Ericgoh (Read error: 60 (Operation timed out)) |
18:00 |
18:08:55 | | Part LinusN |
18:10:30 | *** | Saving seen data "./dancer.seen" |
18:13:24 | | Part HenrikB ("Lämnar") |
18:24:08 | | Join _AciD [0] (~acid@82.67.133.87) |
19:00 |
19:09:09 | | Quit _AciD (Read error: 110 (Connection timed out)) |
19:09:09 | | Quit NibbIer (Read error: 54 (Connection reset by peer)) |
19:28:56 | | Quit dstar5 ("Leaving") |
19:53:27 | | Join scott666_ [0] (~scott666@c-24-245-58-48.mn.client2.attbi.com) |
20:00 |
20:10:31 | *** | Saving seen data "./dancer.seen" |
20:25:27 | | Join _AciD [0] (~acid@longchamp44-1-82-67-133-87.fbx.proxad.net) |
20:32:37 | | Join NibbIer [0] (~nibbler@port-212-202-78-112.dynamic.qsc.de) |
20:43:03 | | Join Tunsnask [0] (~gammel_ma@cpe.atm2-0-1041160.0x503f9f66.arcnxx9.customer.tele.dk) |
20:47:24 | | Quit Tunsnask (Client Quit) |
20:57:49 | | Join zeekoe [0] (~zeekoe@ip51cc69f6.adsl-surfen.hetnet.nl) |
20:59:56 | | Quit zeekoe ("aAA44AArrgGGHhh... my computer just did something _really_ REALLY wrong... cu later") |
21:00 |
21:00:27 | | Join zeekoe [0] (~zeekoe@ip51cc69f6.adsl-surfen.hetnet.nl) |
21:00:31 | | Quit _AciD (Connection timed out) |
21:04:05 | | Join _AciD [0] (~acid@longchamp44-1-82-67-133-87.fbx.proxad.net) |
21:14:40 | | Join gromit`` [0] (augej@ulysse.iiens.net) |
21:15:02 | gromit`` | coucou |
21:15:07 | gromit`` | hello |
21:15:11 | | Join Smooth [0] (909510b8@ACBAED29.ipt.aol.com) |
21:21:21 | Smooth | hi |
21:21:34 | Smooth | Why the "Shutdown" option when holding the OFF button does the same job? |
21:22:53 | | Join LinusN [200] (~linus@labb.contactor.se) |
21:23:23 | LinusN | Smooth: u there? |
21:24:00 | Smooth | yea linus |
21:24:02 | LinusN | the shutdown option saves the settings and spins down the hard drive before turning off |
21:24:08 | Smooth | oh ok |
21:24:15 | Smooth | just was wondering |
21:24:53 | LinusN | amiconn: u there? |
21:25:07 | Smooth | man that gmini220 wipes the floor with the ipod |
21:25:13 | | Join Tunsnask [0] (~gammel_ma@cpe.atm2-0-1041160.0x503f9f66.arcnxx9.customer.tele.dk) |
21:25:14 | amiconn | LinusN: I'm here |
21:25:39 | LinusN | i'm changing the SYS_USB_CONNECTED behaviour of the plugins |
21:25:54 | LinusN | i can't decide if the plugins should exit or not |
21:26:07 | Smooth | linus whats this new "First step in revamping the USB event handling, paving the way for the upcoming SYS_POWER_OFF event"? |
21:26:31 | LinusN | i think they could continue running, but have to return PLUGIN_USB_CONNECTED when they eventually return |
21:27:09 | LinusN | Smooth: it's mainly for the FM and V2 recorders, that can trap the Hold-OFF and save the settings when the user holds OFF |
21:27:18 | Smooth | ok |
21:27:19 | Smooth | cool |
21:27:46 | Smooth | archos rules |
21:28:10 | amiconn | LinusN: I'd say this depends on the plugin, if it makes sense to keep it running when usb is connected |
21:28:34 | amiconn | Would the plugin be "interrupted", displaying the usb screen in that case? |
21:28:43 | LinusN | amiconn: no, it should show the usb screen as usual, but they may continue running afterwards |
21:29:12 | LinusN | instead if immediately returning PLUGIN_USB_CONNECTED |
21:29:12 | LinusN | of |
21:29:24 | amiconn | This may lead to at least 2 problems: |
21:29:50 | LinusN | the plugin calls the default handler, like the normal rockbox code, but it may continue running after the USB screen si finished |
21:29:52 | amiconn | (1) The plugin has to handle the usb event, because it has to redraw the screen afterwards |
21:30:51 | amiconn | (2) Same problem arises for all plugins using grayscale (not that hard to handle there, as long as _only_ grayscale is displayed) |
21:31:19 | LinusN | all plugins handle the USB event today |
21:31:29 | Smooth | archos must be the only company that supports simple drag-n-drop to its HD rather than using DRM software |
21:31:33 | LinusN | they just handle it differently, most of them just return |
21:31:42 | amiconn | Yes, but they usually don't redraw the screen, as they exit afterwards |
21:31:48 | LinusN | Smooth: there are a few others as well |
21:31:57 | Smooth | can't think of any others |
21:32:02 | Smooth | apart from iriver |
21:32:32 | LinusN | amiconn: the calendar continues |
21:32:56 | amiconn | Oops, wasn't aware of that one (I don't use it) |
21:32:56 | LinusN | i was just thinking of what should be the requirement |
21:33:18 | LinusN | i don't think we should force the plugins to exit |
21:33:48 | amiconn | I think it should be handled as it is now, let the plugin decide whether to exit or not |
21:33:54 | LinusN | good |
21:33:59 | LinusN | then we agree |
21:34:11 | Ctcp | Ignored 1 channel CTCP requests in 0 seconds at the last flood |
21:34:11 | * | LinusN goes back to editing all plugins |
21:34:52 | lImbus | bye guys, I'm off for home |
21:34:57 | amiconn | There will still be a problem with the grayscale plugins, since in case an usb event is detected, they have to execute code _before_ the usb screen is displayed |
21:34:58 | LinusN | lImbus: bye |
21:35:15 | LinusN | then they can easily trap the USB event themselves |
21:35:20 | | Part lImbus |
21:35:34 | LinusN | and then call default_event_handler(SYS_USB_CONNECTED); |
21:35:50 | LinusN | the recording code does that, for example |
21:37:14 | amiconn | Perhaps I could integrate a function to simplify that for the developer into the grayscale framework |
21:37:36 | LinusN | grayscale_default_handler()? |
21:38:06 | amiconn | yup, something like that |
21:39:25 | amiconn | There could also be another plugin lib function that does screen backup/restore into a memory area supplied by the plugin |
21:39:37 | amiconn | ...for b&w graphics |
21:39:52 | | Nick midk|sleep is now known as midk (~midk@c66-235-14-120.sea2.cablespeed.com) |
21:39:54 | midk | mornin |
21:39:55 | midk | g |
21:40:16 | amiconn | midk: evening ;) |
21:40:23 | LinusN | amiconn: to restore the screen? |
21:40:29 | amiconn | LinusN: yes |
21:40:43 | LinusN | i think we should increase the plugin memory space |
21:40:56 | zeekoe | evening :) |
21:40:56 | LinusN | 64K |
21:41:25 | amiconn | LinusN: I would do this only if it is absolutely necessary for a plugin. |
21:41:27 | zeekoe | midk: it's been midday at you place |
21:41:32 | midk | :) |
21:41:44 | midk | zeekoe, true, but i was up til 6:50am |
21:41:57 | LinusN | poor bluechip is struggling to fit his stuff in the 32K |
21:42:21 | amiconn | LinusN: I it a real challenge (in a positive sense) to fit all functions into 32K |
21:42:32 | LinusN | :-) |
21:43:07 | amiconn | Jörg managed to fit a complete jpeg decoder _and_ the grayscale framework into 32K |
21:43:21 | amiconn | There is even some room left for extension |
21:43:22 | LinusN | lcd_save_framebuffer()/lcd_restore_framebuffer()? |
21:43:38 | zeekoe | midk: sick... |
21:43:42 | LinusN | midk: your dream may come true :-) |
21:43:46 | zeekoe | midk: don't you have to work... |
21:44:29 | LinusN | lcd_save_framebuffer(char*buf); |
21:44:29 | amiconn | LinusN: Yes, but if I think about it, this would only be a few lines, probably not worth putting into functions. |
21:44:41 | LinusN | is the frame buffer exported? |
21:44:50 | amiconn | After all, these are simple memcpy() calls |
21:45:09 | amiconn | 896 bytes |
21:45:22 | midk | LinusN, i dreamed i was saving some lady from lots of i,robots |
21:45:26 | midk | :\ |
21:45:27 | LinusN | actually, usb_screen() could do it |
21:45:30 | midk | it probably will. |
21:45:51 | | Join Strath [0] (~mike@dgvlwinas01pool0-a251.wi.tds.net) |
21:46:12 | amiconn | LinusN: Yes, lcd_framebuffer is exported |
21:46:20 | LinusN | it may not work that well on the player, though |
21:47:02 | Smooth | moprninh |
21:47:04 | Smooth | morning |
21:47:10 | LinusN | evening |
21:47:18 | Smooth | eveing then |
21:47:20 | amiconn | LinusN: Ooops, I forgot the player. |
21:47:31 | zeekoe | evening |
21:47:31 | | Part Strath |
21:47:43 | LinusN | well, i think the player has a "frame buffer" too now |
21:47:54 | LinusN | used by the rocklatin framework |
21:48:00 | Smooth | do players still exist? |
21:48:06 | LinusN | i have two |
21:48:19 | Smooth | thought they would be obselete by now |
21:48:22 | | Quit _AciD ("http://frbattle.free.fr/mixs/samedi%2012%20juillet%2013-14%20heures%20angle%20mort/AciD%20vs%20Formax%20-%20Live@prun'%20radi) |
21:48:40 | LinusN | there are quite a few of them out there |
21:49:03 | zeekoe | LinusN talked me out of buying a player :-) |
21:49:05 | Smooth | 2 lines of character cells? thats just GAY! |
21:49:08 | zeekoe | Thanks, Linus!!! :-) |
21:49:11 | LinusN | :-) |
21:49:45 | Smooth | midk talks people out of buying ipods |
21:50:18 | zeekoe | :-P |
21:50:38 | zeekoe | Smooth: and of buying what things do you talk people out? |
21:50:55 | Smooth | talk people out of buying anything made by Creative Labs |
21:51:42 | zeekoe | :-P |
21:52:05 | zeekoe | i thought about buying a creative dap jukebox, about 2 years ago |
21:52:15 | zeekoe | glad i didnt buy it, it's huge |
21:52:18 | Smooth | used to have one myself before the archos |
21:52:24 | Smooth | and the battery life is piss-poor |
21:52:37 | midk | pissypoxypissy? |
21:52:44 | zeekoe | is it? |
21:52:53 | Smooth | only 4 hours |
21:52:55 | zeekoe | ... |
21:53:08 | zeekoe | i really like the long playing time of the archos |
21:53:19 | Smooth | and the software required to send music to the DAP is bad, bad, bad |
21:53:26 | zeekoe | i had a lennox power one, it only had 2-3 hours on 2 batts... |
21:53:41 | Smooth | you have to log in all your MP3 files and send them only in small spoonfuls |
21:53:49 | zeekoe | FAT support r00lz |
21:53:49 | Smooth | if you try and send the whole lot in one go, it crashes |
21:53:59 | zeekoe | bad |
21:54:02 | amiconn | Actually, the Archos was the first hd mp3 player that fulfilled my primary requirement: putting music on it must not require special software |
21:54:20 | Smooth | yea |
21:54:21 | LinusN | same here |
21:54:30 | amiconn | (especially as I did not own an x86 pc at that time) |
21:54:33 | LinusN | that's the main reason i chose archos |
21:54:34 | Smooth | im sure that pleased the record-companies |
21:54:39 | zeekoe | amiconn: what did you own? |
21:54:43 | LinusN | amiga |
21:54:47 | zeekoe | wheeeeeeeeeeee |
21:54:50 | amiconn | yup |
21:54:50 | zeekoe | amiga r00lz |
21:54:58 | zeekoe | :P |
21:55:02 | LinusN | i have one A500 and one A4000 |
21:55:03 | zeekoe | amiga with usb? |
21:55:12 | amiconn | My amiga is still up and running 24/7 |
21:55:17 | zeekoe | cool |
21:55:20 | amiconn | Yes, with usb |
21:55:22 | LinusN | not mine :-( |
21:55:32 | Smooth | mi |
21:55:35 | zeekoe | usb isnt that long available on amiga, is it |
21:55:38 | zeekoe | hmm |
21:55:53 | zeekoe | 2 years or so, now i think of it |
21:56:06 | * | zeekoe translated some stuff for OS4 to Dutch |
21:56:24 | amiconn | I bought a Highway card (4 ports usb 1.1 for the Amiga Zorro bus) a little more than 2 years ago, the same time when I bough my Archos |
21:56:25 | LinusN | amiconn: i'm thinking of adding a lib function for saving the lcd frame buffer |
21:56:39 | amiconn | *bought |
21:56:48 | Smooth | hardly change their size when you further compress them using GZIP |
21:57:02 | LinusN | seems a little clearer in the code |
21:57:34 | LinusN | complete with a buffer for storage |
21:57:49 | LinusN | won't be linked if not used |
21:58:37 | amiconn | LinusN: If you want to make this work for the player as well, you would have to export whatever lcd buffer is used there |
21:58:52 | LinusN | and the plugin wouldn't have to care about the player issues |
21:59:03 | Smooth | who changed the progress bar from the slider to the Ipod-style ba? |
21:59:04 | Smooth | bar? |
21:59:07 | LinusN | yes |
21:59:27 | LinusN | i didn't know ipod had one |
21:59:42 | LinusN | then i wouldn't have done it :-) |
21:59:44 | Smooth | the progbar on the ipod slowly fills rather having a slide |
21:59:44 | Smooth | r |
22:00 |
22:00:08 | LinusN | i think the current one looks better |
22:00:11 | Smooth | basically the new progbar works the same as the ipods |
22:00:31 | Smooth | hey i have a new idea for a progbar |
22:00:45 | Smooth | why not have the screen invert from left to right like the invert on the clock plugin |
22:00:46 | Smooth | ? |
22:01:06 | zeekoe | the clock plugin has cool new features? |
22:01:08 | LinusN | looks awful imho |
22:01:09 | * | zeekoe checks out |
22:01:23 | Smooth | u know what i mean linus? |
22:01:31 | Smooth | the left-to-right invert on the clock plugin? |
22:01:55 | LinusN | i know |
22:01:59 | Smooth | im sure mikeholden thought it was a good idea when he revamped the plugin |
22:02:05 | LinusN | mikeholden? |
22:02:15 | Smooth | its his plugin |
22:02:27 | LinusN | id midk and mikeholden the same person? |
22:02:29 | LinusN | is |
22:02:35 | midk | hm? |
22:02:41 | midk | oh |
22:02:42 | midk | no. |
22:02:43 | Smooth | well both start with mi and have a k |
22:02:58 | midk | track's in his little .. world.. again. :) |
22:03:35 | amiconn | Imho the clock plugin shows what happens if you don't care for code size (sorry midk). It is the second largest plugin code-wise, much larger than what I would expect concerning its functionality |
22:03:52 | Smooth | we could have a world-time plugin |
22:03:54 | LinusN | :-) |
22:03:57 | midk | amiconn: wait till i add atomic synchronization :) |
22:03:58 | Smooth | like on some digital watches |
22:04:07 | midk | that's when i'll hit that barrier. |
22:04:19 | zeekoe | you need a receiver for that... or a computer |
22:04:26 | Smooth | moody mikeholden |
22:04:35 | midk | honestly, i'm going to finish fuzzy mode then optimize what i have |
22:04:45 | midk | i can take out some old code. the logos can also go |
22:04:53 | zeekoe | some guys at my school made a thing to _send_ dcf-77 (atomic clock) signals... they were able to change the time :-P |
22:04:56 | midk | duplicate code could be moved to a different function |
22:05:41 | Smooth | fuzzy logic? |
22:05:49 | midk | no, fuzzy. |
22:06:42 | Smooth | pl |
22:06:43 | Smooth | ok |
22:09:04 | amiconn | LinusN: Could you please send me an example of rockbox, compiled with gcc 3.4.1, along with the corresponding .map file? |
22:09:30 | amiconn | I'm curious _why_ gcc 3.4.1 produces larger binaries than gcc 3.3.1 |
22:09:44 | LinusN | indeed |
22:09:50 | amiconn | I'd prefer something that I know well, e.g. the grayscale.rock |
22:10:34 | *** | Saving seen data "./dancer.seen" |
22:10:55 | LinusN | email? |
22:11:23 | amiconn | yup. |
22:11:48 | amiconn | I already have a suspicion what may cause this... |
22:12:29 | | Quit midk ("Leaving") |
22:14:09 | | Join midk [0] (~midk@c66-235-14-120.sea2.cablespeed.com) |
22:14:11 | | Join AciD` [0] (~acid@longchamp44-1-82-67-133-87.fbx.proxad.net) |
22:15:26 | zeekoe | speaking of grayscale... |
22:15:36 | zeekoe | i tried converting some movie about 2 weeks ago |
22:15:41 | zeekoe | it's a 25 fps movie |
22:15:52 | zeekoe | but it ran way too fast (2 times or so) |
22:16:16 | zeekoe | so i tried setting the input frame rate to 25, and the output frame rate to 25 |
22:16:38 | zeekoe | got a really weird movie, not really what one could call greyscale. |
22:16:54 | zeekoe | tried again, but then using 25 fps in, 67 fps out |
22:16:56 | midk | don't change the output frame rate. or don't put it that low.. |
22:16:58 | midk | yeah |
22:17:00 | zeekoe | same, weird result |
22:17:10 | midk | hm |
22:17:25 | zeekoe | it _should_ be possible to change it, isnt it? |
22:17:29 | amiconn | zeekoe: Using the command line tool suite or the DirectShow filter? |
22:17:38 | zeekoe | uh |
22:17:42 | zeekoe | directshow filter? |
22:17:55 | amiconn | If it is the latter, I'm afraid I can't help, since I never used that |
22:17:56 | zeekoe | just the command line thingy |
22:18:07 | zeekoe | what's the ds filter? |
22:19:09 | amiconn | The DirectShow filter is a windows thingy, usable with all video processing tools that use Microsoft's DirectShow architecture, that is able to produce .rvf files, with sound |
22:19:19 | amiconn | If the so |
22:19:42 | zeekoe | whoops... empty batteries... |
22:19:43 | zeekoe | brb |
22:20:00 | amiconn | ..urce sound format is not mp2 or mp3, it does additionally require the lame DirectShow encoder |
22:20:07 | amiconn | (iirc) |
22:20:19 | zeekoe | i think i have that |
22:20:27 | zeekoe | brb |
22:26:01 | zeekoe | hey, i see the directshow thing on the site |
22:26:15 | zeekoe | i'll try that first |
22:32:28 | zeekoe | hmm... it's 1x real time :-/ |
22:38:31 | Tunsnask | how do i set my recorder on HOLD? |
22:42:08 | midk | at the wps, F1+down |
22:42:51 | zeekoe | cool! didnt know that :) |
22:43:32 | Tunsnask | thanks |
22:45:07 | | Quit Tunsnask () |
22:45:25 | zeekoe | hmm... i think i did something wrong last time, now the video is fine |
22:45:31 | zeekoe | still way out of sync though |
22:45:53 | zeekoe | does it matter the audio is 22khz, stereo? |
22:46:59 | amiconn | It shouldn't. I converted a number of movies, even very long ones, and always got the audio in sync. |
22:47:18 | midk | reboot brb |
22:47:20 | amiconn | But then I use the command line tool suite to do the conversion... |
22:47:20 | | Quit midk ("Leaving") |
22:48:42 | zeekoe | hmm weird |
22:48:51 | zeekoe | yeah, i'm using the command line stuff too, again |
22:49:03 | zeekoe | the directshow thingy did really weird |
22:49:23 | zeekoe | it continued to play even a minute after the movie ended |
22:49:24 | amiconn | Of course, using the command line tools requires quite a number of steps to convert a movie though |
22:49:39 | zeekoe | first convert to 112x64 |
22:49:47 | zeekoe | then avi2yuv |
22:49:50 | zeekoe | then halftone |
22:49:53 | amiconn | This is what I do when converting a dvd: |
22:49:54 | zeekoe | then rvf_mux |
22:50:23 | amiconn | (1) Rip the dvd and demux into an .m2v and an .ac3 file |
22:51:16 | | Join midk [0] (~midk@c66-235-14-120.sea2.cablespeed.com) |
22:51:18 | amiconn | (2) Convert the .m2v into an 112x64 avi (cropping & scaling to get the aspect right and get rid of the black bars) |
22:51:34 | amiconn | I'm using Avisynth and VirtualDub for that |
22:52:13 | amiconn | If the resulting Avi would be larger than 2 GB (I use Intel YUV format), it has to be splitted into 2 GB segments |
22:52:55 | amiconn | (3) Convert the avi to yuv with avi2yuv. Size will be almost the same after that if you use Intel yuv in the avi |
22:53:15 | amiconn | This has to be done for every segment |
22:53:30 | zeekoe | (sorry for interrupting...) wheeeeeeee! totally in sync now! i converted 22khz, 8bit to 44k1, 16bit |
22:54:14 | amiconn | Ok, good. Should I stop here? |
22:54:23 | zeekoe | you may continue :) |
22:54:35 | zeekoe | you forgot the audio part :P |
22:54:46 | amiconn | (4) Use halftone to convert to video-only .rvf format |
22:55:20 | | Quit Smooth (Read error: 104 (Connection reset by peer)) |
22:55:38 | amiconn | (5) if you had to segment the video (both avi2yuv and halftone can't handle files >2 GB), concatenate the .rvf segments together |
22:55:54 | amiconn | This is possible because video-only .rvfs have no header |
22:56:10 | zeekoe | cool |
22:56:24 | amiconn | (5) Use headac3he to decode the .ac3 and downmix it to a stereo wav |
22:56:37 | amiconn | Err, this was (6) |
22:56:41 | zeekoe | :P |
22:57:14 | zeekoe | ok, i already expected headac3he here :) |
22:57:29 | amiconn | (7) Encode this .wav with lame into an .mp3 (I use −−preset medium for normal movies, −−preset standard for music videos/movies) |
22:58:04 | zeekoe | so you _really_ watch movies on the recorder? |
22:58:09 | amiconn | Fortunately lame is able to handle wavs > 2 GB, it only shows weird encoding times/ frame counts in that case |
22:58:31 | amiconn | (8) rvf_mux video and audio together |
22:58:55 | LinusN | amiconn: is that so on linux as well? |
22:59:03 | LinusN | the 2Gb flaw? |
22:59:19 | LinusN | and on NTFS? |
22:59:21 | amiconn | zeekoe: Yes, although I don't do that often. |
22:59:23 | zeekoe | amiconn's guide to rvf in less than 10 steps :) |
22:59:48 | zeekoe | i wonder, how do you get 2 GB+ files? |
23:00 |
23:00:02 | zeekoe | my files are only 4 MByte per minute |
23:00:27 | amiconn | Converting e.g. LOTR. LOTR3 does break the 2 GB barrier even for the audio part |
23:01:01 | amiconn | LinusN: For lame on Linux, I don't know. |
23:01:06 | zeekoe | but not for the video i guess |
23:01:51 | amiconn | zeekoe: Haha. Of course it does, as I said _even_. The 2 GB barrier for the video part is it much earlier |
23:01:58 | amiconn | *is hit |
23:02:12 | zeekoe | hmm |
23:02:31 | zeekoe | heh |
23:02:33 | zeekoe | of course |
23:02:53 | zeekoe | the input files are color 112x64, so the output files are much smaller |
23:03:10 | zeekoe | how many greys are in the output file? 67? |
23:03:32 | | Join Tunsnask [0] (~gammel_ma@cpe.atm2-0-1041160.0x503f9f66.arcnxx9.customer.tele.dk) |
23:03:40 | amiconn | LinusN: The 2 GB barrier in avi2yuv has nothing to do with the file system, but with the file handling code in it. Unfortunately we are not able to change it, since avi2yuv is not open source, and hence not available for Linux |
23:05:07 | amiconn | zeekoe: There are no "real" grays in the output file, but only black and white pixels. .rvf uses a higher frame rate (standard is 67 fps) to simulate gray |
23:05:17 | zeekoe | ok |
23:05:27 | zeekoe | so theoretically it's 67 greys |
23:05:34 | | Quit Tunsnask (Client Quit) |
23:06:16 | amiconn | No, the "theoretical" number of grays is unlimited for .rvfs, since it does not use a repeated sequence, but a continuous stream of pixels |
23:06:48 | zeekoe | hmm... cool :) |
23:07:16 | zeekoe | DirectStreamDigital (R) (TM) :-P |
23:07:30 | scott666_ | whatever happened to the gui? |
23:07:35 | | Nick scott666_ is now known as scott666 (~scott666@c-24-245-58-48.mn.client2.attbi.com) |
23:07:51 | amiconn | scott666: what gui? |
23:08:19 | scott666 | the one jörg (i think) was working on |
23:08:37 | zeekoe | it's in the tools dir, just downloaded it |
23:09:03 | | Join Tunsnask [0] (~gammel_ma@cpe.atm2-0-1041160.0x503f9f66.arcnxx9.customer.tele.dk) |
23:09:05 | scott666 | LinusN: any idea when 2.3 is going to be released? |
23:10:07 | LinusN | scott666: some time in september i hope |
23:10:59 | scott666 | not until september? is there something big in the works? |
23:11:20 | LinusN | things are happening, and the core team are on vacation |
23:12:16 | scott666 | so 2.3 will probably be around when rombox is finalized? |
23:15:34 | gromit`` | http://support.microsoft.com/default.aspx?scid=kb;en-us;314458 |
23:15:39 | LinusN | has nothing to do with rombox |
23:15:47 | gromit`` | :) |
23:16:21 | amiconn | LinusN: Got your mail. Actually, grayscale.rock looks like a bad example, since for that the gcc 3.4.1 result is smaller than what gcc 3.3.1 produces (by 36 bytes) |
23:16:42 | LinusN | haha |
23:16:46 | zeekoe | how nice of microsoft... |
23:17:04 | gromit`` | in case you dunno how to do :) |
23:17:19 | zeekoe | "you're sick of a system that's rock-stable? want your good ol' viruses back? here's the guide" |
23:17:50 | zeekoe | not that windows xp is that unstable |
23:18:04 | LinusN | amiconn: can you do sh-elf-objdump -h rockbox.elf? |
23:18:05 | midk | haha |
23:18:51 | | Join [IDC]Dragon [0] (~idc-drago@pD9FF8EC1.dip.t-dialin.net) |
23:18:55 | LinusN | amiconn: never mind, it won't give us anything |
23:19:11 | amiconn | LinusN: yes. Where should I put the result? |
23:20:39 | Tunsnask | chould any one send my a guide to patch my recorder? |
23:20:55 | LinusN | Tunsnask: ??????? |
23:21:02 | zeekoe | what patch |
23:21:22 | Tunsnask | erh... |
23:21:43 | LinusN | amiconn: email me the results from the objdump |
23:22:01 | Tunsnask | how i sply a patch |
23:22:04 | Tunsnask | aply |
23:22:09 | LinusN | Tunsnask: http://rockbox.haxx.se/twiki/bin/view/Main/WorkingWithPatches |
23:22:39 | Tunsnask | but that site dont really make sense to me... |
23:22:54 | Tunsnask | anyway I'll try |
23:23:31 | LinusN | if it doesn't make sense for you, well, then patching isn't for you i guess |
23:24:02 | Tunsnask | it gotta be |
23:24:20 | LinusN | why? |
23:24:36 | Tunsnask | ... |
23:24:42 | Tunsnask | nevermind |
23:26:02 | LinusN | Tunsnask: i don't want to offend you or be rude, but the rockbox patches are for developers |
23:26:24 | zeekoe | Tunsnask: what patch do you actually want to apply? |
23:26:44 | Tunsnask | i dont really know |
23:26:51 | zeekoe | hm |
23:26:53 | zeekoe | why not |
23:27:03 | zeekoe | what do you want from your rockbox |
23:27:33 | Tunsnask | i dont know |
23:27:44 | Tunsnask | :-) |
23:27:50 | zeekoe | so, where did you get the idea of applying a patch? |
23:28:12 | Tunsnask | some friends |
23:28:18 | zeekoe | or is it just so you can tell your friends at school "hey,look, i patched my... |
23:28:22 | zeekoe | heh, okay |
23:28:28 | Tunsnask | :-) |
23:28:31 | LinusN | amiconn: the text section is much smaller in your dump |
23:29:11 | Tunsnask | my search dont work... |
23:29:32 | LinusN | how? |
23:29:33 | amiconn | LinusN: I wonder _why_ that is. rockbox.map would be an interesting thing to read & compare |
23:29:57 | Tunsnask | all my files in my .rockbox folder dont work... |
23:30:11 | LinusN | "don't work"? |
23:30:20 | zeekoe | copy new ones :) |
23:30:31 | Tunsnask | how? |
23:30:43 | zeekoe | http://rockbox.haxx.se/daily.shtml |
23:31:05 | LinusN | Tunsnask: when you install rockbox, you must unzip the entire zip file onto your jukebox |
23:31:24 | zeekoe | or use the windows installer :) |
23:31:37 | amiconn | For grayscale.rock, the text section is the only one that is larger with gcc 3.3.1, all others are identical (apart from .comment, but that doesn't count) |
23:31:54 | LinusN | funny |
23:32:24 | LinusN | amiconn: you want my rockbox.map? |
23:32:49 | LinusN | then pick a module that differs a lot in size |
23:32:57 | LinusN | and i'll send it to you |
23:32:58 | amiconn | Yes, that may be interesting (along with rockbox.bin) |
23:33:18 | Tunsnask | strange it work now.. i had tried it before |
23:33:32 | LinusN | hey, i'll send you all of it (you have DLS, right?) |
23:33:36 | Tunsnask | thanks |
23:33:41 | LinusN | dsl |
23:33:47 | amiconn | yup |
23:33:51 | LinusN | hang on |
23:35:34 | Tunsnask | my search still dont work :-( |
23:35:53 | Tunsnask | plugin returned error |
23:36:11 | zeekoe | you need to open m3u's |
23:36:15 | zeekoe | you do that, do you? |
23:36:20 | Tunsnask | no |
23:36:21 | | Quit [IDC]Dragon () |
23:36:23 | zeekoe | :) |
23:36:32 | zeekoe | go to an m3u, press on+play |
23:36:40 | zeekoe | select open with -> search |
23:36:45 | zeekoe | and off you go |
23:37:11 | Tunsnask | erh... where do I find a m3u? |
23:37:53 | zeekoe | make one |
23:38:05 | amiconn | LinusN: Perhaps the search plugin could tell that you have to use open with on an .m3u to use it if there is no parameter |
23:38:31 | LinusN | yes |
23:38:40 | Tunsnask | how do i make a m3u? |
23:38:41 | zeekoe | Tunsnask: something like menu -> playlists -> create playlist or so |
23:38:45 | amiconn | Currently, it is possible to start it and even enter a search string. If you then hit "Ok" -> Plugin returned error |
23:38:48 | zeekoe | my recorder is off now |
23:38:55 | zeekoe | i mean, plugged into usb |
23:39:09 | LinusN | http://rockbox.haxx.se/twiki/bin/view/Main/PluginSearch |
23:39:47 | amiconn | Although it isn't possible to accidentally start the plugin directly if you have a correct installation unless you set "show files" to "all" |
23:41:08 | LinusN | amiconn: http://linus.haxx.se/fmrecorder-3.4.1.zip |
23:41:54 | amiconn | Thanks, got it |
23:42:17 | Tunsnask | erhm... it still dont work :-/ |
23:42:30 | zeekoe | Tunsnask: what do you do, exactly? |
23:42:49 | Tunsnask | ok wait i got it |
23:42:59 | zeekoe | nice :) |
23:43:08 | zeekoe | LinusN: is it already possible for us earthlings to build rombox? |
23:43:17 | Tunsnask | there i go :-) |
23:44:23 | LinusN | zeekoe: ask amiconn |
23:44:50 | zeekoe | ok, right, you were the rombox guy |
23:44:52 | zeekoe | sorry |
23:45:02 | zeekoe | amiconn: is it already possible for us earthlings to build rombox? |
23:45:05 | zeekoe | :) |
23:45:31 | zeekoe | s/you/amiconn: you |
23:46:32 | amiconn | If you are prepared to fiddle a bit with scripts, and you are either using cygwin or are able to build the required special version of uclpack, yes |
23:47:35 | zeekoe | uclpack? |
23:47:35 | zeekoe | hm |
23:47:47 | zeekoe | i saw that somewhere on the rockbox site :) |
23:47:50 | * | zeekoe looking |
23:48:03 | amiconn | Don't look, it isn't found there |
23:48:33 | zeekoe | ok |
23:48:39 | zeekoe | so where is it found? |
23:48:52 | Tunsnask | ok is it normal that a search takes really long time?? |
23:48:53 | amiconn | [IDC]Dragon, who originally "invented" rombox, prepared a special version of uclpack which is able to generate an uncompressed .ucl file |
23:49:09 | LinusN | Tunsnask: no |
23:49:42 | Tunsnask | hmmm.... |
23:49:46 | amiconn | He send it directly to me. Although uclpack is open source, it is not found on the rockbox page, as it is not a simple single-source-file tool |
23:49:55 | zeekoe | okay |
23:50:04 | amiconn | zeekoe: I could send it to you if you want |
23:50:23 | Tunsnask | there just stands searching.... searching.... searching... and so for 10 minutes... |
23:50:39 | zeekoe | amiconn: well.. i dont think i really need it anyway |
23:51:15 | zeekoe | btw, how's the version management in rockbox? when will a plugin be incompatible? |
23:54:11 | LinusN | Tunsnask: what were you searching for? |
23:54:53 | LinusN | zeekoe: it is incompatible if the plugin API has changed |
23:55:21 | Tunsnask | a song |
23:56:11 | amiconn | LinusN: This is funny: comparing rockbox.map files show that gcc 3.4.1 is better in condensing data (both .rodata and .bss are smaller, the latter only by 4 bytes), but worse in condensing code (both .text and .icode are larger) compared to gcc 3.3.1 |
23:56:26 | LinusN | Tunsnask: come on, if you want our help, try to be helpful back!!!!!! |
23:57:29 | Tunsnask | erh... |
23:58:04 | LinusN | i know you were searching for a song, that's the whole purpose of the search plugin |
23:58:13 | amiconn | There is a bug in the linker of gcc 3.4.1: The size reported for *fill* elements looks rather funny |
23:58:24 | Tunsnask | then why do you ask...? |
23:58:33 | LinusN | you mean binutils 2.15 |
23:58:42 | amiconn | Yes of course |
23:58:49 | zeekoe | Tunsnask: what _exactly_ are you searching for |
23:58:52 | LinusN | Tunsnask: you just told me that it searches forever |