--- Log for 28.01.105 Server: zelazny.freenode.net Channel: #rockbox --- Nick: logbot_ Version: Dancer V4.16 Started: 15 days and 11 hours ago 00.00.00 # yay 00.04.30 Join Stryke` [0] (~Chairman8@24-168-110-99.si.rr.com) 00.05.03 # charging is actually software controlled for some players? 00.05.17 # yes 00.06.21 # wow, i'd have guessed that was a hardware thing, mostly 00.09.17 # does anyone know how the h1x0 players manage that yet? 00.10.26 # hardware 00.11.25 # i'm also thinking of getting mine a new and higher capacity battery, anyone heard something that suggests that won't be a good idea? 00.11.51 # the H1x0? 00.11.53 # h120 00.12.31 # i heard that some people have problems fitting the new batteries in the casing 00.12.43 # yes, that would of course be an issue, hehe 00.14.30 *** Saving seen data "./dancer.seen" 00.16.01 Join QT_ [0] (as@area51.users.madwifi) 00.22.55 # Zagor: Yellow build for win32 sims... 00.23.40 # yeah, apparently win32 doesn't have strcasestr(). 00.24.41 # It must have it, since otherwise linking would fail... 00.25.08 # A propos win32 sim: I looked into the LITTLE_ENDIAN issue with cygwin. This is really strange, but the LITTLE_ENDIAN thing is relatively easy to work around. 00.26.05 # However, if compiling the Win32 sim with cygwin, netinet/in.h doesn't seem to exist.... 00.26.20 # It does work if building the X11 sim with cygwin though... 00.26.45 # right, it should use something other than htonl. that was just a quick hack. 00.27.19 # i'm off to bed now, though. we'll look at it tomorrow. 00.27.28 # Ahahhh! When compiling the sim now with cygwin, the build *fails* 00.27.33 Quit QT (Read error: 110 (Connection timed out)) 00.27.43 Quit Zagor ("Client exiting") 00.39.07 # leaving, cu 00.39.33 # cu 00.39.57 Quit quelsaruk ("KVIrc 3.0.1.99 'Realia'") 00.42.15 Join einhirn [0] (Miranda@carlsberg.heim2.tu-clausthal.de) 00.54.03 Quit Stryke` ("Friends don't let friends listen to Anti-Flag") 01.04.41 Join bagawk [0] (Lee@bagawk.user) 01.05.26 # hey amiconn, could you do a quick favor for me? 01.06.58 # Wazzup? 01.08.20 # Go to http://67.41.87.67/ and tell me if you get an apche confimation page 01.08.37 # i certainly do 01.08.46 # bagawk: yup 01.08.56 # :) 01.09.01 # The page is even localized :) 01.09.03 # THanks 01.09.21 Join johntb [0] (~Baumans@66.216.162.53) 01.09.26 # join #freeciv-dev 01.09.29 Quit johntb (Client Quit) 01.10.03 # localized? In what way? 01.10.53 # apaches default page comes in several languages 01.11.02 # Ahh 01.11.19 # and your browser usually requests one in your language, if you've set it up that way 01.11.33 # I was making a little ftp server on my machine so I could keep my files in one place 01.12.06 # now to get dyndns going :) 01.12.23 Join elinenbe_ [0] (elinenbe_@207-237-225-9.c3-0.nyr-ubr1.nyr.ny.cable.rcn.com) 01.20.45 # does http://leepil.dyndns.org/ work? 01.23.28 # yzp 01.23.36 # Erm, yup 01.23.55 # z is a little far away for u or e 01.23.56 # :) 01.24.03 # (on a QWERTY atleast( 01.24.25 # No, it's not. The german keyboard has y and z swapped compared to english keyboard 01.24.46 # Ahh 01.24.53 # interestin 01.24.57 # g 01.25.27 # It seems I should get some sleep now. 01.25.41 # ok 01.25.43 # bye! 01.25.53 Part amiconn 01.26.08 Quit bagawk ("Leaving") 01.32.27 Part LinusN 02.05.39 Join elinenbe1 [0] (~elinenbe_@65.115.46.225) 02.07.47 Quit elinenbe (Read error: 54 (Connection reset by peer)) 02.07.48 Nick elinenbe1 is now known as elinenbe (~elinenbe_@65.115.46.225) 02.13.16 Quit preglow ("fisle") 02.14.34 *** Saving seen data "./dancer.seen" 02.14.43 Quit mecraw () 02.25.24 Quit edx (Read error: 110 (Connection timed out)) 02.28.23 Join jipi [0] (~jipi@cm6.gamma177.maxonline.com.sg) 02.32.03 Quit jipi (Client Quit) 02.42.26 Join DarthWufei [0] (tinkerbell@24-116-229-60.cpe.cableone.net) 02.42.32 # Hiya 02.42.40 # I think my Archos died. :/ 02.44.17 # It was charging and then I noticed it had some error on it, didn't quite catch what it was, but the unit wouldn't shut off. So I had to remove the AC adapter, it shut off, and then wouldn't turn on. It turns on witht he adapter, and charges, but when I try to load Rockbox.. it stops about 3 steps in and just sits there. 03.03.33 # Oh whoa it works now, I guess the battery got super low. :X 04.05.46 Join edx [0] (edx@pD9EAADC2.dip.t-dialin.net) 04.14.18 Quit MooMaunder (Read error: 60 (Operation timed out)) 04.14.35 *** Saving seen data "./dancer.seen" 04.14.48 Quit Shulberry (Read error: 60 (Operation timed out)) 04.29.09 Quit gromit` (Remote closed the connection) 05.03.51 Join Shulberry [0] (Taxi@oslo-dhcp-248-180.bluecom.no) 05.09.32 Join lostlogic [0] (~lostlogic@node-4024215a.mdw.onnet.us.uu.net) 05.35.28 Quit DarthWufei () 06.14.37 *** Saving seen data "./dancer.seen" 07.12.25 Quit Shulberry (Read error: 60 (Operation timed out)) 07.23.09 Join methangas [0] (methangas@0x50a43276.virnxx10.adsl-dhcp.tele.dk) 07.24.04 # Good morning everyone 07.33.12 Quit midk (Read error: 104 (Connection reset by peer)) 07.35.37 Join Shulberry [0] (Taxi@oslo-dhcp-248-180.bluecom.no) 07.43.04 Join midk [0] (~midk@c66-235-14-120.sea2.cablespeed.com) 07.43.24 Join gromit` [0] (~gromit`@ras75-5-82-234-244-69.fbx.proxad.net) 07.57.36 Join dwihno_ [0] (~dw@81.8.224.89) 07.59.37 Quit dwihno_ (Client Quit) 08.00.15 Join dwihno_ [0] (~dw@81.8.224.89) 08.07.20 Quit einhirn ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") 08.14.39 *** Saving seen data "./dancer.seen" 08.15.42 Quit dwihno (Read error: 110 (Connection timed out)) 08.44.26 Nick QT_ is now known as QT (as@area51.users.madwifi) 09.05.48 Join Zagor [242] (~bjst@labb.contactor.se) 09.47.56 Join lImbus [0] (lImbus@147-172.244.81.adsl.skynet.be) 09.48.19 Join Schnueff [0] (~mah@134.96.247.233) 09.48.40 # Hi, I just finished very successfully my car power supply. somebody interested in pictures/shematics ? 09.49.25 # it's mainly a question to the core devs if it's worth to get on the wiki. 09.54.42 # lImbus: what exactly is the mod? 09.57.19 # it's just a L4940 very low drop regulator with two capacitors 09.58.13 # I ask because I knew it couldn't be complicated, but I didn't dare to do it, until this morning 09.58.36 # no, i mean what does it do? 09.59.00 # uh. it gives power to my archos recorder, so I can charge it while driving 10.00.21 # recorder v2? 10.00.31 # nope, v1 10.02.35 # ok. well sure, throw it up in the wiki. 10.02.51 # kk 10.03.39 # I'll lik it within docs->hardware and a note in the battery and charging FAQ, if I manage it :-) 10.04.10 # s/lik/link 10.04.25 # sounds good 10.14.44 *** Saving seen data "./dancer.seen" 10.31.12 Join LinusN [0] (~linus@labb.contactor.se) 10.33.34 Join MooMaunder [0] (~me@194.152.87.150) 10.34.11 # uhhh. took my a while to understand that the left side link "Doc" on the main page is NOT the same than the DocIndex-Page in the wiki... 10.34.53 # HÄ ? now it is ?!? 10.35.12 # ok. my fault 10.35.14 # it is 10.35.31 # I picked the old "http://www.rockbox.org/docs/" from my browsers proposal... 10.35.49 # it better should redirect into wiki then. 10.36.03 # I got that old url in a bookmark as well. 10.40.43 Part LinusN 10.47.39 Join LinusN [0] (~linus@labb.contactor.se) 10.48.14 # * LinusN is installing the bootloader via iriver's own firmware upgrade function 10.48.39 # * lImbus is clapping and bowing. 10.48.43 # Woo! 10.48.59 # Heja Linus, friskt humör! Skjortan hänger utanför! :D 10.49.15 # well, the boot loader isn't finished 10.49.28 # the loading itself isn't implemented 10.50.01 # Well, the skjorta still is inside the pants then :) 10.50.06 # but i made the tool that inserts the boot loader into the original firmware 10.50.07 # But still, friskt humör! 10.50.37 # so now i can select which code to run by holding the REC button when turning it on 10.50.51 # nicers 10.51.27 # only thing left is to make ROLO understand the new unscrambled file format 11.00.08 # sounds really good :) 11.06.04 Join einhirn [0] (Miranda@bsod.rz.tu-clausthal.de) 11.15.08 Join amiconn [0] (~jens@pD9E7E416.dip.t-dialin.net) 11.28.10 # hi 11.28.20 # hi 11.32.49 # Zagor: r u there? 12.08.51 Part LinusN 12.14.48 *** Saving seen data "./dancer.seen" 12.22.12 Join LinusN [0] (~linus@labb.contactor.se) 12.24.03 Join ripnetuk [0] (~george@82-70-100-230.dsl.in-addr.zen.co.uk) 12.26.26 # amiconn: here now 12.27.23 # Zagor: I checked my cygwin installation - there is no strcasestr() 12.28.18 # ok 12.28.42 # Zagor: btw, I'm just done with that wiki article about my circuit 12.29.49 # iRiver lookin' good :) 12.31.39 # yup 12.31.52 Join kurzhaarrocker [0] (~knoppix@p5487C122.dip0.t-ipconnect.de) 12.32.26 # lImbus: woo, long paragraphs! 12.32.59 # I just wanted to explain to the people what I did not understand before. Shorten as you like :-) 12.33.21 # i propose renaming the subject to CarPowerSupply aswell 12.34.03 # the thing is I have to hurry a bit now. it took longer than expected. do you want me to do it this evening ? or is it so important that you want to fix that now ? :-) 12.34.14 # I dont even know how to rename topics 12.34.25 # it's not important, don't worry 12.35.04 # kk (->goes to my todo list, right after, lemme see, ummm, well, right after coming home from office this evening :-) 12.35.05 # `More' -> `Rename / move topic' 12.35.16 # ahh, danke 12.36.14 # ot: Does anybody here know / use a freeware tool for making use case diagrams? 12.36.15 # lImbus: i wish i have such a short todo list :-) 12.37.36 # LinusN. Mine is very long, but I assume it's not hard to render this topic nice, so... 12.39.28 # uhh. Is Christi in here ? She locked my topic, already squashing out the bugs, I suppose. 12.39.37 # bug == typos, of course 12.40.53 Part kurzhaarrocker 12.41.05 Quit lostlogic (zelazny.freenode.net irc.freenode.net) 12.41.05 NSplit zelazny.freenode.net irc.freenode.net 13.05.56 Join jyp [0] (~jp@49.6-136-217.adsl.skynet.be) 13.05.56 NHeal zelazny.freenode.net irc.freenode.net 13.05.56 NJoin lostlogic [0] (~lostlogic@node-4024215a.mdw.onnet.us.uu.net) 13.10.30 Quit lostlogic (zelazny.freenode.net irc.freenode.net) 13.10.30 Quit jyp (zelazny.freenode.net irc.freenode.net) 13.10.52 NJoin lostlogic [0] (~lostlogic@node-4024215a.mdw.onnet.us.uu.net) 13.20.39 # SUCCESS!!!!!!!!!!!!! 13.20.45 # * ripnetuk claps 13.20.55 # i just booted rockbox with the rockbox boot loader 13.20.58 # have you rolo'ed a exe then :) 13.21.04 # nice one 13.21.11 # congratulations 13.22.40 # i created a tool for inserting our loader into an iriver firmware 13.22.47 # in tools/ 13.23.05 # Zagor: i called it "mkboot", is that ok? 13.25.46 # really cool linus! 13.26.13 # * lImbus gives out a beer or two to LinusN... or three 13.26.41 # gotta run 13.26.42 # cz later 13.26.42 # LinusN: sounds good to me 13.26.48 Quit lImbus (" HydraIRC -> http://www.hydrairc.com <- irc client ownage!") 13.33.24 # Are you going to provide a pre-built binary of your boot loader so we can use your mkboot to inject it into a iRiver firmware? im not sure I want my first test of my m68k cross compiler to be the boot loader :) 13.34.02 # also, if it goes wrong, how many points do you have to solder to get a wiggler working to repair ? 13.34.41 Quit midk (Ping timeout: 14400 seconds) 13.35.14 # ripnetuk: 13 points 13.35.19 # :( 13.35.24 # plus a resistor 13.35.48 # yes, i can provide a boot loader image 13.35.58 # cool 13.36.10 # but, i strongly suggest you wait a little until zagor and bagder have tried it 13.36.50 # i can help them restore their flash if anything goes wrong 13.37.06 Quit lostlogic (zelazny.freenode.net irc.freenode.net) 13.37.06 NSplit zelazny.freenode.net irc.freenode.net 13.37.08 # cool 13.37.11 # brb 13.37.17 # i want to include MiniMon in the loader before releasing it to the public 13.37.41 # much less soldering if something goes wrong 13.37.48 NHeal zelazny.freenode.net irc.freenode.net 13.37.48 NJoin lostlogic [0] (~lostlogic@node-4024215a.mdw.onnet.us.uu.net) 13.39.06 # ok 13.39.18 # i assume minimon is a little debugger that works on the serial port@? 13.39.34 # so if it went wrong we could use a max232 or similar to connect it to a pc? 13.40.26 # exactly 13.40.34 # nice 13.41.30 # well im going to build myself a cross compiler using your latest instructions then (i built one before, but that was AGES ago) 13.41.42 # are the instructions on the rockbox site up to date? 13.42.21 # you rock LinusN 13.47.30 # LinusN: FIRMWARE_OFFSET_FILE_DATA should be 8, not 6 right? 13.47.58 # or am I missing something? 13.48.45 # i am a silly person, yes it should 13.48.57 # and the crc offset should then be 0 13.49.07 # yes 13.49.16 # brain damage on my part 13.49.27 # commit mails are great for review 13.49.31 # yup 13.55.16 # i intend to start working on the new sound system today 13.55.38 # Sound system? 13.55.53 # the new architecture, to support software codecs 13.56.09 # Ah ok. 13.56.13 Join [IDC]Dragon [0] (~d90a3255@labb.contactor.se) 13.56.41 Join kurzhaarrocker [0] (~knoppix@p5487C122.dip0.t-ipconnect.de) 13.57.07 # Will that new sound system take peak-meter like info into account, Zagor? 13.57.26 # * [IDC]Dragon saw some success in the log 13.57.34 # Zagor: Btw, I think the comressed file buffering will buffer the files straight, i.e. without bitswap. Imho it would be a good idea to do the same for the hw codec boxes, doing the bitswap shortly before the data is needed, in small portions. 13.57.36 # kurzhaarrocker: no :-) 13.57.40 # <[IDC]Dragon> congrats, LinusN 13.58.18 # <[IDC]Dragon> amiconn: I think so, too 13.58.23 # amiconn: the problem with that is it requires double buffers for hw codecs too 13.58.37 # * kurzhaarrocker cries and throws the peak meter & split editor into the trashcan 13.58.40 # <[IDC]Dragon> the bitswap is a problem of the transmission 13.58.55 # <[IDC]Dragon> shoudn't affect the whole system 13.59.00 # This would be more consistent, and also allow to leave the id3 tag info within the buffer, because it won't get swapped. 13.59.20 # [IDC]Dragon: Doing this would however require a rework of video and voice ui. 13.59.26 # <[IDC]Dragon> and parse the data, to do tricks like ff/fr 13.59.27 # umm, why would we want the id3 tag in the audio buffer? 13.59.58 # Zagor: In order to get rid of the hard limit on the number of tags 14.00.17 # we still need to keep track of the songs in ram 14.01.20 # Yes, but this could be done dynamically, as a linked list 14.01.39 # ...which needs to be a fixed size, which means we have a fixed limit. 14.01.46 # No. 14.01.56 # where do you get limitless ram on the archos? 14.02.07 # <[IDC]Dragon> the list is interleaved in the mp3 buffer 14.02.30 # We need exactly *one* buffer for the tag of the currently playing track, because this one can get overwritten while the track is still playing. 14.02.32 # <[IDC]Dragon> or rather could/will be 14.03.10 # the primary question remains: why? 14.03.17 # Then we have a pointer pointing to the start of the next track. The first longword is a pointer to the next track. Then comes the tag, then the mp3 data. 14.03.50 # amiconn: so you still need a (limited) list of pointers to id3 tags? 14.03.59 # kurzhaarrocker: of course we will have a peak meter of some kind 14.04.11 # Zagor: the point of such a system would be to get rid of some fixed id3 limits 14.04.42 # but it would make it slightly tricker to get next-song info 14.04.56 # kurzhaarrocker: No. We'd need exactly *one* pointer, pointing to the tag info of the next track. This one has a poiter to the next etc. (or NULL if there is not (yet) a next track) 14.05.06 # possibly it would also be tricky when the id3 data wraps in the buffer 14.05.10 Quit mbr (zelazny.freenode.net irc.freenode.net) 14.05.10 NSplit zelazny.freenode.net irc.freenode.net 14.05.32 NHeal zelazny.freenode.net irc.freenode.net 14.05.32 NJoin mbr [0] (~mb@stz-softwaretechnik.de) 14.05.57 # Bagder: I already thought about this. We could simply set a rule that id3 tag info never wraps, i.e. if it doesn't fit at the end, wrap *before* the tag 14.06.15 # I understand, amiconn, something like a linked list only the links are generated on the fly 14.06.22 # id3 tag info is fixed size, so no problem. 14.06.49 # amiconn: if the id3 tags contain album arts etc, that could waste a good bunch of valuable ram 14.06.56 # so, we add complexity and decrease runtime. all to be able to fit >16 tracks in 2MB ram? 14.07.14 # Zagor: or 32 14.07.19 # megabytes 14.07.41 # Bagder: I didn't think about storing the tags as-is (this would really be a problem), but the tag info as currently used in rockbox. This is fixed size. 14.07.44 # iriver can have 128 id3 slots 14.07.56 # amiconn: ah, ok. I misunderstood 14.08.35 # Storing as-is would also be problematic because id3v1 is located at the end of the file, so preprocessing is necessary anyway 14.08.43 # true 14.11.05 # kurzhaarrocker: yes. When a new track gets loaded the pointer to the next is NULL at first. If then another track is loaded, the pointer of the former one gets updated to point to the newly loaded track etc. 14.12.04 # This requires walking the list once each time a new track gets loaded. This list walking is actually fairly simple 14.14.50 *** Saving seen data "./dancer.seen" 14.14.58 # Just a question... how many tracks does the current rockbox code keep in buffer? as much as needed or max 2? 14.15.55 # max 16 14.16.26 # then it becomes crazy 14.16.35 # crazy? 14.16.35 # I like amiconn's suggestion 14.16.41 # (see the bug report about the norwegian language course) 14.16.59 # but I'm not mr mpeg.c :-) 14.16.59 # crazy == it repeats every 16th song 14.17.09 # Well, 16 tracks should be enough for everyone :) 14.17.14 # Bagder: i think it costs much more than it gains 14.17.46 # "640kb should be enough for everyone" :) 14.17.51 # we still need to handle stuff like album art etc 14.18.07 # yes 14.18.22 # and that makes me a bit scared ;-) 14.19.12 # is there a lag between booking stuff into cvs and being able to book out? i wanted to have a look at the new bootloader committed at 12:51 by Linus, but is doesnt seem to be in the cvs. Ive found a bootloader dir, but (flash/bootloader) but i think thats the Archos one 14.19.20 # * [IDC]Dragon whispers "malloc" 14.19.27 # <[IDC]Dragon> and runs off 14.19.32 # ripnetuk: cvs co bootloader 14.19.32 # :) 14.19.40 # haha 14.19.49 # im doing rockbox-all does that not cover bootloader yet? 14.19.52 # thanks btw 14.19.57 # you guys seen the latest openneo commits btw? 14.20.05 # no, rockbox-all doesn't contain the boot loader 14.20.09 # Bagder: yes 14.20.15 # <[IDC]Dragon> I don't monitor it 14.20.26 # <[IDC]Dragon> what's it about? 14.20.30 # "max number of random songs buffer" 14.20.45 # ok... booked it out... thanks 14.20.45 # they have removed our shuffle 14.20.55 # and keeps a buffer of last-played songs 14.21.08 # funny choice 14.21.12 # that's amazingly silly! 14.21.13 # indeed 14.21.19 # LinusN: The album art etc should be handled the same way as now. I didn't propose to buffer the *tags* as-is, but to simply buffer the id3tag structure within the mp3 buffer instead of a separate array. 14.21.55 # but i guess they have implemented whole-disk random without playlists 14.22.03 # probably 14.22.07 # the rockbox shuffle is really, really smart! me loves it 14.22.18 # I think our shuffle rocks 14.22.35 # That's why it's called rockbox? ;-) 14.22.37 # the only thing it can't handle is whole-disk random without playlist 14.22.48 # (since Linus fixed the random) 14.23.12 # <[IDC]Dragon> we could use a more simple PRNG, though 14.23.37 # <[IDC]Dragon> gives you memory for your song buffer ;-) 14.24.00 # haha 14.24.47 Part kurzhaarrocker 14.25.03 # a faster random will be needed though 14.25.25 # needed? 14.25.27 # for dithering 14.25.42 # yeah 14.25.51 # not necessarily the same function though 14.25.57 # it can probably also be less good 14.26.03 # yes 14.26.03 # <[IDC]Dragon> amiconn has one i the grayscale bib 14.26.06 # <[IDC]Dragon> lib 14.26.12 # we could take that one 14.26.33 # i believe it's the same one bluechip have been proposing all along 14.27.20 # <[IDC]Dragon> I think it's even more simple 14.27.21 # haha 14.27.52 # LinusN, [IDC]Dragon: While the PRNG within the grayscale lib is very fast, it is certainly not good enough for shuffling. 14.31.36 # <[IDC]Dragon> I know 14.32.26 # that's why we still use the twister 14.32.28 # gotta go 14.32.31 # cu later 14.32.37 Part LinusN 14.34.04 Join ashridah [0] (ashridah@220-253-121-135.VIC.netspace.net.au) 14.36.18 # the iriver ifdef in firmware/SOURCES is not that good, imho 14.38.06 # awfully much duplication 14.38.29 # hm. iriver boot loader checked into cvs eh? complete? shell? highly explosive? 14.38.31 # but I guess this is only for now 14.40.16 # When the cross compiler instructions say book binutils out of cvs, do I need the one listed for calmRISC16? i cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/gemoss co binutils-2.15 ? or do i need a more recent version? 14.40.25 # my eyes! 14.40.40 # :) 14.40.48 Join LinusN [0] (~linus@labb.contactor.se) 14.40.56 # * ashridah tosses mad props to LinusN 14.40.59 # the SOURCES is temporary 14.41.08 # ripnetuk: that would work 14.41.21 # i just didn't like having everything checked out all the time 14.41.33 # thanks Bagder 14.41.42 # ripnetuk: when you install the binutils, use 'make -k install' 14.41.55 # the -k being the important part 14.42.09 # ok, thanks... what does -k do? 14.42.25 # at least for me, the install failed on some non-important subdir and -k makes it continue with the other install things 14.42.27 # -k tells make not to stop on errors 14.42.29 # without -k, it stops 14.42.29 # and do i need it both for the original non cvs install and the cvs one? 14.43.00 # this was for the calmrisc16 binutils from CVS the other day 14.43.15 # it may have been fixed since, I don't know 14.44.28 # ok, thanks for the heads up 14.45.50 # dammit the cvs is asking for a password when I try to check out binutils. Im doing cvs -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/gemoss login 14.46.01 # btw what is gemoss? 14.46.07 # press return only 14.46.17 # gemoss is the gmini development tools project 14.46.45 # jyp and the guys run it 14.47.08 # ok... so the binutils for that is OK for iriver then?... im pressing enter only, and getting cvs [login aborted]: end of file from server (consult above messages if any). Is this just a sourceforge crappy cvs issue? 14.47.29 # ah 14.47.36 # no that is for Gmini dev 14.48.32 # for iRiver, you need a coldfire setup 14.51.45 # which needs bintutils from the official binutils cvs ;-) 14.52.10 # I added a description ot the CrossCompiler wiki 14.52.24 # ok 14.52.33 # i will get on with building the non cvs one for now... 14.55.42 # thanks Bagder - thats checkout out (from Redhat) ok now 14.56.37 # our development environments are not the easiest accessible ones ;-) 14.56.46 # thats part of the fun 14.58.22 # binutils seems to require flex - might be worth noting on the wiki 14.58.28 # thank god for urpmi :) 14.58.49 # feel free to update 15.00.02 # * Bagder runs off 15.03.41 # Does Bagder== Daniel Stenberg? 15.06.41 # yes 15.08.26 # ok... just checking as it said the wiki was locked by him... i will go ahead anyway as he just invited me to alter it 15.08.39 # do so 15.09.26 # so has anyone else tried linusn's iriver bootloader? :) 15.10.03 # no, not yet 15.10.13 # not yet... he advised we wait until Badger tried it first, as (i assume) they live close enough to use the wiggler to fix it is it goes wrong 15.10.19 # im well tempted to just try it tho... 15.10.24 # right 15.10.53 # heh. i'm not that desparate myself. don't really have the disposable income to test yet :) 15.11.49 # yeah, me neither... 15.11.55 # * ripnetuk remembers PaulS's situation 15.12.07 # PaulS? 15.12.25 # he tried to hack the original iRiver firmware to load code from disk 15.12.47 # aah, that's right 15.12.55 # by replacing the re-flashing code in the stock firmware... it went wrong, and now he cant flash anything, (but the player works!) 15.12.57 # and managed to render it unable to flash itself again or something? 15.13.05 # that must suck :( 15.23.01 # almost there... im getting a command no not found... i assume no just returns a non-success error code... anyone help me lash up an alias that implements this? 15.23.26 # this is building the cvs binutils. The original one built and installed no probs 15.29.32 Join thegeek [0] (~formoe@g-001.osl255.netcom.no) 15.32.54 # hmm, has badger tested the bootloader yet? 15.38.08 Quit Schnueff ("leaving") 15.38.22 Part lostlogic ("Kernels are for popping") 15.47.00 Join thegeek_ [0] (~formoe@g-001.osl255.netcom.no) 15.47.05 Quit thegeek (Read error: 104 (Connection reset by peer)) 15.53.37 Quit thegeek_ () 15.58.45 Quit ashridah ("sleep") 16.02.14 # Zagor: Could you please fix the simulator issue? Otherwise I can't use the sim. The official build produces a warning, however I get a linker error. 16.03.21 # i'm not sure what the proper fix is. does win32 use stristr instead of strcasestr, or do we need to include strcasestr.c in the win32 build? 16.04.14 # (unrelated: check out this player with user-swappable 2.5" harddrive. http://www.dapreview.net/comment.php?comment.news.991) 16.04.34 # looks fragile 16.09.20 Join thegeek [0] (~thegeek@g-001.osl255.netcom.no) 16.09.43 # thegeek: no, nobody other than linus has tested the bootloader yet 16.09.56 # kk:) 16.10.06 # I'll probably wait a little then;) 16.10.31 # great work btw LinusN:) 16.11.15 # Zagor: Btw, same problem with building the X11 sim on cygwin (linker error). 16.11.38 # cygwin is weird :) 16.13.35 # neuros pocketplayer will support WMA+DRM, *and* be open source. wanna bet not all source will be open...? 16.14.21 # dapreview makes your head spin. so many new player models every week! 16.14.53 # amiconn: since I don't run cygwin, could you help me fix this? 16.14.54 *** Saving seen data "./dancer.seen" 16.16.05 # No stristr() either. I searched all .h files included with cygwin 16.19.15 # Gotta go, cu l8er 16.19.17 # i guess the win32 simulator will have to include the strcasestr.c file then 16.19.38 # I think so too. 16.19.54 # Not only the Win32 sim, but all simulator builds on cygwin 16.20.10 # yes 16.20.14 # annoying :-( 16.21.41 # perhaps all sims could use our own strcasestr then 16.22.19 # it isn't a very standard function 16.22.42 # yeah, that's the easiest solution 16.26.24 # <[IDC]Dragon> I'm looking into hotswap again 16.26.31 # * ripnetuk has my cross compiler for m68k built with cvs and all :) 16.26.45 # <[IDC]Dragon> seems the file code needs only little additions 16.26.48 Quit thegeek () 16.27.19 # <[IDC]Dragon> most of the api functions are bailing out if the file is marked as not busy 16.28.10 Join El_Barto2 [0] (firecreepe@www.e-spirit.de) 16.28.13 # Hi! 16.28.26 # what do you think of the gimini 120? 16.28.28 # <[IDC]Dragon> so, I'd only need a function to set all file/dir handles on a geven volume to not busy 16.28.43 # <[IDC]Dragon> s/geven/given 16.28.44 # do you think its better than a jukebox recorder 20? 16.29.06 # cause there is no alternative soft.. 16.29.24 # <[IDC]Dragon> how would you call such a function? 16.29.58 # [IDC]Dragon: release_files() perhaps? 16.30.08 # El_Barto2: gmini support is being added to rockbox. 16.30.24 # so its a better choice right? 16.30.25 # <[IDC]Dragon> and release_dirs() 16.30.34 # an cheeper.. 16.31.32 # <[IDC]Dragon> the busy flag may have a reenty problem 16.31.47 # El_Barto2: better is a matter of opinion. they are different. 16.31.48 # <[IDC]Dragon> but I'll save that for later ;-) 16.32.14 # hmm 16.32.27 # can i charge it through usb? 16.33.08 # Linus - I just got the iRiver rockbox built, but it built very quick... is it just a shell at the moment? i ended up with a rockbox.bin of size 6718 and rockbox.elf of size 42320 16.33.12 # <[IDC]Dragon> actually, the whole file/open closy handle code must not be reentered, as of now 16.34.02 # <[IDC]Dragon> s/closy/close 16.34.10 # * [IDC]Dragon types weird 16.35.13 # yes, but we have only very few short windows of potential reentrance. although of course it should be fixed anyway. 16.36.26 # <[IDC]Dragon> I don't know if there is a window 16.36.41 # <[IDC]Dragon> only if we sleep inbetween 16.36.57 Quit Shulberry () 16.37.07 # do you know some practival advantage of the gimini 120? 16.37.15 # practical 16.37.28 # vs jukebox recorder 20 ;) 16.37.42 # <[IDC]Dragon> El_Barto2: this is rockbox *developer* IRC 16.37.43 # or disadvantages.. 16.37.48 # ok :) 16.37.52 # sorry 16.38.09 # so where can i find the rockbox soft for the gimini? 16.38.16 # [IDC]Dragon: you're right, since the fat driver is now mutexed 16.38.34 # El_Barto2: it's not available yet. it's work in progress. 16.38.41 # <[IDC]Dragon> only the caching, no more 16.38.59 # [IDC]Dragon: ok, then there's probably a window left open. 16.40.13 # ok..i'll wait ;) 16.40.26 # but what mp3 player would you prefer? 16.48.21 # bagder - i didnt need the -k when installing the cvs binutils - i can now build m68 binaries on my Linux box :) cant get the bootloader compiled (maybe just as well as the temptation is so strong to try it!) 16.49.36 Join Shulberry [0] (Taxi@oslo-dhcp-248-180.bluecom.no) 16.50.11 # ok...understand...i leave you alone ;) 16.50.22 # succes for the firmware! ;) 16.50.23 # cu 16.50.29 # success 16.50.31 Quit El_Barto2 () 16.53.10 # gotta go 16.53.12 Part Zagor 16.58.31 Join amiconn_ [0] (~jens@pD9E7EDE2.dip.t-dialin.net) 17.09.54 Join mecraw [0] (~mecraw@69.2.235.2) 17.11.30 # can any c compentent person give me a clue please? im trying to build LinusN's new bootloader - the directory I checked out has a main.c, Makefile and sources in it. I cant figure out how to get it building - make gives me an error, and lookign at the makefile, it seems to rely on $FIRMDIR and soon being set, so i think its supposed to be built as part of a 'bigger' build job. Where should I put the bootloader dir to get it compiling? 17.15.54 # ripnetuk: it is not ready yet 17.15.59 # <[IDC]Dragon> I think LinusN didn't commit the full thing yet 17.16.02 Quit amiconn (Read error: 110 (Connection timed out)) 17.16.02 Nick amiconn_ is now known as amiconn (~jens@pD9E7EDE2.dip.t-dialin.net) 17.16.03 # <[IDC]Dragon> ;-) 17.16.06 # the configure script is not done 17.16.43 # and i suggest that you stay away from the boot loader unless you have a bdm emulator to save you 17.16.45 Join ripnet [0] (~3e317522@labb.contactor.se) 17.16.52 # ok 17.17.12 # dammit! my linux box has crashed @ home, and i am @work :( thats the end of playijng for today :( 17.17.59 # <[IDC]Dragon> LinusN: you see how important it is not to commit the last part until fully tested 17.18.13 # :-) 17.18.19 # gotta go, cu around 17.18.30 # <[IDC]Dragon> \o/ 17.19.12 Part LinusN 17.22.30 Join ripnetuk_ [0] (~mirc@82-70-100-230.dsl.in-addr.zen.co.uk) 17.25.24 Quit ripnetuk_ (Client Quit) 17.26.17 Quit edx () 17.32.17 Quit ripnet ("CGI:IRC (Ping timeout)") 17.37.12 Join edx [0] (edx@pD9EAADC2.dip.t-dialin.net) 17.42.57 Join Spida [0] (Spida@pD9FFA40C.dip.t-dialin.net) 17.46.23 Quit Spida_ (Read error: 60 (Operation timed out)) 17.47.48 Quit Shulberry () 17.59.46 Join Atur [0] (~marc@host81-154-55-162.range81-154.btcentralplus.com) 18.14.55 *** Saving seen data "./dancer.seen" 18.16.43 Join jyp [0] (~jp@49.6-136-217.adsl.skynet.be) 18.37.58 # <[IDC]Dragon> amiconn: r u there? 18.40.27 Quit mecraw (Read error: 60 (Operation timed out)) 18.45.40 # <[IDC]Dragon> amiconn: in case you will: where should the mounting/unmounting go, into the MMC thread or into the default event handler? 19.01.43 Join Stryke` [0] (~Chairman8@24-168-110-99.si.rr.com) 19.01.59 Quit [IDC]Dragon ("CGI:IRC") 19.03.28 Quit jyp ("poof!") 19.05.14 Quit ripnetuk (Read error: 104 (Connection reset by peer)) 19.29.34 Join R3nTiL [0] (~zorroz@83.69.98.116) 19.33.23 Quit Stryke` (Read error: 60 (Operation timed out)) 19.50.44 Join preglow [0] (thomj@s183a.studby.ntnu.no) 20.02.49 Quit elinenbe (" HydraIRC -> http://www.hydrairc.com <- :P") 20.04.12 # so, this bootloader is more or less finished and ready for use? 20.10.39 Quit R3nTiL () 20.14.57 *** Saving seen data "./dancer.seen" 20.21.11 Join Bluechip [0] (~BlueChip@cpc3-colc1-3-0-cust61.colc.cable.ntl.com) 20.23.48 Join Stryke` [0] (~Chairman8@24-168-110-99.si.rr.com) 20.25.04 Join webguest25 [0] (~52edd80b@labb.contactor.se) 20.25.35 Quit webguest25 (Client Quit) 20.31.23 Quit Stryke` ("Friends don't let friends listen to Anti-Flag") 20.33.18 Join webguest13 [0] (~51a815ab@labb.contactor.se) 20.36.28 Join jyp [0] (~jp@49.6-136-217.adsl.skynet.be) 20.46.03 Join jyp_ [0] (~jp@49.6-136-217.adsl.skynet.be) 20.47.27 Quit jyp ("poof!") 20.47.57 Nick jyp_ is now known as jyp (~jp@49.6-136-217.adsl.skynet.be) 20.58.19 Join [IDC]Dragon [0] (~Joerg@pD9E34183.dip.t-dialin.net) 20.59.27 # are there any never versions of the m68k tools out somewhere? mine seems to puke on crt0.S 21.00.49 Part Bluechip 21.23.00 # hi again [IDC]Dragon 21.23.09 # <[IDC]Dragon> hi there 21.23.37 # <[IDC]Dragon> did you see my msg? 21.23.42 # Got your question - I think the mount/unmount should not rely on the foreground thread calling the event handler. 21.24.28 # <[IDC]Dragon> true, it may "eat" it 21.24.49 # <[IDC]Dragon> but I need the event hdl. to return nonzero 21.24.57 # ..or be called way later, when another MMC is already inserted.. 21.25.15 # Why? 21.25.30 # <[IDC]Dragon> perhaps not... 21.25.47 # <[IDC]Dragon> to have the file tree react on it 21.25.55 # Btw., there is no MMC thread. The MMC driver only uses a tick task. 21.26.25 # <[IDC]Dragon> oh, so this is irq context? 21.26.41 # <[IDC]Dragon> then I can't unmount/mount there 21.27.04 # Yeps. In addition, only short actions should be done there. 21.27.22 # We may have to resurrect the thread... 21.27.47 # <[IDC]Dragon> I think so, or even both 21.29.31 # Perhaps the resurrected mmc thread should react on SYS_MMC_INSERTED/SYS_USB_EXTRACTED, do the mount/ unmount, and broadcast a message itself after doing that. 21.30.03 # <[IDC]Dragon> a separate one? 21.30.19 # <[IDC]Dragon> to be sure there's no race? 21.30.34 # <[IDC]Dragon> of mount vs. redraw 21.30.34 # Something like SYS_FS_CHANGED, to trigger a tree reload (and a dir change to the root if necessary) 21.31.44 # <[IDC]Dragon> sounds reasonable 21.32.11 # Maybe the SYS_MMC_* messages shouldn't be global. This could be done if the queue functions allow posting to a specific queue which is not ours (the USB thread needs them) 21.33.24 # Hmm, our own thread will also need these messages, so we'd have to post to 2 specific queues. 21.35.38 # <[IDC]Dragon> what's bad about global? 21.37.09 # Well, it's not that bad. We inform many threads about MMC changes which simply don't need the info. 21.37.24 # "many" < 10 here 21.42.00 # I'm currently doing runtime tests on Ondio with a modified battery_test plugin. The first test (900 mAh NiMHs) ran for 12 hours. 21.42.22 # Currently I'm sacrificing a fresh set of alkalines... 21.43.56 # <[IDC]Dragon> ohh 21.44.14 # <[IDC]Dragon> my Ondio has a terrible runtime now 21.44.21 # Well, cheap ones from Plus (€ 1.89 for 8 batteries) 21.44.25 # <[IDC]Dragon> I've messed with the backlight 21.44.39 # <[IDC]Dragon> which takes ~160 mA now 21.44.45 # Oops! 21.45.00 # What did you do? 21.45.06 # <[IDC]Dragon> no improvement over the ~40 mA 21.45.22 # <[IDC]Dragon> different coil different capacitor 21.45.40 # <[IDC]Dragon> and it's noisy! 21.46.12 # <[IDC]Dragon> lesson learned: no ceramic caps for such, they work as piezos 21.46.33 # Couldn't you undo the change? 21.46.53 # <[IDC]Dragon> it wasn't perfect before, either 21.47.05 # <[IDC]Dragon> I have some foil caps on order 21.47.18 # <[IDC]Dragon> will change again when I get them 21.47.31 # Ok, I understand. 21.47.50 # 900 mAh NiMHs are nice :) 21.47.56 # <[IDC]Dragon> away for some minutes 22.08.29 Join [IDC]Dragon2 [0] (~idc-drago@pD9E34183.dip.t-dialin.net) 22.14.59 *** Saving seen data "./dancer.seen" 22.17.02 Quit [IDC]Dragon (Read error: 60 (Operation timed out)) 22.17.54 Nick [IDC]Dragon2 is now known as [IDC]Dragon (~idc-drago@pD9E34183.dip.t-dialin.net) 22.34.45 Quit webguest13 ("CGI:IRC (EOF)") 22.43.18 Quit [IDC]Dragon (Read error: 60 (Operation timed out)) 22.46.46 Join mecraw [0] (~mecraw@69.2.235.2) 22.48.21 # preglow: you built the binutils from cvs? 22.48.32 # no, i did not, that explains it 22.48.53 # I added the cvs info to the wiki page earlier today 22.51.22 # really? what page? 22.51.44 # http://www.rockbox.org/twiki/bin/view/Main/CrossCompiler 22.52.24 # that is, the info about building the CVS version was already there, I just added the exact cvs command lines needed 22.53.46 # so i really need to build my own tools from cvs? 22.53.56 # yes 22.54.12 # ait, i'll do that then 22.54.20 # what will be simpler building under, cygwin or linux? 22.54.37 # I think the process is identical 22.54.54 # yes, sure, i'm just not familiar with home completely unix like cygwin is, i just installed it 22.54.56 # I personally would use linux 22.54.59 # have been using mingw up until now 22.55.11 # yes, i think i'll use linux as well 22.57.25 Quit gromit` (Read error: 54 (Connection reset by peer)) 22.57.40 Join gromit` [0] (~gromit`@ras75-5-82-234-244-69.fbx.proxad.net) 22.58.25 # has anyone apart from linus himself tried the bootloader, btw? 22.58.38 # I don't think so 22.58.47 # I was expecting some kind of docs first 22.59.01 # i'm way too eager for my own good 22.59.16 # setting up a dev env is good anyway 23.01.13 Join [IDC]Dragon [0] (~idc-drago@pD9512C24.dip.t-dialin.net) 23.01.21 # apart from cvs the build process as described is accurate? 23.01.35 # yes 23.01.45 # its the same for all the cross compilers 23.01.55 # just different targets 23.02.36 # <[IDC]Dragon> amiconn? 23.02.54 # Here :) 23.03.07 # <[IDC]Dragon> I guess I have to avoid trying mout/unmount in USB mode ;-/ 23.03.40 # Of course. The MMC thread must do the same as the ata thread for the jukeboxes 23.04.16 # ...acknowledge USB and then wait until USB is extracted again, ignoring any SYS_MMC* events meanwhile 23.04.26 # * [IDC]Dragon looks how it does 23.05.11 # I plotted my first NiMH discharge curve now. There is a strange "jump" in it. 23.06.11 # Perhaps this is caused by the LTC3440 changing its switching mode 23.06.30 # <[IDC]Dragon> ah, maybe 23.09.28 # i like this, configure actually writes a makefile, but it contains syntax errors 23.10.53 # [IDC]Dragon: http://amiconn.dyndns.org/NiMH900mAh.png 23.10.58 Quit Atur (Remote closed the connection) 23.11.30 # <[IDC]Dragon> looks nice 23.11.43 # <[IDC]Dragon> if you smoothen it a bit 23.12.40 # <[IDC]Dragon> low level code for hotswap is ready 23.13.00 # <[IDC]Dragon> now I need to teach tree.c what to do 23.13.10 # <[IDC]Dragon> or. filetree.c 23.14.03 # Well, basically filetree.c needs to react on a fs_change message in 2 cases: 23.14.31 # (1) If currently in the root, reload the root to reflect the change. 23.15.11 # (2) If currently in a sub-dir that was on the removed MMC, jump back to the root 23.15.13 # <[IDC]Dragon> yes, that's clear 23.15.41 # Otherwise no action is required 23.16.53 # The default event handler should return nonzero for the fs change message. It doesn't need to do anything 23.16.58 # ..itself 23.17.16 # <[IDC]Dragon> how about the callback? 23.17.17 Join lImbus [0] (lImbus@218-58.244.81.adsl.skynet.be) 23.17.23 # moin moin 23.17.53 # hi 23.19.04 # <[IDC]Dragon> SYS_FS_CHANGED could be handled like a button, why bother the default handler? 23.19.21 # I just wanted to suggest the same :) 23.19.47 # I think there is no default action for fs change, it depends on the context 23.20.09 # filetree.c might be the only one actually interested in this event. 23.20.20 # <[IDC]Dragon> the UI part ii in tree.c 23.20.26 # <[IDC]Dragon> s/ii/is 23.20.38 # <[IDC]Dragon> which makes it hairy 23.20.45 # Perhaps an upcoming norton commander plugin could use it too 23.20.52 # <[IDC]Dragon> it's shared with the db browsing 23.21.04 # <[IDC]Dragon> Zagor, help! 23.22.58 # Bagder: yes, seems linux will be the way to go for me 23.29.20 # [IDC]Dragon: There is a "bool id3db" in dirbrowse() 23.30.26 # all i need to pull from cvs is binutils, yes? 23.30.34 # yes 23.30.41 # <[IDC]Dragon> amiconn: thanks 23.30.42 Join Zagor [242] (foobar@h254n2fls31o265.telia.com) 23.30.46 # you called? 23.30.59 # <[IDC]Dragon> Jini out of the bottle 23.31.01 # :D 23.31.06 # preglow: but that's quite a lot ;-) 23.31.25 # Zagor: I just need that script ^^ 23.31.34 # [IDC]Dragon: Either our alkaline discharge is totally off, or my Ondio has a different battery scale factor than yours. It's now running for >4 hours, but still showing 91% battery 23.31.42 # <[IDC]Dragon> Zagor: as you may have seen, I "only" have to make the browser react on a new sys message 23.31.46 Join Atur [0] (~marc@host81-154-55-162.range81-154.btcentralplus.com) 23.32.02 Join mecraw_ [0] (~mecraw@69.2.235.2) 23.32.07 # <[IDC]Dragon> amiconn: that curve was from a textbook 23.32.12 # [IDC]Dragon: right. that should be tree.c. file- and dbtree don't read sys messages 23.32.14 # <[IDC]Dragon> no real measurement 23.32.35 # <[IDC]Dragon> btw, hotswap works! 23.32.50 # cool! 23.33.07 # [IDC]Dragon: Yes, I read that comment. I'll compare Ondio voltage display with multimeter after the alkaline test finishes. 23.34.05 # Bagder: i completely missed the step about first installing binutils 2.15, is it important? 23.34.13 # I don't know 23.34.20 # I don't see why that would be needed 23.34.21 # Zagor: So tree.c needs to react on that event under the conditions mentioned, plus only if it's in file browse mode. 23.34.23 # [IDC]Dragon: isn't it just a question of adding an elseif after tree.c:1087 23.34.28 # nor do i, so i ignore it 23.34.40 # preglow: try without it, and let's see what happens! ;-) 23.35.22 # and both gcc 3.3.4 and 3.4.2 is mentioned, which should i use? i think i read that gcc 3.3.x produces more compact code somewhere 23.35.41 # Zagor: I think another case: before line 1078 would be more appropriate (#ifdef'ed MMC) 23.36.14 # amiconn: yeah, i agree 23.36.31 # <[IDC]Dragon> there's a HAVE_HOTSWAP now 23.36.58 # preglow: get the latest, I'd say. that 3.3.x note is most important for the SH 23.37.15 # [IDC]Dragon: Prepared for a future SATA hotswap player ;-) 23.37.30 # <[IDC]Dragon> the gmini can do that 23.37.47 # <[IDC]Dragon> it has a CF slot 23.38.19 # Ah, yes 23.38.38 # gcc 4.0 it is :P 23.38.57 Quit mecraw (Read error: 60 (Operation timed out)) 23.39.36 # Zagor: There is still a warning about implicit declaration for the win32 sims. 23.40.02 # <[IDC]Dragon> a button code has the disadvantage that it can't carry data 23.40.18 # yes, i didn't have time to make the complete fix this afternoon. 23.40.24 # I didn't have a good idea how to solve this. Including our own string.h instead of the system's string.h wouldn't be a good idea imho. 23.40.48 # <[IDC]Dragon> in general, it would be good to carry the information which part of the f/s has changed 23.41.39 # amiconn: no, we need to declare it separately somewhere else. i couldn't make up my mind about what a good place was before I had to go 23.41.47 # Zagor: Then the endianess problem with cygwin is also still there 23.43.58 # i need help with cygwin-specific problems. i only rarely run win32. 23.44.09 Join amiconn_ [0] (~jens@pD9E7E57E.dip.t-dialin.net) 23.44.45 # Ooops, disconnected by accidentally switching off the UPS 23.45.00 Quit amiconn (Nick collision from services.) 23.45.01 Nick amiconn_ is now known as amiconn (~jens@pD9E7E57E.dip.t-dialin.net) 23.45.33 # Zagor: I could do some tests. 23.45.58 # <[IDC]Dragon> tree.c insiders: how do I force a redraw from within? 23.46.52 # Zagor: Cygwin defines neither LITTLE_ENDIAN nor BIG_ENDIAN (of course), and also no __LITTLE_ENDIAN__ or BYTE_ORDER. 23.47.01 # <[IDC]Dragon> ok, set reload_dir = true; 23.47.19 # There are only symbols like _X86_ 23.47.46 # I tested a simple kludge in dbtree.c: 23.47.51 # [IDC]Dragon: you might want to make that reload_root instead, otherwise it may fail (if the new card doesn't have the current directory) 23.48.16 # #if !dfefined(LITTLE_ENDIAN) && defned(_X86_) 23.48.21 Quit methangas (" HydraIRC -> http://www.hydrairc.com <- :P") 23.48.22 # #define LITTLE_ENDIAN 23.48.24 # #endif 23.48.28 # <[IDC]Dragon> yeah, finding that out is the advanced version 23.49.30 # However, this does only help for building the X11 sim under cygwin, because for building the Win32 sim, cygwin has no netinet/in.h in that mode 23.50.04 # * amiconn can't type 23.55.19 # <[IDC]Dragon> hehe, this is cool 23.55.27 # ?? 23.55.36 # <[IDC]Dragon> to see come and go 23.55.57 # Ah :) 23.56.19 # Can't test atm, I don't want to have wasted a set of alkalines for no reason. 23.56.38 # <[IDC]Dragon> you said so, yes 23.56.48 # <[IDC]Dragon> "no reason" ;-)