| 07:23:53 | florian | hello! |
| 07:36:12 | colin_werk | Hi florian |
| 09:49:33 | mallum | hey |
| 09:49:37 | pb_ | yo mallum |
| 09:49:53 | mallum | pb_: just ( hopefully ) got through boot floppy hell |
| 09:50:11 | mallum | pb_: went down dalston high street and they wanted 2 quid a floppy disk !!! |
| 09:51:47 | pb_ | mallum: !! |
| 09:51:54 | pb_ | mallum: still, I guess there isn't much demand for floppies these days. |
| 09:52:20 | mallum | yeah I managed to get a box of 10 for a fiver which more reasonable |
| 09:52:53 | mallum | then I had the pain of wasting 50% by trying to get them dd'd right |
| 09:54:42 | pb_ | ah. |
| 09:54:54 | pb_ | you managed to make some bootable disks in the end though? |
| 09:56:49 | mallum | yeah, in the end |
| 10:44:14 | spung_ | pb_: what exactly does event_db_list_destroy(); do? does it free() the memory the event_t's use? |
| 10:44:56 | pb_ | I don't remember offhand; I would have to check the code. I suspect the answer is probably no: it just frees the list, not the events in it. |
| 10:45:16 | spung_ | pb_: how do I free the events? with a simple free() ? |
| 10:45:39 | spung_ | (ahrg, I don't want memory leaks in my code!!) |
| 10:46:12 | pb_ | event_db_destroy (event_t); |
| 10:46:23 | spung_ | cool |
| 10:46:49 | spung_ | pb_: btw, i'm sorry gpe-today isn't coming along as fast as we all wished |
| 10:47:24 | pb_ | yeah, I checked the code, event_db_list_destroy only frees the list itself. It's actually just a wrapper round g_slist_free. |
| 10:47:39 | pb_ | spung_: well, it's good that you are working on it again now. |
| 10:59:17 | pb_ | did you succeed in setting up your SSH key, by the way? |
| 11:10:19 | spung_ | pb_: yes |
| 11:11:01 | spung_ | pb_: just fixing some ugly bugs with "orphan" memory that didn't show up until i added the g_timeout_add() function |
| 11:11:05 | spung_ | :\ |
| 11:11:10 | spung_ | efence rules, btw |
| 11:42:27 | grib | memprof's pretty good too |
| 11:42:29 | mallum | pb_: just uplaoded a fixed matchbox package with xsettings to my experimental |
| 11:42:58 | mallum | grib: what do I have to compile with to gte memprof to show me the function calls ? |
| 11:54:24 | grib | mallum: I think if you just build with -g it will DTRT |
| 11:56:14 | mallum | grib: okey, will try |
| 12:14:14 | mallum | pb_: hmm my 200mhz powerpc gives 399 bogomips, whilst my 200Mhz Arm only gives 151 - why is that ? |
| 12:18:39 | moray | mallum: I don't recall what the bogomips loop does precisely, but it would just suggest that pipelining etc. means your ARM isn't dealing well with a tight loop? |
| 12:19:00 | moray | whereas the PowerPC would be doing the correct branch prediction and not having a problem? |
| 12:19:17 | moray | certainly that seems a possible explanation, though I don't know if it's what's actually going on |
| 12:19:35 | moray | the bogomips loop is not meant to be optimised anyway, given it's there for timing... |
| 12:19:49 | PaxAnima | http://www.tldp.org/HOWTO/mini/BogoMips-2.html#ss2.1 |
| 12:20:10 | PaxAnima | moray: yup |
| 12:20:48 | mallum | hmm, this mac seems pretty fast , definetly faster than a 200mhz pentium |
| 12:22:34 | PaxAnima | the bogomips rating for my 2,26ghz P4 is 4561.30 |
| 12:22:36 | PaxAnima | ;) |
| 12:22:43 | moray | that's probably true, yes - mac people still mutter 'it's not just about clock speed' etc. (without always mentioning the unfortunate fact that while that's true, if you have *enough* clock speed...) |
| 12:23:33 | mallum | PaxAnima: wow, I have nothing neer that :( |
| 12:24:35 | PaxAnima | but then again, it's not a good benchmark or anything scientific about it... |
| 12:24:59 | mallum | yeah as Im reading .... always wondered what is actually meant |
| 12:26:14 | pb_ | mallum: it doesn't really mean anything. The bogomips number is just a measure of how quickly the cpu can spin round a particular loop; it's used by stuff like udelay() to figure out how many loop iterations are required there. |
| 12:26:53 | pb_ | mallum: it can change from one version of the kernel to another; there was certainly a time when ARM machines used to get about twice the bogomips score they do now. |
| 14:12:56 | grib | pb_: gpe-login 0.29 fixed my groups problems. Thanks so much! |
| 14:46:17 | mallum | pb_: new xkbd and figment in unstable |
| 14:48:23 | cmarqu_ | goes to install it |
| 15:06:52 | mallum | cmarqu_: did they work for you ? |
| 15:08:09 | cmarqu_ | Still trying. |
| 15:11:40 | cmarqu_ | xkbd works, figment got killed with by the kernel (OOM) |
| 15:14:33 | cmarqu_ | BTW, would running apps with nohup incur any penalty? |
| 15:15:01 | cmarqu_ | Point is, if the kernel kills gpe-appmgr because of OOM, apps started from it won't get killed too |
| 15:16:42 | moray | cmarqu_: there's some gnome-exec code around that goes through the necessary contortions to fix that |
| 15:17:34 | moray | I thought appmgr was meant to be using that actually? (though I may well be remembering wrong) |
| 15:18:15 | cmarqu_ | Well, it might be that the kernel killed both gpe-appmgr and gpe-nmf for me yesterday, at the same time |
| 15:18:20 | cmarqu_ | I'll ask mibus |
| 15:34:26 | PaxAnima | why does the kernel kill apps? |
| 15:37:16 | moray | PaxAnima: when it runs out of memory, rather than just giving up and stopping |
| 15:37:24 | PaxAnima | oh... |
| 15:37:55 | moray | PaxAnima: the current Linux memory allocation system overallocates - if you ask for memory you get told you can have it, and it's only if you actually *use* it all that there's a problem |
| 15:38:27 | moray | PaxAnima: so malloc() never fails, but if there's a problem the kernel has to work out what to kill |
| 15:39:05 | moray | PaxAnima: it doesn't make sense just to kill whatever made the most recent access (that might be init, e.g...) so it has some heuristics about this, which have been changed from time to time... |
| 15:39:42 | PaxAnima | ok.. think it happend to my old old pc once.. forgot to turn the swap on or something and suddenly the system killed processes like a mad man... |
| 15:40:25 | moray | in general the idea is obviously that you have enough swap that you do never run out of memory in normal usage - obviously if things go very wrong you will do, but then things would go wrong however much memory you had, eventually |
| 15:41:03 | PaxAnima | funny to think that the spec was sorta similar to my ipaq: 200mhz cpu (Amd K6) and 64mbs of RAM... |
| 15:42:27 | moray | PaxAnima: I had a laptop I installed Linux on (not for my own use ;) that was a 4 MB 486 (/33 maybe?) |
| 15:44:15 | pb_ | mallum: cool |
| 15:44:22 | pb_ | grib: cool |
| 15:45:36 | mallum | PaxAnima: yeah but rememebr the ipaq has no swap |
| 15:46:22 | PaxAnima | mallum: no.. |
| 15:46:47 | PaxAnima | ... but I don't run the same apps.. |
| 15:52:21 | mallum | damn kernel is taking forver to compile :( |
| 15:53:02 | nils | mallum: Where (do you compile)? On CATS? Native? That really *hurts* ... hours later ... :) |
| 15:55:23 | mallum | nils: Native on CATS |
| 15:55:30 | mallum | nils: this compile is on powerpc thouhg |
| 15:56:02 | PaxAnima | what's CATS? |
| 15:56:44 | mallum | PaxAnima: an sa110 based motherboard |
| 15:56:55 | mallum | PaxAnima: that has a pci and isa bus |
| 15:57:05 | PaxAnima | oh.. |
| 15:57:53 | mallum | PaxAnima: basically a desktop ipaq :)) |
| 15:59:25 | PaxAnima | heh... |
| 16:00:17 | PaxAnima | where can these be found? any URL for CATS? |
| 16:00:50 | PaxAnima | googling for CATS gives the likes of "I-Love-Cats.com - Free Stuff For Cat Lovers!" and so on.. ;) |
| 16:01:02 | mallum | simtec.co.uk |
| 16:09:04 | mallum | pb_: did you ever get a chance to look at the blackbox image code ? |
| 16:11:13 | pb_ | mallum: mm, I did download the code but I didn't really look at it. What were you having trouble with again? |
| 16:20:43 | mallum | pb_: yeah its just doing my head in :(( |
| 16:25:13 | pb_ | :-/ |
| 16:26:18 | mallum | pb_: its annoying me cos once I get this sorted out I can start AA'ing the dock apps etc |
| 16:27:10 | mallum | pb_: Im kind of half thinking I may just support 24/16/8 with this new stuff and anything lower they'll just have to compile without pngs enabled |
| 16:28:00 | mallum | pb_: but then I fear thats gonna bring a load of new problems for 3100 users etc |
| 16:30:05 | pb_ | yes. |
| 16:30:29 | pb_ | 3100 owners have a miserable enough time as it is; we probably don't want to make life any worse for them. |
| 16:31:10 | mallum | indeed |
| 16:32:05 | mallum | pb_: would you mind awfully if I mail you over my conversion so far ? |
| 16:32:20 | mallum | pb_: and just take a *quick* look at it when you have a mo .. |
| 16:33:02 | pb_ | sure, fire away. |
| 16:33:23 | pb_ | I'll probably be stuck at work for another hour or so, but I will definitely look at it later on this evening. |
| 16:34:49 | mallum | pb_: np, when ever you got a mo |
| 17:43:17 | dc__ | evening |
| 17:45:18 | cmarqu_ | Hi dc__ |
| 17:47:14 | dc__ | cmarqu_: going good? |
| 17:47:28 | cmarqu_ | So so. |
| 17:48:22 | cmarqu_ | dc__: I added Ted and Cameron as Storm developers |
| 17:48:24 | dc__ | indeed. |
| 17:48:31 | dc__ | cmarqu_: ah cool |
| 17:48:34 | mallum | hey dc__ |
| 17:48:40 | dc__ | mallum: heyy :) |
| 17:48:46 | dc__ | mallum: good too? |
| 17:48:57 | mallum | dc__: I uploaded a new xkbd with a kbdconfig.numsonly :) |
| 17:49:14 | dc__ | mallum: leet you are :D |
| 17:49:14 | cmarqu_ | dc__: You might want to give them admin status. But OTOH, they can always ask. |
| 17:49:38 | dc__ | cmarqu_: well yeah, let them have some fun hacking with the code first. |
| 18:03:42 | dc__ | yo pb_ :) |
| 18:03:49 | pb_ | dc__: hey! |
| 18:07:03 | dc__ | good day? |
| 18:07:24 | pb_ | busy, had meetings all day. |
| 18:07:48 | dc__ | :] |
| 18:08:00 | pb_ | dc__: how's things with you? |
| 18:08:50 | dc__ | pb_: alrihgt. |
| 18:09:12 | pb_ | :-} |
| 18:09:36 | pb_ | damn dabs bounced my credit card again. |
| 18:09:41 | dc__ | eeek |
| 18:09:42 | pb_ | clearly something is not quite right there. |
| 18:49:55 | pb_ | mallum: looking at your blackbox stuff now. |
| 18:50:48 | mallum | pb_: :) |
| 18:53:23 | pb_ | mallum: all seems fairly reasonable to me. |
| 18:55:03 | pb_ | mallum: at least, I get a nice colour gradient if I run your program on a truecolor display. |
| 19:01:54 | mallum | pb_: yeah, but its > tan that thats the problem :( |
| 19:02:35 | pb_ | pardon? |
| 19:05:16 | mallum | heh ;) |
| 19:05:22 | mallum | what I meant to say was |
| 19:05:30 | mallum | but it less than that, thats the problem |
| 19:05:41 | pb_ | ah :-) |
| 19:05:59 | mallum | look at all th evil that happens with psudeocolor and greyscale |
| 19:06:23 | mallum | I know its populating some look up tables etc, but its very confusing |
| 19:08:23 | pb_ | yeah |
| 19:08:33 | pb_ | it seems to be trying to set up pseudocolor to emulate truecolor. |
| 19:10:49 | pb_ | let me try it in 8bpp mode. |
| 19:11:00 | mallum | pb_: okey |
| 19:11:01 | pb_ | Invalid colormap size 0 (0/0/0) - reducingSegmentation fault |
| 19:11:02 | pb_ | :-/ |
| 19:12:57 | mallum | yep, same as greyscale |
| 19:13:29 | pb_ | I suspect you are not actually setting colors_per_channel properly. |
| 19:13:34 | mallum | I think its due to the colors per channel var |
| 19:13:45 | pb_ | in blackbox, it seems to happen in BImageControl::setColorsPerChannel |
| 19:14:19 | mallum | yeah, but I could figure out where it got the value from ... |
| 19:14:30 | pb_ | ah. |
| 19:15:57 | pb_ | hrm, it seems to just be a global in blackbox.cc. |
| 19:16:13 | pb_ | set to 4, or the value of "session.colorsPerChannel" from Xrm. |
| 19:17:25 | mallum | its wierd that its constant |
| 19:17:54 | pb_ | now I get a crash in XAllocColor, probably because the XCreateColormap call is commented out. |
| 19:19:30 | mallum | pb_: hmm, I think you may have an earlier version ... I was hacking it on my arm machine - but all I did was uncomment that call and experiment with various values of colsperchan |
| 19:23:35 | pb_ | ok. |
| 19:23:45 | pb_ | how about this bit: |
| 19:23:46 | pb_ | colormap = screeninfo->getColormap(); |
| 19:23:52 | pb_ | did you change that to something else? |
| 19:24:20 | mallum | yeah one sec |
| 19:25:13 | pb_ | well, I put in "colormap = XCreateColormap (..)" and now I do get a colour gradient (of sorts) on the pseudocolor display. |
| 19:25:27 | pb_ | however, that version blows up on truecolor: |
| 19:25:31 | pb_ | X Error of failed request: BadMatch (invalid parameter attributes) |
| 19:25:32 | pb_ | Major opcode of failed request: 78 (X_CreateColormap) |
| 19:25:32 | pb_ | Serial number of failed request: 7 |
| 19:25:32 | pb_ | Current serial number in output stream: 11 |
| 19:25:50 | mallum | pb_: I sent you my updated version |
| 19:25:56 | pb_ | cool. |
| 19:26:15 | mallum | pb_: truecolor should never need to create the colormap |
| 19:27:08 | pb_ | yeah, that's what I figured. |
| 19:29:08 | mallum | pb_: hows it look on an 8bit display ? |
| 19:29:40 | pb_ | mallum: the gradient only has 3 levels. |
| 19:30:15 | pb_ | so, not very good, but I'm not sure exactly what is expected. |
| 19:32:08 | mallum | pb_: yeah, what X server version is it running on ? |
| 19:32:48 | pb_ | 4.2.1 |
| 19:32:51 | pb_ | on my desktop |
| 19:34:11 | mallum | Hmm, I *think* that still has the 'broken' render which steels alot of the colormap that would explain only 3 levels |
| 19:34:49 | pb_ | ah. |
| 19:35:03 | pb_ | I did get a lot of "couldn't alloc color..." messages. |
| 19:43:04 | pb_ | your new version behaves the same way. |
| 19:45:12 | mallum | pb_: hmm so it appears greyscale is just the problem :-( |
| 19:46:51 | pb_ | so it does appear. |
| 19:46:58 | pb_ | what's the behaviour with greyscale? |
| 19:47:34 | pb_ | or, how can I persuade the app to select a grayscale visual so I can try it out? |
| 19:58:21 | mallum | pb_: eek, crashed X |
| 19:58:25 | pb_ | :-/ |
| 19:58:41 | pb_ | did you see the last things I said? |
| 19:58:45 | pb_ | <pb_> so it does appear. |
| 19:58:46 | pb_ | <pb_> what's the behaviour with greyscale? |
| 19:58:46 | pb_ | <pb_> or, how can I persuade the app to select a grayscale visual so I can try it out? |
| 19:58:58 | mallum | no |
| 19:59:08 | mallum | no I didn't catch that |
| 19:59:13 | pb_ | ah. well, there it is. |
| 19:59:48 | mallum | with a greyscale I just got all black :( |
| 19:59:54 | pb_ | ah. |
| 20:00:35 | mallum | can you drop you display down to 4bit ? |
| 20:00:43 | pb_ | don't think so. |
| 20:00:58 | pb_ | however, xdpyinfo reports a grayscale and staticgray visual are available at 8bpp. |
| 20:01:10 | pb_ | well, let me try 4bpp. |
| 20:01:30 | mallum | okey |
| 20:01:34 | pb_ | nope, it's not having that. |
| 20:01:38 | pb_ | (EE) NV(0): Given depth (4) is not supported by this driver |
| 20:01:43 | mallum | :( |
| 20:02:07 | dc__ | returns |
| 20:02:32 | pb_ | dc__: :-) |
| 20:02:58 | mallum | hey dc__ |
| 20:04:40 | dc__ | hum |
| 20:04:51 | dc__ | my kb come tomorrow :] |
| 20:04:53 | dc__ | joy |
| 20:05:00 | mallum | cool |
| 20:05:16 | mallum | pb_: Just trying to figure out how you select the visual ... |
| 20:05:20 | pb_ | ok. |
| 20:08:10 | mallum | pb_: I tink you use XMatchViusalInfo |
| 20:08:19 | pb_ | hmm. |
| 20:10:27 | mallum | and get the visual out of the returned structure ? |
| 20:11:10 | mallum | not returned, I mean set in the call |
| 20:11:48 | pb_ | aha |
| 20:11:51 | pb_ | just spoke to my bank |
| 20:12:16 | pb_ | apparently my credit card had been suspended due to an "unusual pattern of usage". |
| 20:12:17 | pb_ | :-/ |
| 20:12:28 | pb_ | mallum: okay, lemme take a look. |
| 20:18:14 | pb_ | argh, now I get BadMatch from XCreateWindow. |
| 20:22:15 | mallum | hmmm .... |
| 20:22:49 | mallum | maybe cos roots its parent and thats using a different visual |
| 20:23:12 | pb_ | I don't think that ought to matter. |
| 20:23:35 | pb_ | After all, if every window had to be the same visual as its parent, you couldn't use anything other than the visual the root window had. |
| 20:23:43 | mallum | yes true |
| 20:24:01 | pb_ | the manpage for XCreateWindow just says "the visual type and depth must |
| 20:24:02 | pb_ | be a combination supported for the screen, or a BadMatch error results" |
| 20:24:17 | mallum | ah I think its the last copyfromparent |
| 20:24:27 | mallum | that shoudl be the same class as the visual |
| 20:24:49 | pb_ | hmm, isn't that just InputOutput? |
| 20:25:17 | mallum | ah yes ... should have read the botttom on the man page :-) |
| 20:25:18 | pb_ | I tried passing vis->bits_per_rgb rather than copyfromparent for the depth, that didn't seem to help. |
| 20:26:21 | mallum | maybe xdpyinfo lies |
| 20:26:38 | pb_ | maybe, but it seems unlikely. |
| 20:26:54 | pb_ | I passed GrayScale to XMatchVisual and it did return the same visual that xdpyinfo mentioned. |
| 20:27:13 | pb_ | hm, I wonder if my Xlib book is in the house. |
| 20:28:22 | pb_ | aha, yes. |
| 20:28:50 | mallum | pb_: see this :: http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&threadm=CI1tBo.E9s%40unix.portal.com&rnum=3&prev=/groups%3Fq%3DXmatchvisualinfo%2Bbadmatch%26hl%3Den%26lr%3D%26ie%3DUTF-8%26selm%3DCI1tBo.E9s%2540unix.portal.com%26rnum%3D3 |
| 20:29:14 | pb_ | ah. |
| 20:29:55 | mallum | that would make sense |
| 20:30:00 | pb_ | yes. |
| 20:30:11 | pb_ | so, how do I set these border and background pixels? |
| 20:30:57 | pb_ | (though, I am running the program on a bare X server with no wm, so I wouldn't expect it to be inheriting any exotic values) |
| 20:31:37 | mallum | XSetWindowAttributes attr; |
| 20:31:47 | mallum | attr.border_pixel = 1; |
| 20:31:57 | mallum | attr.background_pixel = 1; |
| 20:32:35 | mallum | and pass CWBorderPixel|CWBackPixel in the create window call rather than NULL |
| 20:32:43 | pb_ | righto |
| 20:33:00 | mallum | Im kind of guess a value of 1 should be ok, according to that google link it defualts to None |
| 20:33:03 | pb_ | hrm, still no good. |
| 20:33:32 | mallum | soory pass &attr in rather than NULL , and the mask rather than 0 |
| 20:33:38 | pb_ | yeah, I did that. |
| 20:34:28 | pb_ | let me try a staticgray visual, just in case it behaves any different. |
| 20:34:43 | pb_ | ... nope |
| 20:35:17 | pb_ | hrm, even TrueColor fails. |
| 20:35:27 | pb_ | and DirectColor gives me "unsupported visual 5". |
| 20:37:17 | mallum | pb_: hmm, looking at the greyscale code you see anything which looks out of place ? |
| 20:37:27 | mallum | pb_: in color.c |
| 20:37:37 | pb_ | not obviously, no. |
| 20:38:14 | mallum | well at least we know 8 bit more or less works |
| 20:38:20 | pb_ | yeah. |
| 20:38:55 | pb_ | I might try grayscale again tomorrow, when I can use the matrox machine at the office. |
| 20:39:03 | mallum | okey |
| 20:39:06 | pb_ | and I have a feeling that one will do 4bpp as well. |
| 20:39:14 | mallum | aha :-) |
| 20:39:23 | pb_ | in fact, using the power of the internet, I can check that from here. |
| 20:40:06 | pb_ | ah, hm, no. |
| 20:40:11 | pb_ | (EE) MGA(0): Given depth (4) is not supported by this driver |
| 20:40:47 | pb_ | but! |
| 20:40:59 | pb_ | it looks like matroxfb can do 4bpp, so I might be able to use the fbdev driver to good effect. |
| 20:41:11 | dctanner_ | heh |
| 20:41:39 | pb_ | oh well, we'll find out tomorrow. |
| 20:42:07 | mallum | cool |
| 20:42:32 | mallum | I'll get it on the greyscale ipaq too and can debug that aswell |
| 20:42:37 | pb_ | excellent. |
| 20:43:09 | mallum | Many thanks for helping me out with this :-) |
| 20:43:14 | pb_ | sure, no problem. |
| 20:43:15 | mallum | I owe you more pints |
| 20:43:33 | pb_ | :-) |
| 20:50:28 | mallum | is my color.c the same as what you were using ? |
| 20:50:42 | mallum | nothing important changed in what you were using ? |
| 20:51:54 | mallum | pb_: interesting post to the freedesktop list |
| 21:21:03 | pb_ | mallum_tv: don't think I changed anything important. |
| 21:21:06 | pb_ | mallum_tv: which post is that? |
| 21:25:41 | pb_ | hrm, I guess I should filter xdg-list into its own mailbox. |
| 21:25:46 | dctanner_ | hum |
| 21:25:50 | dctanner_ | sits silently |
| 21:25:55 | pb_ | dctanner_: :-} |
| 21:26:11 | dc__ | lan parties to arrange, you know what it's like :) |
| 21:26:19 | pb_ | ah yes. |
| 21:26:32 | dc__ | hehe |
| 21:26:40 | dc__ | oh! |
| 21:26:44 | dc__ | half term :) |
| 21:26:48 | dc__ | gpe-gallery time |
| 21:26:53 | pb_ | oh, cool. |
| 21:26:56 | pb_ | when's half term? |
| 21:27:03 | dc__ | maybe I'll get it finished by the end of next week |
| 21:27:09 | pb_ | yay |
| 21:27:10 | dc__ | next week |
| 21:27:13 | pb_ | excellent. |
| 21:27:16 | dc__ | is my week off :) |
| 21:27:17 | pb_ | I think this week is half term around here. |
| 21:27:21 | dc__ | indeed. |
| 21:27:23 | dc__ | ah yeah |
| 21:27:44 | pb_ | at least, my boss is taking Friday off to go away with his family, which is usually a sign that the kids are off school. |
| 21:28:32 | pb_ | well, it would certainly be cool to have a working gpe-gallery. |
| 21:28:46 | dc__ | indeed. |
| 21:29:10 | pb_ | I keep thinking I should do some more work on gpe-nmf. |
| 21:29:15 | dc__ | yeah |
| 21:29:18 | dc__ | you should :) |
| 21:29:18 | dc__ | hehe |
| 21:29:27 | dc__ | I've been using my nomad lately |
| 21:29:30 | pb_ | nomad? |
| 21:29:31 | dc__ | that's a bad sign :) |
| 21:29:32 | dc__ | hehe |
| 21:29:50 | pb_ | oh, yeah. |
| 21:30:03 | dc__ | it's pretty cool |
| 21:30:10 | dc__ | works good with linux :} |
| 21:30:12 | dc__ | supprisingly |
| 21:30:13 | pb_ | cool. |
| 21:30:40 | pb_ | I need to try to figure out some way to share music between my empeg and nmf on my ipaq. |
| 21:30:48 | dc__ | ah |
| 21:30:53 | pb_ | It sucks having to encode everythign twice and maintain separate playlists. |
| 21:31:15 | pb_ | and |
| 21:31:25 | dc__ | ah yeah |
| 21:31:38 | pb_ | I keep planning to try to reuse one of the old futuretv set-top boxes as an ogg player for my hi-fi. |
| 21:31:39 | dc__ | and plus it takes ages for me to recode all my oggs to mp3 to put them onto my nomad.. |
| 21:31:41 | dc__ | hum |
| 21:31:48 | dc__ | checks the crative nomad 2 driver pages. |
| 21:31:53 | dc__ | pb_: :F |
| 21:31:55 | dc__ | cool |
| 21:32:00 | pb_ | yeah, that's the problem I have with the empeg, I don't think it does ogg. Or at least, not the software that is in mine. |
| 21:32:12 | pb_ | I guess I need to buy Hugo some pints. |
| 21:32:39 | dc__ | hehe |
| 21:32:41 | dc__ | yeah |
| 21:32:42 | pb_ | dc__: what does :F signify? forked tongue? |
| 21:33:01 | dc__ | pb_: no, simply my lack of good typing skills |
| 21:33:03 | dc__ | heh |
| 21:33:05 | pb_ | aha. |
| 21:33:22 | dc__ | drools over the ne nomad zen |
| 21:33:26 | dc__ | new |
| 21:34:02 | pb_ | oh yeah, looks neat. |
| 21:34:09 | dc__ | they don't seems to advertise the nomad players in the uk much do they..? |
| 21:34:21 | pb_ | dc__: not that I've noticed. |
| 21:34:37 | dc__ | yeah...I got mince form the us a few years ago.. |
| 21:34:41 | dc__ | or rather 2. |
| 21:34:50 | pb_ | right. |
| 21:35:22 | pb_ | amazon.co.uk don't seem to list them either. |
| 21:35:40 | pb_ | (though the US site does) |
| 21:35:53 | pb_ | mind you, that's nothing unusual. :-{ |
| 21:36:50 | dc__ | heh |
| 21:36:54 | dc__ | bugger. |
| 21:37:06 | dc__ | damn creative won't make us ogg support :{ |
| 21:37:13 | pb_ | gutted. |
| 21:37:23 | dc__ | and they even have wma |
| 21:37:30 | pb_ | yeah |
| 21:39:28 | pb_ | hrm. |
| 21:39:34 | pb_ | http://slashdot.org/comments.pl?sid=42350&cid=4453444 |
| 21:43:48 | dc__ | heh |
| 21:43:51 | dc__ | suck |
| 21:43:55 | pb_ | yes. |
| 21:44:17 | dc__ | now if only we could hack apart the frimware :) |
| 21:44:32 | dc__ | but after I sleep :) |
| 21:44:33 | dc__ | night |
| 21:44:35 | pb_ | heh |
| 21:44:37 | pb_ | night |
| 21:45:04 | dc__ | yep, have a nice evening pb_ :) |