**** BEGIN LOGGING AT Mon Jul 11 20:02:14 2011 Jul 11 20:04:40 logger test Jul 11 20:06:07 linuxjacques, logs for this channel now work Jul 11 20:06:43 thanks guys Jul 11 20:10:58 thanks dyoung Jul 11 21:18:00 linuxjacques: it's the latest version! :( Jul 11 21:18:40 hehe Jul 11 21:21:39 dtzWill: maybe I am wrong, but isn't 1.10 released? Jul 11 21:23:37 I could swear I'm using it in gentoo Jul 11 21:25:05 http://lists.freedesktop.org/archives/xorg/2011-July/053281.html Jul 11 21:25:12 (the 1.10.3 announcement) Jul 11 21:30:24 lol, a guy posted a detailed message on the xorg list asking for help on a feature of a light-weight window manager he's writing, and got one response "Why are you writing a new WM?" Jul 11 21:37:13 :D Jul 11 21:37:18 linuxjacques, since when are you using gentoo? Jul 11 21:38:41 PuffTheMagic, he always has. Jul 11 21:38:46 I do too. Jul 11 21:39:05 i thought i was the only one here Jul 11 21:39:14 nope Jul 11 21:42:08 PuffTheMagic: since 2001 Jul 11 21:42:19 OK, maybe it was 2002 Jul 11 21:43:17 speaking of which, this looks interesting: http://mirrors.kernel.org/gentoo/releases/arm/autobuilds/current-stage3-armv7a_hardfp/ Jul 11 21:43:48 I have to use Fedora for work, and as such use it on some of my laptops Jul 11 21:44:29 My iMac has been on gentoo since early 2008 Jul 11 21:44:58 linuxjacques, yup i use those images Jul 11 21:45:08 for my chroots ;) Jul 11 21:45:33 ah, cool, I didn't know you had arm chroots Jul 11 21:46:16 not something i brag about because i dont find them entirely useful Jul 11 21:46:32 i dont like use non-touchscreen environments on touchscreen devices Jul 11 21:47:18 non-touchscreen optimized environments Jul 11 21:47:29 nod Jul 11 21:47:53 I was using my apple BT keyboard with my tp, and I was annoyed that I had to keep touching the screen Jul 11 21:48:14 even web surfing, no Ctrl-L to select the address bar Jul 11 21:48:30 and to scroll :-( Jul 11 21:50:03 and I need a touchstone dock. some of the best buys in my metro area have them, but none near me yet Jul 11 21:50:36 neither does the one near me Jul 11 21:50:57 but usually have it plugged into usb when not in use Jul 11 21:51:03 so i can dev on it Jul 11 21:51:24 me too, but sometimes I want it to be standing Jul 11 21:51:43 i dont use a kb on it so i really dont have that need ;) Jul 11 21:54:47 any of you ever use sched_yield? Jul 11 21:56:22 yes Jul 11 21:56:28 even though they say not to Jul 11 21:56:30 they are wrong Jul 11 21:56:31 lol Jul 11 21:56:32 for my case Jul 11 21:56:38 you talking about ingo's rant? Jul 11 21:57:14 I started using it in 2007, so I don't recall who said not to use it - maybe even the man page says Jul 11 21:57:27 if you ahve a link, I can tell you if that's what I saw Jul 11 21:57:40 basically, they said "you should never need to use this" Jul 11 21:57:43 http://kerneltrap.org/Linux/Using_sched_yield_Improperly Jul 11 21:58:16 im trying to keep my plugin from locking up luna Jul 11 21:58:32 i dont know if i should yield or do a usleep(10) Jul 11 21:59:55 enyo does not seem to play nice with hybrids Jul 11 22:00:25 my app clearly benefits from using sched_yield(), though he would probably just say I should have written the app differently or something Jul 11 22:00:53 I have throughput numbers to prove it Jul 11 22:02:43 is the 10 uS value chosen for a reason? Jul 11 22:02:56 no Jul 11 22:03:23 i had my mendeley app running so smooth and fast using jsoauth Jul 11 22:03:30 but i couldnt download the pdfs Jul 11 22:03:36 and write them in sane way Jul 11 22:03:47 i needed to write a plugin to do that Jul 11 22:03:54 and there is a limit of how much u can send at once Jul 11 22:04:04 so i switched to doing everything int he plugin using liboauth Jul 11 22:04:09 and now the app runs like shit Jul 11 22:04:25 in my case yield is better bacause of the requeuing on the scheduler - I want the thread to relinquish the CPU, but I want it to go to work again as soon as the other threads have had a turn Jul 11 22:04:25 if i dont use threads for some of the http requests it runs slow Jul 11 22:04:35 and with threads it seems to hand and not do shit Jul 11 22:05:34 hanging could be a locking problem in palm's or your code Jul 11 22:05:53 well its not so much as hanging Jul 11 22:06:11 as it is something else i can describe Jul 11 22:06:17 as going very very slow? Jul 11 22:06:38 if i dont use threads it always works but goes slow Jul 11 22:07:05 using threads it seems like it looses shit Jul 11 22:07:11 or threads never return or something Jul 11 22:07:26 hmmm. race with data loss? Jul 11 22:07:40 ok so here is what happens Jul 11 22:07:54 i make a call to the server which gets a list of document ids Jul 11 22:08:02 then for each doc id i need to fetch its details Jul 11 22:08:16 so if I fetch each details serially its SOOO slow Jul 11 22:08:24 so i started spawning them in their own threads Jul 11 22:08:32 which was super fast Jul 11 22:08:51 but then it would come to a point where i couldnt call pthread_create any more Jul 11 22:08:56 i hit some limit Jul 11 22:09:07 so then i started just using 20 threads and doing a join on them Jul 11 22:09:19 thread pool? Jul 11 22:09:37 that is prob what i should be using but i've never implemented one in C Jul 11 22:09:52 though I guess if you are joining them it's not technically a pool Jul 11 22:10:01 no its not a pool Jul 11 22:10:07 that is prob what i need though Jul 11 22:10:13 my understanding of a pool is threads waiting around for stuff to do Jul 11 22:10:20 ya Jul 11 22:10:22 they are long liived Jul 11 22:11:02 i know how the work conceptually Jul 11 22:11:11 but i've only use them in lisp and python Jul 11 22:11:19 where there were higher levels libs to handle it Jul 11 22:12:34 I haven't implemented a pool, only because my app didn't need one, but the hardest part is probably the managing of the pool - giving the threads their jobs and retrieving the results Jul 11 22:14:37 something as simple as two queues might work - put "tasks" on one queue, threads dequeue and go to work, and put results on another queue, and wait for more work Jul 11 22:15:47 that rant of ingo's looks familiar, but I'm pretty sure that date is after I started using sched_yield(0 Jul 11 22:29:51 dtzWill: dso git pull and make stage in xserver-package is all I need? Jul 11 22:30:09 dtzWill: *** No rule to make target `build_x/recordproto', needed by `build_x/xorg-server'. Stop. Jul 11 22:30:45 dtzWill: missing checkin perhaps? Jul 11 22:33:25 rwhitby: absolutely, sorry! Jul 11 22:33:26 just pushed Jul 11 22:33:28 morning rwhitby Jul 11 22:34:21 dtzWill: no worries Jul 11 22:34:30 got lost, also have an x_full branch that runs a full x server that i was debating creating video/input drivers for Jul 11 22:34:42 ++ Jul 11 22:35:07 which might be a good idea down the road, but don't hvae a particularly compelling set of reasons for atm Jul 11 22:36:54 dtzWill: what should I expect to see recompiling in widk? Jul 11 22:37:25 Requested 'xproto >= 7.0.17' but version of Xproto is 7.0.16 Jul 11 22:37:27 rwhitby: well you probably need to rebulid most of x/* Jul 11 22:37:32 Requested 'xfont >= 1.4.2' but version of Xfont is 1.4.1 Jul 11 22:37:48 the version bumps don't cause it automatically? Jul 11 22:38:07 cause if they don't we need to fix that Jul 11 22:38:34 rwhitby: right. as mentioned earlier (err i meant to, not sure if i actually did, was pretty outta it) it doesn't deal well with changing versions Jul 11 22:38:48 (build/%.built doesn't include version is primary issue i think) Jul 11 22:38:53 ah, all the build/%.built targets and build/.unpacked targets need -${VERSION} added to them Jul 11 22:38:55 well unpacked too. really the whole thing ^.^ Jul 11 22:39:02 whoopsy. Jul 11 22:39:08 HOLY SHIT Jul 11 22:39:11 and yes that should do it Jul 11 22:39:27 linuxjacques, the threadpool is like instantaneous Jul 11 22:40:14 dtzWill: so a clobber in packages/x is all I need? Jul 11 22:40:15 PuffTheMagic: very nice Jul 11 22:40:38 i used this -> http://people.clarkson.edu/~jmatthew/cs644.archive/cs644.fa2001/proj/pthreadsPool/ Jul 11 22:41:39 i dont even get a chance to seem up loading screen/progress bar Jul 11 22:43:24 ahh fixed that Jul 11 22:43:27 heh, good problem to have Jul 11 22:43:50 no its because i make a call to the plugin to fetch the library Jul 11 22:44:01 which used to start a main thread Jul 11 22:44:12 which from there spawned all the sub worker threads Jul 11 22:44:24 i did that so that the plugin call would return Jul 11 22:44:31 but i got rid of that thread Jul 11 22:44:40 which was causing luna to wait Jul 11 22:44:46 dtzWill: will try to replicate new stable baseline this morning Jul 11 22:44:51 i added that thread back and i get my progress updates Jul 11 22:49:52 damn it still gets stuck Jul 11 22:50:00 rwhitby: should be all you need, yep Jul 11 22:50:04 rwhitby: new stable baseline? Jul 11 22:50:27 dtzWill: what you have running now Jul 11 22:50:31 rwhitby: you see what i said about xwininfo/etc? should be what we need Jul 11 22:50:41 yep Jul 11 22:50:54 we have to convert to characters for XTerm though Jul 11 22:51:57 characters? Jul 11 22:52:11 oh you can't specify it in raw geometry?! Jul 11 22:52:17 xterm geometry is in characters, not pixels Jul 11 22:52:27 alright, well we can poke at it. Jul 11 22:52:28 bbiab Jul 11 22:52:29 linuxjacques, i think i need to do a sched_yield after each http_get Jul 11 22:52:39 that seems to have resolved the stalling/hanging Jul 11 22:52:54 socket/buffer overflow maybe Jul 11 22:53:59 PuffTheMagic: interesting. I woudln't have anticipated that Jul 11 22:54:09 its still not perfect Jul 11 22:54:13 idk whats going on here Jul 11 22:54:29 pool though still seemed to be a major improvement Jul 11 22:54:35 maybe the tp needs its tcp parameters tuned Jul 11 22:54:39 * rwhitby bbl Jul 11 22:54:59 linuxjacques, i didnt have any issues when was using all js though :/ Jul 11 22:54:59 I know I have problems ssh'ing into the tp over wifi Jul 11 22:55:06 hmm Jul 11 23:31:49 dtzWill: build worked, and runs well. Yes, we need something to fill that space :) Jul 11 23:32:14 rwhitby, were you able to get that tarball to build last night? Jul 11 23:32:27 cryptk: nope Jul 11 23:32:41 kk, I will look into it today if I have time Jul 11 23:32:49 I may not have time since it is the b day and all Jul 11 23:33:14 indeed. Happy B'day - get your priorities right. Jul 11 23:47:08 egaudet, ping! Jul 11 23:48:14 happy birthday cryptk, how old are ya now? Jul 11 23:48:56 yeah, happy birthday cryptk! Jul 11 23:49:10 27 Jul 11 23:50:21 dtzWill: so, we should bump some versions and tags for this new baseline Jul 12 00:37:57 cryptk|offline: happy bday! ^.^ Jul 12 00:37:59 rwhitby: indeed Jul 12 00:38:13 agenda i see is to tag the build Jul 12 00:38:26 get xterm resizing properly Jul 12 00:38:30 update the keymapping Jul 12 00:39:03 oh and probably reorganize things a bit better, x_restructure is a bit of a mess atm Jul 12 00:39:45 i suppose getting what we have cleaned up and in the testing feed Jul 12 00:39:49 is a good primary goal atm Jul 12 00:39:58 also, glad it works well for you too :) Jul 12 00:41:21 dtzWill, the server is working nice... Jul 12 00:42:09 ka6sox-farfarawa: ^.^ you got a copy? :D Jul 12 00:42:26 (not sure what the last copy sent to you was, or maybe rwhitby hooked you up with an ipk) Jul 12 00:42:36 but yeah it is working nice, i'm happy with it. Jul 12 00:42:49 dtzWill, is there something newer than 0.5.0? Jul 12 00:43:33 0.5.0 is what I'm using Jul 12 00:43:44 scoutcamper: not usefully. we have support for on screen keyboard goodness (using the normal palm one), and it sizes things accordingly Jul 12 00:44:15 also rwhitby added logic that has it detect orientation via accelerometer on startup and orient things accordingly, which is useful Jul 12 00:44:29 dtzWill, k, i am setting up to build it from git tonight anyway Jul 12 00:44:53 however the onscreen keyboard stuff doesn't work atm, someone at palm told me on #webos that in theory taht'll be fixed in the next update Jul 12 00:45:21 so hopefully that comes together soon, but b/c of that it's still a WIP Jul 12 00:45:28 yeah Jul 12 00:46:56 the the base server is mostly the same. also updated it (and all the libraries packaged with it) to have about ayear's worth of fixes and the like Jul 12 00:47:06 but afaict it runs the same, but in theory is slightly better. maybe. Jul 12 00:47:40 allright Jul 12 00:47:41 cool Jul 12 00:47:51 dtzWill: I'd like to do the clean up before we worry about xterm size - we can fudge that for the moment, but I want to get the packaging clean before we start letting other people test it Jul 12 00:49:01 rwhitby: sounds good/agreed Jul 12 00:50:34 dtzWill: what's your hacking schedule today? Jul 12 00:52:22 rwhitby: good question. i apologize that i'm so ad-hoc on that front :) Jul 12 00:52:43 gonna get some more work done (you know, bills and all hehe), but can probably spend a good amount of time doing stuff Jul 12 00:52:58 esp some slightly mindless things like cleaning up the build Jul 12 00:53:04 rwhitby: what do you think our priorities should be? Jul 12 00:53:44 dtzWill: I think getting x_restructure to the point where each package is only built once Jul 12 00:53:57 (so that it can eventually replace trunk) Jul 12 00:54:29 dtzWill: and I'd like to go through the xserver install fileset and prune anything which is not related (e.g. keymaps and stuff for other devices) Jul 12 00:54:58 dtzWill: and go through and make sure everything has the final name (e.g. rename palm-prex to something more sensible for the whole webOS range) Jul 12 00:55:23 dtzWill: basically take the current functionality, and get it ready for a production build at this baseline Jul 12 00:57:33 okay, great. Jul 12 00:59:52 * rwhitby bbiab Jul 12 01:02:08 grrrrr Jul 12 01:02:26 i am SO damn sick of eclipse crashing Jul 12 01:02:29 dann HP Jul 12 01:03:20 lol Jul 12 01:04:01 does eclipse provide some kind of integrated enyo debugging or something? Jul 12 01:13:29 rwhitby: hmm, i guess we'll have an 'xlib' package again? Jul 12 01:14:24 the issue is the various binaries (X as well as xterm) need libraries (dynamically configurable via rpath/LD_LIBRARY_PATH), and misc resources (fonts, keymapping stuffs, etc, not configurable atm) Jul 12 01:18:20 maybe just ship them all in the xserver packagef Jul 12 01:18:26 so the xserver is self-container Jul 12 01:18:27 *contained Jul 12 01:18:33 could be app-cat compat if we wanted that direction Jul 12 01:18:53 and xterm just ships the tiny binary, and expects to be able to find xserver's package Jul 12 01:19:02 which is fine since we need to break the jail for xterm anyway Jul 12 01:19:16 and having *other* x clients depend on the server is kinda lame, but might just be a tad cleaner Jul 12 01:19:37 (I feel this is how things like gnome depending on sound drivers happens in ubuntu...) Jul 12 01:24:40 dtzWill, latest webos/eclipse plugin does a tail -f /var/log/messages | grep Jul 12 01:24:42 or something like that Jul 12 01:24:52 and pipes it to the eclipse console Jul 12 01:25:59 oh, interesting. Jul 12 01:26:03 and that fails? :( Jul 12 01:27:05 every now and then launching a the app im working on breaks somthing Jul 12 01:27:14 and then eclipse stops responding Jul 12 01:27:18 so i have to kill it Jul 12 01:27:21 and start it back up Jul 12 01:27:29 :( Jul 12 01:29:33 rwhitby: should we maybe make xecutah a bit more primary-x-interaction-deal? Jul 12 01:29:41 worded less terribly, maybe it can determine what packages you have installed Jul 12 01:29:51 and/or know what packages exist, and have menus for them. Jul 12 01:30:03 perhaps launching xserver as part of launching xterm or so Jul 12 01:30:05 (misc ideas) Jul 12 01:30:15 on one hand keeping it dead simple is a huge win Jul 12 01:30:24 on the other hand might be nifty/useful to give it more functionality, idk Jul 12 01:30:39 might be nice for it to hit up preware and tell you about xecutah-compat packages Jul 12 01:30:50 and let you install them, in response to preware updating feeds Jul 12 01:31:13 (similar to the way just type works, or the way i'm guessing it works--by exporting the info in a way that's externally searchable) Jul 12 01:32:04 this all of course also hinges on what direction we go--ship resizable chroot and let people just apt-get things (and if so, do we try to provide a frontned a-la cydia), or do we try to package things ourselves? Jul 12 01:32:42 Jul 12 01:35:41 also, if xecutah controls 'everything' Jul 12 01:35:48 dtzWill: yes, xecutah will eventually turn into that front-end Jul 12 01:35:50 it can do things like spawn multiple xservers on different displays Jul 12 01:35:54 and run one client each Jul 12 01:35:54 at the moment, let's keep it simple Jul 12 01:36:18 which could be nice and useful Jul 12 01:36:36 rwhitby: mkay, i'm good with that, just dumping some ideas :) Jul 12 01:36:42 * dtzWill is cleaning up x_restructure atm Jul 12 01:36:47 (rebuilding to make sure everything still works hhee) Jul 12 01:36:56 yep, let's keep those ideas in front-of-mind as we go, so we can architect to support them in the future Jul 12 01:37:02 (I agree with all the ideas as good things) Jul 12 01:37:11 hooray :D Jul 12 01:38:35 so let's talk about how to package it Jul 12 01:42:47 dtzWill: is there any benefit to distributing the X libraries separately from the server? Jul 12 01:43:12 i.e. will anyone ever want to run an x client on a webOS device without also having a X server running? Jul 12 01:43:49 (I know you can do that for running x clients on the webOS device and displaying on a remote X server, but that's a niche case) Jul 12 01:45:28 dtzWill: I think we want both individually packaged clients (like xterm) for casual users, and also to support the full chroot solution for power users. Jul 12 01:48:36 rwhitby: exactly my thoughts re:"is there really a point in splitting xlibs from xserver" Jul 12 01:48:46 rwhitby: okay, great re:app packaging solution. Jul 12 01:49:04 we stage things we can/have demand comparable to complexity hehe Jul 12 01:49:08 and let chroot handle the power users Jul 12 01:49:13 who want kde or something :) Jul 12 01:50:13 dtzWill: ok, next thing is naming agreement then Jul 12 01:50:15 scoutcamper: what issues are you seeing in the WIDK? (pastebin?) Jul 12 01:50:27 org.webosinternals.xserver for the server package Jul 12 01:50:29 rwhitby: for the moment i have xserver (And xlibs) as org.webositnernals.xserver and the xterm standalong as xterm Jul 12 01:50:37 (very very changeable, just starting point for conversation) Jul 12 01:50:42 org.webosinternals.xterm for the xterm (which depends on xserver) Jul 12 01:50:53 * dtzWill nods Jul 12 01:51:33 damn i want control over my launcher pages Jul 12 01:51:39 the damn toolbar thing is hella empty Jul 12 01:51:48 now, palm-pre and palm-prex keymaps - what should they really be called? Jul 12 01:52:08 i don't remember their details, i want to say palm-prex should just replace palm-pre Jul 12 01:52:17 i don't remember the details of those, tbh :/. they're.. lame :( Jul 12 01:52:25 (my way of saying i don't understand them) Jul 12 01:52:41 i figured them out enough to get it going, but it was never something i really knew what i was doing. Jul 12 01:52:43 BTW, the keymaps dir has a README saying that dir should not be used, and that the rules dir should be used instead Jul 12 01:52:51 lol Jul 12 01:52:54 well, great >.< Jul 12 01:53:11 yeah having to manually invoke xkbset or w/e is kinda lame too, but i'm not sure we can make kdrive do the right things automagically Jul 12 01:53:25 well the existing keymappings work for the pre Jul 12 01:53:28 dtzWill, http://pastebin.com/y1D9Xuk0 Jul 12 01:53:29 no idea how they work on the pixi Jul 12 01:53:41 dtzWill, im sure i missed something simple Jul 12 01:53:44 they kind-of work on the touchpad, but we'll want a separate touchpad keymapping Jul 12 01:54:04 (or at least let's assume that and rejoice if somehow they work out well, but i don't think they will) Jul 12 01:54:14 so we want palmpre, palmpixi, hpveer, and hptouchpad keyboard configs? Jul 12 01:54:16 scoutcamper: oh, very sorry. Jul 12 01:54:22 scoutcamper: all of this is built from the WIDK Jul 12 01:54:31 rwhitby: i ..guess? :/ Jul 12 01:54:35 (yes) Jul 12 01:54:39 dtzWill, lol Jul 12 01:54:53 i don't have a veer to play with, i'd naively expect the veer to be similar to the pre, but what do i know. Jul 12 01:54:59 scoutcamper: which is a big adventure all by itself Jul 12 01:55:23 dtzWill, ive got widk built Jul 12 01:55:53 scoutcamper: okay well checkout the x_restructure branch, and from 'packages/x/xserver-package/' run 'make stage' Jul 12 01:55:54 scoutcamper: x_restructure branch Jul 12 01:56:07 if that works, run 'make package' to make an ipk, and 'make install' to install it. Jul 12 01:56:19 not sure re:intsall, i typicaly just run 'make stage -j8 && make test' Jul 12 01:57:58 rwhitby: xserver from cleaned x_restructure looks good Jul 12 01:58:01 building xterm package atm Jul 12 01:58:58 oh wtf "please include X11/Xlib.h before xutf8.h" Jul 12 01:59:00 grumble grumble Jul 12 02:05:45 fwiw xterm does *not* build properly atm, investigating. Jul 12 02:05:51 doesn't seem like a restructuring thing...weird. Jul 12 02:06:18 dtzWill, so far it seems to be working :D Jul 12 02:07:03 scoutcamper: hooray! be patient, hehe. if you have mutiple cores the -j option is supported by the WIDK infrastructure, but some packages don't play nice or have missing deps Jul 12 02:07:29 this is my old 1 core laptop that ive converted into a dev machine Jul 12 02:07:30 so you can speed things up that way, if you're wililing to re-try when a package fails, perhaps building serially to get past a particular misconfigured package Jul 12 02:07:40 mkay then just watch the text fly by ^.^ Jul 12 02:08:38 errr xterm has a +maximized resource optoin? Jul 12 02:08:43 (looking at the source) Jul 12 02:08:45 hehe Jul 12 02:09:05 sweet Jul 12 02:09:13 no idea how it works/what it does Jul 12 02:09:14 but Jul 12 02:09:16 maybe :) Jul 12 02:09:25 (will poke at it once get this building properly again) Jul 12 02:09:38 * dtzWill blames luti Jul 12 02:09:39 luit Jul 12 02:10:23 and wide-char. Jul 12 02:10:34 nopers, still fails >.< Jul 12 02:11:14 dtzWill, http://pastebin.com/KFjh3eMU Jul 12 02:11:27 dtzWill, are you building on mac or linux? Jul 12 02:11:29 ok, xserver fails to start on Pre 2 - investigating Jul 12 02:11:45 rwhitby: the one built from widk? Jul 12 02:11:49 pre2 doesn't hvae a compatible libpdl Jul 12 02:11:50 dtzWill: yes Jul 12 02:12:02 scoutcamper: make toolchain at top level Jul 12 02:12:07 so will fail to run to due to missing symbol is my guess Jul 12 02:12:29 (or perhaps claims can't find appropraite libpdl, but don't think they're versioned lke that) Jul 12 02:13:36 scoutcamper: pull then make toolchain Jul 12 02:13:42 k Jul 12 02:13:53 dtzWill: xserver-package rebuilt here fine Jul 12 02:14:17 rwhitby: we can just make xserver dlopen libpdl and dlsym to the right thing... Jul 12 02:14:22 dtzWill rwhitby, what are you guys building with? linux or mac? Jul 12 02:14:27 linux Jul 12 02:14:39 ubuntu 11.04 32-bit Jul 12 02:14:42 think gcc'll let us create whatver linkage type is "define this if you can, else make it null (think it's extern weak)" with attributes Jul 12 02:14:48 cool Jul 12 02:14:49 me too Jul 12 02:15:05 so we can check "if (PDL_SetKeyboardState) PDL_SetKeyboardState()" or so Jul 12 02:15:06 dtzWill: doing a x packages clobber and rebuild to double check Jul 12 02:15:23 rwhitby: mmhmm. that's what i did, worked here. xterm is failing somehow, i wouldn't be surprised if it was just me. Jul 12 02:15:28 nothing i changed seems...relevant... Jul 12 02:16:07 dtzWill: it worked here Jul 12 02:16:12 heh, called it x.x Jul 12 02:16:17 rwhitby: does the packge install/work? Jul 12 02:16:17 dtzWill: just rebuilding for sanity check Jul 12 02:16:21 * dtzWill nods, ty Jul 12 02:16:26 ./bin/Xsdl: symbol lookup error: ./bin/Xsdl: undefined symbol: PDL_SetKeyboardState Jul 12 02:16:29 that's on Pre 2 Jul 12 02:16:45 also, called it. xD \o/ Jul 12 02:16:56 well hooray for that, that's straightforward to fix. Jul 12 02:16:57 interestingly, it happens not immediately at initial exec time Jul 12 02:17:20 so let's put in the version checking? Jul 12 02:17:25 that is strange. maybe it has some kinda lazy symbol resolution?? Jul 12 02:17:50 maybe they did something clever or that i don't understand, here's hoping it's as simple as not making the call : Jul 12 02:18:18 rwhitby: would you handle that? Jul 12 02:18:32 dtzWill: I'll put an if around it that depends on specific accel values, and test that theory Jul 12 02:18:52 rwhitby: heh, kk Jul 12 02:18:54 keyboard in portrait only for a test Jul 12 02:19:03 after this rebuild is done Jul 12 02:19:07 dtzWill, http://pastebin.com/8in3bJmW Jul 12 02:19:30 oh no, looks like xterm doesn't like the newest xserver Jul 12 02:19:40 failed previous testing b/c i clobbered but didn't rm staging/armv7/usr Jul 12 02:19:43 (-rf) Jul 12 02:19:57 okay i'll fix this. Jul 12 02:21:26 looks like version of xterm we had wasn't new enough for the xserver, whoopsy. testing that theory now. Jul 12 02:21:48 nope, haha. Jul 12 02:21:51 oh well upgrading xterm doesn't hurt. Jul 12 02:23:00 nope, lied, that was it. Jul 12 02:23:04 (forgot to clobber, sorry for noise) Jul 12 02:24:15 dtzWill, any idea how to fix the error i got? Jul 12 02:24:27 sorry haven't looked yet Jul 12 02:24:41 scoutcamper: rwhitby's fix should handle that i think. Jul 12 02:25:07 if it doesn't, go to root of WIDK and 'make doctors/Palm_webOS_SDK-Mac-3.0.0.643.mpkg' Jul 12 02:25:11 and then things should work. Jul 12 02:25:14 k Jul 12 02:25:24 rwhitby's fix didnt fix the doctor Jul 12 02:25:42 pastebin of make toolchain Jul 12 02:26:28 1 min Jul 12 02:26:32 have to re-do Jul 12 02:26:48 (to far back in my terminal log) Jul 12 02:27:09 rwhitby: can we make xterm/xserver packages not have icons Jul 12 02:27:10 ? Jul 12 02:27:12 at least xterm... Jul 12 02:27:24 or we should promote xecutah.sh to what's run Jul 12 02:27:46 rwhitby, http://pastebin.com/RXeMVW67 Jul 12 02:27:50 dtzWill: yeah, we could change appinfo to run xecutah.sh Jul 12 02:27:55 kk will do Jul 12 02:28:11 scoutcamper: you didn't git pull Jul 12 02:28:57 scoutcamper: in general, always accompany a "didn't work" on any kind with a pastebin Jul 12 02:29:05 s/on/of/ Jul 12 02:29:05 yeah Jul 12 02:30:47 rwhitby, i have done a git pull of the master branch and the x_restructure branch, same thing Jul 12 02:31:59 rwhitby: also, if you saw delay on pre2 Jul 12 02:32:03 it's possible that it was just building the jail Jul 12 02:32:12 and since it's 10's of MB maybe that was the delay? Jul 12 02:32:18