| 00:02:02 | bertrik | the tea5767 code that mcuelenaere just updated makes it seem as if there are two i2c addresses that the radio chip can be on, but it's really a difference in the i2c drivers rather than in the radio chip |
| 00:04:06 | bertrik | ideally all i2c drivers would use the same convention for i2c slave addresses |
| 00:08:56 | * | flyback bbl, family dinner |
| 00:09:03 | *** | Saving seen data "./dancer.seen" |
| 00:10:46 | | Quit Kitar|st (Connection timed out) |
| 00:19:35 | | Quit casainho (Remote closed the connection) |
| 00:23:23 | | Quit stephen__ ("Leaving") |
| 00:35:45 | | Join slashroot [0] (n=morpheus@87.243.142.75) |
| 00:39:38 | | Quit slashroot (Client Quit) |
| 00:41:06 | | Quit Hillshum (Read error: 113 (No route to host)) |
| 00:41:51 | | Quit dfkt ("-= SysReset 2.53=- Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn.") |
| 00:49:41 | | Quit petur ("Zzzzz") |
| 00:54:51 | | Join n1s [0] (n=n1s@rockbox/developer/n1s) |
| 00:56:00 | | Quit JdGordon| ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") |
| 00:57:27 | | Join Tomis [0] (n=Tomis@70.134.74.0) |
| 00:58:16 | | Join togetic [0] (n=togetic@unaffiliated/ibuffy) |
| 01:00 |
| 01:03:05 | | Join Tomis2 [0] (n=Tomis@70.134.96.143) |
| 01:03:10 | | Join fdinel [0] (n=Miranda@modemcable235.127-131-66.mc.videotron.ca) |
| 01:17:39 | | Quit toffe82 (Read error: 54 (Connection reset by peer)) |
| 01:19:22 | | Quit Tomis (Read error: 110 (Connection timed out)) |
| 01:19:23 | | Nick Tomis2 is now known as Tomis (n=Tomis@70.134.96.143) |
| 01:36:38 | | Join NoGare [0] (n=chatzill@dyn216-8-128-56.ADSL.mnsi.net) |
| 01:37:11 | | Join Tomis2 [0] (n=Tomis@70.134.85.22) |
| 01:40:41 | | Quit Horscht ("Verlassend") |
| 01:42:46 | | Quit JdGordon ("Leaving.") |
| 01:43:39 | | Quit Tomis (Read error: 60 (Operation timed out)) |
| 01:43:39 | | Nick Tomis2 is now known as Tomis (n=Tomis@70.134.85.22) |
| 01:54:38 | | Join Horscht [0] (n=Horscht2@xbmc/user/horscht) |
| 02:00 |
| 02:03:50 | | Join sagemfreak_ [0] (n=sven@p5492223A.dip0.t-ipconnect.de) |
| 02:04:31 | Unhelpful | amiconn: i'm trying to figure out your log in grey_core.c... it normalizes the input value to put the highest set bit at 1<<30, and then it tries a series of multipliers... if a multiplier leaves the result less than 1<<32, then the result replaces the value and the log of the multiplier is subtracted from the result? |
| 02:07:10 | | Quit sagemfreak (Read error: 60 (Operation timed out)) |
| 02:09:07 | *** | Saving seen data "./dancer.seen" |
| 02:13:40 | | Quit darkham (Client Quit) |
| 02:16:33 | | Quit n1s (Read error: 113 (No route to host)) |
| 02:17:24 | | Quit Phyber0ptik (Read error: 104 (Connection reset by peer)) |
| 02:40:26 | | Quit GeekShado_ (Read error: 54 (Connection reset by peer)) |
| 02:43:30 | | Quit jordan`` (Remote closed the connection) |
| 02:45:28 | | Join StealthyXIIGer [0] (n=stealthy@69.216.113.160) |
| 02:58:47 | | Join jordan` [0] (n=jordan@78.235.252.137) |
| 03:00 |
| 03:50:31 | | Join Strife89 [0] (n=michael@adsl-154-13-96.mcn.bellsouth.net) |
| 03:56:58 | | Quit NoGare ("ChatZilla 0.9.85 [Firefox 3.6b5/20091204143806]") |
| 04:00 |
| 04:06:43 | | Part froggyman |
| 04:09:07 | | Join JdGordon [0] (n=jonno@rockbox/developer/JdGordon) |
| 04:09:09 | *** | Saving seen data "./dancer.seen" |
| 04:33:33 | | Quit StealthyXIIGer (Read error: 60 (Operation timed out)) |
| 04:33:38 | | Join JdGordon1 [0] (n=jonno@c-24-22-210-83.hsd1.wa.comcast.net) |
| 04:42:02 | | Quit JdGordon1 (Read error: 60 (Operation timed out)) |
| 04:49:46 | | Quit kkurbjun ("Leaving.") |
| 04:51:30 | | Join kkurbjun2 [0] (n=kkurbjun@204.183.33.50) |
| 04:51:41 | | Nick kkurbjun2 is now known as kkurbjun (n=kkurbjun@204.183.33.50) |
| 04:52:52 | CIA-6 | New commit by kkurbjun (r24100): Brickmania: Improve screen collision detection. |
| 04:56:14 | | Quit sbhsu (Remote closed the connection) |
| 04:56:26 | | Join sbhsu [0] (n=a6530466@Zion.dorm.au.edu.tw) |
| 05:00 |
| 05:08:54 | | Part kkurbjun |
| 05:27:48 | | Quit panni_ ("( www.nnscript.de :: NoNameScript 3.81 :: www.XLhost.de )") |
| 05:42:06 | | Quit togetic (Read error: 110 (Connection timed out)) |
| 05:47:59 | * | flyback be back later |
| 06:00 |
| 06:09:10 | *** | Saving seen data "./dancer.seen" |
| 06:16:19 | | Join StealthyXIIGer [0] (n=stealthy@69.216.113.160) |
| 06:20:34 | | Quit fdinel ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") |
| 06:36:17 | | Quit Tomis (Read error: 113 (No route to host)) |
| 06:54:32 | | Quit FlynDice (Remote closed the connection) |
| 06:59:25 | | Quit StealthyXIIGer (Read error: 110 (Connection timed out)) |
| 07:00 |
| 07:00:06 | | Nick fxb is now known as fxb__ (n=felixbru@h1252615.stratoserver.net) |
| 07:03:23 | | Quit Strife89 ("Bed.") |
| 07:04:55 | | Join Horschti [0] (n=Horscht2@xbmc/user/horscht) |
| 07:13:46 | | Join Tomis [0] (n=Tomis@70.134.64.112) |
| 07:14:55 | | Nick AaronM is now known as AaronMcD (n=Aaron@adsl-250-8-242.bhm.bellsouth.net) |
| 07:15:04 | | Nick AaronMcD is now known as AaronM (n=Aaron@adsl-250-8-242.bhm.bellsouth.net) |
| 07:19:25 | JdGordon | so why the heck do we allow the delete option in the WPS context menu? |
| 07:21:29 | JdGordon | it really makes no sense that we allow the delete there... especially with its current undefined behaviour |
| 07:23:09 | | Quit Horscht (Read error: 110 (Connection timed out)) |
| 07:23:46 | | Quit AaronM (Client Quit) |
| 07:26:29 | | Join AaronM [0] (n=Aaron@adsl-250-8-242.bhm.bellsouth.net) |
| 07:29:50 | JdGordon | does "#define LCD_BACKDROP_BYTES (LCD_FBHEIGHT*LCD_FBWIDTH*sizeof(fb_data))" look correct? |
| 07:43:58 | | Quit CaptainKewl ("( www.nnscript.com :: NoNameScript 4.22 :: www.esnation.com )") |
| 07:46:29 | * | JdGordon doesnt like it when its quiet in here.... |
| 07:46:44 | JdGordon | can anyone tihnk of a reason to want to disable the theme but still show the users backdrop? |
| 07:48:02 | | Join Hillshum [0] (n=hillshum@75-165-229-121.slkc.qwest.net) |
| 07:53:26 | JdGordon | anyone know if its currently possible for a theme to set a backdrop but have no backdrop displayed in the WPS? |
| 08:00 |
| 08:01:34 | | Quit mikroflops (Remote closed the connection) |
| 08:01:48 | | Join mikroflops [0] (n=yogurt@217-208-157-242-no112.tbcn.telia.com) |
| 08:06:19 | amiconn | JdGordon: The delete option makes very much sense in the wps, for when you're test-listening a folder with new music |
| 08:06:38 | JdGordon | sure, but it should skip to the next track then |
| 08:06:49 | amiconn | why? |
| 08:07:02 | JdGordon | because otherwise you are in an undefined state |
| 08:07:13 | JdGordon | the whole track might not be buffered |
| 08:07:26 | amiconn | Yes, but what's the problem with that? |
| 08:07:43 | amiconn | Btw, that's much more likely on lowmem targets |
| 08:07:53 | JdGordon | you get a crappy track jump |
| 08:08:12 | JdGordon | A possible solution to all this is queuing the delete to only happen at the end of the track |
| 08:08:22 | amiconn | Well, it would just switch to the next track like if the track was shorter |
| 08:08:37 | JdGordon | I think thats very ugly |
| 08:08:52 | JdGordon | The delete action should be well defined |
| 08:08:53 | amiconn | I think that's 100% acceptable (and iirc it's documented) |
| 08:09:13 | *** | Saving seen data "./dancer.seen" |
| 08:09:21 | JdGordon | its acceptable, but having it guarentee that the track will play to the end, but the track will be deleted once its played its much cleaner |
| 08:09:21 | amiconn | Most of the time you will skip after the delete anyway |
| 08:09:41 | JdGordon | yes, so it shoud either auto-skip, or delete once the skip happens |
| 08:09:42 | amiconn | Imo that would be superfluous |
| 08:10:20 | amiconn | Either keep it as it is, or skip right after delete |
| 08:10:51 | amiconn | But I think the former is better. |
| 08:11:04 | JdGordon | FS #9929 is what brought this up |
| 08:11:22 | JdGordon | I prefer the latter |
| 08:13:39 | amiconn | Too much hassle for something that isn't really ann everyday feature, imo |
| 08:13:47 | amiconn | s/ann/an/ |
| 08:13:53 | JdGordon | before I start pulling my hair out... was the backdrop define before correct? |
| 08:14:12 | JdGordon | and I agree... but I'd like to close the bug one way or another |
| 08:14:31 | | Quit AaronM ("sleepin with my black ipod playing death cab...... naked") |
| 08:15:07 | amiconn | The question is whether it behaves as described |
| 08:16:17 | amiconn | If rockbox gets confused by deleting *while* buffering, it would need to be fixed. Afaik it doesn't, but then I used this feature maybe once or twice during all the years, and only on hwcodec |
| 08:16:43 | JdGordon | "Delete the currently playing file." is the sum total of the manual text for this feature |
| 08:17:30 | JdGordon | there very possibly is a potential bug if the delete happened at exactly the right time while buffering, but hugley unlikely |
| 08:19:32 | amiconn | Well, a manual fix would also be a fix, wouldn't it? |
| 08:19:59 | JdGordon | yes |
| 08:20:00 | amiconn | "Rockbox will continue playing what's already in the buffer." |
| 08:20:28 | JdGordon | from a users POV that sounds unexpected though |
| 08:20:41 | JdGordon | "the file is deleted, why is it still playing?" which is exactly that bug |
| 08:20:53 | amiconn | To answer your other question - that #define looks correct |
| 08:20:59 | JdGordon | thanks |
| 08:24:53 | amiconn | That's the question, is it a bug or a feature? How intuitive should "intuitive" be? |
| 08:25:37 | JdGordon | yes |
| 08:25:43 | amiconn | You can see it as a feature - rockbox deletes the file as soon as possible, yet continues playing as long as possible, or until you skip - you decide |
| 08:29:52 | amiconn | Btw, deleting at end-of-track wouldn't fix the "bug", it would even make it worse |
| 08:31:15 | JdGordon | how do you mean? |
| 08:31:41 | amiconn | "I hit 'delete', but nothing happens. The file is still there, and is still playing" |
| 08:32:01 | JdGordon | well yeah, that was just a quick and obviously bad idea |
| 08:32:28 | * | flyback http://www.youtube.com/user/Aussie50 <=== learn cool stuff |
| 08:33:02 | | Join kugel [0] (i=kugel@rockbox/developer/kugel) |
| 08:34:04 | amiconn | Skip after delete would solve it - more intuitiveness at the cost of losing an admittedly tiny feature |
| 08:34:21 | amiconn | And more code (probably also tiny). |
| 08:34:23 | JdGordon | doesnt that tiny feature trigger an error in the playback engine? |
| 08:34:37 | JdGordon | i.e its expecting to load more from the file but gets a read error instead |
| 08:34:59 | amiconn | That I don't know. Back then I didn't observe any on hwcodec |
| 08:35:02 | JdGordon | adding the skip is 1 function call |
| 08:35:38 | JdGordon | hmm, maybe a bit more than that |
| 08:35:52 | * | JdGordon closes |
| 08:36:21 | amiconn | Sure it will see a read error. It should be able to handle it though, otherwise the error handling is broken and needs fixing |
| 08:38:30 | JdGordon | moving the backdrop buffers into the skin buffer isnt as trvial as I was hoping :( |
| 08:40:58 | * | amiconn wonders what would be the advantage |
| 08:41:18 | JdGordon | right now... none... |
| 08:41:18 | JdGordon | well, little |
| 08:41:32 | JdGordon | but when more than one skinnable screen can have its own backdrop, heaps |
| 08:41:51 | JdGordon | especially if you dont use themes |
| 08:43:20 | JdGordon | unless we decide to give up on keeping all the backdrops in memory |
| 08:43:46 | JdGordon | which means reloading from disk when changing between screens, which sucks |
| 08:44:12 | | Join n1s [0] (n=n1s@rockbox/developer/n1s) |
| 08:44:36 | amiconn | Different backdrops per screen? |
| 08:45:42 | JdGordon | yes |
| 08:46:01 | JdGordon | screen being wps, fm, rec, main |
| 08:46:06 | * | amiconn wonders where this will lead |
| 08:47:39 | * | JdGordon thinks its actually in amiconn's interest if this goes ahead... considering its probable RAM savings. |
| 08:49:02 | amiconn | n1s: Is this bitreverse function really used often enough to give a measurable speedup? |
| 08:49:22 | amiconn | If so, there's more potential in it, also for ARMv4/v5 and coldfire |
| 08:51:53 | * | kugel recommends amiconn to read the ml sometimes |
| 08:52:14 | | Join tomers [0] (n=86bfe845@giant.haxx.se) |
| 08:52:45 | tomers | jdgordon: Have you reach any sort of concensus with other developers before closing "FS #9929 - context menu delete does not work as expected |
| 08:52:46 | tomers | "? |
| 08:53:02 | JdGordon | red the last 30min of the logs |
| 08:53:47 | JdGordon | read* |
| 08:53:48 | kugel | if it's documented it's not a bug anyway, even though one could argue that it's strange behavior |
| 08:53:50 | n1s | amiconn: i measured a speedup, but on pp and coldfire it was in the 0.3-0.5% range (so possibly caused by some side effect like cache alignment) on the beast it sped up decoding of some files as much as 2% |
| 08:55:10 | n1s | it isn't called *that* often it was just a simple optimization i wanted to do for the beast since gcc doesn't use the rev instruction to do the byteswap |
| 08:56:35 | amiconn | Well, there's more to it because the 4-bit, 2-bit and 1-bit stages can be optimised further |
| 08:58:11 | amiconn | This very much reminds me of my geek bitswap for SH1 :) |
| 08:58:24 | n1s | amiconn: i tried doing half the masks before shifting to use half as many constants and that gave slightly better code on arm but only gave a speedup when *not* using the swap32()... |
| 08:59:18 | amiconn | You only need the mask once - the other half can be done using xor |
| 09:00 |
| 09:00:46 | | Join stoffel [0] (n=quassel@p57B4D2FE.dip.t-dialin.net) |
| 09:01:37 | | Join einhirn [0] (i=Miranda@vpn10.rz.tu-clausthal.de) |
| 09:04:08 | amiconn | This should even improve things when written in C |
| 09:04:39 | n1s | amiconn: ah, yeah, the coldfire swap32 does that |
| 09:08:21 | | Quit gevaerts (Nick collision from services.) |
| 09:08:32 | | Join gevaerts [0] (n=fg@rockbox/developer/gevaerts) |
| 09:09:06 | | Join petur [50] (n=petur@rockbox/developer/petur) |
| 09:09:22 | | Join flydutch [0] (n=flydutch@host1-166-dynamic.8-87-r.retail.telecomitalia.it) |
| 09:11:13 | * | JdGordon has a cunning plan! |
| 09:15:28 | n1s | aaah! |
| 09:16:08 | JdGordon | setting a viewports colour to TRANSPARENT_COLOR wont work :p |
| 09:16:57 | kugel | no surprise |
| 09:17:46 | * | JdGordon is *trying* to find a workable solution to having these settings outside of the sbs |
| 09:20:19 | | Quit tomers ("CGI:IRC") |
| 09:20:59 | JdGordon | that could work if the lcd driver stored its default colours from a setting callback... but frankly, that seems like more effort than its actually worth |
| 09:28:23 | | Join webguest94 [0] (n=48ebd536@giant.haxx.se) |
| 09:30:44 | webguest94 | when i uninstalled rockbox from my ipod, it went crazy and now it won't even work properly |
| 09:31:17 | GodEater | webguest94: first: How did you do the uninstall. second: how do you define "went crazy" and "won't even work properly". |
| 09:31:46 | n1s | amiconn: the xor version is 4 instructions shorter on coldfire (when compiling with O3) but also uses only 4 large immediates instead of 8 |
| 09:33:09 | webguest94 | well from the rockbox that i installed menu, theres the uninstall and so i did that, after the process my ipod started saying some stuff like loading rockbox-error!can't load rockbox on ipod |
| 09:33:20 | webguest94 | and now its stock like that |
| 09:33:35 | GodEater | webguest94: do you mean you used rbutil? |
| 09:33:40 | webguest94 | no matter what i do my comp can't even recognize the ipod |
| 09:34:01 | GodEater | webguest94: have you reset it and restarted it in disk mode? |
| 09:34:04 | webguest94 | yes, thats what was installed |
| 09:34:41 | webguest94 | yes i have reset it and started it back to disk mode, but it takes me back to the same place with the error screen thing |
| 09:34:49 | GodEater | in that case you're not in disk mode |
| 09:35:02 | GodEater | you may find this page helpful : http://support.apple.com/kb/HT1363 |
| 09:35:52 | GodEater | pay attention to the bit where it says "immediately". I means it. |
| 09:35:56 | GodEater | *It means it. |
| 09:36:38 | | Join Grahack [0] (n=chri@ip-222.net-82-216-222.rev.numericable.fr) |
| 09:36:53 | n1s | amiconn: scrap that, it's only one instruction shorter, but also gcc is braindead |
| 09:37:26 | webguest94 | yes thats what i have done...immediately pressed and hold the select and play and it did the check and what not but no more than a minute it went back to the same screen with the rockbox can't be loaded |
| 09:38:08 | amiconn | n1s: The latter isn't exactly breaking news ;\ |
| 09:38:23 | GodEater | webguest94: if you keep seeing that message you are NOT going into disk mode, it's as simple as that. |
| 09:38:27 | webguest94 | how so not breaking news? |
| 09:39:32 | webguest94 | ok..how do i fix it...well it goes through the whole process of disk mode with the check screen then back to the can't load screen after a minte |
| 09:39:36 | webguest94 | or less |
| 09:40:04 | GodEater | if you're seeing a "check screen" then you're putting it into diagnostics mode, not disk mode |
| 09:40:09 | GodEater | i.e. you're doing the wrong thing |
| 09:40:33 | n1s | amiconn: so the only gain is less immediates and one instr less |
| 09:41:19 | webguest94 | how so..i followed the instructions? |
| 09:42:05 | GodEater | webguest94: search me, you're the one doing it - not me. But if you follow those instructions properly, your ipod will enter disk mode, and your computer will be able to see it again. |
| 09:42:33 | webguest94 | ok..thanks |
| 09:45:44 | amiconn | n1s: Less immediates is good for speed too |
| 09:46:40 | n1s | amiconn: ok, it's actually a few instructions shorter on arm too so i'll have to benchmark this again |
| 09:46:41 | amiconn | One thing is that smaller code means better cache efficiency (although the effect might be covered by cache aliasing) |
| 09:47:11 | amiconn | Another is that too many instructions with more than one extension word starve the instruction fetch pipeline |
| 09:47:21 | amiconn | +in sequence |
| 09:47:31 | | Quit Grahack ("Leaving.") |
| 09:49:24 | * | amiconn can also think about some arm asm trickery that should be even better than what gcc comes up with |
| 09:53:41 | | Join JdGordon1 [0] (n=jonno@c-24-22-210-83.hsd1.wa.comcast.net) |
| 09:54:16 | | Quit JdGordon1 (Client Quit) |
| 09:57:39 | | Quit webguest94 ("CGI:IRC (EOF)") |
| 10:00 |
| 10:02:16 | * | n1s curses inline asm |
| 10:09:16 | *** | Saving seen data "./dancer.seen" |
| 10:17:40 | | Quit zMastaa (Read error: 110 (Connection timed out)) |
| 10:34:15 | | Join elcan [0] (i=user36@pr0.us) |
| 10:38:24 | | Quit stoffel (Read error: 60 (Operation timed out)) |
| 10:43:23 | | Join pamaury [0] (n=pamaury@sal63-1-82-243-96-220.fbx.proxad.net) |
| 10:59:41 | | Quit jds2001 (Remote closed the connection) |
| 10:59:54 | | Join jds2001 [0] (n=jds2001@fedora/jds2001) |
| 11:00 |
| 11:23:18 | | Quit kugel (Read error: 60 (Operation timed out)) |
| 11:29:15 | | Join Horscht [0] (n=Horscht2@xbmc/user/horscht) |
| 11:35:46 | | Join bmbl [0] (n=Miranda@unaffiliated/bmbl) |
| 11:42:35 | | Join bianca [0] (n=0cec7962@giant.haxx.se) |
| 11:45:52 | bianca | hey guys, I'm having a bit of an issue. I rockboxed my sansa over a year ago on an old laptop. I'm now using a different computer and want to add some media to the blasted thing, but I seem unable to add it as a device in the rockbox utility, despite looking over the faq and manual. any suggestions? |
| 11:46:24 | | Join bertrik_ [0] (n=bertrik@ip117-49-211-87.adsl2.static.versatel.nl) |
| 11:49:25 | Horscht | bianca, you want to add music to your rockbox player? |
| 11:50:46 | Horscht | if so, just connect it to your PC using USB and use your computers filemanager to copy the mp3 files to the player. The Player should appear as a Mass Storage Device |
| 11:51:01 | | Quit Horschti (Read error: 110 (Connection timed out)) |
| 11:53:35 | pamaury | Hello, could someone here try to reproduce a bug related to "open" and "dircache_get_entry_ptr" ? I strongly suspect that dircache_get_entry_ptr is buggy and this bug makes open buggy. It requires to add code and compile |
| 11:54:32 | | Quit bertrik_ ("mandatory reboot") |
| 11:57:57 | | Quit bertrik (Read error: 113 (No route to host)) |
| 11:58:44 | | Join bertrik [0] (n=bertrik@ip117-49-211-87.adsl2.static.versatel.nl) |
| 11:59:20 | | Join stoffel [0] (n=quassel@p57B4D2FE.dip.t-dialin.net) |
| 12:00 |
| 12:06:36 | | Join kugel [0] (i=kugel@rockbox/developer/kugel) |
| 12:09:19 | *** | Saving seen data "./dancer.seen" |
| 12:10:37 | | Quit shaggy-h () |
| 12:10:49 | | Join shaggy-h [0] (n=kiwi@host-87-74-127-193.dslgb.com) |
| 12:16:25 | | Join Jaykay [0] (n=chatzill@p5DDC6C5D.dip.t-dialin.net) |
| 12:18:59 | | Quit n1s (Read error: 113 (No route to host)) |
| 12:20:32 | | Quit bertrik (Read error: 104 (Connection reset by peer)) |
| 12:20:51 | Jaykay | JdGordon: cleaning up the bug tracker is fine, but you are overdoing it. you closed FS #9929 with the reson "it might seem odd, but this is the expected behaviour", which is just plain wrong. a user never expects odd behaviour. |
| 12:21:03 | * | Jaykay suggests reopening it |
| 12:22:18 | gevaerts | Jaykay: users expect a lot of odd behaviour |
| 12:24:18 | Jaykay | gevaerts: in this case we expect normal behaviour and rockbox does something odd |
| 12:24:39 | gevaerts | Jaykay: "normal" and "odd" are both subjective. I'd expect it to keep playing... |
| 12:25:27 | gevaerts | so I think that while some people might think it's odd, it's not a bug, and if you want different behaviour that's a feature request |
| 12:25:32 | | Quit mikroflops (Read error: 54 (Connection reset by peer)) |
| 12:25:40 | | Join mikroflops_ [0] (n=yogurt@217-208-157-242-no112.tbcn.telia.com) |
| 12:25:44 | Jaykay | gevaerts: i guess because you know how the buffering works. a user doesn't know this, and thinks the file doesn't exist anymore, and wonders how rockbox is still able to play the non-existent file |
| 12:26:47 | gevaerts | Jaykay: for lots of people, the way our playlist system works is odd. Shall we drop playlists and expect people to manually select the new track to play every time? |
| 12:26:55 | gevaerts | Again, "odd" is not a bug |
| 12:26:56 | | Quit Lss__ (Read error: 104 (Connection reset by peer)) |
| 12:27:10 | Horscht | how is our playlist system odd? |
| 12:27:30 | | Join Lss [0] (n=Lss@cm17.delta75.maxonline.com.sg) |
| 12:27:35 | Jaykay | gevaerts: but expected behaviour != shown behaviour is a bug |
| 12:27:41 | gevaerts | Jaykay: expected by who? |
| 12:27:50 | Jaykay | by users |
| 12:28:07 | kugel | Jaykay: I think that is *documented* behavior, hence it's not a bug |
| 12:28:08 | Horscht | technicaly inexperienced users |
| 12:28:14 | gevaerts | Users also expect avi files to work. Is that a bug? |
| 12:28:44 | Jaykay | kugel: make rockbox freeze on boot, document it, and call it "expected behaviour" |
| 12:29:03 | Horscht | Jaykay, i don't realy see your point here |
| 12:29:26 | Jaykay | gevaerts: then they expect too much. but this just a different behaviour |
| 12:29:30 | Horscht | what you just proposed would "break" rockbox, therefore it would be a bug, not a documented feature ;) |
| 12:29:40 | kugel | Jaykay: it wouldn't be a bug then indeed. In that case we officially declared rockbox unusable. that's nothing you can file a bug for |
| 12:30:19 | Horscht | unless you didn't do it on purpose |
| 12:30:28 | kugel | the chain goes like documented -> intended -> not a bug |
| 12:31:56 | Jaykay | kugel: then document every bug and close the reports.... for me that doesn't make sense |
| 12:32:23 | kugel | this is not a bug |
| 12:32:28 | kugel | it's intended |
| 12:32:59 | Jaykay | i just thought that, if just a small change is needed to make rockbox show the behaviour the user expects, why not make this small change? |
| 12:33:13 | Jaykay | kugel: then explain why this is intended |
| 12:33:17 | GodEater | we are the users, and it is the behaviour we expcet |
| 12:33:24 | Horscht | just because *you* expect it, doesn't mean everyone does |
| 12:33:49 | Horscht | for me it's perfectly reasonable the file continues playing |
| 12:34:04 | Jaykay | Horscht: even if it shouldn't exist anymore? |
| 12:34:04 | | Join mikroflops [0] (n=yogurt@217-208-157-242-no112.tbcn.telia.com) |
| 12:34:12 | Horscht | it doesn't |
| 12:34:22 | Jaykay | the user just deleted it... |
| 12:34:33 | Horscht | I may have deleted the file, but I didn't clear my buffer, did I? |
| 12:34:40 | | Quit mikroflops_ (Read error: 104 (Connection reset by peer)) |
| 12:34:46 | Jaykay | does the user know anything about buffering? |
| 12:34:48 | | Join bertrik [0] (n=bertrik@ip117-49-211-87.adsl2.static.versatel.nl) |
| 12:34:52 | Horscht | well, yes |
| 12:34:59 | GodEater | Jaykay: yes - we're the users, and we know about it |
| 12:35:19 | Jaykay | ok, do most users know much about buffering? |
| 12:35:35 | GodEater | you're not asking the right question - the question is "do we care?" |
| 12:35:37 | Horscht | yes |
| 12:35:57 | Horscht | i'd say the majority of users knows about buffering |
| 12:37:07 | Jaykay | Horscht: wow. imo thats just plain wrong. how should a user know this? |
| 12:37:21 | | Quit bianca ("CGI:IRC") |
| 12:37:27 | Horscht | common sense? |
| 12:37:47 | kugel | looking at the buffering screen for example. I think most people have had a short look at it at least |
| 12:37:51 | Horscht | note: I *am* a plain user. Not a developer! |
| 12:39:12 | | Join watto [0] (n=watto@193.203.81.165) |
| 12:39:25 | kugel | Jaykay: this is intended behavior. that's a fact, not an opinion |
| 12:41:15 | Jaykay | kugel: shouldn't rockbox be intuitive to use? |
| 12:41:46 | GodEater | "intuitive" is subjective again |
| 12:42:01 | Jaykay | Horscht: so you really think the majority of usrs know how buffering works...? |
| 12:42:10 | Horscht | yes |
| 12:42:53 | bertrik | I do think too that it is a bit odd, but also perfectly explainable and harmless and I don't consider it a real bug |
| 12:45:04 | Jaykay | kugel: this behaviour is not documented btw |
| 12:46:35 | kugel | it should be then. I admittedly haven't looked, but someone said it was (hence "I think it is documented...") |
| 12:47:57 | | Quit pamaury ("exit(*(int *)0 / 0);") |
| 12:49:59 | Jaykay | ok, maybe i'll open a new task for the missing documentation in a few minutes, if everyone here agrees that this is the behaviour a user expects. |
| 12:50:35 | Jaykay | is it possible that rockbox buffers a 5mb-file in about 2 seconds? |
| 12:51:05 | GodEater | I would imagine so |
| 12:51:35 | * | Jaykay does a test with a bigger file |
| 12:51:47 | rvvs89 | If I unlink a file on UNIX, I can expect that any open file descriptors to that file will remain unaffected by the file being deleted. |
| 12:51:52 | kugel | " if everyone here agrees that this is the behaviour a user expects." <- Again, that is not the question |
| 12:52:00 | rvvs89 | In my opinion this is expected behaviour. |
| 12:52:24 | AlexP | It is both expected and unexpected, depending on who you are |
| 12:52:27 | Jaykay | rvvs89: how many % do use unix...? |
| 12:52:30 | GodEater | and on windows you'd simply be unable to delete it |
| 12:52:36 | AlexP | Either way, it is intended and therefore not a bug |
| 12:52:46 | AlexP | And in this case it is the correct behaviour |
| 12:53:24 | rvvs89 | Jaykay: You were asking for a consensus on what is expected behaviour, I am providing my opinion. |
| 12:53:38 | AlexP | And I'm not sure where you would document it |
| 12:54:12 | AlexP | If we stick every little thing in the manual that some people may or may not expect or know, it is going to get even more huge than it already is |
| 12:54:17 | GodEater | the point is it doesn't really matter what the consensus is. Rockbox is developed by and for it's developers. We always reserve the right to say "this is the way it works, and if you don't like it - well, sucks to be you" |
| 12:55:26 | Jaykay | AlexP: imo the manual is for documenting rockbox' behaviour, and this belongs to it |
| 12:55:37 | AlexP | I disagree in this case |
| 12:55:40 | GodEater | Jaykay: feel free to submit a patch for the manual then |
| 12:55:57 | AlexP | And the how many % use unix is completely irrelevent |
| 12:55:58 | rvvs89 | I suspect that the majority of users do not consider deleting music they are currently playing. |
| 12:56:13 | GodEater | rvvs89: it's a very edge case indeed |
| 12:56:14 | Jaykay | GodEater: i'll report a bug instead, ok? :) |
| 12:56:16 | AlexP | Should we make Rockbox behave exactly like Windows by that reasoning? |
| 12:56:20 | kugel | AlexP: I think it's fine to document behavior if it's not clear to everyone |
| 12:56:22 | AlexP | Jaykay: It isn't a bug |
| 12:56:30 | AlexP | kugel: I agree to an extent |
| 12:56:30 | GodEater | Jaykay: no, if you want the manual change, then write the change. |
| 12:56:48 | AlexP | kugel: I'm just saying that we can't go down that road ad infinitum |
| 12:57:10 | Jaykay | GodEater: if i find a bug, i'll report a bug. if it's not a bug, i won't |
| 12:57:11 | kugel | that would require questionable behavior everywhere |
| 12:57:22 | AlexP | kugel: There are always things that aren't clear to everyone, and it is a trade off between listing them and having something readable |
| 12:57:31 | AlexP | kugel: Yes, which there is (to someone) |
| 12:57:45 | kugel | I don't think so |
| 12:57:51 | AlexP | jesus |
| 12:58:03 | AlexP | Try and follow the logical argument |
| 12:58:09 | kugel | anyway, I think this specific bit should be documented |
| 12:58:51 | GodEater | We can cover it pretty easily : Rockbox tries to be POSIX compliant. For what this means, please refer to the POSIX standards. |
| 12:59:05 | * | kugel didn't know that |
| 12:59:06 | | Join zMastaa [0] (n=windows7@host86-147-92-59.range86-147.btcentralplus.com) |
| 12:59:29 | GodEater | (caveat: where it makes sense for a DAP OS to be POSIX compliant at all) |
| 12:59:30 | GodEater | :D |
| 12:59:37 | AlexP | Jaykay: Incidently, a patch here would be a piece of piss |
| 12:59:53 | GodEater | AlexP: assuming you can think of a good way to write it. |
| 13:00 |
| 13:00:22 | Jaykay | AlexP: i don't understand what you mean |
| 13:01:05 | AlexP | Jaykay: Find where delete in the context menu is described then have \note{If the file that you have just deleted is currently buffered in the dap memmory, then it will not be removed and will still play. It has however been deleted from disk.} |
| 13:01:15 | AlexP | Jaykay: piece of piss = trivially easy |
| 13:01:31 | Jaykay | ah, ok |
| 13:01:39 | * | kugel would word it differently |
| 13:01:39 | GodEater | s/memmory/memory |
| 13:01:47 | AlexP | kugel: well, whatever |
| 13:01:52 | kugel | :) |
| 13:02:09 | AlexP | kugel: That was an example off the top of my head. Feel free to do it - you are the one that thinks it should be documented, not me |
| 13:02:44 | Jaykay | may i report it as a bug with a patch? because bugs get closed faster than patches :) |
| 13:03:12 | AlexP | no |
| 13:03:20 | AlexP | If you have a patch, it is a patch :) |
| 13:11:37 | Jaykay | AlexP: but it's also a bug with a fix :D well, ok, i'll maybe do it later |
| 13:12:08 | | Join Horschti [0] (n=Horscht2@xbmc/user/horscht) |
| 13:14:35 | | Quit Xerion (Read error: 54 (Connection reset by peer)) |
| 13:16:26 | AlexP | Jaykay: It is just the wording that is a bit tricky - you need to find something concise |
| 13:16:55 | Jaykay | so, as the devs expect different things as the users, is it expected that a deleted file plays up to a certain point, then stops (i think at the point where it stopped buffering) and that it's not possible to start any track after this? |
| 13:17:17 | AlexP | First bit yes, second bit no |
| 13:17:23 | * | Jaykay thinks that just skipping a track which gut deleted would be much easier :D |
| 13:17:34 | AlexP | What do you mean by not possible to start a track? |
| 13:17:43 | AlexP | You click on it and nothing happens? |
| 13:17:48 | AlexP | If so, then that is a bug |
| 13:17:49 | Jaykay | the wps shows, but the track doesn't play |
| 13:17:58 | AlexP | That does sound like a bug to me |
| 13:18:09 | AlexP | Does the deleted file have to be semi-buffered? |
| 13:18:28 | AlexP | i.e. if it is all buffered and it completes, then everything is fine |
| 13:18:30 | AlexP | ? |
| 13:18:31 | Jaykay | AlexP: what would be the alternative? |
| 13:18:42 | Jaykay | erm, wait |
| 13:18:42 | | Quit Horscht (Read error: 60 (Operation timed out)) |
| 13:19:29 | Jaykay | ...that would be normal playback... why should this happen? but i'll test it |
| 13:19:43 | Jaykay | and shutting down needs ~15s after this |
| 13:20:00 | AlexP | No, I mean that if you deleted a file that was fully buffered then you can start new tracks as normal |
| 13:20:19 | Jaykay | aaah, ok, wait |
| 13:20:20 | AlexP | i.e. the bug only appears when the system tries to buffer the remaining part of a file that is no longer there |
| 13:21:15 | Jaykay | how big is the buffer on a e200? |
| 13:21:41 | AlexP | v1 is 32 MB, so ~£) MB ish I'd guess |
| 13:21:46 | AlexP | er, ~30 |
| 13:22:06 | Jaykay | ok, thanks |
| 13:23:24 | Jaykay | is the already played part of a track immidiately deleted from the buffer? |
| 13:24:03 | kugel | no |
| 13:24:22 | Jaykay | when is it deleted? on rebuffering? |
| 13:24:42 | kugel | it's overwritten by the next rebuffer. and in some cases the old buffer is used when skipping backwards |
| 13:26:53 | | Join arohtar [0] (n=faemir@78.33.109.163) |
| 13:28:01 | | Quit arohtar (Client Quit) |
| 13:28:21 | | Join arohtar [0] (n=faemir@78.33.109.163) |
| 13:29:11 | | Quit faemir (Nick collision from services.) |
| 13:29:14 | | Nick arohtar is now known as faemir (n=faemir@78.33.109.163) |
| 13:30:06 | | Join sampattuzzi [0] (n=sam@88-106-164-225.dynamic.dsl.as9105.com) |
| 13:30:36 | sampattuzzi | I'm getting compile errors with rockbox. It's the first time I try compiling and I'm not sure what is wrong, |
| 13:31:36 | sampattuzzi | http://pastebin.org/68118 |
| 13:32:00 | sampattuzzi | Could anybody please tell me what dependencies I'm missing (if any)? |
| 13:32:57 | Jaykay | AlexP: if the deleted file was fully buffered, playback continues as normal. |
| 13:51:45 | | Join FlynDice [0] (n=FlynDice@65.74.4.35) |
| 13:53:30 | | Quit BHSPitLappy (Read error: 60 (Operation timed out)) |
| 14:00 |
| 14:09:22 | *** | Saving seen data "./dancer.seen" |
| 14:09:28 | | Join Grahack [0] (n=Grahack@ip-222.net-82-216-222.rev.numericable.fr) |
| 14:09:44 | | Quit zMastaa (Read error: 60 (Operation timed out)) |
| 14:09:59 | | Join zMastaa [0] (n=windows7@host81-155-77-229.range81-155.btcentralplus.com) |
| 14:22:55 | | Quit pixelma (niven.freenode.net irc.freenode.net) |
| 14:22:55 | NSplit | niven.freenode.net irc.freenode.net |
| 14:22:55 | | Quit ps-auxw (niven.freenode.net irc.freenode.net) |
| 14:22:55 | | Quit parafin (niven.freenode.net irc.freenode.net) |
| 14:22:55 | | Quit bzed (niven.freenode.net irc.freenode.net) |
| 14:24:18 | NHeal | niven.freenode.net irc.freenode.net |
| 14:24:18 | NJoin | parafin [0] (i=parafin@paraf.in) |
| 14:24:18 | NJoin | ps-auxw [0] (n=arneb@dyn37.ps-auxw.de) |
| 14:24:18 | NJoin | bzed [0] (n=bzed@devel.recluse.de) |
| 14:24:18 | NJoin | pixelma [0] (i=quassel@rockbox/staff/pixelma) |
| 14:30:24 | | Join n1s [0] (n=n1s@rockbox/developer/n1s) |
| 14:38:14 | | Quit zMastaa (Remote closed the connection) |
| 14:38:27 | | Join zMastaa [0] (n=windows7@host81-155-77-229.range81-155.btcentralplus.com) |
| 14:40:33 | | Quit einhirn (Read error: 54 (Connection reset by peer)) |
| 14:52:22 | | Quit n1s (Read error: 60 (Operation timed out)) |
| 14:53:17 | | Join ZincAlloy [0] (n=d9eeee2b@giant.haxx.se) |
| 14:56:28 | | Quit stoffel (Read error: 60 (Operation timed out)) |
| 14:59:21 | | Nick dys` is now known as dys (n=andreas@krlh-5f735889.pool.mediaWays.net) |
| 15:00 |
| 15:00:02 | ZincAlloy | hi everybody. somebody put my Slick-Bushfire theme onto the h300 theme site, although its license is not compatible with CC-BY-SA. could somebody take it off, please? |
| 15:03:04 | Jaykay | ZincAlloy: don't you want to relicense it? |
| 15:04:03 | ZincAlloy | I can't. The background image is licensed cc-by-nc |
| 15:07:49 | | Join n1s [0] (n=n1s@rockbox/developer/n1s) |
| 15:09:12 | AlexP | ZincAlloy: Will do |
| 15:09:31 | ZincAlloy | AlexP: thanks a lot! |
| 15:10:46 | AlexP | ZincAlloy: Could you PM me your e-mail address? Just to double check it with the submission one :) |
| 15:16:04 | | Quit zMastaa (Remote closed the connection) |
| 15:16:18 | | Join zMastaa [0] (n=windows7@host81-155-77-229.range81-155.btcentralplus.com) |
| 15:16:29 | | Quit kugel (Read error: 60 (Operation timed out)) |
| 15:17:36 | AlexP | ZincAlloy: Sorry, I misunderstood - I see now he has taken your -NC theme and put it on there |
| 15:18:00 | ZincAlloy | exactly. |
| 15:18:19 | ZincAlloy | arbox widgets and hazzard have the same issue |
| 15:18:36 | AlexP | OK, Slick-Bushfire has gone, I'll remove those others too |
| 15:18:56 | | Join DerPapst [0] (n=DerPapst@91-64-221-175-dynip.superkabel.de) |
| 15:18:57 | ZincAlloy | and free state as well |
| 15:20:45 | AlexP | OK, they are all gone |
| 15:20:52 | ZincAlloy | thanks a lot |
| 15:21:03 | AlexP | No worries, we want to respect licences :) |
| 15:21:24 | AlexP | He has submitted loads though, I bet there are similar issues for other targets |
| 15:22:33 | ZincAlloy | there are some far worse issues on the theme gallery.. |
| 15:23:16 | ZincAlloy | like itunes 0.1 for e200 |
| 15:24:10 | AlexP | can you arbitrarily relicence gpl to CC-SA-BY ? |
| 15:24:55 | GodEater | sampattuzzi: can you post the output of running configure as well? |
| 15:30:20 | | Quit ZincAlloy ("CGI:IRC") |
| 15:30:24 | | Join ZincAlloy [0] (n=d9eeee2b@giant.haxx.se) |
| 15:33:03 | | Quit Sajber^ (Read error: 54 (Connection reset by peer)) |
| 15:39:09 | | Join GeekShadow [0] (n=Antoine@reactos/tester/GeekShadow) |
| 15:45:14 | | Join dfkt [0] (i=dfkt@unaffiliated/dfkt) |
| 15:53:51 | n1s | amiconn: that xor variant of bitrev is indeed ~0.5% faster on pp |
| 15:54:12 | n1s | eh vorbis decoding is 0.5% faster |
| 15:56:34 | n1s | ... for medium bitrates, and about 1% on higher bitrates so worth it imo |
| 15:57:40 | | Join StealthyXIIGer [0] (n=stealthy@69.216.113.160) |
| 16:00 |
| 16:01:37 | sampattuzzi | http://pastebin.org/68147 |
| 16:01:47 | sampattuzzi | GodEater: ^^ |
| 16:02:05 | | Quit ZincAlloy ("CGI:IRC") |
| 16:04:09 | sampattuzzi | AlexP: depends on if you hold the copyright |
| 16:04:19 | sampattuzzi | in which case you do whatever you like |
| 16:05:36 | AlexP | sampattuzzi: Clearly, but in this case they don't |
| 16:06:37 | AlexP | Should we not just close FS #10872 and be done with it? It scraps anything other than latin alphabet left to right text so is never going to go in |
| 16:07:15 | Llorean | AlexP: Does it _actually_ scrap their ability to be used, or does he just think it does? |
| 16:07:30 | AlexP | Llorean: I'm just going on what he said |
| 16:07:32 | Llorean | I haven't tried it, but I'm having a hard time understanding from his descriptions what exactly he's doing that would make RTL impossible. |
| 16:08:15 | Llorean | Is it that it would make other font use impossible as a whole? |
| 16:08:27 | GodEater | sampattuzzi: that's very odd output you're getting there from your compile attempt |
| 16:08:31 | GodEater | configure looks like it worked fine |
| 16:08:36 | | Join kugel [0] (n=kugel@rockbox/developer/kugel) |
| 16:08:43 | sampattuzzi | GodEater, seemed that way to me too |
| 16:08:55 | GodEater | sampattuzzi: which platform are you building on? |
| 16:09:25 | *** | Saving seen data "./dancer.seen" |
| 16:11:32 | sampattuzzi | GodEater, Ubuntu |
| 16:11:55 | GodEater | and you say this is the first time you've ever tried building rockbox? |
| 16:13:06 | sampattuzzi | yes but I built the UI testing build |
| 16:13:21 | * | GodEater has no idea what that means |
| 16:13:35 | sampattuzzi | the simulator |
| 16:13:40 | GodEater | ah right |
| 16:13:43 | GodEater | in the same directory |
| 16:13:44 | GodEater | ? |
| 16:14:30 | sampattuzzi | GodEater, nope, don't think so |
| 16:15:00 | GodEater | and rockboxdev.sh ran ok? |
| 16:15:16 | sampattuzzi | I might try running that again |
| 16:15:43 | sampattuzzi | I'm pretty sure it worked first time though |
| 16:16:11 | gevaerts | this doesn't look like a rockboxdev.sh failure |
| 16:16:32 | gevaerts | which files do you have in build-dir? |
| 16:17:05 | sampattuzzi | ls |
| 16:17:05 | sampattuzzi | apps autoconf.h firmware make.dep Makefile |
| 16:17:37 | gevaerts | try removing them all and then start again |
| 16:19:08 | sampattuzzi | It's getting further now |
| 16:19:19 | sampattuzzi | thanks GodEater and gevaerts |
| 16:19:31 | GodEater | you're welcome |
| 16:21:37 | amiconn | n1s: C or asm? |
| 16:25:56 | * | amiconn thinks that asm allows some further shifter trickery that gcc certainly won't do |
| 16:26:13 | n1s | amiconn: pure C for armv4 i did two lines on inline asm, one for coldfire, and one for armv6 |
| 16:26:43 | n1s | since gcc messes up badly for coldfire and just misses the rev instruction on armv6 |
| 16:28:39 | n1s | amiconn: oh? |
| 16:32:10 | | Quit StealthyXIIGer (Connection timed out) |
| 16:38:43 | | Join jon-kha [0] (i=jon-kha@kahvi.eu.org) |
| 16:43:55 | | Quit elcan (SendQ exceeded) |
| 16:45:45 | | Quit rphillips ("reboot") |
| 16:53:43 | | Quit n1s ("Lämnar") |
| 16:53:57 | | Join n1s [0] (n=n1s@rockbox/developer/n1s) |
| 16:54:51 | n1s | amiconn: this is wat i came up with http://pastebin.ca/1724927 a small speedup on coldfire too, no real difference on the beast |
| 16:55:37 | | Join liar [0] (n=liar@83.175.83.185) |
| 17:00 |
| 17:01:06 | * | amiconn wonders what that compiles to on arm |
| 17:02:08 | | Quit kugel (Read error: 60 (Operation timed out)) |
| 17:10:02 | | Join rphillips [0] (n=rphillip@66-90-184-91.dyn.grandenetworks.net) |
| 17:15:45 | | Join Sajber^ [0] (n=Sajber@211.142.216.81.static.tab.siw.siwnet.net) |
| 17:17:02 | | Join ifonefox [0] (n=irchon@mobile-166-137-136-159.mycingular.net) |
| 17:18:46 | | Quit ifonefox (Remote closed the connection) |
| 17:20:28 | n1s | amiconn: this when compiling with O2 for arm7tdmi http://pastebin.ca/1724963 |
| 17:22:03 | n1s | interesting thing is that m68k-gcc only goes mad when specifying a coldfire target, when compiling for a regular m68k it just generates the swap directly |
| 17:25:21 | | Join Xerion [0] (i=xerion@82-170-197-160.ip.telfort.nl) |
| 17:27:39 | | Join pamaury [0] (n=pamaury@sal63-1-82-243-96-220.fbx.proxad.net) |
| 17:30:48 | n1s | i guess i should test a new gcc and report a bug if this is still done |
| 17:35:34 | | Quit Jaykay (Read error: 110 (Connection timed out)) |
| 17:47:46 | | Join Jaykay [0] (n=chatzill@p5DDC6C5D.dip.t-dialin.net) |
| 17:58:48 | | Join stoffel [0] (n=quassel@p57B4D2FE.dip.t-dialin.net) |
| 18:00 |
| 18:00:37 | | Join b1uebrother [0] (n=dom@92.117.112.218) |
| 18:02:08 | | Quit Xerion (" ") |
| 18:08:26 | | Join jae [0] (n=jae@HSI-KBW-091-089-249-155.hsi2.kabel-badenwuerttemberg.de) |
| 18:09:28 | *** | Saving seen data "./dancer.seen" |
| 18:12:56 | jae | Hmmm... I'm on Win7 and, trying to update my Fuze, get "Target mismatch detected. Installed target: sansafuze, selected target: Sansa Fuze (Unstable)" |
| 18:13:59 | jae | Is that due to a more recent change, or due to using autodetection (which didn't work back on WinXP, but that was pre-24000 ;-)? |
| 18:15:36 | bertrik | jae, there have been some target renames recently indeed, this could explain your problem, but I'm not completely sure |
| 18:15:45 | jae | Installed version is r23894 :D |
| 18:16:03 | * | jae goes and checks SVN logs |
| 18:16:47 | | Join AaronM [0] (n=Aaron@adsl-250-8-242.bhm.bellsouth.net) |
| 18:17:39 | jae | Anyone got an idea why I can't switch machines with synergy when rbutilqt is up (Win7)? |
| 18:19:02 | | Quit petur ("work->home") |
| 18:19:08 | CIA-6 | New commit by bluebrother (r24101): Rename player sections to match the platform section. ... |
| 18:20:13 | | Join toffe82 [0] (n=chatzill@ppp-71-142-15-73.dsl.frs2ca.pacbell.net) |
| 18:20:32 | b1uebrother | jae: yes, that's caused by target renames. The next version of Rockbox Utility will be adjusted to that |
| 18:20:58 | | Join merbanan [0] (n=banan@c-94-255-209-233.cust.bredband2.com) |
| 18:21:10 | b1uebrother | synergy as in synergy2.sf.net? |
| 18:21:55 | jae | Yes, as in that |
| 18:23:57 | b1uebrother | no idea what's the problem, but I might give it a try some time later. |
| 18:24:27 | * | b1uebrother wonders if it would be possible to try that using a vm |
| 18:25:25 | jae | rbutilqt doesn't have to be visible, just has to have input focus |
| 18:26:18 | b1uebrother | does that issue also appear on wxp? |
| 18:26:44 | jae | Haven't noticed it there (so probably didn't), but not sure, will check later |
| 18:26:57 | | Quit Hillshum (Read error: 60 (Operation timed out)) |
| 18:38:55 | * | jae is really weird... |
| 18:39:21 | jae | Apparently, since setting a different cache directory doesn't work... |
| 18:40:29 | jae | I get a "Mountpoint does not exist"... even though I did create the directory (okay, externally, since the selection dialog doesn't (for some reason) have "Create directory" option) |
| 18:41:24 | gevaerts | what would be the point of creating a mount point from within rbutil? |
| 18:42:03 | sampattuzzi | I'm trying to pinpoint which revision a bug occurs in for better debugging. Is there a faster way of compiling or some tips for doing this? |
| 18:42:09 | jae | Hmm, news to me that Win7 has mount points... |
| 18:43:56 | jae | gevaerts: so how *do* you change the cache path? Or: what do I miss? |
| 18:44:27 | gevaerts | sampattuzzi: ccache can help a lot. Also, if you're looking for a bug in the core (i.e. not a codec or plugin thing), just "make bin" will be enough (codecs or plugins might then not work properly though). Also, are you doing a binary search over revisions? Going back one by one is slow |
| 18:45:12 | gevaerts | jae: hm, sorry. I probably misunderstood what you were seeing. The cache selecting dialog could indeed use a create option |
| 18:45:38 | sampattuzzi | gevaerts, I'm trying some revisions I think might have caused it first then I will do binary search. |
| 18:45:50 | | Join bluebroth3r [0] (n=dom@92.117.43.76) |
| 18:46:00 | | Join Xerion [0] (i=xerion@82-170-197-160.ip.telfort.nl) |
| 18:46:10 | gevaerts | that seems sensible enough |
| 18:47:17 | bluebroth3r | jae: you have problems with mountpoint or cache path? |
| 18:48:44 | sampattuzzi | gevaerts, how do I know which revision was the official release? |
| 18:49:13 | jae | bluebroth3r: Cache path... trying to set it gets me the mountpoint message (OS is Win7 x64) |
| 18:49:49 | gevaerts | sampattuzzi: the official releases are on a different branch, so if you're just looking at trunk you won't get those anyway |
| 18:49:49 | jae | Hunting a daily build of rbutil to check, my installed version is 1.2.3 (r22749) |
| 18:49:58 | bluebroth3r | hmm. Maybe there's something up with 64bit? There have also been reports in the proxy settings not working correctly on 64bit linux |
| 18:50:07 | sampattuzzi | gevaerts, ok thanks |
| 18:50:15 | bluebroth3r | jae: there are no daily builds of Rockbox Utility |
| 18:50:30 | gevaerts | sampattuzzi: apart from that, 3.4 branched at r22748 |
| 18:50:39 | jae | bluebroth3r: I feared as much ;) |
| 18:50:56 | bluebroth3r | there's an svn build from some days back here: http://www.alice-dsl.net/dominik.riebeling/rockbox/ |
| 18:51:49 | | Quit b1uebrother (Read error: 60 (Operation timed out)) |
| 18:53:29 | jae | Thanks... oops, gone |
| 18:53:44 | gevaerts | he's not :) |
| 18:53:58 | jae | Interesting message "Your configuration is invalid. This is most likely due to a change device path." |
| 18:54:15 | jae | Sounds to me like it really doesn't like that path to change at all ;) |
| 18:54:44 | | Quit sampattuzzi ("Ex-Chat") |
| 18:54:48 | jae | Oh, yeah, that was another brother :D |
| 18:55:28 | bluebroth3r | yeah, I'm split personality ;-) |
| 18:55:40 | | Quit HBK (Read error: 110 (Connection timed out)) |
| 18:56:36 | jae | Okay, reporting bug... as it doesn't even let me set the *previous* default. |
| 18:57:16 | jae | (Which was "Users\jae\AppData\Local\Temp"... it complains with that mountpoint nonsense) |
| 18:58:02 | bluebroth3r | I guessed you checked the mountpoint? It also needs to be writeable. |
| 18:58:49 | bluebroth3r | can you post the system trace (from About / Troubleshoot / System Trace) somewhere? |
| 18:59:45 | jae | Oh, and despite the error message, it seems to actually take the value anyway |
| 18:59:57 | jae | Lemme try to download a theme or five |
| 19:00 |
| 19:02:50 | jae | Gets weirder... I *do* have data in the previously empty directory... (AppData\Local\Rockbox, new dir rbutil-cache, some hex-named file that could be the compressed theme I "tried" to d/l) |
| 19:03:21 | jae | But it *did* complain with "Mount point is wrong!" |
| 19:03:47 | jae | Ooops. |
| 19:05:06 | jae | Good thing I haven't yet logged a PR |
| 19:05:26 | CIA-6 | New commit by nls (r24102): Improved bitrev with approach suggested by Jens Arnold, gives 0.5%-1% speedup for tremor decoding on sansa c200 (PP) and a tiny speedup on coldfire as ... |
| 19:05:32 | jae | Problem was... the messages |
| 19:06:12 | jae | I didn't expect the config to not work when the player isn't connected. Which it wasn't. |
| 19:06:42 | jae | And the theme installer error... well, "Mount point is wrong" is just wrong if the player isn't connected at all |
| 19:07:02 | jae | It should better say "Mount point is wrong or player isn't connected" |
| 19:07:14 | bluebroth3r | well, if the player is not connected then the drive letter assigned to the player doesn't exist. Which makes the mountpoint invalid :) |
| 19:07:37 | jae | Or reversed order if the player *had* been connected in the past |
| 19:08:04 | jae | bluebroth3r: are you, by any chance, a mathematician? (CS student works just as well... ;) |
| 19:08:47 | bluebroth3r | the main problem is that the user can enter anything into the mountpoint input box. I'd really like to move that to some "experts" view, but for that to work the autodetection has to get more reliable. Which it currently isn't ... |
| 19:09:24 | bluebroth3r | jae: no, I've studied electrical engineering |
| 19:09:44 | | Join StealthyXIIGer [0] (n=stealthy@69.216.113.160) |
| 19:10:24 | Llorean | jae: How can there be a right mount point if the player isn't connected? |
| 19:10:47 | Llorean | Or rather, how can "mount point is wrong" be incorrect if the mount point *is* wrong? |
| 19:11:24 | jae | But it wasn't... |
| 19:11:30 | Llorean | It was. |
| 19:11:47 | jae | Well, we can split hairs over that bit of semantics all night long. Not that it would have any beneficial effect... |
| 19:11:51 | Llorean | How can you have the correct mount point for a player that's not mounted? |
| 19:12:42 | bluebroth3r | jae: well, I agree that the error message could be better, but as soon as you disconnect a removeable drive it doesn't have a drive letter assigned anymore, and there is no guarantee that reconnecting it again will yield it getting the same drive letter |
| 19:13:00 | bluebroth3r | the same is true for mountpoints on linux and OS X. |
| 19:13:19 | bluebroth3r | so in this case we need to consider the mountpoint as wrong. We simply can't rely on the OS here. |
| 19:13:31 | jae | bluebroth3r: that bit with that changing path/driveletter is true |
| 19:13:37 | | Join Casainho [0] (n=chatzill@87.196.10.255) |
| 19:14:05 | Llorean | I'm confused though. Why were you pointing it at a device that wasn't connected and expecting it to work? |
| 19:14:08 | jae | I fought (successfully) with udev this last week to get it assign a persistent /dev to the fuze |
| 19:14:31 | jae | (complicated a bit by the external microSD being an additional drive...) |
| 19:14:46 | jae | Llorean: I wasn't at any one time |
| 19:14:59 | bluebroth3r | so, displaying something like "Mountpoint wrong. Check if the player is connected and is mounted / assigned a drive letter" might be an idea. |
| 19:15:06 | Llorean | jae: "(12:06:08 PM) jae: I didn't expect the config to not work when the player isn't connected. Which it wasn't." |
| 19:15:24 | jae | "the config" == "the configuration dialog" |
| 19:15:41 | Llorean | Doesn't that include pointing it to the player? |
| 19:15:45 | bluebroth3r | completely detecting the player upon startup would be really nice and completely "fix" such issues, but autodetection still isn't good enough. |
| 19:15:53 | jae | I was changing the cache path, and got a weird error that had (apparently) nothing to do with what I changed |
| 19:16:28 | jae | It does include it, yes... and since it's one dialog with one OK button, it has to check the whole config when this is clicked |
| 19:16:42 | jae | I've realized that by now |
| 19:16:49 | | Join Hillshum [0] (n=hillshum@75-165-229-121.slkc.qwest.net) |
| 19:16:50 | bluebroth3r | no, it does not. The problem is that when clicking "ok" all values are checked, and apparently some other value became invalid ;-) |
| 19:17:10 | Llorean | bluebroth3r: That is a problem. The rbutil settings shouldn't be impossible to change without a device attached |
| 19:17:22 | * | bluebroth3r really needs to find time to work on autodetection ... and the GUI ... and the configuration ... :o |
| 19:17:42 | jae | They aren't... it did accept the cache path change, it just threw a (seemingly) weird error |
| 19:17:47 | bluebroth3r | Llorean: well, when should those values get checked instead? |
| 19:18:14 | Llorean | bluebroth3r: Only when values on that tab are changed, or when you attempt to start an install? |
| 19:18:17 | jae | If it could/can detect which values were *changed*... and only check those? |
| 19:19:14 | bluebroth3r | Llorean: well, that only defers the error. I'd prefer to give it as soon as possible. I've already thought about something like done for the TTS configuration −− display a hint inline if the value is incorrect. |
| 19:20:03 | Llorean | bluebroth3r: The problem is that it interferes with other configuration. Maybe give the error as soon as RBUtil is launched? Something like "rbutil requires an attached player to use. The previous player configuration appears to no longer be valid."? |
| 19:20:11 | bluebroth3r | so the values that are still the defaults (like on first startup no player selection) won't get checked ever. |
| 19:20:18 | Llorean | That way people don't try to use it without a player attached. |
| 19:20:50 | bluebroth3r | Llorean: we already give such an error on startup, it just doesn't tell anything about a connected player. |
| 19:21:03 | Llorean | Maybe change the message then. |
| 19:22:05 | bluebroth3r | "Your configuration is invalid. This is most likely due to a changed device path. The configuration dialog will now open to allow you to correct the problem." |
| 19:22:13 | bluebroth3r | I don't see anything that could be unclear here. |
| 19:22:21 | pamaury | Is there someone here that has free time to test a plugin I wrote to check that open is buggy due to a dircache bug ? |
| 19:22:32 | bluebroth3r | this message also appears if the configuration is missing |
| 19:22:38 | jae | Dang. Thought those cache files would be usable, but it appears they aren't |
| 19:22:54 | bluebroth3r | jae: they are :) |
| 19:23:16 | bluebroth3r | the cache files are the files as downloaded, with the md5sum of the URL as filename. |
| 19:24:18 | jae | But since they |
| 19:24:31 | bluebroth3r | svn creates a file cache.txt with the mappings |
| 19:24:56 | bluebroth3r | but that feature isn't included in the latest release. |
| 19:25:20 | jae | But since they're w/o endings, they're just binary blobs to Windows. |
| 19:25:27 | jae | Where's that cache.txt? |
| 19:26:09 | jae | Or do you mean the svn version of rbutil? |
| 19:26:21 | bluebroth3r | yes, the svn version of rbutil. |
| 19:27:16 | bluebroth3r | it was added after the last rbutil release. |
| 19:29:15 | bluebroth3r | hmm, rbutilqt.php returning links to download.php instead of the files makes the rbutil download dialog show up a very weird filename :/ |
| 19:30:58 | jae | And another one: your SVN build gives me "No themes available for the selected target" |
| 19:31:23 | jae | While 1.2.3 does give me themes. |
| 19:32:18 | bluebroth3r | yes, that's a known issue. Also caused by the target renames. |
| 19:35:48 | jae | Would be nice if the themes dialog didn't quit after every install... yes, multi-select is possible, but not that simple to use |
| 19:35:52 | | Join pixelma_ [0] (i=quassel@rockbox/staff/pixelma) |
| 19:35:52 | | Quit pixelma (Nick collision from services.) |
| 19:35:59 | | Quit amiconn (Nick collision from services.) |
| 19:36:02 | | Join amiconn_ [0] (i=quassel@rockbox/developer/amiconn) |
| 19:36:07 | | Nick pixelma_ is now known as pixelma (i=quassel@rockbox/staff/pixelma) |
| 19:36:21 | | Nick amiconn_ is now known as amiconn (i=quassel@rockbox/developer/amiconn) |
| 19:36:22 | | Quit dfkt ("-= SysReset 2.53=- Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn.") |
| 19:38:40 | | Join Strife89 [0] (n=Strife89@adsl-154-13-96.mcn.bellsouth.net) |
| 19:38:50 | bertrik | I just built a clip-build from svn but with compiler option -Os and the resulting build works but menu items miss their first character |
| 19:39:04 | bertrik | Ideally, the optimisation level should only affect the speed, right? |
| 19:39:45 | jae | Ideally, yes ;) |
| 19:43:32 | * | bluebroth3r bbl |
| 19:43:34 | | Quit bluebroth3r ("leaving") |
| 19:55:34 | pamaury | Up: Is there someone here that has free time to test a plugin I wrote to check that open is buggy due to a dircache bug ? |
| 20:00 |
| 20:00:33 | jae | Can someone point me to how to disable that stupid Sansa-side database refresh? I know I've seen it before, but for the life of me, I can't find the info anymore. |
| 20:01:59 | bertrik | I think it's in the SansaFAQ wiki page or something like that |
| 20:04:02 | | Quit toffe82 (Read error: 104 (Connection reset by peer)) |
| 20:06:01 | jae | Ouch. Thanks, yes, that's it... and I'm stupid. |
| 20:06:44 | n1s | bertrik: speed and size but yeah ;P |
| 20:06:51 | jae | Or maybe it isn't? Doesn one of these work for the Fuze? |
| 20:08:00 | jae | n1s: <nitpick>speed and/or size</nitpick> |
| 20:08:41 | n1s | jae: it will *very* rarely only affect one of them |
| 20:09:30 | jae | Not *another* hair-splitting session please! ;-) |
| 20:09:33 | *** | Saving seen data "./dancer.seen" |
| 20:10:15 | n1s | i though that's what we're here for :) |
| 20:10:20 | * | jae does nitpick, but he doesn't split hairs ;) |
| 20:10:43 | | Join kugel [0] (n=kugel@rockbox/developer/kugel) |
| 20:10:45 | bertrik | Actually it seems that the icon overwrites the first character. if I disable icons, it looks OK. If I enable a pointer-selector, the text does shift 1 icon-position to the right |
| 20:12:26 | | Join BHSPitLappy [0] (n=BHSPitLa@unaffiliated/bhspitmonkey) |
| 20:16:06 | sagemfreak_ | liar: is there any new progress on the ipod nano 2g flash problem? |
| 20:17:01 | sagemfreak_ | (ive used your patch successfully yesterday - but ive noticed that it is under strong discussion) |
| 20:19:23 | | Join toffe82 [0] (n=chatzill@ppp-71-142-15-73.dsl.frs2ca.pacbell.net) |
| 20:22:26 | amiconn | n1s: How inefficient... |
| 20:22:36 | liar | sagemfreak_: TheSeven said he is going to commit it, but he wants to see some test results |
| 20:23:53 | | Part watto |
| 20:27:55 | | Join HBK [0] (n=hbk@rrcs-97-77-49-215.sw.biz.rr.com) |
| 20:29:52 | sagemfreak_ | liar: do you have some testbenches to prove the reliability of the patch (which i can run)? |
| 20:30:17 | | Join Martin9988 [0] (n=xojolito@72.168.49.74) |
| 20:31:59 | | Part Martin9988 |
| 20:40:33 | | Quit flydutch ("/* empty */") |
| 20:43:25 | amiconn | n1s: That's 27 instructions (excluding the bx lr) if I counted correctly. I can shorten this to 18 instructions. |
| 20:43:45 | | Quit GeekShadow (Read error: 104 (Connection reset by peer)) |
| 20:44:02 | amiconn | (15 for ARMv6) |
| 20:44:13 | | Join GeekShadow [0] (n=Antoine@reactos/tester/GeekShadow) |
| 20:45:27 | amiconn | n1s: What do you think: http://pastebin.ca/1725178 (untested, but should work)? |
| 20:47:44 | | Quit stoffel (Remote closed the connection) |
| 20:48:40 | liar | sagemfreak_: if one of the patches in FS #10775(especially the last one) fails for you then it is unreliable |
| 20:49:18 | sagemfreak_ | liar: :-) then i will watch for any errors |
| 20:49:58 | sagemfreak_ | btw - who has experience with the usb subsystem? |
| 20:50:07 | gevaerts | which bits? |
| 20:50:37 | liar | sagemfreak_: usb isnt working for you too? |
| 20:50:45 | sagemfreak_ | no |
| 20:51:10 | sagemfreak_ | nand writing / reading is working since ive applied the patch |
| 20:51:39 | sagemfreak_ | the ipod is detected (when i disable hid) |
| 20:51:44 | sagemfreak_ | and i can write onto the ipod but |
| 20:52:03 | gevaerts | what OS are you using? |
| 20:52:07 | sagemfreak_ | after restart, the ipod is broken and itunes is needed (everything is wiped) |
| 20:52:14 | sagemfreak_ | ubuntu 9.10 and 8.10 |
| 20:52:36 | sagemfreak_ | havent tested windows yet |
| 20:53:38 | sagemfreak_ | but before restart everything looks fine (i can browse files and so on) - maybe the partiton information is wiped? |
| 20:54:19 | gevaerts | OK. That means that hid not working is not because of an OS bug (some OSX versions can't handle it, as well as windows 2000 apparently) |
| 20:54:21 | liar | sagemfreak_: i have seen that too but that should be fixed with my patch |
| 20:54:31 | sagemfreak_ | no |
| 20:54:40 | liar | sagemfreak_: hid isnt working for me too |
| 20:55:34 | | Quit dys (Remote closed the connection) |
| 20:55:47 | liar | without my patch the first sector of the flash gets zeroed |
| 20:56:07 | sagemfreak_ | ive applied this patch: http://www.rockbox.org/tracker/task/10775 |
| 20:56:25 | liar | sagemfreak_: and usb with hid disabled still fails? |
| 20:56:39 | sagemfreak_ | after patching it was possible to run plugins and browse files (was not possible before) |
| 20:57:33 | | Join dfkt [0] (i=dfkt@unaffiliated/dfkt) |
| 20:57:54 | sagemfreak_ | yes still fails (patch from Sunday, 20 December 2009, 22:25 GMT+1 ) |
| 20:58:43 | sagemfreak_ | is Tuesday, 22 December 2009, 00:19 GMT+1 signifficant different? |
| 20:59:03 | liar | sagemfreak_: no |
| 20:59:12 | sagemfreak_ | bad |
| 20:59:32 | sagemfreak_ | yesterday i had 3 devices here |
| 21:00 |
| 21:00:12 | sagemfreak_ | 2 of them can browse/start plugins without the patch and the third is needing the patch |
| 21:00:25 | sagemfreak_ | but all devices crash after usb write |
| 21:05:32 | CIA-6 | New commit by alle (r24103): Improve typesetting and fix a typo |
| 21:08:33 | liar | sagemfreak_: does not happen on mine |
| 21:08:39 | liar | sagemfreak_: could you try Friday, 13 November 2009, 00:00 GMT+1 |
| 21:09:17 | sagemfreak_ | liar: which type do you use? ive used 2 8gb models. |
| 21:09:52 | liar | sagemfreak_: 8gb |
| 21:10:01 | liar | sagemfreak_: it seems like only 8GB models have this problems |
| 21:10:39 | sagemfreak_ | liar: i think so too - yesterday ive only tested 8gb models. |
| 21:11:12 | sagemfreak_ | liar: but i own a 4gb model too. first of all i will test the 4gb model with the current patch |
| 21:12:44 | sagemfreak_ | liar: how much bytes have to be saved for backup purposes (with dd)? |
| 21:14:44 | liar | sagemfreak_: i think only the first sector needs to be backed up, but i am not sure if it delets other sectors too |
| 21:16:56 | sagemfreak_ | liar: ok - i will copy all contents using the apple file tranfer mode. the 8gb is prepared for christmas :-) |
| 21:17:23 | sagemfreak_ | liar: so this night is the last night i will have my hands on it :-) |
| 21:20:01 | bertrik | sagemfreak_, liar, I think theseven was also quite interested in being able to distinguish between players that have different NAND behaviour |
| 21:21:17 | liar | sagemfreak_: can you check the return value of nand_get_chip_type? |
| 21:21:55 | liar | (on the nano where NAND reading/writing fails) |
| 21:22:01 | sagemfreak_ | liar: how? |
| 21:22:37 | liar | sagemfreak_: you have a build system installed? |
| 21:25:04 | pamaury | gevaerts: have you got a player and time to check something ? |
| 21:25:25 | gevaerts | pamaury: yes. Does it matter which player? |
| 21:27:05 | amiconn | n1s: Better order (avoiding all unnecessary duplication): http://pastebin.ca/1725218 |
| 21:27:22 | sagemfreak_ | liar: yes |
| 21:27:32 | pamaury | I don't think so, it has to do with dircache. I suspect open is buggy when it uses dircache. In fact, I suspect (from the code) that dircache_get_entry is buggy or too weird. I have coded a plugin which does some tests and print the results in the log. See http://pastebin.com/d5857feba |
| 21:28:45 | pamaury | gevaerts: I think that with dircache, opening a directory opens the first file within the directory instead of failing. If you can, try it with and without dirache. |
| 21:30:57 | * | gevaerts compiles |
| 21:31:06 | liar | sagemfreak_: put a splashf(200,"%8x",result); before the return in firmware/target/arm/s5l8700/ipodnano2g/nand-nano2g.c in nand_get_chip_type |
| 21:31:44 | n1s | amiconn: looks very nice and should be faster on arm7tdmi i am sure, iiuc there are quite a few stalls in that for arm 11 so it would be interesting to benchmark, have you done so? |
| 21:31:55 | amiconn | no |
| 21:32:15 | n1s | i'll do that then |
| 21:32:39 | n1s | i guess the gain from inlining would be very small |
| 21:32:40 | amiconn | There are essentially two tricks vs. what gcc does |
| 21:33:12 | amiconn | (1) The constants are derived from their predecessors, that takes just *one* eor per stage |
| 21:33:49 | amiconn | (2) The and/eor/orr sequence pre-shifts (and corrects that for eor), saving an extra mov just for shifting |
| 21:34:09 | n1s | very clever indeed :) |
| 21:34:54 | amiconn | The byte-swap constant isn't necessary for byte swapping on armv6, but it is used to compute the nibble-swap constant. That's 3 instructions in total - same as if I would construct the nibble constant directly |
| 21:36:01 | n1s | amiconn: i noticed that gcc doesn't construct these constants when compiling for arm11, it just ldr's them |
| 21:36:33 | amiconn | Then it might make sense to do the same here |
| 21:37:22 | | Join dys [0] (n=andreas@krlh-5f735889.pool.mediaWays.net) |
| 21:38:09 | Unhelpful | how many cycles is LDR on older arm? arm11 has a *lot* of one-cycle instructions (but with >1cycle result latencies) |
| 21:38:27 | amiconn | 3 cycles on ARM7TDMI iirc |
| 21:38:43 | kugel | amiconn: would reordering help pipelining a bit on that paste? |
| 21:40:01 | kugel | probably not |
| 21:40:03 | Unhelpful | amiconn: and that's throughput? it makes more sense to construct constants in that case, if they can be formed from 3 valid immediates with add/subtract etc... |
| 21:41:23 | | Quit bmbl ("Bye!") |
| 21:41:41 | Unhelpful | n1s: a constructed constant on arm11 takes as many cycles as it takes instructions... ldr takes only one cycle, *provided* there are other instructions that can be scheduled during the result delay. that would be why the behavior changes on arm11 :) |
| 21:42:02 | n1s | makes sense :) |
| 21:43:14 | pamaury | gevaerts: still alive or did my plugin successfully blow up you dap ;) |
| 21:43:16 | Unhelpful | it can make arm11 much faster, but also a bit more difficult to work on as you must be careful about not just execution times, but also result latencies, and early and late operands |
| 21:45:20 | | Quit Jaykay (Read error: 110 (Connection timed out)) |
| 21:46:27 | | Join froggyman [0] (n=sopgenor@pool-72-69-220-194.chi01.dsl-w.verizon.net) |
| 21:48:43 | gevaerts | pamaury: still alive, doing three things at the same time :) |
| 21:49:24 | amiconn | weird |
| 21:49:50 | amiconn | ARM11 will need 6 cycles for each 4-insn sequence in this code whereas ARM7 will only need 4 |
| 21:50:25 | | Join relentless [0] (n=piprg@cpe-173-88-137-100.neo.res.rr.com) |
| 21:50:32 | amiconn | That is because Rm is an early reg when using fixed shifts |
| 21:50:40 | n1s | amiconn: yeah, it needs an register that is shifted in one instr as an "early reg" |
| 21:50:51 | relentless | Is there a way in the config file that I can make it auto maticly go to shuffle? |
| 21:51:01 | relentless | I broke my screen, so I cant see what I am picking.. |
| 21:51:20 | amiconn | There is no useful reordering possible. Perhaps the more "classic" sequence is better on ARMv6 then |
| 21:51:35 | amiconn | (can still profit from constant deriving) |
| 21:51:41 | bertrik | relentless, you could put a set of voice files on the player so hear what you're doing |
| 21:51:58 | relentless | Ok, but I cant turn it on |
| 21:52:20 | bertrik | IIRC, voice is on by default, you just need to put the voice files on it |
| 21:52:26 | relentless | ok |
| 21:52:30 | relentless | I will try that |
| 21:53:34 | Unhelpful | amiconn: you're referring to this? http://pastebin.ca/1725218 |
| 21:55:17 | gevaerts | pamaury: without dircache, "something is wrong", with dircache "open is buggy" |
| 21:55:34 | pamaury | Ok, I get the same. So open is buggy |
| 21:55:37 | n1s | amiconn: your code seems correct as it gives the same crc as the c code but it's a little slower than when using the inlined c function so i guess i'll try to convert this to inline asm... |
| 21:55:52 | n1s | on c200 that is |
| 21:56:31 | pamaury | gevaerts: is there a dircache expert or nobody has touched this piece of code for ages ? |
| 21:57:37 | gevaerts | pamaury: you are ;) |
| 21:57:43 | relentless | ok, I went to download the voice files and it 404'd |
| 21:58:30 | Unhelpful | pamaury: Slasheri is the *cache guru. i think you may already know more than anybody save him :P |
| 21:58:53 | pamaury | gevaerts: crap, I'll have to modify dircahe to fix this, but this is all due to the weird behaviour of dircache_get_entry. |
| 21:59:21 | * | gevaerts is trying to understand the test code |
| 21:59:29 | * | bertrik fixed the problem with list text being overwritten by list icons with -O3 but doesn't really understand the fix yet |
| 21:59:37 | bertrik | -Os I mean |
| 21:59:43 | | Quit topik ("Changing server") |
| 21:59:56 | pamaury | gevaerts: the only interested part is the test_open. The rest is administration |
| 21:59:59 | kugel | bertrik: can I see the diff? |
| 22:00 |
| 22:00:01 | pamaury | *interesting |
| 22:00:36 | gevaerts | pamaury: didn't you swap the "This is normal" and "Hum, something is wrong (2)" strings? |
| 22:00:45 | amiconn | n1s: Optimised for ARMv6 (no stall in the logic sequence, and ldr'd first constant): http://pastebin.ca/1725261 |
| 22:01:14 | gevaerts | Apart from that I think it looks like you're right |
| 22:01:42 | n1s | amiconn: cool, seems we'll have to do inline asm to beat the c function unfortunately :/ |
| 22:01:54 | bertrik | kugel, see http://pastebin.ca/1725263 , moving the const int icon_width seems to fixs the problem |
| 22:02:23 | | Join Sajber^1 [0] (n=Sajber@211.142.216.81.static.tab.siw.siwnet.net) |
| 22:02:25 | kugel | pamaury: a (possibly very) related question, how does dircache handle opening files which don't exist? |
| 22:02:43 | pamaury | gevaerts: no, This is normal if open fails to open a directory (iirc) but if it manages to open it (due to dircache bug) then it should read the text in the file !! |
| 22:02:48 | | Join topik [0] (i=awesome@wtf.grmpf.org) |
| 22:03:00 | kugel | i.e. is it possible that the file is still cached even if it has been removed? and what happens in that case? |
| 22:03:13 | gevaerts | pamaury: ah, right. So the normal open is also wrong... |
| 22:03:19 | pamaury | kugel: as far as i have read the code, not very well. |
| 22:04:06 | | Nick topik is now known as sark (i=awesome@wtf.grmpf.org) |
| 22:04:09 | | Nick sark is now known as topik (i=awesome@wtf.grmpf.org) |
| 22:04:25 | kugel | there's this bug that deleting a file while playing it confuses buffering. I haven't looked at the buffering code, but assuming it checks the return of open() properly, I suspect dircache on fault |
| 22:04:49 | pamaury | kugel: I have tried to break the code this afternoon and there are several cases where I think I could manage to delete/rename a file and make the cache inconsistent |
| 22:04:56 | amiconn | There's a simple solution for testing that theory - run with dircache disabled |
| 22:07:02 | pamaury | The bug I showed here is due to the fact that opening a directory with dircache will return a handle to the first file in the directory and not to the directory itself but there also are some weird behaviours when a file doesn't exist |
| 22:09:32 | * | Unhelpful glares at kugel and says something that might actually be rockbox-related :P |
| 22:09:34 | *** | Saving seen data "./dancer.seen" |
| 22:09:53 | * | gevaerts doesn't understand why open() without dircache doesn't fail on a directory |
| 22:10:10 | gevaerts | oh, wait |
| 22:10:48 | gevaerts | Why is open() allowed on directories if it's read-only? |
| 22:10:56 | pamaury | Perhaps open manages to open the directory but can't read anything |
| 22:11:24 | Unhelpful | amiconn: you can get error on the order of 2^-7 on log2 with two 32x16->[47:16] and one 32x32->top32 multiply. this is fairly efficient on armv6 but i thought might be possible to to quickly on coldfire as well |
| 22:11:44 | gevaerts | exactly. What's opening a directory supposed to achieve anyway? |
| 22:12:30 | pamaury | Nothing but it is allowed. But in linux there's a O_DIRECTORY option to fail if the path is not to a directory ! |
| 22:12:44 | pamaury | Perhaps to do some fcntl on it ? |
| 22:12:54 | gevaerts | maybe on POSIX, but on rockbox? |
| 22:13:01 | pamaury | Ah, nothing :) |
| 22:13:18 | pamaury | It shouldn't be allowed I guess, or only to check existence |
| 22:13:35 | pamaury | But there's opendir to do it |
| 22:13:41 | gevaerts | The commit message says "You can't open() a directory as a file (at least not for writing)" |
| 22:13:49 | gevaerts | (r4359, LinusN) |
| 22:13:56 | Hillshum | That's old |
| 22:14:22 | pamaury | Wow, that's ages ago ! What did he changed ? |
| 22:15:02 | gevaerts | he added the protection against opening directories in write mode |
| 22:15:13 | gevaerts | I want to know why... |
| 22:16:15 | gevaerts | or at least why he allowed it for readonly |
| 22:16:41 | kugel | perhaps it would result in undefined breakage with our drivers? |
| 22:16:53 | pamaury | I really think it's to allow open to check the existence of a directory. It could be strange if you can't open something but then opendir it. |
| 22:17:50 | gevaerts | probably. But what's reading supposed to do in that case? |
| 22:18:59 | Unhelpful | gevaerts: i propose that reads return "you shouldn't do that." |
| 22:19:05 | pamaury | Nothing, but you have to have a mode to open it |
| 22:21:16 | JdGordon | kugel: can you help me get rockbox on my mini2440? |
| 22:21:31 | gevaerts | pamaury: if I change your test to RDWR, it works properly both with and without dircache. |
| 22:21:49 | kugel | JdGordon: not sure. bob_c guided me but that's a while back |
| 22:22:02 | JdGordon | did you do it in linux or windows? |
| 22:22:07 | kugel | linux |
| 22:22:08 | gevaerts | I agree that not reading anything would be cleaner, but is returning the contents of a file really a bug? |
| 22:22:23 | kugel | the windows tools on the cd didn't work for me |
| 22:22:44 | | Quit Sajber^ (Connection timed out) |
| 22:23:36 | pamaury | Well yes if you didn't open that file. |
| 22:23:56 | pamaury | What would happend if you delete that file ? No open is opened on it so it would be valid. |
| 22:24:38 | kugel | JdGordon: I've used latest openocd (git checkout); it has some syntax changes so the files in the hg repo need a bit of changing |
| 22:25:00 | JdGordon | have you got the config file that worked? |
| 22:25:12 | pamaury | Anyway, there is something unclear with dircache_get_entry which is the reason of the "bug". And there should be no different behaviour between dircahe and without dircache modes |
| 22:25:19 | gevaerts | I don't know. Either read() should return EISDIR, or the results are undefined I'd say |
| 22:25:23 | kugel | yea, I should have those |
| 22:25:55 | JdGordon | can you email them please? |
| 22:25:55 | * | gevaerts notices that the test code doesn't check the return value of read() |
| 22:26:04 | kugel | yep |
| 22:26:05 | * | JdGordon needs to figure out how to build openocd |
| 22:26:34 | pamaury | gevaerts: yes, indeed because the code is bulletprof |
| 22:27:03 | * | n1s fails at converting that asm function to inline asm |
| 22:27:17 | kugel | JdGordon: the packages of your distros might be sufficiently up-to-date |
| 22:27:45 | kugel | although I needed to pass 2 options to configure so that jtag-via-parport works |
| 22:29:08 | | Join Jaykay [0] (n=chatzill@p5DDC6C5D.dip.t-dialin.net) |
| 22:29:48 | JdGordon | Open On-Chip Debugger 0.2.0-in-development (2009-06-30-01:49) svn:r2403 |
| 22:30:26 | kugel | wait a few minutes, I'll have a look what version I used |
| 22:30:47 | kugel | they switched to git at some point though, the svn should be out of date |
| 22:31:48 | gevaerts | uh, can't you access errno from plugins? |
| 22:32:09 | gevaerts | or sprintf? |
| 22:32:28 | kugel | does rockbox implement errno? |
| 22:32:31 | gevaerts | yes |
| 22:32:34 | pamaury | gevaerts: I don't think errno is accessible from a plugin which is a shame |
| 22:32:46 | gevaerts | it's not a shame, it's a serious bug |
| 22:32:59 | kugel | hm, then I wonder why some (IIRC for example lua) fake errno |
| 22:33:06 | pamaury | There should be a get_errno function in rb. |
| 22:33:36 | kugel | or a pointer to errno as with current tick, but it doesn't really matter |
| 22:33:58 | kugel | (although I would prefer the getter function way) |
| 22:34:00 | | Join Jethro85 [0] (n=Jethro85@68-186-223-118.dhcp.cdtw.ga.charter.com) |
| 22:38:33 | | Quit Grahack ("Tu m'as vu ?") |
| 22:39:37 | gevaerts | kugel: people will be used to errno as a global |
| 22:40:14 | JdGordon | it could be added as a #define then |
| 22:40:41 | kugel | so #define errno *rb->errno (or rb->get_errno()) |
| 22:41:14 | | Quit Jethro85 (" HydraIRC -> http://www.hydrairc.com <- Now with extra fish!") |
| 22:41:18 | pamaury | I also prefer this way, errno is a variable in people mind. |
| 22:42:14 | gevaerts | on the other hand, via rb-> we can't do better than a pointer anyway |
| 22:42:23 | bertrik | errno always seemed a hack to me in C |
| 22:42:46 | kugel | to me too |
| 22:42:53 | JdGordon | does anyone want my clip+ to try getting code running on it? |
| 22:42:57 | JdGordon | its already open |
| 22:43:00 | kugel | and not very thread safe |
| 22:44:29 | pamaury | errno is clearly a hack but it's better than nothing. The greatest problem is that it's not thread safe |
| 22:45:17 | pamaury | (but it could be made thread safe with some ugly #define) |
| 22:45:58 | bertrik | I think each thread needs its own errno, at least what I remember seeing VxWorks do |
| 22:46:18 | pamaury | VxWorks ? |
| 22:47:47 | CIA-6 | New commit by alle (r24104): Describe how 'delete current file' works |
| 22:48:06 | bertrik | pamaury, it's a real-time OS, probably off-topic for #rockbox |
| 22:48:37 | pamaury | ok |
| 22:49:14 | pamaury | So do we add a errno getter in rb ? |
| 22:49:52 | | Join syrou [0] (n=aramon@87.216.165.32) |
| 22:49:52 | gevaerts | I think we should |
| 22:50:03 | syrou | hi all |
| 22:50:04 | amiconn | n1s: You mean like this: http://pastebin.ca/1725322 |
| 22:50:06 | amiconn | ? |
| 22:50:07 | gevaerts | ah, more bugs! |
| 22:50:46 | pamaury | Why more bugs ? |
| 22:50:51 | n1s | amiconn: yes! |
| 22:51:00 | syrou | i'm experiencing some weird problem trying to upgrade the drive in my ihp-120 unit. can anybody please help me? |
| 22:51:13 | n1s | obviously my failed attempt is't identical :) |
| 22:51:31 | CIA-6 | New commit by gevaerts (r24105): only get the file pointer if fd is actually valid. |
| 22:51:35 | n1s | syrou: if you describe the problem, maybe we can :) |
| 22:51:47 | syrou | ok thanks n1s |
| 22:52:32 | syrou | i'm trying to use an mk1231gal drive. have recompiled with the 24105 release and upgraded the boot loader with it |
| 22:53:04 | syrou | have tried both with or with out the MAX_PHYS_SECTOR_SIZE set to 4096 in the h120 headers |
| 22:53:26 | syrou | but i only get a "no partition found" |
| 22:53:31 | pamaury | gevaerts: I'll add some code about errno tomorrow. I will think about this dircache issue, there is something to be fixed clearly. Did you say that there is no sprintf in rb ? |
| 22:53:57 | pamaury | gevaerts: because there is actually a snprintf |
| 22:54:01 | pamaury | iirc |
| 22:54:08 | gevaerts | pamaury: exactly. I didn't look properly the first time |
| 22:54:24 | gevaerts | There's no sprintf, but you don't need it if you have snprintf... |
| 22:54:34 | pamaury | indeed |
| 22:54:55 | syrou | being a 120gb drive i suppose i don't have to activate the LBA48 support |
| 22:55:48 | kugel | GeekShadow: we have sprintf |
| 22:55:50 | | Join b1uebrother [0] (n=dom@92.116.93.154) |
| 22:55:53 | amiconn | The mk1231 doesn't need MAX_PHYS_SECTOR_SIZE afaik |
| 22:55:53 | kugel | gevaerts: ^ |
| 22:56:16 | amiconn | While using it should work, rockbox will be slower than without it |
| 22:56:16 | gevaerts | kugel: not in plugins anyway |
| 22:56:19 | kugel | oh, that was only a test file apparently |
| 22:56:26 | syrou | amiconn: yes, for what i've read it's firmware it's capable of mapping 4096 blocks into 512 ones |
| 22:56:34 | * | kugel didn't know firmware/test/ exists! |
| 22:56:43 | gevaerts | Does anyone think that http://pastie.org/755037.txt will lead to problems? it makes read() and write() fail on directories |
| 22:57:12 | n1s | syrou: obvious question, is there a regular primary partition on it? |
| 22:57:34 | syrou | n1s: yes, there is a 0c FAT32L primary one |
| 22:57:44 | gevaerts | It should be safe, and things still work, but you never know if there's some weird code that depends on this... |
| 22:58:03 | syrou | and i'm using a very small ZIF to CE-ATA adapter which makes the drive spin |
| 22:58:13 | pamaury | gevaerts: the real question is: what do it returns without this ? Nothing ? |
| 22:58:52 | n1s | syrou: did you test if the Original Firmware can read it? |
| 22:58:54 | | Part toffe82 |
| 22:59:14 | b1uebrother | hmm. Are the result codes of ipodpatcher meaningful in any way? |
| 22:59:14 | bertrik | gevaerts, existing code that fails with this, was probably already incorrect, so you're basically just making any possible bugs more visible (which is a good thing IMO) |
| 22:59:25 | syrou | n1s: the original firm loads but it shows a single directory with garbled chars. i cannot cd into it |
| 22:59:59 | n1s | that sounds bad... |
| 23:00 |
| 23:00:31 | syrou | but with the zif>usb bridge, everything seems to be ok |
| 23:04:14 | gevaerts | pamaury: in that case the existing code just reads, but since file->size is 0, it reads zero bytes. |
| 23:04:39 | gevaerts | pamaury: so it seems that it's really dircache_get_entry_ptr() that returns the wrong file |
| 23:04:47 | pamaury | Ok. Yes |
| 23:05:05 | pamaury | In reality I traced the bug starting from dircache |
| 23:05:30 | syrou | what i'm going to try is to zeroize the whole drive |
| 23:05:36 | syrou | and the repartition it |
| 23:06:08 | syrou | the drive comes from a transcend mini case, and curiously, it has the apple logo on the hard drive label |
| 23:06:22 | syrou | maybe the apple logo means trouble? |
| 23:08:20 | gevaerts | pamaury: I think I see what's wrong |
| 23:08:42 | * | gevaerts isn't sure though |
| 23:09:08 | pamaury | gevaerts: with dircache you mean ? |
| 23:09:13 | gevaerts | yes |
| 23:09:19 | pamaury | gevaerts: I know what is wrong |
| 23:09:21 | pamaury | :) |
| 23:09:25 | gevaerts | ah, ok :) |
| 23:09:58 | pamaury | gevaerts: It's because its goes through ->down at each iteation whereas it should not at the last one if it's a directory. That's what I believe is the bug |
| 23:10:07 | pamaury | But's perhaps there's more ;) |
| 23:10:20 | gevaerts | that's what I think too, but yes, it could be more difficult |
| 23:10:25 | * | bertrik still doesn't know what is wrong with the menu text alignment when compiling with non-standard optimisation level |
| 23:10:59 | gevaerts | pamaury: do you object to my EISDIR patch? It would make your test plugin meaningless |
| 23:11:14 | n1s | amiconn: gives a speedup of 0.1% for 96kbps going up for higher bitrates to 0.7% for 500kbps on c200 over the version i committed earlier today |
| 23:12:08 | pamaury | gevaerts: I don't object, it's a partial fix but it won't fix the dircache problem. Anyway EISDIR is better than 0 size read |
| 23:12:44 | pamaury | gevaerts: the difficult part with dircache is that this ->down behaviour could be expected in other parts of dircache :( |
| 23:12:50 | gevaerts | It's not a fix for the dircache issue, true. It's more of a general fix |
| 23:13:08 | gevaerts | and yes, changing dircache without fully understanding it sounds risky... |
| 23:13:26 | n1s | amiconn: on the beast it gives "Error: invalid literal constant: pool needs to be closer" though |
| 23:13:39 | CIA-6 | New commit by gevaerts (r24106): Make read() and write() return -1/EISDIR on directories |
| 23:14:18 | pamaury | gevaerts: but my test plugin will still fail with dircache: it will read the buggy.txt file |
| 23:14:29 | gevaerts | ah, yes |
| 23:15:37 | gevaerts | pamaury: regarding your (much?) earlier comment that using sector offsets for file ids breaking on defragmenting : do we care? |
| 23:16:35 | gevaerts | I mean, using dircache indexes will break if the wrong file gets deleted, and so on. There will always be some sort of edge case where whatever scheme you use breaks |
| 23:17:10 | pamaury | Yes, the question is: what is best solution ? I think the sector way is quite good |
| 23:18:18 | gevaerts | I think so too. It's simple, it doesn't require much RAM, and it's not as if people defragment every day |
| 23:18:49 | pamaury | yep |
| 23:19:00 | bertrik | this is about the MTP id? |
| 23:19:03 | amiconn | n1s: Then let gcc do that part: http://rockbox.pastebin.ca/1725354 |
| 23:19:38 | | Quit syrou () |
| 23:20:16 | pamaury | bertrik: MTP persistent unique object id, a stupid object property that is needed by windows |
| 23:20:22 | gevaerts | pamaury: actually, the cluster offset is probably better. It allows bigger disks |
| 23:20:52 | pamaury | It's a 128-bit offset, so sector is not a problem :) |
| 23:21:05 | gevaerts | ah, ok |
| 23:21:17 | bertrik | is this just some number that just needs to be unique for each file during one session, or does this also need to be persistent in the life time of the DAP? |
| 23:21:28 | * | gevaerts was assuming 32 bit |
| 23:21:37 | bertrik | and does MTP use it as a key to retrieve files? |
| 23:22:28 | pamaury | bertrik: persistent for object life time |
| 23:22:43 | pamaury | MTP doesn't use it AT ALL, it's getter only, totally useless |
| 23:23:15 | gevaerts | but windows breaks if you don't have it? |
| 23:23:41 | pamaury | Yes. That's was my big problem this last days |
| 23:23:58 | | Join matsl [0] (n=matsl@host-90-233-163-151.mobileonline.telia.com) |
| 23:25:16 | bertrik | pamaury, ok, sector number sounds good to me too in that case, but you're the expert now :) |
| 23:25:54 | | Quit matsl (Read error: 104 (Connection reset by peer)) |
| 23:26:08 | | Join matsl [0] (n=matsl@host-90-233-163-151.mobileonline.telia.com) |
| 23:27:03 | n1s | amiconn: yeah, that works nicely, no speed diff on the beast so i'd say go ahead and commit :) |
| 23:27:28 | amiconn | Any speedup on PP? |
| 23:27:46 | n1s | <n1s> amiconn: gives a speedup of 0.1% for 96kbps going up for higher bitrates to 0.7% for 500kbps on c200 over the version i committed earlier today |
| 23:28:05 | amiconn | Also, did you check whether the armv4 sequence is indeed slower on armv6? |
| 23:28:30 | n1s | no, can do that now |
| 23:28:53 | | Join evilnick [0] (i=5752157c@rockbox/staff/evilnick) |
| 23:33:09 | Unhelpful | hrm... potentially useful for things that divide repeatedly by a fixed constant? http://en.wikipedia.org/wiki/Modular_multiplicative_inverse |
| 23:33:42 | | Join Omlet [0] (i=omlet05@112.146-241-81.adsl-dyn.isp.belgacom.be) |
| 23:33:51 | Unhelpful | the scaler does this, but right now calculates either 1<<24 or 1<<32 / N during setup |
| 23:34:41 | n1s | amiconn: doesn't seem to make any difference larger than measuring uncertainty |
| 23:34:45 | Unhelpful | the coprime-to-modulus part could be handled by factoring out powers of two from the divisor and storing an amount to shift... |
| 23:36:24 | GeekShadow | kugel, what it means ? |
| 23:37:08 | kugel | GeekShadow: nevermind, bad nick completition |
| 23:37:19 | GeekShadow | oh ok :p |
| 23:37:46 | GeekShadow | it was for gevaerts so ;) |
| 23:37:56 | GeekShadow | you can ping me to test anything on meizu m3 |
| 23:40:38 | amiconn | n1s: Did you check what gcc produces for PP from your C version? |
| 23:42:06 | n1s | <n1s> amiconn: this when compiling with O2 for arm7tdmi http://pastebin.ca/1724963 |
| 23:42:33 | amiconn | That's not svn... |
| 23:42:48 | * | flyback wants his own death for xmas, too much bullshit everywhere |
| 23:42:59 | | Join fdinel [0] (n=Miranda@modemcable235.127-131-66.mc.videotron.ca) |
| 23:44:52 | amiconn | n1s: An svn build produces this (inlined fragment): http://pastebin.ca/1725380 |
| 23:46:24 | n1s | ah, i just compiled the bitreverse function stand alone, which gives what i pastebinned |
| 23:46:37 | n1s | that is a bit different |
| 23:47:55 | n1s | it sure spends a lot of instructions to construct the masks |
| 23:48:41 | | Quit b1uebrother ("leaving") |
| 23:49:14 | amiconn | It doesn't construct - it directly applies the partial masks |
| 23:50:23 | n1s | right, i'm too tired for this, anyway what is it you want to say by showing this? |
| 23:50:24 | n1s | :) |
| 23:52:05 | n1s | and what it generated for the original c must have been horrid since that is a lot faster... |
| 23:52:24 | n1s | s/that/this/ |
| 23:52:30 | Unhelpful | writing C that explicitly constructs masks from the previous mask would probably force it to construct or load the first mask... |
| 23:53:08 | amiconn | true that |
| 23:53:24 | amiconn | It might make things slower on coldfire though |
| 23:53:28 | | Quit matsl (Read error: 104 (Connection reset by peer)) |
| 23:53:32 | amiconn | Or mips (which I cannot test) |
| 23:53:43 | | Join matsl [0] (n=matsl@host-90-233-163-151.mobileonline.telia.com) |
| 23:54:11 | | Join Kitar|st [0] (n=Kitarist@BSN-143-75-63.dial-up.dsl.siol.net) |
| 23:54:13 | | Join saratoga [0] (i=5f4b4473@gateway/web/freenode/x-dkwvdxxfrbjhjzut) |
| 23:54:52 | amiconn | The construction is fast on arm because of the shifter operand |
| 23:55:17 | saratoga | stripwax: (for the logs) I didn't use any code to estimate the mul count in the fft, I just traced it on paper and counted by hand |
| 23:55:25 | saratoga | assuming that message before was meant for me |
icon identifies that the person is a core developer (has commit access).