--- Log for 22.02.112 Server: hitchcock.freenode.net Channel: #rockbox --- Nick: logbot_ Version: Dancer V4.16 Started: 1 day and 0 hours ago 00.00.15 Quit domonoky (Read error: Connection reset by peer) 00.04.59 Join factor [0] (~factor@r74-195-184-248.msk1cmtc01.mskgok.ok.dh.suddenlink.net) 00.18.18 Quit lebellium (Quit: ChatZilla 0.9.88 [Firefox 11.0/20120215222917]) 00.19.21 Quit aarch (Ping timeout: 252 seconds) 00.20.03 # rasher: does checkwps auto-update on the theme site now? 00.20.18 # gevaerts: I think it should 00.20.25 Join aarch [0] (~z@ip-115.viapori.fi) 00.20.54 # I'm asking because checkwps apparently gives errors on yp-r0 on my new theme that it *doesn't* give when I run it locally 00.21.27 # curious 00.28.38 # rasher: checkwps for yp-r0 gives me errors too up to 9acd70288dfa47cac084b965a046df6f71d4ee26 (14 feb) 00.29.01 # weird 00.29.04 # let me re-run manually 00.29.35 Join dfkt [0] (dfkt@unaffiliated/dfkt) 00.30.23 Quit n17ikh (Quit: leaving) 00.40.05 # i just built a rockbox apk, and got a warning that the signer certificate has expired. how do i refresh that? 00.40.23 # uninstall it and reinstall it 00.40.36 # the whole android sdk/ndk? 00.41.09 # no, the apk from your phone 00.42.03 # oh, i meant i got the warning in linux, when the build finished and the apk got signed 00.42.50 # rasher: a checkwps build done with buildall.sh also fails :\ 00.43.01 # i will try if it actually installs after uninstalling the older one 00.43.35 # oh 00.43.50 # gevaerts: oh 00.44.00 # * gevaerts thinks he sees something 00.44.56 # rasher: ypr0 is an app build, which means it believes the --lcdwidth=100 --lcdheight=100 buildall.sh gives it... 00.45.06 # And most 240x320 themes will break on that 00.45.07 # Oh ah! 00.52.00 # rasher: maybe just force it to 240x320 for now? 00.53.58 # actually... 00.54.22 # ah, that was an easy fix - jsut had to delete the debug.keystore file 00.58.34 # rasher: I think I have a proper fix 01.03.23 Quit Guinness (Read error: Connection reset by peer) 01.03.38 Join Guinness [0] (Slayer@c-68-55-111-159.hsd1.va.comcast.net) 01.04.22 # gevaerts: is it much work to give the right resolutions in buildall.sh? 01.04.42 Quit bertrik (Quit: And That, My Liege, Is How We Know the Earth to Be Banana Shaped) 01.04.52 # rasher: a bit. there's no reason for the ypr0 to allow overriding the resolution though 01.05.22 # I have that working locally, but I did some things wrong and I'm trying to figure out how to push stuff without messing everything up 01.08.48 # Commit a16b65e in rockbox by 03Frank Gevaerts: Force YPR0 to 240x320 01.08.58 # rasher: that should do it 01.10.19 # I get some complains about LCD_WIDTH being redefined 01.10.37 # not the end of the world I assume 01.11.06 # hm 01.11.13 # a16b65e build result: All green 01.11.56 # I don't think that can happen if you *don't* set --lcdwidht/height, so I think it's fine 01.15.43 # Commit 680c6fc in rockbox by 03Frank Gevaerts: Store listitem_viewport_cfg->label as skinoffset instead of raw pointer 01.18.08 # 680c6fc build result: All green 01.24.10 Quit dfkt (Quit: -= SysReset 2.55=- Sic gorgiamus allos subjectatos nunc.) 01.25.47 Join Keripo [0] (~Keripo@mcn150.wireless-pennnet.upenn.edu) 01.27.33 Quit Thra11 (Read error: Connection reset by peer) 01.28.20 Quit tchan (Read error: Connection reset by peer) 01.28.54 Quit Keripo (Read error: Connection reset by peer) 01.29.08 Join tchan [0] (~tchan@lunar-linux/developer/tchan) 01.29.30 *** Saving seen data "./dancer.seen" 01.31.20 Join Keripo [0] (~Keripo@mcn150.wireless-pennnet.upenn.edu) 01.55.33 Join n17ikh [0] (~peter@c-174-56-150-44.hsd1.sc.comcast.net) 01.58.48 Quit kadoban (Ping timeout: 276 seconds) 02.06.36 Quit nosa-j (Read error: Connection reset by peer) 02.07.02 Join nosa-j [0] (~m00k@adsl-74-235-26-63.clt.bellsouth.net) 02.19.18 Quit remlap (Ping timeout: 245 seconds) 02.28.52 Join remlap [0] (~Patrick@190.28.169.217.in-addr.arpa) 02.33.30 Nick mc2739_ is now known as mc2739 (~mc2739@rockbox/developer/mc2739) 02.34.48 Quit Keripo (Quit: Leaving.) 02.44.21 Quit funman (Read error: Operation timed out) 02.47.23 Join funman [0] (~fun@adsl.via.ecp.fr) 02.47.30 Quit funman (Changing host) 02.47.30 Join funman [0] (~fun@rockbox/developer/funman) 02.54.53 Quit funman (Ping timeout: 240 seconds) 02.56.44 Join funman [0] (~fun@rockbox/developer/funman) 03.14.28 Quit SynrG (Quit: leaving) 03.22.49 Join SynrG [0] (~synrg@debian/developer/synrg) 03.29.31 *** Saving seen data "./dancer.seen" 03.46.37 Join [Saint] [0] (~Saint]@unaffiliated/saint/x-8516940) 04.11.05 Quit TheSeven (Read error: Operation timed out) 04.11.34 Join TheSeven [0] (~TheSeven@rockbox/developer/TheSeven) 04.29.13 Quit amiconn (Disconnected by services) 04.29.14 Join amiconn_ [0] (quassel@rockbox/developer/amiconn) 04.29.36 Nick amiconn_ is now known as amiconn (quassel@rockbox/developer/amiconn) 04.29.45 Quit pixelma (Disconnected by services) 04.29.46 Join pixelma_ [0] (quassel@rockbox/staff/pixelma) 04.30.06 Nick pixelma_ is now known as pixelma (quassel@rockbox/staff/pixelma) 04.36.37 Join Rower85 [0] (husvagn@v-413-alfarv-90.bitnet.nu) 04.48.44 Quit anewuser (Ping timeout: 244 seconds) 05.01.56 Quit nosa-j (Ping timeout: 265 seconds) 05.07.34 Join nosa-j [0] (~m00k@adsl-74-235-26-63.clt.bellsouth.net) 05.23.34 Join [Saint_] [0] (~Saint]@unaffiliated/saint/x-8516940) 05.25.15 Quit [Saint] (Ping timeout: 240 seconds) 05.29.32 *** Saving seen data "./dancer.seen" 05.46.26 Join Rob2223 [0] (~Miranda@p4FFD15E7.dip.t-dialin.net) 05.50.15 Quit Rob2222 (Ping timeout: 240 seconds) 06.01.50 Quit [Saint_] (Ping timeout: 260 seconds) 06.03.47 Join [Saint] [0] (~Saint]@unaffiliated/saint/x-8516940) 06.06.55 Quit curtism (Quit: Live Long and Prosper) 06.11.38 Join Keripo [0] (~Keripo@eng323.wireless-resnet.upenn.edu) 06.16.23 Quit perrikwp (Read error: Connection reset by peer) 06.17.35 Join perrikwp [0] (~quassel@cpe-024-163-024-033.triad.res.rr.com) 06.25.35 Quit The_prospector (Read error: Connection reset by peer) 06.27.23 Quit perrikwp (Read error: Connection reset by peer) 06.30.48 Join perrikwp [0] (~quassel@cpe-024-163-024-033.triad.res.rr.com) 06.31.39 Join The_prospector [0] (baconmaste@unaffiliated/cornman) 06.39.55 Join perrikwp_ [0] (~quassel@cpe-024-163-024-033.triad.res.rr.com) 06.42.39 Join perrikwp__ [0] (~quassel@cpe-024-163-024-033.triad.res.rr.com) 06.42.55 Quit perrikwp (Ping timeout: 244 seconds) 06.44.34 Quit perrikwp_ (Ping timeout: 240 seconds) 06.45.21 Join perrikwp [0] (~quassel@cpe-024-163-024-033.triad.res.rr.com) 06.47.56 Quit perrikwp__ (Ping timeout: 260 seconds) 07.05.14 Join [Saint_] [0] (~Saint]@unaffiliated/saint/x-8516940) 07.08.51 Quit [Saint] (Ping timeout: 276 seconds) 07.18.03 Join hiptobecubic [0] (~john@unaffiliated/hiptobecubic) 07.29.36 *** Saving seen data "./dancer.seen" 07.45.34 Join kadoban [0] (~kadoban@ip98-165-177-158.ph.ph.cox.net) 07.49.34 Quit zenlunatic (Ping timeout: 240 seconds) 07.50.27 Quit factor (Ping timeout: 276 seconds) 08.04.59 Join factor [0] (~factor@r74-195-184-248.msk1cmtc01.mskgok.ok.dh.suddenlink.net) 08.22.12 Join GodEater_ [0] (93722cd1@rockbox/staff/GodEater) 08.25.27 Quit Scromple (Read error: Connection reset by peer) 08.27.44 Join Zagor [242] (~bjst@rockbox/developer/Zagor) 08.33.49 Join ender` [0] (~ender@foo.eternallybored.org) 08.34.11 Join wodz [0] (~wodz@89-76-160-35.dynamic.chello.pl) 08.36.26 # Commit b4eab59 in rockbox by 03Marcin Bukat: Arm stack unwinder 08.38.50 # b4eab59 build result: 176 errors, 0 warnings (Marcin Bukat committed) 08.38.56 # hmm 08.39.31 # that didn't go well then! 08.40.25 # bootloaders don't compile unwarminder library apparently 08.42.11 Quit The_prospector (Read error: Connection reset by peer) 08.42.25 Join The_prospector [0] (baconmaste@2001:470:a:5c1::3) 08.42.36 Quit The_prospector (Changing host) 08.42.36 Join The_prospector [0] (baconmaste@unaffiliated/cornman) 08.43.58 Quit The_prospector (Read error: Connection reset by peer) 08.44.13 Join The_prospector [0] (baconmaste@unaffiliated/cornman) 08.44.50 Quit [Saint_] (Remote host closed the connection) 08.49.11 Quit The_prospector (Read error: Connection reset by peer) 08.49.17 Join The_prospector [0] (baconmaste@unaffiliated/cornman) 08.53.22 Quit The_prospector (Read error: Connection reset by peer) 08.53.33 Join The_prospector [0] (baconmaste@unaffiliated/cornman) 08.55.06 Quit The_prospector (Read error: Connection reset by peer) 08.55.22 Join The_prospector [0] (baconmaste@unaffiliated/cornman) 09.00.30 Quit The_prospector (Read error: Connection reset by peer) 09.00.32 # How is arm_support.S not built by bootloader? We use something else there (libgcc)? 09.01.58 # Commit 164cb21 in rockbox by 03Marcin Bukat: unwarminder: fix bootloader builds 09.02.13 # * wodz crosses fingers 09.02.38 # wodz: yes, arm_support.S just replaces some div routines that are otherwise provided by gcc 09.03.04 # that explains why I missed bootloader.make 09.03.37 # I silently assumed it is essential to build arm binary in every mode 09.04.11 # 164cb21 build result: All green 09.04.25 # wodz: the unwinder shouldnt be in the bootloader imo 09.04.40 # isnt it rather large? 09.05.06 # 5k or so 09.06.03 # not worth it for bootloaders if you ask me, and some do need to be as small as possible 09.06.57 # I am not agains of ifdefing for bootloader but I kindly point out that the patch was looooong on the tracker then on gerrit and noone made such comment 09.07.33 # everyone forgot about bootloaders obviously :) 09.09.00 # Anyway I have no time now to look into, maybe later today but I am terribly lacking free time. or you can ifdef if you prefer 09.10.26 Quit tchan (Read error: Connection reset by peer) 09.10.36 Join Guinness` [0] (Slayer@c-68-55-111-159.hsd1.va.comcast.net) 09.11.34 Join tchan [0] (~tchan@lunar-linux/developer/tchan) 09.11.35 Quit Guinness (Read error: Connection reset by peer) 09.14.54 Quit sobersab1e (Quit: leaving) 09.15.03 Join [Saint] [0] (~Saint]@unaffiliated/saint/x-8516940) 09.15.51 # Commit d8fd988 in rockbox by 03Thomas Martitz: (Author: Jean-Louis Biasini) stats's plugin PLA integration (main code + manual) 09.16.41 # gah, the commit message isnt right :\ 09.17.53 # bluebrother^: can you have a look at g#77? 09.18.08 # seems like a trivial change to me 09.18.33 # d8fd988 build result: All green 09.20.58 # Torne: is there a way to compare patch sets in gerrit? 09.25.55 Join dan_a_ [0] (~dan_a@wormhole.domicilium.com) 09.27.06 Quit dan_a (Ping timeout: 245 seconds) 09.27.43 Join lebellium_gs2 [0] (~lebellium@tmo-096-14.customers.d1-online.com) 09.29.39 *** Saving seen data "./dancer.seen" 09.30.31 # Thanks gevaerts for the R0 on theme website ;) 09.33.06 Quit wodz (Quit: Leaving) 09.53.33 Quit lebellium_gs2 (Ping timeout: 240 seconds) 10.15.09 Quit kadoban (Ping timeout: 244 seconds) 10.29.47 Join dan_a [0] (dan_a@217.23.173.156) 10.31.43 # JdGordon: I think we should consider some data structure optimisations at some point. If people have lots of viewports, walking through the list every time you need those with a specific label isn't going to be very fast 10.32.10 # Of course that might not be easy to do without changing draw order... 10.33.40 Quit dan_a_ (Ping timeout: 260 seconds) 10.34.14 Quit dan_a (Ping timeout: 260 seconds) 10.34.45 # gevaerts: i cincerely doubt the speedup would be noticable compared to even a highly optimised codec 10.34.52 # sincerely* 10.35.16 # JdGordon: you're clearly not considering themes with hundreds of viewports ;) 10.35.32 # even then... 10.36.22 # switching to an array of pointer/offsets would be theoretically faster than walking the list, but by enough to make it worth it? 10.36.49 # * gevaerts will try to do some measurements and things sometime during the next year or so :) 10.36.55 # plus it means we need to add magic to get the correct sized array 10.37.48 Quit adnap (Remote host closed the connection) 10.38.12 Join adnap [0] (~adnap@rrcs-71-42-140-57.sw.biz.rr.com) 10.38.36 # gevaerts: g#113 is not the correct way to do it if that is what we want 10.38.43 # ok 10.38.47 # well, its part correct 10.39.23 # I'ts probably a bit extreme 10.39.33 Quit hiptobecubic (Ping timeout: 244 seconds) 10.40.28 # no, I mean, if thats what we want the tag needs to be set to SKIN_REFRESH_DYNAMIC in the lib 10.40.47 # which will make do_refresh always true so it can be removed, but the table and code needs to match 10.41.07 # Ah, right 10.41.20 # Well, the thing really is just this one pointer not being set properly 10.41.50 # Ideally it would be set properly in all needed places 10.42.35 # I'm not really happy with how skined lists turned out 10.42.49 # but meh 10.43.23 Quit incoganon (Remote host closed the connection) 10.45.18 Quit Keripo (Quit: Leaving.) 10.46.45 Join dan_a [0] (~dan_a@wormhole.domicilium.com) 11.07.12 Join petur [0] (~petur@rockbox/developer/petur) 11.07.29 Quit GeekShadow (Ping timeout: 260 seconds) 11.15.52 Quit [Saint] (Remote host closed the connection) 11.29.43 *** Saving seen data "./dancer.seen" 11.34.03 Quit jhMikeS (Ping timeout: 276 seconds) 11.46.30 # kugel: yes, you can pick which versions to compare in the diff viewer 11.50.16 Quit factor (Read error: Connection reset by peer) 11.56.06 Join hiptobecubic [0] (~john@unaffiliated/hiptobecubic) 11.56.59 # can i get some testing and feedback on http://gerrit.rockbox.org/120 ? 11.57.30 # I want to change all lcd framebuffer accesses to pointers as the first step to getting dynamic lcd sizes going and multiple framebuffers 12.02.16 Join superlinuxpro [0] (~asdf@adsl-67-33-129-210.asm.bellsouth.net) 12.08.15 Join factor [0] (~factor@r74-195-184-248.msk1cmtc01.mskgok.ok.dh.suddenlink.net) 12.09.12 # Hello, Im typing to make a short "video" clip with lotsof drawpixel calls. My .c file is FULL of rb->lcd_drawpixel() functions (100 frames * dozens of drawpixels per frame. the .c file itself it 2 megabytes.) when I type "make" from the build folder, it says "out of memory allocating 547340640 bytes after a total of 496640000 bytes". Please tell me how to fix this. I eventually want to make this "video" ten times as long 12.11.30 Quit aarch (Quit: leaving) 12.12.37 # this is with the linux ubuntu virtual machine from the HowtoCompile wiki page 12.24.08 # superlinuxpro: the plugin size isn't unlimited... 12.25.21 # gevaerts beginner here. can you point me to a solution if youve got one? 12.25.49 # Well, you *could* grab the audio buffer and load data in there 12.27.11 # dont know what you mean 12.27.30 # gevaerts don't know what you mean. I can't do much mroe than follow a hello world wiki 12.31.20 Join anewuser [0] (~anewuser@190.207.138.187) 12.31.20 Quit anewuser (Changing host) 12.31.20 Join anewuser [0] (~anewuser@unaffiliated/anewuser) 12.32.00 Join lebellium_gs2 [0] (~lebellium@tmo-110-79.customers.d1-online.com) 12.33.55 # Gevaerts I just tried your medieval theme, nice :) btw what 240*320 device do u have and what is exactly this "new skinned list feature" ? 12.36.32 # does rockbox have a file system? 12.39.00 # if you are drawing a "video" clip with individual pixels you are probably taking entirely the wrong approach 12.39.43 # you realise it's possible to draw shapes, text, or just paint entire 2d bitmaps onto the screen in one go? 12.40.02 # in fact not just bitmaps; we have image decoders for jpg, png, etc :) 12.40.40 # Torne Ive already got all the pixels 12.40.56 # yes, but that's *dumb*, i mean 12.41.00 # and will take up many times more space 12.41.03 # lebellium_gs2: gigabeat F, and http://www.rockbox.org/wiki/CustomWPS#Drawing_the_lists_using_a_skin 12.41.55 # superlinuxpro: if you insist on drawing individual pixels, at least get them from an array in a loop, not using billions of lcd_drawpixel() calls 12.42.18 Quit petur (Quit: Leaving) 12.42.54 # Thx, I'll have a look at it :) 12.43.00 Quit tuxx- (Ping timeout: 272 seconds) 12.44.46 Quit lebellium_gs2 (Quit: Bye) 12.45.50 Quit GodEater_ (Ping timeout: 245 seconds) 12.48.54 Join tuxx- [0] (tuxx@pantoff0l.nl) 12.49.47 Join merbanan [0] (~benjamin@2a00:801:102:104:212:34ff:fe55:5a58) 12.50.15 # gevaerts I have 128*64 pixels * 1000 frames. If i replace 128*64*1000 drawpixel(10,10)s with 128*64*1000 my_array[500][10][10]=DRAW, then use a loop to call the drawpixel function, will that solve it? 12.51.31 # if not can you tell what exactly you mean by reading fro an array please? 12.51.47 # programming beginne rhere 12.52.11 Join GodEater_ [0] (93722cc8@rockbox/staff/GodEater) 12.54.19 # does any target use DSP for codecs? 12.56.29 # I think of "TMS320DM320 improvements" idea for GSoC, which would consists of utilising the hardware inside this chip to do magic (accelerated video, DSP to aid some decoding, etc.) 12.58.09 # at current state the DSP is just acting as some kind of "audio data bridge" 12.58.48 # only two targets use the dsp at all 12.58.55 # not even sure if any of the others have one 13.03.11 Join Fuze_V2_ [0] (~584d30a4@www.haxx.se) 13.04.23 # hmm, the use of that for accelerated video is already in the "umbrella" video playback project idea 13.06.28 Join dfkt [0] (dfkt@unaffiliated/dfkt) 13.08.05 # are fopen and fread supported for reading and writing data? 13.10.45 # superlinuxpro: you should be looking at having, for a start, 1000 bitmaps (which is basically 128*64*1000 pixels, but not just in a big array) and drawing them with a loop that calls the bitmap draw function 1000 times :) 13.11.07 # this will be far, far faster, take up a lot less space, and be much simpler 13.29.47 *** Saving seen data "./dancer.seen" 13.35.04 # Torne Thanks for replying. how do I learn how to use bitmaps? i am a beginner with C and linux. Is there a special way to do it with rockbox? The API file says "lcd_bitmap(src,x,y,width,height,clear) put a bitmap at given position" I Guess i know what x,y,width,and height is, but how do I find out what clear is, and what src is, and how to make a bitmap? the PLUGIN_API file says void lcd_bitmap(const fb_data *src, int x, int y 13.35.13 Quit merbanan (Ping timeout: 240 seconds) 13.38.07 Join merbanan [0] (~benjamin@2a00:801:102:104:212:34ff:fe55:5a58) 13.38.12 Quit T44 (Ping timeout: 276 seconds) 13.43.33 Quit merbanan (Ping timeout: 240 seconds) 13.46.53 Join Topy44 [0] (~Topy44@f049179082.adsl.alicedsl.de) 13.47.14 # superlinuxpro: you can read and write files, yes 13.47.58 # And yes, using an array will reduce memory use a lot 13.48.57 # Reading that data from a file instead of having it in your code will help too, since you can then store it in the audio buffer (although that will stop playback) and not be limited by the 512K plugin buffer most targets have 13.53.05 # In general though, I think the best idea would be not to try this sort of thing at this stage. You can get away with not really understanding working with pointers and things like that in small and simple programs, but you do need to understand those things if you want to do more 13.56.28 # gevaerts Thanks for replying. So in my .c file, even if I've got got the same name of array assignments (e.g. myarray[1000][10][10]=TRUE; as I used to have drawpixel() calls, as long as I put the drawpixel function inside some nested loops it will reduce memory usage? 13.56.32 Join merbanan [0] (~benjamin@2a00:801:102:104:221:70ff:fecb:d6f9) 13.56.58 # If I go and google about pointers and stuff will it take me long to learn ? Or will it be harder b/c rockbox has some special way to do it? 13.57.00 Join PaulJam [0] (~GPB@p5DD6EC64.dip.t-dialin.net) 13.58.47 # myarray[1000][10][10] sounds wrong (what are the three dimensions meant to be? Frames, and pixels in the frame?), but yes, you'll use less space. Basically a drawpixel call needs to store all of those numbers *plus* a function call 13.59.27 # You need a general understanding of pointers in C. Working in rockbox adds some fun that you won't see on a PC, but chances are you can ignore that 14.00.47 # * gevaerts would recommend an online tutorial, but he hasn't personally needed one in the last 15 years or so, so he can't point at one 14.01.12 Quit PaulJam (Quit: Leaving) 14.03.43 Join PaulJam [0] (~GPB@p5DD6EC64.dip.t-dialin.net) 14.04.00 # gevaerts yes the little display is 128*64 pixels, and the video has about 1000 frames 14.04.51 # ok 14.05.03 # Ive compiled a file ten times as small 14.05.09 # its only a few frames though 14.08.07 Join WalkGood [0] (~4@unaffiliated/walkgood) 14.23.34 Join [Saint] [0] (~Saint]@unaffiliated/saint/x-8516940) 14.25.39 # superlinuxpro: if you assign the members of the array one at a time that will *also* be very large 14.25.49 # you need to include the actual data into your binary, not code to produce the data 14.26.02 # so, either a giant array initialiser {1, 2, 3, 4, 5, 6,... }; 14.26.22 # which would have to have 100,000 elements for your [1000][10][10] array :) 14.26.54 # or more sensibly, read it from a file 14.27.52 # also, a real bitmap format would be even smaller still, since your array is using at least one byte per pixel, but since they are mono, you only need one bit (and a sensible bitmap format will squish eight mono pixels into a byte) 14.29.44 # but.. yeah. do something simpler. learn C better first. 14.31.04 Join Thra11 [0] (~thrall@80.229.120.85) 14.32.14 # * [Saint] posits that bad code is much simpler than good C. ;) 14.35.24 # it's difficult to call a file with hundreds of thousands of lines simple :) 14.52.01 # Torne Thanks for helping. if i just google c tutorial file input and output will i get bad information? do i have to use a rockbox function like: int read(int fildes, void *buf, size_t nbyte); 14.52.01 # The read() function attempts to read nbyte bytes from the file associated 14.52.01 # with the open file descriptor, fildes, into the buffer pointed to by buf. 14.52.03 # ? 14.54.40 # yes; we do not have the functions in stdio.h; our filesystem api is more comparable to the UNIX read/write syscalls 15.00.57 Join webguest79 [0] (~3b9c9e01@www.haxx.se) 15.10.32 Join MethoS- [0] (~clemens@134.102.106.250) 15.12.44 Join idak [0] (~aidehara@PPPpm251.aichi-ip.dti.ne.jp) 15.14.57 Join leavittx [0] (~leavittx@89.221.199.187) 15.16.52 # I'm sorry for my long message again. But,,,, I think that contributing rockbox is very difficult for "non 15.16.53 # native English" people. The reason is that a irc is almost needed (something to say attention), and the irc discussion is quite difficult for them. 15.17.27 # (1) There are a lot of acronym and slang they can't understand. (2) It needs a quick response to discuss one's idea. ((3) for East Asian, different timezone (UTC+8 or +9)) 15.17.57 # (1) is much more a problem because those words can't look up in dictionary. I think that if rockbox keeps on positioning irc as main development tool, there will (or already or still) be only Western people. 15.19.25 # <[Saint]> 2 is untrue, and 3 is irrelevant. Its a logged channel, and irc is *not* the only place for development discussion. 15.20.06 # <[Saint]> We have a mailing list, and a tracker also. 15.20.15 # [Saint]: but irc is the main channel, so I think idak has a point 15.20.40 # <[Saint]> Oh, sure...but its not like irc is the only option. 15.20.40 # rather than waving off his concern, I think we should think about how we can meet them 15.22.02 Join y4n [0] (y4n@unaffiliated/y4ndexx) 15.22.49 # <[Saint]> Regarding 1, isn't there a list of common Rockbox acronyms floating around? 15.23.05 # <[Saint]> Perhaps on the wiki. I seem to recall this. 15.23.29 # <[Saint]> If I'm imagining it, it could be a nice thing to do. 15.23.55 Join The_prospector [0] (baconmaste@unaffiliated/cornman) 15.24.35 # i'm not sure that acronyms is a big problem, unless people are unwilling to clarify when asked 15.24.38 # and that seems unlikely 15.24.48 # I'm pretty sure the "non native" speakers actually outnumber the native ones too 15.25.54 # we've also got at least two active people in UTC+12 and UTC+13 :) 15.26.07 # <[Saint]> Turns out we do have a list of common terms and acronyms used anyway. 15.26.57 # idak: what do you propose instead of irc ? 15.27.05 # <[Saint]> www.rockbox.org/wiki/ProjectGlossary 15.28.10 # <[Saint]> Said glossary needs some additions, but I can do that tomorrow if I remember. 15.28.20 # I think irc is good for non native. But now rockbox irc has a lot ofslang 15.28.46 # idak: can you give some examples of this slang? We can try to clarify. 15.29.49 *** Saving seen data "./dancer.seen" 15.29.56 # yesterday i can't understand "japanese drive-by trolling". I checked slang dictionary and understand it. 15.30.14 # can't -> couldn't 15.30.36 # <[Saint]> Right...that's rather unlikely to come up in development talk ;) 15.30.39 # sadly that isn't rockbox specific slang - that's almost an internet wide thing 15.31.52 # Yes, but I think it is almost the same. Because non native can't separate them. 15.32.06 # idak: en.wikipedia.org/wiki/Drive-by_shooting + en.wikipedia.org/wiki/Troll_(Internet) 15.32.21 # <[Saint]> Acronyms likely to be used here are (mostly) covered in the glossary I linked above. 15.32.22 # a bit late now, of course :-) 15.34.39 # <[Saint]> As GodEater_ pointed out too, there's actually more non-native English speakers in here than native speakers, but it is a "universal language". You're quite unlikely to find very exotic examples of English use here. 15.34.41 # idak: jokes are inevitably difficult to translate. expecting people not to joke is a tricky one ;) 15.35.36 # [Saint]: I don't think there's much point arguing with idak's opinion. these are his impressions and feelings. they are true by definition. 15.36.23 # <[Saint]> I'm not saying he's wrong...I think you're reading too much into it. I'm saying its the way it is for a reason. 15.36.28 # naturally we don't want to limit the irc discussion. but I am absolutely interested in suggestions how to make it more including. 15.36.55 # [Saint]: ok. I am, after all, not a native speaker :-) 15.38.22 # In generally, mailing list is suitable for non native, because there are a lot of time to translate. 15.39.21 # <[Saint]> Are you aware of the development/users mailing lists? 15.40.28 # rockbox-dev is a perfectly reasonable place to ask questions about development; just because most people use IRC *more* doesn't mean you won't get a response 15.42.36 # yes, the dev mailing list is definitely a good place for discussion. 15.45.43 # I'm not aware of ML, because i used patch tracker. But recent days patch tracker was closed(?) and changed to gerrit. 15.46.29 # idak: it has always been the case that just uploading a patch to the tracker is not a good way to get something included 15.46.48 # it's always been a good idea to send a message to the mailing list or ask on irc about it 15.46.58 # This is still true now we have gerrit instead of flyspray 15.47.22 # the tool is just for hosting the proposed change and allowing people to comment on it; getting people interested in the first place is still the author's job, not the tool's. 15.47.59 # if you aren't comfortable with discussing things on irc, which is fine, then posting to the rockbox-dev mailing list is the best choice, probably. 15.48.15 # if you're proposing a specific patch, upload it to gerrit first and provide a link in the mail 15.48.42 # Humm, I found that rockbox development has two cycle that creating patch to tracker/girrit and saying attention to ML or irc. 15.48.57 # But, this is not described before. 15.50.02 # where would you expect to find that information? (serious question) 15.51.24 Quit The_prospector (Read error: Connection reset by peer) 15.51.38 Join The_prospector [0] (baconmaste@unaffiliated/cornman) 15.51.59 # http://www.rockbox.org/wiki/DevelopmentGuide 15.52.26 Quit PaulJam (Quit: Leaving) 15.52.38 # Right, yes. 15.53.25 # That seems like a good idea; we should edit both there and docs/CONTRIBUTING to explain that uploading your patch for review is not the last step, and you should expect to have to actively communicate with developers to get it included. 15.53.32 # I didn't know that saying attention to ML or irc is almost needed. I think a lot of non native is only post patch. 15.54.00 # We had hundreds/thousands of open patches on flyspray 15.54.10 # Actually paying attention to them is very difficult 15.54.26 # especially since in many cases people have just posted them and then never come back *even if* we respond 15.54.53 # for example it is quite common that a patch is acceptable, but when we ask the author for their real name in order to commit it they never respond 15.54.59 # Yes, they simply thought "ignored". 15.55.26 # No, i mean, in many cases in the past we *have* responded, but the author of the patch is already not paying attention any more 15.55.32 # after that happens enough times people give up 15.55.48 # someone who is actively engaging with us via IRC or the mailing list is much less likely to disappear :) 15.56.00 # Very few patches are acceptable as-is when uploaded. 15.56.13 # There's usually something that needs changing or improving, or more docs adding, or the author's real name provided, or similar. 15.56.26 # So, it's difficult for us to get anywhere if we don't have an open line of communication with the author. 15.58.15 Quit The_prospector (Read error: Connection reset by peer) 15.58.27 Join The_prospector [0] (baconmaste@unaffiliated/cornman) 16.04.16 Quit The_prospector (Read error: Connection reset by peer) 16.05.13 # now time is up (0 a.m.). Thank you for a lot of comment! 16.06.03 Quit idak (Quit: Leaving.) 16.07.30 # poor fellow 16.07.39 # think he got a bit overwhelmed there 16.10.35 Quit webguest79 (Quit: CGI:IRC (Ping timeout)) 16.13.45 Join zenlunatic [0] (~justin@c-68-48-40-231.hsd1.md.comcast.net) 16.16.58 # I'm glad he has spoken up though 16.17.44 # all view points are valuable 16.18.25 # <[Saint]> I'm not sure what we could do that isn't already in place, though. And unfortunately neither was s/he. 16.19.13 # <[Saint]> Being made aware of the ml certainly seemed to help. 16.20.00 # well we should definitely update the development guide page as indicated though 16.20.38 # just because some people "know" to pester someone somewhere about a patch they've written, doesn't mean everyone does - as he illustrated. 16.21.54 Quit qnm (Ping timeout: 260 seconds) 16.24.10 Join qnm [0] (~qnm@2001:44b8:3110:f300:208:9bff:fec0:179a) 16.32.32 Quit nosa-j (Read error: Connection reset by peer) 16.32.38 Join nosa-j [0] (~m00k@adsl-74-235-26-63.clt.bellsouth.net) 16.34.52 # GodEater_: Yeah, that is a definite action we can and should take 16.35.07 # we basically agreed at devcon that yes, we are okay with the process working this way, and with patches that aren't being pushed being ignored 16.35.22 # but we didn't actually do anything to tell anyone else this :) 16.36.14 # osmosis baby 16.36.19 # that's how it's supposed to work 17.00.59 Quit Thra11 (Ping timeout: 276 seconds) 17.02.03 Part Zagor 17.07.57 Join swilde [0] (~wilde@aktaia.intevation.org) 17.29.50 *** Saving seen data "./dancer.seen" 17.30.57 Join domonoky [0] (~Domonoky@rockbox/developer/domonoky) 17.32.49 # Does any one know where can I find in the OF of sansa Fuze V2 the routine to handle the keys? 17.43.18 Join kadoban [0] (~kadoban@ip98-165-177-158.ph.ph.cox.net) 17.46.18 Quit leavittx (Ping timeout: 244 seconds) 17.49.07 Quit hiptobecubic (Ping timeout: 240 seconds) 17.57.44 # GodEater_, Torne, Zagor: maybe flyspray could be set to an automatic reply if someone posts a patch along the lines of "if you want your patch included, please communicate it via mailing list or IRC" or somesuch? 17.58.00 # maybe gerrit too 18.02.57 Join wodz [0] (~wodz@89-76-160-35.dynamic.chello.pl) 18.06.36 # I'd like to ask broader audience - should unwarminder be compiled for bootloaders? The delta is between 2.8kB and 5.5kB (I guess it comes from code being compiled in thumb or arm mode) 18.07.59 Join bertrik [0] (~bertrik@ip117-49-211-87.adsl2.static.versatel.nl) 18.08.00 Quit bertrik (Changing host) 18.08.00 Join bertrik [0] (~bertrik@rockbox/developer/bertrik) 18.12.04 # hmm, delta table is a bit strange - what is the last column? Moreover Zen Vision, ZVMs and Samsung YP-R0 deltas are plain wrong. 18.14.15 # wodz: it seems like it'd be nice to have it in the bootloader as well, to me, unless tha tmakes the bootloader too large on some device 18.14.32 # wodz: also, i will hopefully have a look at handling data aborts during unwinding at some point :) 18.14.52 # I added check in UIE() to unwind only once btw 18.16.51 # Do we have bootloader on ARM target that may be affected? I mean do we have bootloader near max size allowed by the platform? 18.18.52 Quit dan_a (Ping timeout: 245 seconds) 18.20.36 # * bertrik vaguely remembers, maybe the clip v1 18.23.45 # bertrik: who may know for sure? funman? 18.25.15 # on the clip v1, we replace a 123k OF image with a 116k new image containing compressed OF + RB bootloader 18.25.37 Join pamaury [0] (~quassel@LAubervilliers-153-51-14-105.w193-252.abo.wanadoo.fr) 18.25.38 Quit pamaury (Changing host) 18.25.38 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 18.29.17 # on the clip+, we have a bit more room left, with a 134k OF image replaced by 123k (OF+RB bootloader) 18.29.53 Quit pamaury (Ping timeout: 240 seconds) 18.30.54 Join Keripo [0] (~Keripo@int043.apn.wireless-pennnet.upenn.edu) 18.31.28 Join pamaury [0] (~quassel@LAubervilliers-153-51-14-105.w193-252.abo.wanadoo.fr) 18.31.28 Quit pamaury (Changing host) 18.31.28 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 18.31.55 Join n1s [0] (~n1s@nl118-175-223.student.uu.se) 18.31.55 Quit n1s (Changing host) 18.31.55 Join n1s [0] (~n1s@rockbox/developer/n1s) 18.33.51 Quit anewuser (Ping timeout: 255 seconds) 18.34.01 Join dan_a [0] (~dan_a@217.23.173.156) 18.34.04 # 5.5kB compressed should be ~3kB after compression 18.34.30 # so we should be fine 18.36.58 Join anewuser [0] (~anewuser@190.207.138.187) 18.36.58 Quit anewuser (Changing host) 18.36.59 Join anewuser [0] (~anewuser@unaffiliated/anewuser) 18.37.20 # I don't see much need to have it in the bootloader, but not that much harm either. If we do get into size trouble at some point for a specific target, I'd argue for the stack unwinding stuff to go first. 18.42.52 Join Thra11 [0] (~thrall@80.229.120.85) 18.44.13 Quit pamaury (Ping timeout: 240 seconds) 18.45.51 Join jlbiasini [0] (~metaphys@d86-32-96-55.cust.tele2.at) 18.48.59 Join rudle [0] (~sean@dsl-69-171-138-154.acanac.net) 18.49.04 # wodz: Oh, you did? I must've missed that. 18.49.54 # wodz: Ah, but it still clears the screen and writes the new panic message 18.49.56 Quit n1s (Read error: Connection timed out) 18.50.00 # so you still lose the partial backtrace 18.50.14 # Anyway, what i'm proposing would trap the abort and not hit UIE at all 18.50.26 # and then the backtrace can just neatly conclude with "oh, and the next bit is invalid, be suspicious" 18.50.35 Join n1s [0] (~n1s@nl118-175-223.student.uu.se) 18.50.36 Quit n1s (Changing host) 18.50.36 Join n1s [0] (~n1s@rockbox/developer/n1s) 18.51.16 # wodz: possibly for now it would be better if you hit UIE with triggered==true to not touch the lcd at all and just skip directly to system_exception_wait 18.51.38 # sorry, if i'd spotted this i'd've mentioned it :) 18.51.51 # i didn't see that you had addressed the recursive trace issue at all 18.52.15 # Torne: This way you will not know that backtrace() bombed out (weak argument but you know...) 18.53.01 Quit wodz (Quit: Leaving) 18.53.20 Quit Keripo (Quit: Leaving.) 18.53.41 # wodz: That's kinda worse, though: this way you won't know that the original crash even happened 18.53.44 # is it possible to get a crash dump from a device? i just installed rockbox onto my ipod and it's bombing during playback 18.54.01 # rudle: we are, in fact, just discussing the just-committed code which does basically that ;) 18.54.10 Quit swilde (Remote host closed the connection) 18.54.10 # what does the device say when it dies? 18.54.31 # nothing, it locks up and emits a most unfortunate buzzing noise 18.54.42 # i can restart it by holding 'play/pause' 18.55.16 # er.. just that button? 18.55.21 # that's not ever supposed to restart it :) 18.55.37 # <[Saint]> If so...its not actually "locking up". 18.55.54 # err, i guess it turns off the player. it's an ipod classic 18.56.12 # [Saint]: i say locks up because no other piece of the UI is responsive, the backlight stays dark, etc 18.56.20 # Oh, if it just turns it off, then probably rockbox is still running 18.56.27 Join januszBLOK [0] (~janusz@88.199.38.158) 18.56.32 # and it's just that it's screwed up its state such that it's not updating the screen.. 18.56.35 # hi guys 18.56.50 # i have a problem with clip+ 18.57.03 # probably bricked 18.57.27 # Torne: that's interesting. are there any actions i can take to further investigate the cause? 18.57.52 # is this when playing a specific file? any file? at random? 18.58.04 # windows show me 4 mb device 18.58.15 # and can not format 18.58.39 # any file, it's fairly random. i have a sneaking suspicion that the drive is hosed, and i'm trying to confirm that theory 18.59.07 # rudle: have you checked the filesystem? 18.59.09 # rudle: how often does it happen? 18.59.27 # n1s: after about 15~20 minutes of playback 18.59.37 # Torne: with fsck? sorry i'm kinda new to rockbox 18.59.46 # chkdsk, fsck, etc, yeah. 18.59.49 Join TheLemonMan [0] (~LemonBoy@adsl-ull-133-212.50-151.net24.it) 19.00.51 # rudle: does it happen when using the scrollwheel or just when it's playing? 19.01.06 # n1s: when it's playing, untouched 19.01.26 # ok, probably not the hold switch issue then 19.01.49 # <[Saint]> Is this separate to the issue you mentioned in #freemyipod? 19.02.13 # [Saint]: it occurs with relatively the same frequency, which suggests a drive issue 19.02.25 # fsck returned exit code 1, i'm pasting the output now 19.02.47 # <[Saint]> Please do it in pastebin. 19.03.06 # working on it :P 19.03.06 # <[Saint]> We don't like getting flooded ;) 19.03.29 # logbot_ might get annoyed :) 19.05.00 # rudle: apple's firmware hasn't ever locked up but instead just skipped songs? 19.05.16 # did it skip whole songs, or jump to the next on in the middle of playing the previous one? 19.05.34 # TheSeven: no lockups, and it would skip 'the rest of the song' when it did 19.06.04 # http://paste.pocoo.org/show/555123 heres the fsck output 19.06.05 # sounds very much like corruption of files or a bad disk then 19.06.45 Join lebellium [0] (~chatzilla@e179039185.adsl.alicedsl.de) 19.06.47 # well he claims that this happens completely at random, not reproduible, so I'd rather think bad connection/signal somewhere, probably not bad sectors 19.07.11 Join GeekShadow [0] (~antoine@56.134.197.77.rev.sfr.net) 19.07.18 # is it worth running something like SMART on the drive? 19.07.43 # can't hurt to gather as much information as possible 19.07.44 # rudle: if you remember a track where this has happened, can you try playing it again? 19.08.16 # i'm on it 19.08.22 # rudle: could it be possible that this ipod got in touch with water or some other liquids at some point? 19.08.38 Join hiptobecubic [0] (~john@unaffiliated/hiptobecubic) 19.08.53 # hmm, i don't think so. i've taken pretty good care of it 19.09.05 # rudle: the fsck log looks more like an emcore bug than an HDD issue... have to look into that 19.09.41 # and a very very weird one... 19.11.50 # n1s: it made it through the song, but crashed shortly after 19.12.17 Join leavittx [0] (~leavittx@89.221.199.187) 19.12.57 # rudle: indeed, you just uncovered a FAT driver bug :) 19.13.07 # awesome! 19.13.33 # * TheSeven wonders if it was him who screwed that up or some guy he copied the code from 19.14.24 # <[Saint]> When all else fails, pass the blame :) 19.16.52 # anyway, fixed it in emCORE HEAD 19.17.06 # sweet, is that safe to try out now? 19.17.51 # it should be when the build system finishes compiling 19.18.08 # this only screwed up a couple directory links though, rather harmless bug 19.18.24 # certainly not responsible for any playback trouble 19.18.49 # oh, i see 19.18.58 # you could try installing this if you want: http://builds.freemyipod.org/emcore-installer/target/ipodclassic/emcore-installer-ipodclassic-r862.ubi 19.19.10 Quit GodEater_ (Ping timeout: 245 seconds) 19.19.21 # throw away the whole .apps tree before running that and it should be fixed 19.29.53 *** Saving seen data "./dancer.seen" 19.37.01 # so are there any actions i can take to diagnose the issue? if rockbox isn't actually locked up, could i get some debug info at least? 19.40.24 Quit Bagder (Quit: connection reset by beer) 19.41.01 Quit Xerion (Read error: Connection reset by peer) 19.41.06 Join Xerion [0] (~xerion@5419EF19.cm-5-2d.dynamic.ziggo.nl) 19.41.20 Join benedikt93 [0] (~benedikt9@unaffiliated/benedikt93) 19.47.24 Join thomasjfox [0] (~thomasjfo@dslb-088-067-055-251.pools.arcor-ip.net) 19.47.32 Quit thomasjfox (Changing host) 19.47.32 Join thomasjfox [0] (~thomasjfo@rockbox/developer/thomasjfox) 19.50.10 Quit januszBLOK (Ping timeout: 240 seconds) 19.51.11 Join Bagder [241] (~daniel@rockbox/developer/bagder) 19.54.17 Quit domonoky (Quit: Leaving.) 19.55.30 Join domonoky [0] (~Domonoky@rockbox/developer/domonoky) 20.02.13 Quit merbanan (Ping timeout: 240 seconds) 20.05.58 # Can someone add my "thomasjfox" gerrit account to gerrit's commiters group? 20.06.14 # thomasjfox: IIRC you need Torne or Zagor for that 20.06.36 # * thomasjfox summons Torne 20.07.10 # I'm wondering how many (active) commiters didn't migrate yet 20.07.38 # Though the new committers list is quite long already 20.09.12 # they aren't very active comitters if they haven't migrated yet :) 20.09.33 # thomasjfox: for some definition of "active" all active committers migrated already :) 20.09.53 # ;) 20.14.13 Join Keripo [0] (~Keripo@165.123.49.232) 20.16.09 Quit Fuze_V2_ (Quit: CGI:IRC) 20.16.26 Join lorenzo92 [0] (~chatzilla@host184-18-dynamic.252-95-r.retail.telecomitalia.it) 20.18.42 Quit lorenzo92 (Remote host closed the connection) 20.19.07 Quit WalkGood (Quit: me fui) 20.22.28 # hmm, ipod drive seems really upset, it won't mount as FAT under linux. is it safe to just format the drive? 20.27.35 Join zaphee [0] (~user@ede67-2-82-232-36-5.fbx.proxad.net) 20.28.22 Part zaphee 20.34.03 Join zaphee [0] (~user@ede67-2-82-232-36-5.fbx.proxad.net) 20.34.07 Part zaphee 20.36.41 Quit Keripo (Quit: Leaving.) 20.37.54 Join lorenzo92 [0] (~chatzilla@host184-18-dynamic.252-95-r.retail.telecomitalia.it) 20.39.49 # gevaerts: do you have still more ideas for my broken e280 if wobbling the flash chips doesn't make them writeable? 20.39.59 # no 20.40.10 # :-( 20.40.42 # gevaerts: thanks anyhow for your ideas. 20.45.06 # the smd connections look ok as far as I can tell. 20.53.12 Quit bzed (Ping timeout: 272 seconds) 20.53.50 Quit user890104 (Ping timeout: 272 seconds) 20.54.35 Join bzed [0] (~bzed@devel.recluse.de) 21.00.42 Quit [Saint] (Read error: Connection reset by peer) 21.00.56 Join [Saint] [0] (~Saint]@unaffiliated/saint/x-8516940) 21.07.57 Join dhrasmus [0] (~dhrasmus@c-98-246-192-57.hsd1.or.comcast.net) 21.11.02 Quit y4n (Quit: HOLY SHIT! WE'RE ALL JUST LIVING ON A GINORMOUS FUCKING SPINNING ROCK FLOATING THROUGH SPACE CIRCLING A BIG FUCKING BALL OF FIRE!!!) 21.13.19 Join saratoga [0] (980329b4@gateway/web/freenode/ip.152.3.41.180) 21.14.09 # bluebrother^: perhaps it would be more clear if the "quick start" tab in rbutil installed a current build for targets without a release instead of being greyed out 21.15.42 Join curtism [0] (~curtis@bas11-montreal02-1128531121.dsl.bell.ca) 21.15.42 Quit curtism (Changing host) 21.15.42 Join curtism [0] (~curtis@unaffiliated/programble) 21.16.57 Join mshathlonxp [0] (msh@87.110.21.209) 21.24.12 Quit dhrasmus (Quit: Leaving) 21.29.54 *** Saving seen data "./dancer.seen" 21.34.27 # whats teh equivalent of "svn revert -R" in git? 21.34.44 Quit benedikt93 (Quit: Bye ;)) 21.35.41 # saratoga: git reset --hard, probably 21.36.32 # for future reference, if i want to update my check out and i've made trivial changes to it, whats the usual way to merge my changes with updates? 21.36.33 Quit rudle (Quit: leaving) 21.36.55 # saratoga: git pull? 21.37.06 # that complains if i've made local changes 21.37.18 # Depends. If you have committed locally, git pull --rebase. If not, git stash 21.37.28 # The git pull and git stash pop 21.37.42 # how do i commit locally? 21.37.53 # git commit 21.38.06 # and that won't push anything back to rockbox.org? 21.38.13 # Not at that time, no 21.38.22 # when should i commit things locally 21.38.25 # You have to be a bit careful if you never want to push it though 21.38.53 # Up to you, really 21.39.38 # * gevaerts asks our resident git experts about tutorials :) 21.41.34 # a safe way to prevent accidental pushes is to use a readonly transport for cloning 21.50.58 # i though git stash; git pull, git stash pop would reapply local changes after pulling? 21.52.20 # yes 21.53.34 # so how would you do what saratoga ask, what git revert does, just git stash ? 21.53.40 # and leave it there 21.54.15 # git revert is different from svn revert 21.54.31 # n1s: git revert creates a commit that undoes another. 21.55.08 # ah, i meant to typoe what svn revert does, i assumed git revert did something i don't want 21.55.28 # n1s: he asked two different things :) 21.55.56 Quit thomasjfox (Quit: Konversation terminated!) 21.55.57 # indeed, i missed the second question 21.56.15 # so git reset --hard path/to/file should do what i want? 21.56.17 Quit Thra11 (Read error: Operation timed out) 21.57.06 # "git co [file]" is basically the same thing 21.57.26 # git checkout even 21.57.38 # so that's ok with overwriting local changes? 21.57.44 # yes 21.57.56 # i should take notes 21.59.31 # saratoga: I'd like to remove that tab completely anyway. 21.59.34 # reset and checkout differ in how they handle the index 21.59.43 # yes thats also an option 21.59.49 # naturally 22.00.11 # does anyone have an opinion on the final version of FS#12288 ? 22.00.11 # http://www.rockbox.org/tracker/task/12288 3Sansa Clip+: "Home" in the main menu to WPS/Radio (patches, unconfirmed) 22.01.28 Join Thra11 [0] (~thrall@31.185.220.196) 22.01.43 # http://marklodato.github.com/visual-git-guide/index-en.html is a nice one 22.01.56 Quit Thra11 (Remote host closed the connection) 22.02.03 Join Thra11 [0] (~thrall@31.185.220.196) 22.04.28 # * bluebrother^ likes this one: http://www.ndpsoftware.com/git-cheatsheet.html 22.06.36 Quit hiptobecubic (Ping timeout: 240 seconds) 22.07.39 Quit TheLemonMan (Quit: WeeChat 0.3.6) 22.09.15 Join bluebrother [0] (~dom@f053154251.adsl.alicedsl.de) 22.09.16 Quit bluebrother (Changing host) 22.09.16 Join bluebrother [0] (~dom@rockbox/developer/bluebrother) 22.12.37 Quit bluebrother^ (Ping timeout: 245 seconds) 22.12.59 Quit fs-bluebot (Ping timeout: 276 seconds) 22.14.59 Join fs-bluebot [0] (~fs-bluebo@f053154251.adsl.alicedsl.de) 22.25.33 Quit lorenzo92 (Quit: ChatZilla 0.9.88 [Firefox 10.0.2/20120216115113]) 22.28.27 # saratoga, I lost track of that patch, I'll try it no 22.28.31 # w 22.35.16 # Commit 1a4a934 in rockbox by 03Dominik Riebeling: Don't poll SAPI script output. 22.35.23 Join dfkt_ [0] (~dfkt@unaffiliated/dfkt) 22.36.24 Quit dfkt (Ping timeout: 260 seconds) 22.38.04 # bluebrother: there is still a problem with RockboxUtility post install hint on the Fuze+: http://dl.dropbox.com/u/43468173/RockboxUtility%20hint.jpg 22.38.06 # 1. means already Disconnect your player like 3. 22.38.11 # 1a4a934 build result: All green 22.39.23 # I used last version compiled from git 22.40.22 # If you want I will make a patch to correct that 22.40.54 # or is it bluebrother^ ? 22.41.02 # also spelling mistake in inbstallation 22.42.19 # saratoga, I don't know much about the keymap code, but I like the way it works with that patch 22.42.20 # ah right but this is probably related with the french translation only and not with the structure or the code itself 22.42.38 # fine with me for commit 22.43.49 # bluebrother: did you see my ping from earlier? 22.49.41 # funman: ever looked at an STM32 datasheet? 22.49.59 # I just noticed that those chips seem to use the same synopsys OTG that the ipods and amsv2 use 22.50.16 # and the documentation in there seems to be way better than the s3c6400x one 22.50.58 # this also means that I now have a devboard with jtag access etc. which should be compatible driver-wise 22.51.03 # might ease debugging a lot :) 22.51.34 Join user890104 [0] (venci@Addicted.to.Minecraft.ipv6.6bez10.info) 22.53.16 # kugel: yes. I'm not sure if I like the changed behaviour though 22.54.02 # we close pretty much all "selection" dialogs after installation, and changing that for theme installation would make it inconsistent 22.58.45 # bluebrother: should I make a patch for the post hint problem? 23.01.03 # jlbiasini: I'm already looking at it 23.01.18 # ok 23.01.40 # thanks 23.01.42 # :) 23.03.05 # bluebrother: actually just removing the 1. would be sufficient... if it's compatible with other target 23.03.34 # well, of course not :) 23.03.49 # other players don't define their own "remove player" string ;-) 23.04.15 # that's all the fun about it :D 23.05.30 Quit Rower85 (Quit: Hmmm...) 23.06.16 # bluebrother: themes are different though, people might want to install several, no other things are like that i think 23.07.26 # n1s: you can already select multiple themes. Shouldn't that be sufficient? 23.08.13 # i didn't know that (i've never used it though), maybe others don't know that either 23.08.19 # hmm. 23.08.27 # I've even put a not on the bottom of that screen 23.08.35 # oh :) 23.08.36 # *note 23.08.53 # yeps, still there :) 23.09.05 # sounds like we should fix the users then :) 23.09.09 # funman: that also means that there's a set of open source (but not neccessarily GPL-compatible) CMSIS drivers for that USB core out there 23.09.29 # if people seem to miss that changing behaviour might be something to consider 23.11.35 # bluebrother: i'd guess they just don't expect it and noone reads instructions since they *know* how things work 23.12.01 # anyway, doesn't sound like it's in much need of fixing 23.12.04 Join z180 [0] (~6d2a6283@www.haxx.se) 23.12.36 # making it harder for people to install themes is also likely to decrease the load on our servers :P 23.12.43 # since the patch was posted i just assumed the dialog only let you install one theme and then closed so you'd have to click a lot to install more 23.13.19 # well, multiselect was introduced when the "install all" button was removed. 23.14.21 # but I still want to implement the reworked main tab which will change the behaviour of that screen completely anyway :) 23.14.22 # i don't know how it looks but perhaps a list with checkboxes or something for selection would make it clearer 23.14.33 # funman: http://pastie.org/3435388 might also contain some clues about those lockup issues 23.14.55 # of course there is still other stuff I want to get fixed so this might not happen too soon 23.16.24 # bluebrother: do you thing you will have time to have a look to my manual patches? Or do you prefer that I ask someone else? 23.17.03 Quit z180 (Quit: CGI:IRC (Ping timeout)) 23.17.21 # I know this is quite harassing.... 23.17.28 # :( 23.17.46 # jlbiasini: I'll try ... I have a cold right now so I'm a bit slow getting things done 23.18.25 # jlbiasini: as you have probably noticed, few patches get through unless someone is pusing for them to be reviewed and committed 23.19.20 # n1s: I'm a bit afraid to annoy people asking all the time for commiting my patches 23.19.57 # And the first version I sended to bluebrother were a bit dirty... :( 23.20.19 # when people are annoyed they'll look at the patch so yo'll stop :) 23.20.58 # Commit dc9bd85 in rockbox by 03Dominik Riebeling: Remove duplicate entry from postinstall hint. 23.20.59 # Commit f9bf62e in rockbox by 03Dominik Riebeling: Fix post installation hint for h100 / h300 players. 23.22.55 # hmm, nobody noticed the post installation hint being broken for h100 / h300 :( 23.23.02 # kugel: did you see that I updated bounce PLA? I also send a fireworks PLA 23.23.22 # f9bf62e build result: All green 23.23.33 Join rainysun [0] (~55de119a@www.haxx.se) 23.25.25 # is there an easy way to pull a review in my working copy? 23.26.00 Join Keripo [0] (~Keripo@165.123.49.232) 23.26.37 # bluebrother: i think there's a link in the gerrit interface? 23.26.49 # ah, I can simply run that? 23.26.50 # * bluebrother tries 23.27.02 # nice. 23.27.11 # I thought that's for a new copy 23.27.25 # yeah i guess cherry-pick usually 23.27.50 # hmm, it's not a clone so I guess that wouldn't work without having a clone already. Maybe I was thinking too much about it :) 23.28.02 Join Strife89 [0] (~Strife89@207.144.201.128) 23.29.55 *** Saving seen data "./dancer.seen" 23.29.56 Quit n1s (Quit: Ex-Chat) 23.30.06 # * jlbiasini is happy to see that he is not the only one searching around about git 23.30.52 Join Scromple [0] (~Simon@119.225.209.134) 23.30.52 Quit rainysun (Quit: CGI:IRC (EOF)) 23.32.25 # Commit 5f2fb4a in rockbox by 03Dominik Riebeling: (Author: Jean-Louis Biasini) Fuze+'s manual: change ugly \ButtonPlayPause 23.32.44 # nice how easy that was :) 23.33.06 Quit dan_a (Ping timeout: 265 seconds) 23.33.47 Quit fs-bluebot (Quit: So long, and thanks for all the fish.) 23.34.41 # 5f2fb4a build result: All green 23.35.00 Join fs-bluebot [0] (~fs-bluebo@f053154251.adsl.alicedsl.de) 23.35.20 # is the author of g#77 around in this channel? 23.35.50 # * bluebrother needs to fix the bot 23.36.59 # bluebrother: yes this one is the easy one :) 23.37.11 Quit leavittx (Ping timeout: 252 seconds) 23.38.49 # jlbiasini: yes, but I was referring to submitting a change via gerrit :) 23.39.26 # bluebrother: Yeah I got it!! :D 23.42.27 Quit bertrik (Ping timeout: 248 seconds) 23.45.19 # FS's gurus up there? FS#12405 can be close 23.45.21 # http://www.rockbox.org/tracker/task/12405 3Improve touchpad implementation for the fuzeplus's port (patches, unconfirmed) 23.47.06 Nick dfkt_ is now known as dfkt (~dfkt@unaffiliated/dfkt) 23.51.08 # jlbiasini: has it been merged? 23.51.36 # nvm 23.54.07 Quit fs-bluebot (Quit: So long, and thanks for all the fish.) 23.54.43 Join fs-bluebot [0] (~fs-bluebo@f053154251.adsl.alicedsl.de) 23.55.14 # * bluebrother looking at g#119 23.55.36 # hmm, not reacting on action events? g#119 23.55.37 # 3Gerrit review # at http://gerrit.rockbox.org/r/#change, 23.55.47 # slightly broken :) 23.55.53 Quit fs-bluebot (Client Quit) 23.56.34 Join fs-bluebot [0] (~fs-bluebo@f053154251.adsl.alicedsl.de) 23.56.59 # Trying again: g#119 23.57.00 # 3Gerrit review #119 at http://gerrit.rockbox.org/r/#change,119 23.58.17 # bluebrother: yes it's a old FS with a lot of different patch, at end everything was patched 23.58.40 # either way, I've already closed it 23.58.41 # and send: see last comment 23.58.46 # thanks