| 00:00.05 | PaxAnima | moray: yes.. that's what the "cycle" thing is: suggest more words |
| 00:00.07 | mallum | ------------------------ |
| 00:00.25 | mallum | | be bean beee beetle beaker | |
| 00:00.30 | mallum | ------------------------------------ |
| 00:00.32 | moray | mallum: although eventually for the UI it might be better if it appeared as part of the same app as the keyboard/whatever |
| 00:00.36 | mallum | kind of thing |
| 00:00.44 | moray | mallum: yup, I think that will be fairly obvious to users |
| 00:01.06 | mallum | moray: well I dlike to make it a seperate app so it'd work with any input mechanism |
| 00:01.07 | moray | mallum: although presumably they won't necessarily be in alphabetical order, if (say) bed is thought far more likely |
| 00:01.20 | mallum | moray: yeah alphabetical |
| 00:02.06 | mallum | moray: eg you could use it with xstroke, your upcoming thingy, xkbd etc |
| 00:02.16 | moray | mallum: I think PaxAnima's 'dynamic' dictionary tries to guess what you're most likely to mean |
| 00:02.36 | moray | mallum: indeed - although with the thing I am (may be) working on, I'd need closer integration with the dictionary really |
| 00:02.39 | mallum | okey all I need is a func that does something like |
| 00:02.56 | PaxAnima | moray: yes.. as you type words, they are added to the dynamic dictionary, which has higher precence when trying to complete words |
| 00:03.05 | PaxAnima | precedence |
| 00:03.06 | mallum | char **get_possible_words(char *chars_so_far) |
| 00:03.20 | moray | (since with handwriting you need a dictionary to try to work out what letters they might be trying to write in the first place) |
| 00:03.41 | moray | mallum: might be better as an iterator? |
| 00:03.56 | moray | mallum: i.e. it returns back some token, which you can pass to future calls to get more words |
| 00:04.06 | moray | mallum: so it just gave one word at a time |
| 00:04.21 | moray | mallum: otherwise it'll have to work out some huge number of words unnecessarily |
| 00:04.45 | PaxAnima | mallum: the way it works now: char* predict_word( char* word_so_far), char* predict_word_cycle() gives you the next possible word |
| 00:04.56 | mallum | moray: probably something like; |
| 00:04.56 | PaxAnima | mallum: so adding a get_possible_words should be a simple task |
| 00:04.56 | mallum | Bool get_possible_words(char *chars_so_far, struct *possible_completions_t) |
| 00:05.46 | moray | PaxAnima: how does your _cycle function know where to start from...? |
| 00:07.05 | moray | mallum: think when you've just typed the first letter of a word - you're almost certainly going to want to write more letters rather than scroll through all the possible completions, and there are going to be a huge number of completions, so it's not worth the dictionary working them all out in advance. since there's a defined order it can easily work out more words if you do want them |
| 00:10.46 | *** join/#gpe Aviator (dsm29@student.cusu.cam.ac.uk) |
| 00:17.19 | *** join/#gpe PaxAnima (~petter@v058b.studby.ntnu.no) [NETSPLIT VICTIM] |
| 00:17.44 | PaxAnima | stupid net |
| 00:17.58 | PaxAnima | moray_: still around? |
| 00:19.46 | *** join/#gpe PaxAnima_ (~petter@v058b.studby.ntnu.no) |
| 00:19.53 | moray | PaxAnima: hi |
| 00:20.28 | PaxAnima | hi |
| 00:20.37 | *** part/#gpe PaxAnima_ (~petter@v058b.studby.ntnu.no) |
| 00:20.56 | PaxAnima | moray: what did you and mallum discuss after I disconnected? |
| 00:21.10 | moray | PaxAnima: mallum got kicked off as well |
| 00:21.23 | PaxAnima | ah |
| 00:21.28 | moray | (and hasn't reappeared apparently) |
| 00:21.46 | PaxAnima | ok |
| 00:22.48 | PaxAnima | as for the dock app, I'm not sure what would be the best way: as mallum suggests or as it works in gpe-irc: single word prediction, with the possibility to cycle through words |
| 00:23.07 | moray | PaxAnima: I was just asking, how does your predict_word_cycle () know where to start looking from - is there some parameter? |
| 00:23.44 | moray | PaxAnima: I think that for the toolbar (dock) UI, it's probably worth showing more than one word given that there's enough screen space |
| 00:23.44 | *** join/#gpe FlyPiper (~ISP-1@12-222-141-210.client.insightBB.com) [NETSPLIT VICTIM] |
| 00:24.12 | PaxAnima | moray: the dictionary keeps a copy of the last word that is to be completed and the position, so it knows where to start for the next word |
| 00:24.15 | moray | PaxAnima: you can click on the appropriate word to get it immediately |
| 00:24.28 | PaxAnima | yeah, I think that would be best |
| 00:24.44 | moray | PaxAnima: ergh, I think that's probably not that nice, think what happens when the app does more than one word lookup at once? |
| 00:25.00 | PaxAnima | moray: how "more than one word"? |
| 00:25.12 | moray | PaxAnima: can't you have the app be returned / pass back the last word/position ? |
| 00:25.46 | moray | PaxAnima: so you'd have position = predict_word (sofar, position); , starting off with position = NULL ? |
| 00:26.22 | pb_ | indeed, that would seem better. |
| 00:26.32 | *** join/#gpe gdsx (xsdg@xsdg.staff.freenode) |
| 00:26.43 | PaxAnima | moray: don't quite follow you |
| 00:27.30 | moray | PaxAnima: basically, it would be nicer to put your current global record of what you've done so far into a struct, which is held in application memory |
| 00:28.12 | PaxAnima | I kinda lied about the word cycle: it currently done in the same function as the prediction; predict_word has a boolean argument as well for wheter or not it should try to cycle to the next word |
| 00:28.51 | PaxAnima | moray: well, that's whats done.. the data is stored in the Dictionary struct... |
| 00:28.56 | moray | PaxAnima: my example above was if some application wanted to have more than one input field going at once, both using word prediction - with your current system it would appear that lookups for one item would confuse the library state and stop the other from working? |
| 00:29.20 | PaxAnima | it's not predict_word( char* word ), it's predict_word( Dictionary* dict, char* word) |
| 00:29.20 | moray | PaxAnima: but that struct is currently global? (it is, from the information you've given us so far) |
| 00:29.29 | PaxAnima | it was implied, but not too well |
| 00:29.47 | moray | PaxAnima: ok, so you may already be doing what I was saying... :) |
| 00:29.52 | PaxAnima | you create a dictionary by using Dictionary* my_dict = dictionary_new( dictionary_type) |
| 00:30.04 | PaxAnima | so, yes |
| 00:30.05 | PaxAnima | ;) |
| 00:30.05 | moray | PaxAnima: but is that per-lookup? |
| 00:30.26 | moray | PaxAnima: or if you did two word-cycles at the same time would you then need two copies of the whole dictionary? |
| 00:30.27 | PaxAnima | you perform a lookup in the dictionary you pass as an argument |
| 00:30.45 | PaxAnima | moray: a cycle gives the next possible word of the dictionary you use |
| 00:31.07 | moray | PaxAnima: so where does your 'dynamic' frequency-based dictionary come into it? |
| 00:31.59 | PaxAnima | moray: well, the dictionary can be one of 3 types: normal, compressed or statistical (ie. it keeps track of the frequency the words are used) |
| 00:32.48 | PaxAnima | moray: http://v058b.studby.ntnu.no/dictionary.h <-- the header file.. maybe it makes the use more clearer |
| 00:34.00 | moray | PaxAnima: so if an application wants to use the library to get predictions from (e.g.) the initial string "qui", it needs to decide either to use the frequency-based (smaller?) dictionary or the 'normal' (larger?) one? |
| 00:35.05 | PaxAnima | moray: well, the predictive system, as I do with the irc input, has a smaller frequceny based dictionary for common words and a normal one for the rest, where the frequency based is first used when looking up a word |
| 00:35.46 | moray | PaxAnima: but at the moment the application needs to deal with loading both dictionaries etc.? - can't you make the library automatically cycle from one to the other? (or are there situations when that would be a bad idea?) |
| 00:36.29 | PaxAnima | moray: the irc input does that, and that will also be the behaviour of the predictive system |
| 00:37.18 | PaxAnima | ie. if you cycle words, and the first dictionary gives the same word or NULL, the next dictionary is queried |
| 00:37.42 | PaxAnima | the same word = the word has been predicted earlier in the cycle |
| 00:38.05 | moray | how are you meant to keep track of repetitions like that? |
| 00:39.00 | PaxAnima | moray: if the completed word has been suggested earlier in the cycle? |
| 00:39.22 | moray | PaxAnima: but shouldn't it be the library's job to avoid that ... ? |
| 00:39.57 | moray | PaxAnima: with a large dictionary, predicting from e.g. an initial "e", it could be expensive to keep a record of every word so far and compare against it at each iteration? |
| 00:41.03 | PaxAnima | moray: the dictionary system has ways of speeding things up |
| 00:42.24 | PaxAnima | tried it on the ipaq with a 38 000 word dictionary, and it worked quite well |
| 00:42.46 | hunterkll | ja |
| 00:43.28 | moray | well, I can see the dictionary itself can speed it up, I'm just confused by you saying that the library might return the same word twice, and that the app should notice that... - but I suspect this will work out in practice as things are implemented |
| 00:44.02 | PaxAnima | moray: the predictive library keeps track of that.. |
| 00:44.32 | PaxAnima | moray: the predictive library uses the dictionary library, and handles those things |
| 00:44.43 | moray | erm, ok then |
| 00:44.44 | pb_ | moray: from looking at the gpe-irc code, it isn't as bad as all that - there seems to be an expectation that the words are in a strict cycle, and it returns not only the same word but the same pointer each time. So all you need to do is keep track of the first char* you get back, and stop once you see that one come around for a second time. |
| 00:44.55 | moray | pb_: ah, ok |
| 00:46.06 | PaxAnima | pb_: actually, that has been changed with the latest versionn, after adding the use of compression at runtime, so the comparison of pointer has been replaced by a strcmp() |
| 00:46.20 | pb_ | ah, that's not so good then. |
| 00:46.29 | pb_ | is there any reason it can't just return NULL to sgnal that it's all out of ideas? |
| 00:46.40 | moray | PaxAnima: (a strcmp is a *lot* slower than a pointer compare) |
| 00:46.41 | PaxAnima | pb_: it does |
| 00:46.51 | pb_ | PaxAnima: so where does the strcmp come in? |
| 00:47.43 | PaxAnima | pb_: well, instead of returning a direct pointer to the data in the dictionary, it returns a strdup() of it, due to the way the compression is handled at runtime.. as the compression performs quite badly, I might revert to the old way of doing it |
| 00:48.24 | PaxAnima | we'll how the new system performs when dc adds it to gpe-irc |
| 00:48.38 | pb_ | crumbs. |
| 00:48.46 | PaxAnima | didn't notice anything on my laptop (450mhz celeron) |
| 00:49.05 | *** join/#gpe walters (walters@verbum.org) |
| 00:49.35 | PaxAnima | I'll try to look into the online compression part.. |
| 00:49.45 | PaxAnima | what's the correct way of measuring memory usage? |
| 00:54.36 | PaxAnima | hmm... am I disconnected again? |
| 00:55.09 | hunterkll | no |
| 00:55.13 | moray | PaxAnima: the correct way is probably with a memory profiling app |
| 00:55.13 | hunterkll | i can see you |
| 00:55.19 | PaxAnima | just got so quiet.. |
| 00:55.39 | moray | PaxAnima: you can guess from top etc., but that will only help if you take into account the other libraries you're linking against etc. |
| 00:56.11 | PaxAnima | using the info from top/ps the gain of online compression is 28_bytes_, which is far less than it should be.. |
| 00:57.12 | PaxAnima | on disk, the compression gains about 200k (from 351k to about 150).. I only use 1 byte extra in the online version (due to speedup), so I wonder where the remaing 160k is.. |
| 00:58.53 | hunterkll | in /dev/null |
| 00:59.10 | PaxAnima | most likely ;) |
| 00:59.31 | hunterkll | thats where i do all my dads backups too |
| 00:59.39 | hunterkll | it saves tape, so it must be a good thing |
| 01:03.35 | PaxAnima | oh lord... More than 30000 total errors detected. I'm not reporting any more. |
| 01:03.35 | PaxAnima | ==22035== Final error counts will be inaccurate. Go fix your program! |
| 01:03.43 | PaxAnima | (from valgrind) |
| 01:04.01 | moray | oh dear.. |
| 01:04.17 | PaxAnima | oh.. all comes from the same code |
| 01:04.23 | PaxAnima | so it's only 1 error |
| 01:04.32 | moray | ah right |
| 01:05.26 | PaxAnima | so it's quite natural, as I load the 38k dictionary.. |
| 01:06.29 | PaxAnima | and the reported "error" isn't an error either |
| 01:06.46 | hunterkll | lol |
| 01:07.03 | PaxAnima | damn valgrind |
| 01:44.56 | PaxAnima | ccmalloc shows me 144k less allocated memory when using runtime compression... that seems like a more likely number |
| 01:49.28 | PaxAnima | ... than the 28 bytes reported by ps/top |
| 02:12.33 | *** join/#gpe PaxAnima (~petter@v058b.studby.ntnu.no) |
| 02:13.29 | PaxAnima | found a solution to avoid the use of strcmp() (so I'll do it while I still remember it, so I can sleep better..;) |
| 02:45.22 | PaxAnima | fixed |
| 02:45.23 | PaxAnima | good night |
| 03:05.44 | *** join/#gpe walters (walters@verbum.org) |
| 05:07.39 | *** join/#gpe dneuer (~smoothie@192.204.192.117) |
| 07:53.38 | *** join/#gpe florian (boor@vmax.unix-ag.uni-siegen.de) |
| 07:53.53 | florian | hi! |
| 08:42.18 | *** join/#gpe florian (boor@vmax.unix-ag.uni-siegen.de) |
| 08:42.22 | florian | hi |
| 09:26.38 | *** join/#gpe ade|temp (~py99and@hebe.ex.ac.uk) |
| 09:26.55 | ade|temp | test |
| 09:35.44 | *** join/#gpe mallum (~mallum@pc-80-193-218-21-hw.blueyonder.co.uk) |
| 10:09.21 | *** join/#gpe pb_ (~pb_@dsl-62-3-66-201.zen.co.uk) |
| 10:10.32 | mallum | hey pb_ |
| 10:10.37 | mallum | gpe-teleport ? |
| 10:11.41 | pb_ | hi mallum |
| 10:12.45 | pb_ | teleport is one of the display migration programs. |
| 10:12.57 | mallum | pb_: yeah thought so .. |
| 10:13.01 | mallum | pb_: coolio dudeo :-) |
| 10:13.12 | mallum | pb_: one of ? |
| 10:13.18 | mallum | pb_: theres more ? |
| 10:13.29 | pb_ | well, it's the "client" counterpart to libdm. |
| 10:13.36 | mallum | pb_: okey |
| 10:13.59 | mallum | pb_: is it wortrh patching libdm strait into our gtk ? |
| 10:17.38 | pb_ | mallum: hrm, dunno. I thought about that, but I would prefer not to carry around more gtk patches than necessary. |
| 10:18.07 | mallum | pb_: yah |
| 10:18.18 | pb_ | mallum: maybe once we have an implementation that the gtk guys might actually be prepared to apply upstream, we could start patching gtk, but I think it's a bit early for that. |
| 10:18.43 | mallum | pb_: will some of the gpe libs like libdm, libxsettings etc could you put tarballs of them on the gpe site ? |
| 10:18.54 | pb_ | good plan, I'll do that shortly. |
| 10:19.33 | mallum | pb_: cool, thanks. It just then I can direct people to a download location in the matchbox building instructions rather than CVS |
| 10:20.13 | pb_ | yeah, absolutely. |
| 10:20.30 | pb_ | I keep thinking we should start making "release" tarballs of some of the more mature GPE applications, too. |
| 10:21.32 | mallum | yeah definetly |
| 11:08.40 | *** join/#gpe PaxAnima (~petter@v058b.studby.ntnu.no) |
| 11:09.22 | PaxAnima | morning |
| 11:13.31 | PaxAnima | pb_: found a way to avoid using strcmp(): as words are completed from the compressed dictionary, the decompressed string is stored (and use if called later).. this allows me to return a pointer to the internal data of the dictionary, like the earlier version |
| 11:13.54 | pb_ | PaxAnima: ok, cool |
| 11:14.39 | PaxAnima | the compressed dictionary consumes 141k less memory than the uncomressed one, according to ccalloc |
| 11:15.52 | pb_ | right. |
| 11:16.26 | pb_ | if the compressed dictionary lives in a file on disk, and you make read-only use of it, it would be best to mmap() it into memory rather than using malloc and read. |
| 11:18.07 | PaxAnima | hmm.. maybe, but there will be a lot of file access during the serch for words |
| 11:20.30 | PaxAnima | time for breakfast |
| 11:20.40 | pb_ | right, but if it is read-only access, it is best to let the kernel deal with it. |
| 11:21.01 | mallum | pb_: another of my possible planned future X hacks is to look at adding rendezvous support into the XServer and Ipaq |
| 11:21.20 | pb_ | mallum: what's that? |
| 11:21.26 | mallum | pb_: it should then be possible for the ipaq to automatically 'discover' XServers |
| 11:21.33 | pb_ | ah cool |
| 11:21.45 | mallum | pb_: http://www.apple.com/macosx/jaguar/rendezvous.html |
| 11:22.06 | mallum | pb_: its apple but an open W3 ? standard and apple libs are open source |
| 11:22.29 | pb_ | righto |
| 11:23.03 | mallum | pb_: I think it could be pretty interesting for PDA's in a kind of wireless roaming enviroment |
| 11:23.25 | pb_ | indeed, sounds very useful |
| 11:23.55 | mallum | cool I have a new viking catologue through the post |
| 11:24.10 | mallum | Only about the 5th so far |
| 11:24.28 | mallum | I cant see how they make any money, they must spend it all on catologues and postage |
| 11:24.53 | mallum | hmm, paper shredders ... |
| 11:30.48 | pb_ | yeah, indeed. But having that picture of their chairman pointing out the great deals on the front cover makes it all worthwhile for me. |
| 11:31.36 | mallum | yeah, I think its his vanity thats the driving force behind mass mailouts |
| 11:34.45 | pb_ | presumably. |
| 11:35.51 | mallum | pb_: ooh this is quite special http://www.expansys.com/product.asp?code=D211 ( nokia gprs / wlan card ) |
| 11:37.35 | *** join/#gpe pierre (~pierre@AClermont-Ferrand-201-1-3-168.abo.wanadoo.fr) |
| 11:38.31 | pb_ | oh yeah, neat. |
| 11:42.03 | pb_ | btw, if you want to play with the gpe migration stuff, the current gpe-calendar2 and gpe-todo2 in unstable are migration-capable now. |
| 11:46.26 | florian | bbl |
| 11:56.20 | mallum | pb_: cool , will try it out in a mo |
| 11:58.53 | mallum | pb_: how does it work with single instance ? |
| 11:59.14 | mallum | pb_: I guess if you migrated an app, itd probably launch a new instance of it locally ? |
| 11:59.40 | mallum | pb_: maybe it should re migrate the app back again |
| 12:00.48 | pb_ | mallum: how does single instance figure out if the app is still running? |
| 12:01.45 | mallum | pb_: it currently has a mapping on the root window of binary name to window id |
| 12:02.27 | mallum | pb_: do a xprop -root and you'll see it _MB_EXEC_MAP or summin |
| 12:02.42 | pb_ | mallum: if it looks for a particular window ID then yes, it would launch another instance locally. But that might well be what you want anyway if you have moved the original one to another display. We could have it try to yank the old one back, but there is no guarantee that it will be possible to do that (since you might no longer have connect permissions for the other display). And I'm not sure how you'd find out what window id the app had sta |
| 12:02.43 | pb_ | rted using on the other display, either. |
| 12:02.55 | pb_ | mallum: ah right |
| 12:03.26 | mallum | pb_: note I plan to eventually wrip that code out of matchbox and into its own seperate existance |
| 12:03.49 | pb_ | ok, cool. |
| 12:05.11 | mallum | pb_: its just easiest to debug whilst in matchbox, and there are calls in libMB to deal with that property - you probably should touch it directly at the moment |
| 12:05.49 | pb_ | right |
| 12:07.20 | mallum | pb_: has it been working good for you so far ? |
| 12:07.30 | pb_ | mallum: so far, yeah. |
| 12:09.20 | mallum | pb_: cool |
| 12:10.23 | mallum | pb_: Im quite pleased with the startup notification stuff. The only thing I think its missing is a nice way to detect faliures |
| 12:11.39 | pb_ | mallum: yes, indeed. In general, it would be nice if the launchers could display an error dialog if apps crash during startup, ideally with some output captured from stderr or something. |
| 12:12.09 | mallum | pb_: yeah, I've though about a bubble comming out of mbmenu |
| 12:13.06 | mallum | pb_: or an external sn 'listening' app that would popup a gtk dialog on faliure |
| 12:13.53 | pb_ | yes. or you could have an external dialog-showing app that the launchers would run when they want to report an error, rather than having it there all the time. |
| 12:20.24 | mallum | yep |
| 13:21.46 | *** join/#gpe FlyPiper (~mark@168.215.193.70) |
| 14:20.13 | *** join/#gpe florian (~fuchs@1Cust231.tnt1.laf1.deu.da.uu.net) |
| 14:23.50 | florian | hi all |
| 14:23.51 | *** join/#gpe ole_ (~ole@1Cust231.tnt1.laf1.deu.da.uu.net) |
| 14:24.08 | ole_ | hi all |
| 14:24.09 | florian | ole_: HI! |
| 14:24.29 | *** join/#gpe mccarthy (~mccarthy@granular.che.pitt.edu) |
| 14:24.50 | mccarthy | pb_: I think the random crashing might be your fault... :) |
| 14:25.12 | florian | ibot |
| 14:25.20 | florian | sorry.... |
| 14:29.49 | ole_ | Could anybody help me with a strange gpe2 problem? I freshly installed familiar 0.6.1 with gpe2. Most things seem to work quite fine for the first look, but with some (nearly all?) applications I sometimes get the following error message: "GLib-ERROR **: /home/pb/glib-2.1.5/glib/gmem.c:173: failed to allocate 35651584 bytes". Has anybody experienced the same problem? |
| 14:31.13 | ole_ | I've just tried to strace these applications (for exampele gpe-filemanager)... Have not found any real answer... |
| 14:33.20 | *** join/#gpe nils_ (~nils@1Cust231.tnt1.laf1.deu.da.uu.net) |
| 14:33.50 | mccarthy | nils_: !!! hello |
| 14:34.10 | mccarthy | nils_: nelson says we can release gpe-atd as atd |
| 14:34.11 | mallum | hey nils_ |
| 14:34.18 | nils_ | mccarthy: Hi! |
| 14:34.43 | nils_ | mccarthy: Not really! Cool! But how the hell do I get the sources into "his" CVS? |
| 14:34.45 | *** join/#gpe pierre_ (~pierre@AClermont-Ferrand-201-1-3-76.abo.wanadoo.fr) |
| 14:35.35 | mallum | ole_: the is something to do with gconv IIRC |
| 14:35.51 | nils_ | mccarthy: OK, then anyway, then I'll build a new atd package ASAP and put it up into unstable but leave the sources in our CVS as gpe-atd as long as I do not have write perms on "his" atd tree... |
| 14:36.32 | mccarthy | nils_: cool |
| 14:36.45 | mccarthy | nils_: gpe-calendar works great with your atd (BTW) |
| 14:36.53 | nils_ | ole_: Does it work now :) ? |
| 14:37.05 | nils_ | mccarthy: Oh! Good to hear, tnx... |
| 14:37.31 | mccarthy | nils_: we now have re-occurring alarmed events working (almost) perfectly! :) |
| 14:38.03 | ole_ | nils_: sorry... not yet :( |
| 14:38.56 | nils_ | mccarthy: How do you do it finally? I mean, does the alarm program notify gpe-calendar again or does the alarm program itself set a new alarm? |
| 14:39.12 | mccarthy | nils_: the alarm notifies gpe-calendar |
| 14:39.44 | nils_ | mccarthy: Oh good! Is this a little documented somewhere? I'd love to have a look at it... |
| 14:39.49 | mccarthy | nils_: but right now gep-calendar gets confused sometimes and resets the *same* alarm again (since people generally tell alarms to go off *before* events ;) |
| 14:40.36 | nils_ | mccarthy: Which is in general quite a good idea ;) |
| 14:41.01 | nils_ | mccarthy: Oh BTW ... I would like to raise a little request for new gpe-calendar releases :)) |
| 14:41.26 | mccarthy | nils_: I think I fixed it by passing an argument identifying the last alarm's time so that we dont sschedule *another* alarm with the *exact* same time |
| 14:42.24 | nils_ | mccarthy: Would it be somehow possible not to put the event's time in the description field but instead to fill those into the left hand side timeline bar? This is also how most other apps like Palm and thelike handle this. |
| 14:43.04 | ole_ | mallum: Strange... after removing gconv (and Dillo2) it seems to work for the moment... Now I get a lot of string convertion errors, but the apps seem to work.... strange... |
| 14:43.52 | mccarthy | nils_: pb had some reason he liked it this way (I actually like it your way :) but he wrote that part of the code.... |
| 14:44.44 | mccarthy | yeah, I think I've got it! |
| 14:44.45 | nils_ | mccarthy: Then I should maybe hassle pb :) Hey Philip!? Listening? |
| 14:44.55 | moray | mccarthy: re identifying events, make sure things work properly if a user sets more than one alarm for the same time |
| 14:44.59 | mccarthy | nils_: no he isnt I tried before |
| 14:45.19 | mccarthy | moray: hmmmm..... I hadn't thought of that.... |
| 14:45.22 | mallum | ole_: I dont think you meant to remove it |
| 14:45.55 | mallum | ole_: I think you need to replace ISO8895-1.so with http://www.handhelds.org/~pb/testing/ISO8859-1.so |
| 14:46.04 | mccarthy | moray: right now multiple users can set alarms for the same time, but I dont think the *same* user can do multiple alarms for the same time... |
| 14:46.44 | moray | mccarthy: right. you might need to use some 'more unique' identifier than the alarm time - you could e.g. just give all alarms a serial number as they're created |
| 14:47.12 | ole_ | mallum: Yes, i removed it... only dillo2 dependet to it... I seems to work, I'll try to replace the ISO8895 lib... |
| 14:47.38 | mccarthy | moray: I think that time.uid might work fine (and be findable without saving additional info |
| 14:47.46 | moray | mccarthy: or just special-case dealing with multiple alarms at the same time, and then treat the passed-back time as a 'schedule alarms since' |
| 14:48.48 | mallum | pb_: hmm, I cant get gpe-teleport to work :( |
| 14:54.32 | *** join/#gpe jsmanrique (~jsmanriqu@213-98-110-79.uc.nombres.ttd.es) |
| 14:54.52 | jsmanrique | hi! |
| 14:54.56 | jsmanrique | afternoon |
| 15:01.46 | pb_ | mallum: ah, what happens? |
| 15:02.37 | mallum | pb_: it just locks up the app I want to migrate :( |
| 15:03.01 | pb_ | mallum: oh dear. |
| 15:03.07 | pb_ | mallum: which app are you testing with? |
| 15:03.12 | mallum | pb_: also is it meant to be a dialog ? |
| 15:03.16 | mallum | pb_: gtk-calender |
| 15:03.20 | mallum | gpe rather |
| 15:03.26 | pb_ | mallum: yes, it's meant to be a dialog. |
| 15:03.35 | nils_ | pb_: Hi! (Hopefully) Short question: mccarthy told me that you wrote and voted for gpe-calendar displaying the event times in the description part not in the left hand time bar... why is that? |
| 15:04.14 | mallum | pb_: makes it kind of awkard to enter a new display ... would it not be better as a toolbar ? |
| 15:04.34 | pb_ | nils_: I just prefer it that way. There's an option you can set with xst to switch to the other style. |
| 15:04.38 | pb_ | mallum: maybe, yeah. |
| 15:04.55 | pb_ | mallum: does gpe-calendar print anything on stderr when you try to migrate it? |
| 15:05.25 | mallum | pb_: yeah I get a whole load of gdk errors, I will take a look in a mo and grab the source |
| 15:05.45 | pb_ | mallum: want to paste the errors here? |
| 15:06.05 | nils_ | pb_: Oh well ... sorry for disturbing ;) Is there anything you have not yet thought about :)) ? Now I have just to find out which option it is and how I set it... |
| 15:06.10 | mallum | pb_: yeah sure, just give me a mo |
| 15:06.30 | pb_ | nils_: try xst write GPE/Calendar/day-view-combined-times int 1, something like that. |
| 15:07.38 | nils_ | pb_: great! many tnx! |
| 15:08.15 | pb_ | nils_: by the way, did mccarthy mention that nelson said he/you could package your modified atd as the "official" one? |
| 15:09.03 | nils_ | pb_: Yes, he did! Finally a good decision :) And that's also why we came to talk about gpe-calendar and the time display stuff. |
| 15:09.44 | pb_ | nils_: ah right, cool. |
| 15:10.04 | ole_ | mallum: thanks, it seems to be ok now |
| 15:16.57 | mccarthy | pb_: when did this "cached-window" stuff appear in event-ui.c? |
| 15:17.19 | pb_ | mccarthy: maybe 4 weeks ago? check the changelog. |
| 15:17.34 | mccarthy | pb_: what is the purpose? |
| 15:18.01 | pb_ | mccarthy: ameliorate the colossal amount of time it takes to create the event window. |
| 15:18.51 | mccarthy | pb_: ok, but I think it might be the cause of the crashing.... |
| 15:18.54 | pb_ | mccarthy: why so? |
| 15:21.33 | mccarthy | pb_: when I run it in gdb (on the ipaq) I get the follwoing at crash... |
| 15:21.47 | mccarthy | (gpe-calendar:2488): GLib-GObject-WARNING **: invalid uninstantiatable type `(nil)' in cast to `GtkObject' |
| 15:21.47 | mccarthy | (gpe-calendar:2488): Gtk-CRITICAL **: file /home/pb/gtk+-2.2.0/gtk/gtkobject.c: |
| 15:21.47 | mccarthy | line 670 (gtk_object_get_data): assertion `GTK_IS_OBJECT (object)' failed |
| 15:22.06 | mccarthy | edit_event (ev=0x4cbe0) at event-ui.c:1185 |
| 15:23.16 | *** join/#gpe nils__ (~nils@80.228.39.138) |
| 15:23.32 | *** part/#gpe nils__ (~nils@80.228.39.138) |
| 15:23.34 | mccarthy | pb_: which seems to suggest that the "w" thing is screwy |
| 15:23.52 | mccarthy | where *w= edit_event_window (); |
| 15:23.56 | *** join/#gpe nils__ (~nils@1Cust231.tnt1.laf1.deu.da.uu.net) |
| 15:25.12 | pb_ | mccarthy: ok, you will have to check the code and figure out what is going wrong. |
| 15:26.09 | mccarthy | pb_: first I will comment out the cached stuff to see if that is it... |
| 15:26.27 | mccarthy | pb_: i am *really* close to fixing the reschedule issue as well |
| 15:26.31 | nils__ | pb_: I must have missed something ... but what is/where can I find xst? I do not seem to have it on any of my systems... |
| 15:26.48 | *** part/#gpe jsmanrique (~jsmanriqu@213-98-110-79.uc.nombres.ttd.es) |
| 15:27.55 | pb_ | nils__: ipkg install xst |
| 15:35.24 | pb_ | heh, looks like someone rebooted kernel concepts :-) |
| 15:36.24 | mccarthy | pb_: it looks like it works fine when the cached window thing is commented out.... |
| 15:36.33 | pb_ | mccarthy: ok. |
| 15:36.53 | mccarthy | pb_: so I am not sure what is wrong yet (but it doesnt crash on my desktop so it is a real pain to debug :( ) |
| 15:37.07 | pb_ | ah. |
| 15:43.27 | mccarthy | w00t! rescheduling works fine....now to track down a few more bugs and be done.... |
| 15:51.34 | *** join/#gpe nils__ (~nils@1Cust97.tnt11.laf1.deu.da.uu.net) |
| 15:51.36 | *** join/#gpe ole_ (~ole@1Cust97.tnt11.laf1.deu.da.uu.net) |
| 15:51.39 | mccarthy | pb_: why dont you ever run event_ui_init? |
| 15:52.02 | *** join/#gpe florian (~fuchs@1Cust97.tnt11.laf1.deu.da.uu.net) |
| 16:02.05 | moray | do we know if the pango modules / pixbuf-loader problems are yet fixed by the latest package versions? |
| 16:17.01 | pb_ | mccarthy: event_ui_init's sole purpose was to pre-create a cached event window, but that made startup too slow. |
| 16:17.22 | mccarthy | pb_: ok. I have a new way to do it that I am trying....we'll see |
| 16:18.07 | mccarthy | pb_: did you see that I fixed the rescheduling thing? |
| 16:18.34 | mccarthy | pb_: now I need to make sure that nils is actually *releasing* his atd.... |
| 16:19.26 | pb_ | mccarthy: cool. |
| 16:19.48 | mccarthy | pb_: afk?! |
| 16:20.38 | pb_ | mccarthy: away from keyboard |
| 16:20.48 | mccarthy | pb_: ahhh |
| 16:57.18 | *** join/#gpe spung_study (~rewt@a213-22-98-118.netcabo.pt) |
| 17:35.23 | pb_ | moray: it would appear not, though I don't know what exactly the current problem is. It doesn't help that there are still old versions of pango and pango-querymodules kicking around in the feed, which seem to be managing to inveigle themselves onto people's machines somehow. |
| 17:41.29 | *** join/#gpe PeterHolik (~admin@chello212186086221.11.vie.surfer.at) |
| 17:54.30 | *** join/#gpe prpplague (~JoeBob1@12.148.134.9) |
| 18:04.27 | *** join/#gpe FlyPiper (~46-cub@168.215.193.70) |
| 18:08.01 | *** join/#gpe florian (~fuchs@1Cust115.tnt2.laf1.deu.da.uu.net) |
| 18:08.12 | *** join/#gpe nils__ (~nils@1Cust115.tnt2.laf1.deu.da.uu.net) |
| 18:08.50 | mccarthy | nils__: are you planning on releasing the atd soon? |
| 18:11.53 | nelson | nils__: do you have a hh.org account? |
| 18:12.19 | nils__ | nelson: Of course :) |
| 18:46.07 | mccarthy | pb_: you around? |
| 18:46.12 | pb_ | mccarthy: yo! |
| 18:46.35 | mccarthy | pb_: why would the thing crash on my ipaq, but not on my desktop? |
| 18:46.43 | pb_ | mccarthy: no idea, can you get a backtrace in gdb? |
| 18:47.02 | mccarthy | pb_: yeah, (before) but it didnt make any sense... |
| 18:47.08 | pb_ | ah. |
| 18:47.10 | mccarthy | but right now I couldnt anyhow |
| 18:47.14 | pb_ | hrm. |
| 18:47.21 | mccarthy | since I am getting a The error was 'BadWindow (invalid Window parameter)'. |
| 18:47.24 | mccarthy | error |
| 18:47.37 | mccarthy | which is says will screw up gdb |
| 18:47.43 | pb_ | oh, an X error. |
| 18:47.50 | pb_ | yeah, the trouble is those are reported asynchronously. |
| 18:48.01 | pb_ | I think you might be able to use the "--sync" option or some such to make them synchronous. |
| 18:48.47 | mccarthy | pb_: yeah, it *says* that but it doesnt seem to make any diff |
| 18:48.56 | pb_ | mccarthy: ah. |
| 18:49.06 | mccarthy | crap |
| 18:49.28 | pb_ | mccarthy: you may have to appeal to one of the X-perts for help. |
| 18:54.56 | mccarthy | pb_: damn, this makes no sense that it works *flawlessly* on the desktop.... |
| 18:56.03 | pb_ | mccarthy: :-/ |
| 19:02.09 | moray | gosh, they're getting militant on #handhelds.org |
| 19:05.00 | *** join/#gpe BBrox (~ulmer@bbrox.org) |
| 19:05.03 | pb_ | moray: yeah. |
| 19:08.32 | *** join/#gpe joseph (unknown@24-90-171-4.nj.rr.com) |
| 19:08.36 | joseph | mccarthy: hey you around? |
| 19:19.06 | mccarthy | joseph: yeah |
| 19:19.10 | joseph | hey |
| 19:19.14 | joseph | do you use prism2_cs.o ? |
| 19:19.19 | joseph | pb_ said you might |
| 19:19.23 | mccarthy | yep |
| 19:19.33 | mccarthy | only for 2.4.18 kernels though |
| 19:19.39 | mccarthy | (it was a real pain to build) |
| 19:19.57 | joseph | aw |
| 19:20.02 | joseph | i need it for 2.4.19, any ideas what i can do ? |
| 19:20.10 | joseph | well |
| 19:20.17 | joseph | im using a netgear cf 802.11b card |
| 19:20.20 | joseph | on a 3900 |
| 19:20.21 | mccarthy | build it |
| 19:20.37 | mccarthy | I had to grab a cross-compile toolchain |
| 19:20.40 | mccarthy | build a kernel |
| 19:20.55 | mccarthy | I *think* I had to build pcmcia stuff |
| 19:21.00 | joseph | that sucks |
| 19:21.04 | mccarthy | and *then* I built the modules themselves |
| 19:21.36 | mccarthy | I could tar up what I needed if you wanted to poke around in it (and have a lot of bandwidth to grab from) |
| 19:21.52 | mccarthy | then you would jut sub in the new kernel and re-build |
| 19:21.58 | joseph | well i dont have any place to build it |
| 19:22.21 | mccarthy | I built it on a i386 linux box, you dont have one of those? |
| 19:23.01 | joseph | haha |
| 19:23.13 | joseph | err, x86 freebsd or linux-ppc ;-/ |
| 19:23.22 | mccarthy | ahhh |
| 19:23.47 | joseph | alrighty |
| 19:23.51 | joseph | let me know how the netgear card works :) |
| 19:23.53 | joseph | on your 3900 :) |
| 19:24.05 | joseph | cause i think it must have something to do with the 3900, everyone else seems to get them workings with minimal effort |
| 19:24.32 | mccarthy | I dont have a netgear card, it is a linksys; and I use it ona 3670 |
| 19:24.35 | pb_ | yeah. well, the pcmcia is still a bit flaky on 3900 at the moment. But I think jamey did say he had got some wireless cards to work. |
| 19:24.44 | mccarthy | but the wlan_ng stuff does wep nicely |
| 19:24.46 | joseph | pb_: using what kernel |
| 19:24.50 | joseph | mccarthy: im not using wep |
| 19:24.52 | pb_ | joseph: don't know |
| 19:25.03 | joseph | mccarthy: the hostap_cs driver doesn't detect the hardware address |
| 19:25.07 | joseph | it shows 00:00:00:00:00:00 |
| 19:25.08 | joseph | heh |
| 19:25.32 | mccarthy | hmmm. thats not goof |
| 19:25.35 | mccarthy | goof=good |
| 19:27.35 | *** part/#gpe mccarthy (~mccarthy@granular.che.pitt.edu) |
| 19:29.15 | joseph | yeah, i know |
| 19:29.20 | joseph | argh |
| 19:31.32 | *** join/#gpe jg_ (~jg@dialup-63.214.85.178.Dial1.Boston1.Level3.net) |
| 19:50.27 | *** join/#gpe walters (walters@verbum.org) |
| 20:06.50 | *** join/#gpe pb_ (~pb@pc2-cmbg4-3-cust239.cmbg.cable.ntl.com) |
| 20:07.00 | pb_ | mallum: did you ever capture those gdk errors? |
| 20:11.08 | mallum | pb_: no, but it turned out I was trying to connect to a display that was non existant |
| 20:11.21 | pb_ | mallum: ah. |
| 20:11.30 | mallum | pb_: it seem to die pretty badly if you give it a false display |
| 20:11.31 | pb_ | mallum: did it work better when you tried a display that did exist? |
| 20:11.38 | mallum | pb_: yeah then it worked |
| 20:12.19 | mallum | pb_: also it would be cool if it gave you a dropdown list of running migratable apps, you could then just select one and then migrate it |
| 20:12.21 | pb_ | mallum: I haven't tried a display that totally didn't exist. It seemed to be able to cope reasonably well with a display that existed but didn't have authentication, though. |
| 20:12.47 | pb_ | mallum: yeah, that might be neat. |
| 20:13.11 | mallum | pb_: matchbox sets a list of all running window id's |
| 20:13.23 | pb_ | mallum: is that a standard wm thing, or matchbox only? |
| 20:14.03 | pb_ | mallum: it would be easy enough for it to cruise round all the children of the root, though I guess that might generate a lot of server traffic. |
| 20:14.05 | mallum | pb_: see http://www.freedesktop.org/standards/wm-spec/1.3/html/x110.html _NET_CLIENT_LIST |
| 20:14.26 | pb_ | ok. |
| 20:15.00 | pb_ | hrm, poxy evolution doesn't seem to work at all on this machine since I upgraded to 1.2. |
| 20:17.11 | mallum | pb_: doh :( |
| 20:17.30 | pb_ | I think it might be getting stuck scanning some of my big imap mailboxes. :-/ |
| 20:17.36 | mallum | pb_: you could maybe pull code for _NET_CLIENT_LIST froms gnomes libwck |
| 20:17.53 | mallum | pb_: why dont you like mutt ? |
| 20:18.15 | pb_ | mallum: dunno, I've just never got on with it. I guess I'm spoilt and prefer a GUI mail tool nowadays. |
| 20:18.59 | pb_ | mallum: I guess if I made the effort to learn or adjust the mutt keybindings I could probably get used to it. |
| 20:19.20 | mallum | pb_: yeah, I have a fairly sane config if you want it |
| 20:19.35 | pb_ | mallum: yah, the _NET_CLIENT_LIST thing doesn't look very complicated, I can probably manage to implement that myself. |
| 20:19.38 | pb_ | mallum: ah, that might be cool. |
| 20:19.51 | mallum | pb_: most of the keybindings seem to be the same as emacs |
| 20:19.55 | mallum | pb_: more or less |
| 20:19.59 | moray | mallum: I use mutt remotely, but apart from general GUI-prettiness with evolution, I find it useful being able to do things like view several messages at once easily |
| 20:20.15 | mallum | pb_: I'll pop it in the post to you |
| 20:20.24 | pb_ | mallum: cool |
| 20:20.40 | mallum | I have a .muttrc for the ipaq too which works well with the 5.5 font |
| 20:20.53 | pb_ | moray: that's true. Also I like the separate panel that shows you how many messages are in each folder. |
| 20:21.06 | moray | mallum: I also have things forwarded into lots of different mailboxes by exim, and I find it easier with a GUI to spot what folder to deal with next |
| 20:21.21 | pb_ | moray: exactly, yes. |
| 20:22.57 | mallum | moray: I have a monsterous perl script that connects to various accounts, filters into a load of maildirs running through spamassasin on the way |
| 20:23.25 | mallum | moray: its a beast, uses loads of cpu, but works well |
| 20:23.41 | mallum | moray: well does what I want it to well |
| 20:23.47 | moray | mallum: ha. most of my accounts just get forwarded these days, since I don't really trust destructive-mail-fetchers (e.g. fetchmail, as compared with normal leave-in-place IMAP) |
| 20:24.18 | mallum | moray: it also auto archives all my mail |
| 20:24.37 | mallum | moray: which is the feature Im most pleased with |
| 20:25.05 | mallum | moray: then I have imap running on the box too, so I can use things other than mutt if I want |
| 20:25.17 | mallum | ( I never tried mutt imap ) |
| 20:25.27 | moray | mallum: ah right; I tend to just use not delete mail, and back up my mail/ folder - although things with a personal address of mine in the headers also get copied away an extra time |
| 20:26.02 | moray | mallum: at one point I had a fork in my mail forwarding, so that moray@inkvine got a copy of everything purely as a backup |
| 20:26.17 | moray | though that got confusing when I got messages sent directly to that address as well ;) |
| 20:27.08 | mallum | yeah I only delete things I hit d for in mutt |
| 20:27.28 | moray | btw, I now have wireless to my ipaq again (as long as it's in an appropriate part of the room), which is useful |
| 20:27.48 | mallum | moray: if you run a co though you should delete as much mail as possible |
| 20:27.53 | moray | mallum: I tend not to *delete* even spam, but file it away for use in some future auto-filtering project |
| 20:28.02 | moray | mallum: ah, sure |
| 20:28.22 | moray | I do delete things like the 'there's a new kernel traffic summary out' message |
| 20:30.26 | pb_ | joseph: ping |
| 20:33.07 | pb_ | ibot, seen joseph? |
| 20:33.07 | | joseph is currently on #opie (59m 36s) #gpe (59m 36s) #handhelds.org (59m 36s). Has said a total of 96 messages. Is idling for 32m 16s |
| 20:33.39 | moray | poor kittens |
| 20:33.44 | pb_ | quite. |
| 20:38.30 | pb_ | mallum: I can't make libdm go badly wrong even with a nonexistent display. |
| 20:44.23 | mallum | pb_: hmm, I will play again in a mo |
| 20:44.41 | pb_ | mallum: righto |
| 20:44.51 | nelson | b_: hey-ho! I've found two guys at Dell who are wanting to port Familiar to the Dell Axim. |
| 20:45.00 | nelson | pb_: they're wanting to try running bootblaster. Do you have instructions for running it on the h3900? |
| 20:45.02 | pb_ | nelson: rock! |
| 20:45.35 | pb_ | nelson: it's basically the same drill as on older ipaqs, except that you need the specific 3900 from feeds/BootBlaster3900. |
| 20:45.57 | nelson | Okay, what about the bootloader? |
| 20:46.11 | mallum | nelson: woohoo ! |
| 20:46.11 | joseph | pb_: hey!! |
| 20:46.12 | pb_ | nelson: probably the only thing they will need to change in bootblaster for the axim would be the flash write protect. |
| 20:46.35 | mallum | nelson: the dell pda's are really cheap too ? |
| 20:46.39 | joseph | pb_: i got one of the cards working!!! |
| 20:46.44 | joseph | the netgear, with the new kernel, and orinoco_cs |
| 20:47.08 | joseph | i wonder why the 2.4.19-pxa1 driver didn't work *shrug* |
| 20:47.11 | nelson | mallum: yes, rather. They beat the ipaq 1910. |
| 20:47.15 | pb_ | nelson: if they are really lucky, an h3900 build of bootldr might come up far enough to at least give them a serial prompt without any changes. But most likely it will need some small tweaks to enable the serial transceivers, etc. |
| 20:47.33 | pb_ | joseph: ah cool. I was going to tell you that I built hostap-cs for -hh4, and it seems to work ok with my actiontec card. |
| 20:47.40 | nelson | pb_: yes, could be.... |
| 20:47.41 | joseph | hostap-cs works also!? |
| 20:47.51 | joseph | is hostap-cs a better driver?! |
| 20:47.52 | nelson | pb_: where can they find an h3900 build of bootldr? |
| 20:47.59 | pb_ | joseph: well, it's able to read the MAC address at least. I forgot to bring an AP home with me (doh) so I can't tell whether it really works. |
| 20:48.17 | pb_ | nelson: either in handhelds.org/~pb/3900/ or in feeds/bootldr/pxa, I forget where the latest version is. |
| 20:48.24 | joseph | neat0 |
| 20:48.26 | pb_ | nelson: the source is in handhelds.org cvs of course. |
| 20:49.05 | pb_ | joseph: if you want to try hostap, I put some binaries in handhelds.org/~pb/3900/hostap. |
| 20:49.25 | joseph | k awesome! |
| 20:49.26 | joseph | thanks! |
| 20:49.28 | joseph | where do you compile them? |
| 20:49.29 | joseph | on the device? |
| 20:49.38 | pb_ | joseph: no, I cross compile from my desktop. |
| 20:49.55 | nelson | What's the URL to "feeds/bootldr/pxa"? |
| 20:50.07 | pb_ | nelson: http://handhelds.org/feeds/bootldr/pxa/ |
| 20:50.20 | nelson | pb_: tnx. What about bootblaster? |
| 20:50.41 | pb_ | nelson: http://handhelds.org/feeds/BootBlaster3900/ |
| 20:50.53 | nelson | pb_: the ~pb URL has the newest bootldr. |
| 20:51.03 | pb_ | nelson: ok. I should probably move it to the feed. |
| 20:51.05 | joseph | pb_: for sound, when its ready, will a whole new kernel be available or just that individual module? |
| 20:51.17 | pb_ | joseph: probably a whole new kernel. |
| 20:51.27 | joseph | ah |
| 20:51.54 | pb_ | joseph: probably only a single module would be necessary, but it's usually easiest to respin the whole set of kernel packages. |
| 20:52.03 | joseph | yeah |
| 20:52.05 | joseph | no conflicts that way |
| 20:52.12 | pb_ | there isn't really any scripting support for building just a single .ipk. |
| 20:52.36 | pb_ | and also of course it means you get any other updates that might have been checked in meanwhile. |
| 20:53.35 | joseph | cool |
| 20:54.46 | joseph | how do you cross compile from an x86? |
| 20:54.52 | joseph | is it just an option to gcc? |
| 20:55.01 | pb_ | joseph: you need a separate compiler. |
| 20:55.15 | joseph | ah |
| 20:55.20 | joseph | where can i get one for xscale? |
| 20:55.36 | pb_ | on hh.org somewhere |
| 20:55.39 | pb_ | ibot, toolchain? |
| 20:55.42 | | methinks toolchain is at http://handhelds.org/z/wiki/Toolchains, or http://openzaurus.org/official/toolchain/, or at http://www.csh.rit.edu/~jeffm/pub/cross/arm-linux/ppc/ which can be modified to work with Zaurus cross development |
| 20:55.46 | joseph | i guess i'll have to get linux up on an x86, or will it also work on linux-ppc? |
| 20:56.13 | pb_ | maybe try that last url ibot mentioned, looks like it might be for ppc. |
| 20:56.35 | pb_ | you can definitely build one for ppc if you compile from source, but that can be a bit of a pain. |
| 20:56.55 | pb_ | france is our resident toolchainmeister, he might know better than me. |
| 20:57.07 | joseph | hehe ok |
| 20:57.34 | mallum | joseph: I use linux ppc too, so Id be interested if you get a working toolchain |
| 20:57.43 | joseph | alright, i'll check it out |
| 20:57.48 | joseph | nwo i have a bunch of stuff to do |
| 20:57.54 | joseph | i'll do the wiki report first |
| 20:57.57 | mallum | joseph: I've never tried however |
| 20:58.02 | joseph | then mess with toolchain when i get my ipaq up and running the way i want |
| 20:58.08 | pb_ | joseph: cool. |
| 20:58.23 | joseph | meanwhile i have to do some volunteer shit at school in 1 hour |
| 20:58.33 | joseph | they require 60 hours to graduate, fucking sucks. |
| 20:58.33 | pb_ | heh. |
| 20:58.46 | pb_ | joseph: what kinda "voluntary" work do you have to do? |
| 20:58.49 | joseph | anything |
| 20:58.51 | joseph | just gotta get a write-up |
| 20:58.54 | joseph | that says you did it |
| 20:58.58 | pb_ | ah right. |
| 20:59.00 | joseph | in-school stuff works too |
| 20:59.06 | joseph | which is what most kids do |
| 20:59.14 | joseph | some people volunteer at hosptials and shit but thats not my thing |
| 20:59.31 | joseph | i do a lot of animal rights volutneer work though |
| 20:59.49 | pb_ | cool. |
| 21:01.21 | *** join/#gpe mccarthy (~mccarthy@granular.che.pitt.edu) |
| 21:01.51 | mccarthy | do we *really* only have sqlite 2.4 on the ipaqs right now?! |
| 21:02.03 | pb_ | mccarthy: complain to admin@handhelds.org |
| 21:02.07 | mccarthy | I have been using 2.7 for a while, but I could have *sworn* I uploaded it |
| 21:02.17 | pb_ | mccarthy: oh, you mean in unstable? |
| 21:02.18 | mccarthy | pb_: no I mean in the feeds |
| 21:02.27 | pb_ | doh |
| 21:02.38 | pb_ | yes, looks like 2.4 is latest there |
| 21:02.47 | mccarthy | pb_: oops :) |
| 21:02.58 | mccarthy | I guess I will upload it.... |
| 21:04.29 | pb_ | mccarthy: heh, good plan |
| 21:06.43 | mccarthy | pb_: all done :) |
| 21:06.50 | pb_ | cool |
| 21:07.04 | mccarthy | damn I wish my damn gpe-calendar worked.... |
| 21:07.21 | mccarthy | now I dont know if I should revert back to your cached stuff.... |
| 21:07.43 | mccarthy | since it didnt crash any *worse* than the current implementation I have here ;) |
| 21:07.56 | pb_ | heh. |
| 21:10.04 | mccarthy | pb_: does yours crash as well or is it maybe a weird setup on *my* ipaq? |
| 21:10.18 | pb_ | mccarthy: haven't tried recently, debugging kernel stuff at the moment |
| 21:10.41 | joseph | pb_: whats the best way to completely remove the old kernel (2.4.19-pxa1) with ipkg ? |
| 21:10.52 | pb_ | joseph: you have to do it one package at a time. |
| 21:11.00 | joseph | eh son of a ... |
| 21:11.12 | pb_ | joseph: or hassle TheMasterMind1to fix -recursive. |
| 21:11.12 | joseph | i cant follow depends and remove the meta package? |
| 21:11.28 | pb_ | joseph: in theory yes, but it doesn't actually work. |
| 21:12.32 | joseph | hmm |
| 21:12.33 | joseph | alrighty |
| 21:12.33 | joseph | i |
| 21:12.36 | joseph | i'll just leave it |
| 21:13.10 | pb_ | with the new kernel packaging this shouldn't be a problem in future, since each version will replace older ones. |
| 21:16.51 | joseph | thank god hehe |
| 21:18.51 | moray | pb_: although it might still be nice if ipkg didn't just sit there hung in complex situations ;) |
| 21:18.57 | pb_ | moray: indeed. |
| 21:23.16 | pb_ | mallum: what were the libs you wanted distribution tarballs of again? |
| 21:23.48 | joseph | pb_: |
| 21:23.51 | joseph | the interface seems a little slow |
| 21:23.56 | joseph | the 802.11b connection, that is |
| 21:23.59 | joseph | does 128-bit wep slow it down? |
| 21:24.01 | pb_ | joseph: hrm |
| 21:24.08 | pb_ | joseph: possibly, yes. |
| 21:24.16 | joseph | that much? |
| 21:24.25 | joseph | i mean, its downloading packages as slow as the serial connection |
| 21:24.28 | joseph | even slower, maybe |
| 21:24.35 | pb_ | joseph: dunno, I don't use wep much, but I doubt it should be _that_ slow. |
| 21:24.42 | moray | joseph: also check the nominal rate in iwconfig |
| 21:24.45 | pb_ | joseph: talk to moray or mallum, I think they are wep-using dudes. |
| 21:24.54 | pb_ | uh, mccarthy not mallum |
| 21:25.11 | joseph | <PROTECTED> |
| 21:25.55 | moray | joseph: hm - try setting "iwconfig INTERFACE rate auto" |
| 21:26.14 | moray | joseph: if it's currently hardwired at 11 Mb/s and losing lots of packets that might explain it |
| 21:26.40 | moray | joseph: otherwise, try a ping from the ipaq to another machine and see how fast/slow and how lossy the connection is |
| 21:27.02 | moray | joseph: also, if you have any power saving options on the card might only be waking up some of the time |
| 21:27.27 | joseph | moray well its like 5 feet from the AP :) |
| 21:27.29 | mallum | pb_: oh xsettings libs mainly |
| 21:27.50 | pb_ | mallum: ah ok. I think they're just copied straight from the reference implementation though. |
| 21:28.08 | moray | joseph: well, whatever problem is affecting transfers should also affect pings (probably) |
| 21:28.12 | pb_ | mallum: but this should be no challenge for our new "make dist" target :-) |
| 21:28.54 | joseph | PING google.com (216.239.35.100): 56 data bytes 64 bytes from 216.239.35.100: icmp_seq=0 ttl=50 time=95.9 ms 64 bytes from 216.239.35.100: icmp_seq=1 ttl=50 time=96.0 ms |
| 21:29.25 | moray | joseph: leave it running for a while then control-C and get the summary statistics |
| 21:29.44 | moray | joseph: though it might be more useful to ping a local host than google (unless they're just next door to you) |
| 21:29.54 | joseph | hehe k |
| 21:29.58 | moray | joseph: otherwise effects from the rest of the network will interfere |
| 21:30.21 | joseph | --- 192.168.0.1 ping statistics --- 11 packets transmitted, 11 packets received, 0% packet loss round-trip min/avg/max = 2.8/2.9/3.2 ms |
| 21:30.36 | joseph | well ping packets are tiny |
| 21:30.39 | moray | hm, that sounds pretty good to me |
| 21:30.44 | joseph | so encrypting them (if they even are encrypted) wouldn't take long at all |
| 21:30.49 | pb_ | probably want to try leaving it going for a bit longer. |
| 21:30.55 | pb_ | maybe try larger packets also (-s xxx) |
| 21:31.19 | pb_ | and, if you have netkit ping rather than busybox ping, sending them a bit faster (-i xxx I think) |
| 21:31.23 | joseph | brb |
| 21:31.34 | joseph | i think its all busybox |
| 21:32.49 | moray | joseph: here, pinging *to* the ipaq I only get 100 packets transmitted, 79 received, 21% packet loss, time 99775ms |
| 21:32.49 | moray | rtt min/avg/max/mdev = 3.684/7.432/29.220/3.788 ms |
| 21:34.05 | *** join/#gpe PaxAnima (~petter@v109a.studby.ntnu.no) |
| 21:34.13 | pb_ | moray: that seems like quite a poor rate of packet loss |
| 21:34.33 | pb_ | moray: are you keeping your ipaq inside a microwave oven/Faraday cage/other bad place? |
| 21:35.00 | joseph | moray why would that happen ? |
| 21:35.42 | moray | pb_: no, but I'm several floors and a few walls from the nearest access point |
| 21:35.52 | joseph | that might do it |
| 21:36.01 | moray | pb_: different parts of my room would give significantly different success rates |
| 21:36.03 | pb_ | moray: ah, fair enough |
| 21:36.06 | joseph | is there any way to list the APs available |
| 21:36.09 | joseph | without using something like kismet |
| 21:36.11 | joseph | which i can't get running anyway |
| 21:36.15 | joseph | on the ipaq |
| 21:36.23 | pb_ | no, I never managed to make kismet work on the ipaq either. |
| 21:36.27 | moray | joseph: I don't think so, unfortunately |
| 21:36.33 | joseph | i want to get kismet working |
| 21:36.35 | joseph | that'd kick ass |
| 21:36.41 | joseph | i have it working on my iBook |
| 21:36.43 | joseph | in linux-ppc |
| 21:36.49 | pb_ | I tried the binary from debian-arm but that was no better. |
| 21:36.56 | pb_ | it seems to have some bizarre problem reading its config file. |
| 21:37.04 | joseph | yeah! that too! |
| 21:37.11 | joseph | along with a weird lib problem too i think |
| 21:37.20 | pb_ | ah, I don't think I saw the lib problem. |
| 21:37.28 | pb_ | but I'm glad it's not just me who has trouble :-) |
| 21:37.37 | joseph | :) |
| 21:37.38 | joseph | yeah |
| 21:37.40 | joseph | it was reading like |
| 21:37.41 | joseph | wl0 |
| 21:37.43 | pb_ | I was hoping florian's prismstumbler would come to my rescue, but it seems to be gtk1 only. |
| 21:37.48 | joseph | instead of wlan0 |
| 21:37.50 | joseph | and stuff like that |
| 21:37.57 | pb_ | right, yeah, that's the same thing I saw. |
| 21:38.04 | moray | indeed - a (working) GTK2 AP viewer would be nice |
| 21:38.46 | pb_ | mallum: I put some source in the gpe ftp directory. |
| 21:38.54 | pb_ | maybe I'll try compiling kismet myself tomorrow. |
| 21:39.00 | joseph | pb_: awesome! |
| 21:39.02 | joseph | let me know how it works out ! |
| 21:39.10 | joseph | i'll look through the source later and see if i see the source of the problem |
| 21:39.15 | joseph | err, that didnt sound good haha |
| 21:39.27 | pb_ | actually, lemme look at the build log first and see if there are any obvious warnings. |
| 21:39.34 | mallum | pb_: cool, thanks :-) |
| 21:39.37 | joseph | hah, good idea |
| 21:39.39 | moray | ~ # kismet_server |
| 21:39.39 | moray | kismet_server: error while loading shared libraries: libstdc++-libc6.2-2.so.3: cannot open shared object file: Error 9 |
| 21:39.48 | moray | is presumably the library problem joseph mentioned |
| 21:39.49 | pb_ | oh, you need libstdc++. |
| 21:39.51 | joseph | got that, too |
| 21:39.52 | joseph | yes |
| 21:39.55 | joseph | actually |
| 21:39.58 | joseph | i dont think it was stdc++ |
| 21:39.59 | joseph | i had that |
| 21:40.00 | joseph | it was another lib |
| 21:40.02 | pb_ | I thought it had the appropriate dependencies when I tried. |
| 21:40.09 | moray | pb_: it claimed to be installing it I think |
| 21:40.12 | pb_ | ah, there was a new debian build of kismet today. |
| 21:40.18 | pb_ | moray: maybe it just needs an ldconfig |
| 21:40.23 | joseph | !! |
| 21:40.25 | joseph | is it in feeds/unstable |
| 21:40.52 | pb_ | not yet |
| 21:41.13 | moray | apparently it installed libstdc++2.10-glibc2.2_2.95.4-0.010407-fam1_arm.ipk |
| 21:41.56 | joseph | moray i really dont think the problem lib was glibc, stdc++ or anything like that |
| 21:41.57 | pb_ | oh, actually, it might be in debian unstable by now, dinstall would have been an hour or so ago. |
| 21:42.00 | joseph | it was som other weird one i've never seen before |
| 21:42.18 | pb_ | it's 2.6.2-6 anyway |
| 21:42.35 | pb_ | and there were no suspicious warnings during the build. |
| 21:42.45 | moray | ( apparently that package gives you libstdc++-3-libc6.2-2-2.10.0.so ) |
| 21:42.48 | joseph | err, the cf card interface just died on me |
| 21:42.49 | joseph | !! |
| 21:42.56 | pb_ | hell |
| 21:43.06 | moray | joseph: you mean it stopped working / crashed the kernel / gave an error ... ? |
| 21:43.24 | joseph | Jan 1 00:04:39 pmod daemon.info klogd: NETDEV WATCHDOG: eth0: transmit timed out Jan 1 00:04:39 pmod daemon.warn klogd: eth0: Tx timeout! Resetting card. ALLOCFID=0128, TXCOMPLFID=0299, EVSTAT=800b Jan 1 00:06:34 pmod daemon.info klogd: NETDEV WATCHDOG: eth0: transmit timed out Jan 1 00:06:34 pmod daemon.warn klogd: eth0: Tx timeout! Resetting card. |
| 21:43.24 | joseph | ALLOCFID=0128, TXCOMPLFID=010e, EVSTAT=800b Jan 1 00:11:24 pmod daemon.info klogd: NETDEV WATCHDOG: eth0: transmit timed out Jan 1 00:11:24 pmod daemon.warn klogd: eth0: Tx timeout! Resetting card. ALLOCFID=0128, TXCOMPLFID=026c, EVSTAT=800b Jan 1 00:13:33 pmod daemon.info klogd: NETDEV WATCHDOG: eth0: transmit timed out Jan 1 00:13:33 pmod d |
| 21:43.25 | joseph | aemon.warn klogd: eth0: Tx timeout! Resetting card. ALLOCFID=0128, TXCOMPLFID=01cd, EVSTAT=800b Jan 1 00:16:14 pmod daemon.info klogd: NETDEV WATCHDOG: eth0: transmit timed out Jan 1 00:16:14 pmod daemon.warn klogd: eth0: Tx timeout! Resetting card. ALLOCFID=0128, TXCOMPLFID=013d, EVSTAT=800b Jan 1 00:20:25 pmod syslog.info -- MARK -- |
| 21:43.29 | joseph | <PROTECTED> |
| 21:43.33 | joseph | shit didn't mean to paste all that |
| 21:43.37 | joseph | but yeah |
| 21:44.03 | moray | hm, with some wireless cards I've got those Tx timeout messages in a fairly harmless way |
| 21:44.26 | *** join/#gpe FlyPiper (~ISP-1@12-222-141-210.client.insightBB.com) |
| 21:45.03 | joseph | mm |
| 21:45.33 | joseph | alright, this could get annoying. |
| 21:47.41 | joseph | and why do so many damn packages have postinst scripts that dont exist/work/etc |
| 21:48.23 | pb_ | joseph: file against them in bugzilla |
| 21:48.33 | joseph | a lot of the opie packages |
| 21:48.45 | pb_ | ah. |
| 21:48.53 | pb_ | you'd have to raise a stink in #opie about those. |
| 21:48.57 | joseph | yea |
| 21:49.03 | joseph | hey man |
| 21:49.07 | joseph | im happy at least the latest build |
| 21:49.09 | joseph | suspends |
| 21:49.11 | joseph | on a 3900 |
| 21:49.11 | pb_ | here in #gpe we laugh in the collective face of the opie packages and their postinst scripts. |
| 21:49.23 | joseph | lol |
| 21:49.38 | pb_ | heh, well in fact right now my latest 3900 build _doesn't_ suspend. :-} |
| 21:49.47 | joseph | gpe or opie? |
| 21:49.55 | pb_ | anything. |
| 21:49.59 | joseph | hmm |
| 21:50.02 | pb_ | I copied the new sa1100 code into the pxa version. |
| 21:50.06 | joseph | if you use 131.152.105.154 archives |
| 21:50.12 | joseph | it will suspend |
| 21:50.25 | joseph | well i haven't tried it with the new kernel |
| 21:50.25 | pb_ | but I think I have found the source of the "only suspends as root" bug now. |
| 21:50.30 | joseph | but with 2.4.19-pxa1 it did |
| 21:50.40 | moray | pb_: oh right, what's that? |
| 21:51.39 | pb_ | moray: new kernel calls pm_helper "synchronously", by forking a thread from the process that called apm and waiting for it to complete, in an attempt to make sure that the pre-suspend scripts really do run before the machine goes to sleep. The older versions used keventd to launch them in a "fire and forget" manner. |
| 21:52.13 | joseph | pb_: err, so, how do you suspend it? |
| 21:52.24 | moray | pb_: ah right |
| 21:52.37 | pb_ | moray: one effect of the new scheme is that pm_helper inherits the calling process's permissions rather than those of keventd, which means it runs with euid 0 but real uid nonzero. |
| 21:53.02 | pb_ | moray: and of course busybox sh does seteuid(getuid) in order to drop any accidentally-acquired root privileges, so it fails. |
| 21:53.47 | pb_ | moray: I'll fix the kernel to set real uid 0 on pm_helper and I think that should cure it. |
| 21:55.06 | joseph | dude |
| 21:55.09 | joseph | this interface keeps dying |
| 21:55.11 | joseph | HOWCOME :( |
| 21:55.23 | moray | pb_: ok |
| 22:03.26 | joseph | pb_: did you ever try the stuff from kismetwireless.net/download.shtml |
| 22:03.30 | joseph | theres an ipaq/arm package |
| 22:03.36 | joseph | will arm packages work on xscale? |
| 22:06.43 | pb_ | joseph: yes |
| 22:07.07 | joseph | its binary compatible right? |
| 22:07.12 | pb_ | right |
| 22:07.23 | joseph | whoo task-obie is done |
| 22:07.25 | pb_ | (no, I've never tried the packages from that site) |
| 22:07.26 | joseph | after all those disconnections |
| 22:07.49 | joseph | ergh |
| 22:08.06 | pb_ | heh |
| 22:09.23 | joseph | damn it |
| 22:09.24 | joseph | i just had it |
| 22:11.01 | joseph | opie-login: error while loading shared libraries: libjpeg.so.62: cannot open shared object file: Error 9 |
| 22:11.04 | joseph | nothing ever works right |
| 22:12.21 | mccarthy | pb_: do you have access to your ipaq currently? (and does it have a recent gpe-calendar?) |
| 22:15.17 | mallum | Could anyone here do a fresh checkout of matchbox from CVS and see if it builds with just './configure --enable-png' ? |
| 22:25.58 | moray | mallum: hm, if I do ./autoconfigure.sh it dies with "configure.ac: 173: required file `./ltmain.sh' not found" "util/Makefile.am:34: variable `APM_PROGS' not defined" but gives me a configure script; a ./configure --enable-png succeeds (but complains "./configure: line 9574: test: =: unary operator expected"; then if I just try make it dies due to the lack of libmbdock - am I meant to have that installed already? |
| 22:27.05 | mallum | moray: cool, thanks for testing |
| 22:28.29 | moray | mallum: (no problem, tell me when you want me to try again) |
| 22:29.29 | *** join/#gpe PaxAnima (~petter@v109a.studby.ntnu.no) |
| 22:29.41 | mallum | moray: Im just about to commit a fix . |
| 22:31.32 | mallum | moray: okey committed, should build now ( ./autoconfigure may give some errors but ignore em' |
| 22:31.47 | joseph | pb_: so currently suspend in gpe doesn't work ? |
| 22:32.18 | moray | joseph: suspend on 3900s doesn't work with his latest testing build, is I thought what he said? |
| 22:32.27 | joseph | but build of what |
| 22:32.34 | moray | joseph: kernel |
| 22:32.36 | joseph | oh |
| 22:34.48 | pb_ | joseph: suspend in gpe works fine, modulo kernel bugs. it will be OK on your machine with any released 3900 kernel. |
| 22:35.09 | pb_ | mccarthy: yes and no in that order, I thinl |
| 22:35.11 | pb_ | k |
| 22:35.58 | mccarthy | pb_: ok |
| 22:36.05 | pb_ | mccarthy: but I can update if you want. |
| 22:36.24 | mccarthy | pb_: could you. I would like to hear if doing this crashes your system.... |
| 22:36.29 | moray | mallum: looks like it's working now - didn't work the first time due to some freetype brokenness on my setup |
| 22:36.30 | mccarthy | 1) open future view |
| 22:36.35 | joseph | pb_: has gpe2 been updated recently? |
| 22:36.40 | mccarthy | 2) open an event (from future view) |
| 22:36.41 | joseph | to fix those annoying install glitches |
| 22:36.47 | mccarthy | 3) cancel the edit of the event |
| 22:36.52 | mccarthy | 4) try to open it again |
| 22:37.03 | mallum | moray: did you enable --enable-xft ? |
| 22:37.18 | pb_ | joseph: I think the pango glitches should mostly be gone. There is still a problem with gdk-pixbuf loaders |
| 22:37.35 | joseph | hmm |
| 22:37.36 | moray | mallum: nope, the problem was only from looking for the header file though, src/matchbox isn't linked against freetype |
| 22:37.47 | joseph | pb_: gpe2 is the only thing i _can_ install from unstable, right ? |
| 22:37.49 | moray | mallum: (arguably that's still wrong I suppose) |
| 22:38.08 | joseph | does gpe in 0.6.1/2 work alright? |
| 22:38.08 | mccarthy | argh! I *hate* that I need to add a 2 to the end of everything! |
| 22:38.28 | moray | mccarthy: it would be less irritating if ipkg warned you it was going to fetch libgtk1.2 I think... |
| 22:38.36 | pb_ | joseph: yeah, gpe1 in unstable probably still exists,but I doubt it works. |
| 22:38.43 | pb_ | joseph: gpe1 in 0.6.1 should be ok |
| 22:38.50 | mccarthy | moray: I *completely* agree |
| 22:38.55 | joseph | pb_: alrighty |
| 22:38.56 | pb_ | moray: yes |
| 22:39.02 | joseph | cause i know the gpe in your images doesn't work a |
| 22:39.46 | mccarthy | pb_: let me know what happens with my "test" |
| 22:39.54 | mccarthy | anyone else wanna try it?! |
| 22:39.57 | pb_ | mccarthy: updating now |
| 22:40.30 | pb_ | btw, I am also building some 2.4.19 -hh5 packages with the suspend fix. |
| 22:40.42 | mallum | moray: hmm, maybe I missed an ifdef somewhere do you know what file gave you the error ? |
| 22:41.22 | moray | In file included from mbdesktop.h:33, |
| 22:41.22 | moray | <PROTECTED> |
| 22:41.22 | moray | /usr/X11R6/include/X11/Xft/Xft.h:35: freetype/freetype.h: No such file or directory |
| 22:41.33 | moray | apparently :/ |
| 22:41.39 | mallum | ah mbdesktop, thought as much :-) |
| 22:41.53 | mallum | I only just remove xft only from that |
| 22:43.15 | pb_ | mccarthy: yes, crashes |
| 22:43.24 | pb_ | mccarthy: I also get a load of Gdk-WARNINGs |
| 22:43.27 | moray | mallum: desktop/.libs/mbdesktop isn't linked against freetype stuff either though, just to confirm |
| 22:43.49 | joseph | pb_: well im really happy i got this 802.11b card working !!! |
| 22:44.01 | pb_ | joseph: yeah, that's certainly good news :-) |
| 22:44.08 | joseph | i just wonder why it didnt work with the 2.4.19-pxa1 kernel |
| 22:44.35 | moray | hm, I wonder why my GNOME2 workspace switcher has decided to only show the current workspace (and not believe in the existence of the others) |
| 22:44.37 | mccarthy | pb_: ok. I have no idea when it will get fixed, but OK. :) |
| 22:44.53 | mallum | moray: yeah, I just committed a fix |
| 22:45.31 | mallum | moray: matchbox now has loads of configure options ( see ./configure --help ), Im just trying to get them all combinations working |
| 22:45.53 | mallum | moray: currently only --enable-png is needed ( but will go soon ) |
| 22:45.59 | moray | mallum: yup - you seem more determined to beat autoconf into submission than the rest of us ;) |
| 22:46.39 | mallum | moray: yeah, currently Im beating it pretty good |
| 22:46.57 | joseph | pb_: leaving the wifi card in the jacket while the ipaq is in suspend doesn't draw any power right? |
| 22:47.57 | *** join/#gpe dc_ibook (~dctanner@modem-20-63-60-62.vip.uk.com) |
| 22:47.59 | dc_ibook | :) |
| 22:48.06 | pb_ | dc_ibook: evening |
| 22:48.11 | moray | hello dc_ibook |
| 22:48.40 | dc_ibook | evening moray, pb_ |
| 22:49.07 | pb_ | dc_ibook: I tried to build a gpe-irc ipk yesterday, but it seemed to be missing some pixmaps in cvs. |
| 22:49.08 | dc_ibook | I managed to finish of most of the colors config in a free period today :) |
| 22:49.18 | pb_ | dc_ibook: ah cool :-0 |
| 22:49.24 | dc_ibook | yep |
| 22:49.29 | dc_ibook | I also made the pixmaps. |
| 22:49.33 | joseph | pb_: when is mmc support coming, any idea? |
| 22:49.34 | dc_ibook | lemme commit them now |
| 22:49.42 | pb_ | joseph: no idea |
| 22:50.03 | joseph | who is working on it ? |
| 22:50.08 | pb_ | joseph: nobody right now |
| 22:50.10 | joseph | oh |
| 22:50.20 | dc_ibook | pb_: ah wait, I need to debug this outstanding segfault first. |
| 22:50.29 | pb_ | joseph: I have the specs for the SD block, but I haven't actually done anything yet. |
| 22:50.34 | mccarthy | later all....anyone that feels like tracking down the weird Gdk/X bugs in gpe-calendar please feel free ;) |
| 22:50.43 | dc_ibook | mccarthy: ;p |
| 22:51.16 | mccarthy | dc_ibook: but I *did* figure out how to make the rescheduled alarms work nicely (before I threw in the towel on this weord bug) |
| 22:51.20 | mccarthy | ! |
| 22:51.23 | mccarthy | night |
| 22:51.41 | *** part/#gpe mccarthy (~mccarthy@granular.che.pitt.edu) |
| 22:55.13 | pb_ | dc_ibook: ok, let me know when it is ready. |
| 22:55.41 | joseph | pb_: alright, got that stupid voluteer thing now |
| 22:55.47 | joseph | so, see ya |
| 22:55.47 | pb_ | joseph: enjoy |
| 22:55.50 | joseph | thanks for the info yet again!!!!@#!! |
| 22:56.14 | joseph | i'll be on later but you'll probably be sleeping by that time |
| 22:56.18 | joseph | being in gmt and all :-P |
| 22:56.21 | joseph | so goodnight |
| 22:58.40 | pb_ | dc_ibook: btw, I bought an ibook for myself today. |
| 22:58.46 | mallum | dc_ibook: hey |
| 22:58.53 | dc_ibook | mallum: evening :) |
| 22:59.00 | dc_ibook | pb_: oh really?? |
| 22:59.07 | mallum | pb_: really ? |
| 22:59.34 | moray | some I think it mentioned earlier, but what's the problem behind / solution to lots of "(gpe-soundbite:3587): Gdk-WARNING **: Error converting from UTF-8 to STRING: Conversion from character set 'UTF-8' to 'ISO-8859-1' is not supported" |
| 22:59.41 | dc_ibook | pb_: welcome to the club! |
| 22:59.45 | pb_ | dc_ibook: well, I tried. had the usual problem with my credit card being declined, so I will have to talk to my bank tomorrow and get them to take the stop off it again. |
| 23:00.02 | mallum | pb_: the mini tibook ? |
| 23:00.10 | dc_ibook | pb_: oh heh, well, sounds cool. |
| 23:00.12 | moray | pb_: hm, so you didn't decide to go for one of these 17" apple laptops? ;) |
| 23:00.18 | dc_ibook | pb_: yah, the cute white one ;] |
| 23:00.20 | dc_ibook | ? |
| 23:00.58 | pb_ | mallum: no, the older 12" ibook (G3 8000. the new mini tibook is cool but hugely more expensive. |
| 23:01.03 | pb_ | er, 800 not 8000 |
| 23:01.12 | pb_ | moray: heh, no |
| 23:01.26 | pb_ | dc_ibook: yah |
| 23:01.31 | mallum | pb_: cool , probably better supported anyway |
| 23:01.42 | pb_ | mallum: yeah, the new ones have nvidia graphics which I also didn't fancy |
| 23:01.44 | mallum | pb_: Im sure you'll be really pleased with it |
| 23:01.56 | mallum | pb_: yeah, which means no accel drivers |
| 23:02.02 | dc_ibook | pb_: yep, I can tell you from experience :)) |
| 23:02.16 | moray | mallum: I was still put off by the one buttonness - although I suppose it's good practice for GPE... |
| 23:02.24 | pb_ | mallum: cool, I'm sure I will be. |
| 23:02.32 | mallum | moray: I just run xmonobut ;-) |
| 23:02.52 | dc_ibook | pb_: there's a great tutorial for the white iBooks which also covers some of the special iBook keys and debian netinst :] |
| 23:02.56 | mallum | moray: plus you can map keys to the missing mouse buttons via the kernel |
| 23:02.57 | dc_ibook | pb_: usefull at times. |
| 23:03.02 | pb_ | dc_ibook: ah cool |
| 23:03.04 | mallum | biab - supranos time |
| 23:03.17 | dc_ibook | as I found out when I almost killed my yaboot yesterday ;} |
| 23:03.30 | moray | anyone know what I should do about the error up there that got lost in the celebration, btw? |
| 23:03.39 | pb_ | moray: ah yes :-) |
| 23:03.49 | pb_ | moray: you need to install the iso8859-1 gconv module. |
| 23:03.58 | moray | hm, I think I thought I'd done that |
| 23:04.11 | pb_ | moray: apparently glibc disagrees. |
| 23:04.22 | moray | ah, presumably same problem with regenerating an appropriate file then? |
| 23:04.30 | pb_ | moray: shouldn't be, actually. |
| 23:04.46 | moray | hm, I'll check if ipkg has done something silly then |
| 23:05.07 | pb_ | moray: the appropriate file in this case is /usr/lib/gconv/gconv-modules, which is static (but provided by the gconv-modules package, which you conceivably might not have installed) |
| 23:05.50 | pb_ | moray: also check that the versions match on libc6 and gconv-module-iso8859-1: you can't use 2.3 libc with 2.2 gconv modules, or presumably vice versa. |
| 23:05.52 | pb_ | dc_ibook: :-/ |
| 23:10.08 | dc_ibook | galeon crashes when I try to copy a url from it, heh. |
| 23:10.18 | pb_ | heh. |
| 23:10.28 | dc_ibook | pb_: well, just search for debian ibook install or something, it can be usefull at times. |
| 23:10.59 | moray | pb_: well, apparently I didn't have a gconv-modules file at all, for whatever reason (despite the package being installed) - it's possible some stuff is still broken from the last time I filled up flash |
| 23:10.59 | dc_ibook | pb_: now, with sql. |
| 23:11.04 | pb_ | dc_ibook: are you using a utf-8 locale there? I remember I used to have problems with gtk1 apps crashing during cut and paste if I set anything exotic or invalid as my locale. |
| 23:11.21 | pb_ | moray: ah right. |
| 23:12.08 | dc_ibook | pb_: ah, yes, must be the case then. |
| 23:12.11 | dc_ibook | pb_: oh well |
| 23:12.29 | pb_ | dc_ibook: best upgrade to galeon-snapshot. anyway, what were you saying about sql? |
| 23:12.42 | dc_ibook | pb_: with the sql command "replace into config ('property', 'value') values (NULL, '%q', '%q')" it should replace any previous values in property right? |
| 23:13.05 | dc_ibook | pb_: well, basicly, in my table i have 3 columns. |
| 23:13.12 | dc_ibook | pb_: id, property, tag |
| 23:13.27 | dc_ibook | pb_: and I want to change the tag value in some rows. |
| 23:13.51 | dc_ibook | pb_: but I only have the values for property and tag, and not id. |
| 23:14.09 | pb_ | dc_ibook: well, my sql is a bit rusty, but I thought it was something like "update config set tag='%q' where property='%q' and tag='%q'" or whatever |
| 23:14.29 | dc_ibook | ahhh |
| 23:14.31 | dc_ibook | <PROTECTED> |
| 23:15.29 | pb_ | dc_ibook: if you have no joy with that, I can probably find my sql book and look up the actual syntax. |
| 23:16.17 | dc_ibook | pb_: do I have to have the previous value of tag? |
| 23:16.26 | pb_ | dc_ibook: nope |
| 23:16.31 | dc_ibook | pb_: good'o |
| 23:16.36 | pb_ | dc_ibook: you can just say "where property=..." |
| 23:17.05 | dc_ibook | good |
| 23:18.45 | dc_ibook | yay |
| 23:18.47 | dc_ibook | works :) |
| 23:18.50 | dc_ibook | pb_: thanks. |
| 23:18.51 | pb_ | cool |
| 23:19.54 | dc_ibook | oh...h |
| 23:19.57 | dc_ibook | hrm |
| 23:20.14 | dc_ibook | I think I spoke too soon |
| 23:20.25 | pb_ | ah. :-/ |
| 23:20.33 | dc_ibook | now it has worked, but also inserted copys. |
| 23:20.39 | dc_ibook | how about... |
| 23:20.52 | dc_ibook | if I made the property column UNIQUE? |
| 23:21.02 | dc_ibook | can you do that like in mysql |
| 23:21.11 | pb_ | you can, but I doubt it will help. |
| 23:21.16 | dc_ibook | oh. |
| 23:21.36 | pb_ | making it UNIQUE will just mean you get an SQL error if you try to insert a duplicate entry, which is probably not what you want. |
| 23:21.50 | dc_ibook | riht |
| 23:22.16 | dc_ibook | what if I remove the id column....which I don't reallty need, and make that PRIMARY KEY |
| 23:22.25 | pb_ | the "update" command shouldn't be creating any duplicates. Are you sure you don't have any stray INSERTs? |
| 23:22.30 | dc_ibook | or should the solution be in my original edit call? |
| 23:22.57 | pb_ | I think it should. |
| 23:23.11 | pb_ | It doesn't seem like you should need to change the schema. |
| 23:23.12 | dc_ibook | hm |
| 23:23.16 | dc_ibook | pb_: okay. |
| 23:23.35 | dc_ibook | lemme commit the code and images anyhow. |
| 23:23.52 | pb_ | ok |
| 23:26.09 | dc_ibook | pb_: right, should compile atleast now. |
| 23:26.26 | pb_ | dc_ibook: cool, let me try |
| 23:30.55 | moray | mallum: I presume that gpe-soundbite still upsets mbdesktop by having parameters in its Exec= line in the .desktop files? - checking on my desktop, various Debian packages do have options in that line too, so it's *presumably* meant to be allowed |
| 23:31.17 | dc_ibook | I guess |
| 23:31.33 | *** join/#gpe FlyPiper (~ISP-1@12-222-141-210.client.insightBB.com) |
| 23:31.36 | pb_ | moray: oh yeah, I was planning to build some scripts to work around that temporarily. |
| 23:31.57 | pb_ | moray: ie create "/usr/bin/gpe-soundbite record" and "/usr/bin/gpe-soundbite play" that just exec gpe-soundbite with the right arguments. |
| 23:32.24 | moray | pb_: hm, soundbite appears to be good at causing this sort of problem, what with the two programs in one menu upsetting appmgr previously... |
| 23:32.43 | dc_ibook | hehe |
| 23:32.57 | pb_ | moray: heh, yes. |
| 23:33.17 | dc_ibook | pb_: does it compile? |
| 23:33.23 | moray | pb_: yes, I was just checking that mallum wasn't about to fix it before I bothered making a version with scripts like that |
| 23:33.29 | dc_ibook | pb_: not missing any more source files or images ;] |
| 23:33.41 | pb_ | moray: like you say, I'm fairly sure the args-in-exec thing ought to work. mbdock does have code for an execs() function that knows how to break up the commandline, so I guess using that would fix it. |
| 23:33.47 | pb_ | dc_ibook: seems to work fine, you want me to upload the ipk? |
| 23:33.56 | dc_ibook | pb_: yes pleas. |
| 23:34.03 | pb_ | dc_ibook: ok |
| 23:34.05 | dc_ibook | pb_: I'll test tomorrow night :) |
| 23:34.10 | dc_ibook | sleep for me now. |
| 23:34.16 | pb_ | dc_ibook: done. |
| 23:34.20 | dc_ibook | I guess I should download the SQL docs. |
| 23:34.21 | pb_ | dc_ibook: g'night |
| 23:34.22 | dc_ibook | :] |