**** BEGIN LOGGING AT Fri Jan 06 02:59:57 2012 Jan 06 05:00:17 PuffTheMagic_: it's annoying to fix the bug in question without just dropping their whole linked-list graphicsstate dealy Jan 06 05:00:36 and just associate a graphics state with every character position and call it a day Jan 06 05:01:00 i fixed it for the case where moving the cursor is a new cursor position, which means it fixes vttest and the echo command you gave Jan 06 05:01:34 but putting cursor into existing text and doing same thing results in a similar failure Jan 06 05:01:50 basically their graphics model wasn't built to handle arbitrarily moving, although i'm trying to fixy it Jan 06 05:25:35 hooooraayy Jan 06 05:34:53 eeek PuffTheMagic_ are you using mc from ipkg-opt? Jan 06 05:35:03 i just installed it and ran it and @.@ does *not* look like what you've been posting Jan 06 05:38:01 ah, had a borked terminal it would appear. Jan 06 06:10:38 ya Jan 06 06:10:52 PuffTheMagic_: how'd you get it to use the nice bars Jan 06 06:10:55 instead of ascii chars? Jan 06 06:11:09 ummm Jan 06 06:11:23 should be part of the font Jan 06 06:11:35 and the charset that the term selects Jan 06 06:14:19 does doing a 'reset' fix your issue? Jan 06 06:14:29 oh it fixed the 'borked terminal' thing Jan 06 06:14:37 but so did bouncing wterm haha which i'm doing an awful lot Jan 06 06:14:54 had a built that fixed the echo command and vttest, but mc was still acting weird (and i wasn't quite happy with it) Jan 06 06:15:01 anyway hopefully get this nailed soonish, we'll see :) Jan 06 06:15:45 i appreciate it very much, doubt I would have found the source of that bug as quickly Jan 06 06:16:58 what bug are you seeing in mc? Jan 06 06:17:11 (as shown in that picture [Colors] Jan 06 06:17:22 i thought it was the same bug as the echo test Jan 06 06:17:43 oh i mean what are you seeing that's wrong Jan 06 06:17:46 see how the prompted box background colors are spread out Jan 06 06:17:52 oh Jan 06 06:17:53 oh wow Jan 06 06:17:55 haha Jan 06 06:18:11 i believe that is the same issue Jan 06 06:18:27 are you able to get the nice lines yet in mc? Jan 06 06:18:39 no, but haven't been trying. Jan 06 06:18:48 also 'f10' should quit mc..right? Jan 06 06:19:21 seems to just insert 21~ Jan 06 06:19:58 do you have TERM/etc set to anything in particular? /me making wild debugging guesses Jan 06 06:20:06 (and saw you and ka6sox talking about that the other day i think) Jan 06 06:25:10 i have mine set to xterm Jan 06 06:25:24 hmm mine's set to vt100 somehow Jan 06 06:25:26 i guess i should read up on terminfo some day Jan 06 06:25:38 so i can send the right commands Jan 06 06:25:45 rxvt and xterm work the best Jan 06 06:26:07 setting TERM=xterm made mc a)know to use colors and b)use lines Jan 06 06:28:25 i didnt realize vt100 didnt use the line chars Jan 06 06:28:32 i knew color wouldnt work though Jan 06 06:33:59 mine is set to vt102 Jan 06 06:48:22 PuffTheMagic_: does htop work for you? Jan 06 06:48:32 yes mostly Jan 06 06:48:36 (trying to make sure my changes don't bork things) Jan 06 06:48:50 does yours look bad now Jan 06 06:48:52 i'm seeing the very top line not working right i believe Jan 06 06:48:54 hrm Jan 06 06:49:01 but otherwise looks right Jan 06 06:49:17 (on TERM=xterm) Jan 06 06:49:27 ya Jan 06 06:49:34 that gets erased sometimes Jan 06 06:49:39 i know what i added that did that Jan 06 06:49:41 need to debug that Jan 06 06:49:42 oh Jan 06 06:49:44 okay Jan 06 06:49:46 so i didn't do that then Jan 06 06:49:47 hooray Jan 06 06:52:10 100 looks bad, 220 looks better, 102 looks bad, xterm is pretty colors Jan 06 06:55:01 PuffTheMagic_: do you have any good way to benchmark the terminal? 'time dmesg'? heh Jan 06 06:58:58 benchmark, not really Jan 06 06:59:16 i just know it doesnt crash Jan 06 06:59:20 which makes me happy Jan 06 06:59:25 old wterm couldnt handle all that day Jan 06 06:59:26 data Jan 06 06:59:57 dtzWill: seems fast enough for me Jan 06 07:00:14 i was going to install gperf at some point Jan 06 07:00:26 i'm not complaining i'm just trying to make sure i'm not slowing things down Jan 06 07:00:29 i don't think so Jan 06 07:00:32 but just wanted to check :) Jan 06 07:00:37 we'll see what you think i suppose hehe Jan 06 07:00:53 i cant imagine you slowing it down at all Jan 06 07:01:04 and if its fixed who cares Jan 06 07:01:07 * dtzWill adds sleep(1) everywhere Jan 06 07:01:09 lol Jan 06 07:01:12 it can always be optimized Jan 06 07:01:40 easier to tune something once it works Jan 06 07:03:40 ooooh Jan 06 07:03:49 https://github.com/PuffTheMagic/wTerm/network is more interesting now Jan 06 07:04:29 i wonder how well githubs auto merges work Jan 06 07:06:07 * dtzWill issues pull requests Jan 06 07:06:16 I wonder if TERM should just be force set to xterm Jan 06 07:06:25 * dtzWill feels like he's officially github'd it up with pull requests Jan 06 07:07:01 Brybry: could've sworn there was a preware patch that did exactly that at some point Jan 06 07:07:02 I am so confused at what just happened with this network graph Jan 06 07:21:14 dtzWill: merged Jan 06 07:21:15 thanks Jan 06 07:21:18 it looks good Jan 06 07:21:32 \o/ Jan 06 07:22:14 think u fixed htop too Jan 06 07:22:24 never mind Jan 06 07:22:28 spoke too soon Jan 06 07:23:28 Brybry: ya there is prob a way to force the TERM Jan 06 07:23:44 I think something like setenv("TERM", "xterm", 1); Jan 06 07:23:44 i just add a file to profile.d Jan 06 07:23:48 that sets mine Jan 06 07:23:48 just trying to think where Jan 06 07:24:01 terminal.cpp before setUser() apparently was not the place! Jan 06 07:25:02 Brybry: problem is, wterm uses login -f root Jan 06 07:25:12 which means what ever we set will get replaced at some point Jan 06 07:26:53 dtzWill: i might simplify your fix later, idk Jan 06 07:27:17 might be able to just use the default graphics state for padding/fill Jan 06 07:27:24 instead of the saving that u are doing Jan 06 07:32:43 the padding/fill does use the default graphics state Jan 06 07:33:12 the saving is only done when you overwrite text in the middle of a line, and the saving is so that you can set the state for the character following the one being written to Jan 06 07:33:26 but it probably isn't the bestest, no :) Jan 06 07:35:38 I wonder if syslog is threadsafe Jan 06 07:47:10 dtzWill: well your patch is prob good enough to bring wterm out of beta Jan 06 08:04:30 PuffTheMagic_: hrrmm, looks like even if you merge in a commit that closes an issue it's not closed, issue 9 ( https://github.com/PuffTheMagic/wTerm/issues/9 ) is still open Jan 06 08:04:41 (nbd, but just noticed and thought i'd share since i didn't expect that) Jan 06 08:07:48 i didnt close the bug Jan 06 08:07:54 i just closed the merge request Jan 06 08:08:37 but thanks for reminding me to do that Jan 06 08:10:05 are we using the redmine anymore? Jan 06 15:01:02 ka6sox: i'd say ya Jan 06 17:49:19 first cut of portrait keyboard almost done Jan 06 17:49:28 complete with orientation change support Jan 06 18:55:37 PuffTheMagic_: \o/ orientation changes and portrait keyboard Jan 06 19:08:47 D Jan 06 19:08:49 :D Jan 06 19:08:55 its pretty half assed Jan 06 19:09:01 but i can improve it latter Jan 06 19:09:29 any idea why wterm idles at ~30% cpu? Jan 06 19:10:14 you get pretty much the same overall cpu idle with top in novaterm as you do with top in sdlterm/wterm Jan 06 19:11:03 ? Jan 06 19:11:17 sorry, i don't follow. could you explain? Jan 06 19:12:18 does wterm idle at 30% cpu if you're running top from novaterm or sshd Jan 06 19:12:24 yes Jan 06 19:13:06 i'm not measuring 'idle' cpu with an actively updating application running in it Jan 06 19:13:29 that's what I think he was checking Jan 06 19:13:32 well but afaik it's not *doing* anything, i mean first glance things seem well behaved, which is why i was wondering if puff had any leads Jan 06 19:13:42 dwc-: ah, okay. thanks :) Jan 06 19:13:50 mine seems to be idling at 53-60% actually Jan 06 19:13:58 hmm, guess I'm wrong or maybe the new event loop changed it Jan 06 19:14:11 not even a blinking cursor to animate Jan 06 19:14:14 but just looking at wterm's cpu % in top doesn't give you the whole picture Jan 06 19:14:15 dwc-: mine went 'down' to 30% after i pinned the proc at 1.5ghz Jan 06 19:14:26 (as opposed to normal ondemand govnah xD) Jan 06 19:14:36 [pid 23824] sched_yield() = 0 Jan 06 19:14:36 [pid 23824] select(175, [174], NULL, NULL, {0, 1}) = 0 (Timeout) Jan 06 19:14:36 [pid 23824] sched_yield() = 0 Jan 06 19:14:36 [pid 23824] select(175, [174], NULL, NULL, {0, 1}) = 0 (Timeout) Jan 06 19:14:36 [pid 23824] sched_yield() = 0 Jan 06 19:15:09 interesting Jan 06 19:15:11 and I dunno how its version of top handles multicore Jan 06 19:15:39 oh Jan 06 19:15:40 wait Jan 06 19:15:40 what Jan 06 19:16:07 the select timeout is 1 usec? (dwc i assume you're posting that since it's happening a bunch?) Jan 06 19:16:19 yeeep Jan 06 19:18:42 hmm, it definitely uses more than the original sdlterm Jan 06 19:19:42 yep Jan 06 19:19:48 well the strace fragment dwc posted points me here: https://github.com/PuffTheMagic/wTerm/blob/master/src/plugin/terminal/terminal.cpp#L384 Jan 06 19:20:08 oddly, my pid 23824 doesn't have a fd 175 Jan 06 19:20:11 or 174 Jan 06 19:20:16 oh wait, yes it does' Jan 06 19:20:18 NEVERMIND Jan 06 19:20:30 select with smallest possible timeout, then yield, grabbing/releasing the master lock in a spinloop Jan 06 19:20:37 lrwx------ 1 root root 64 Jan 6 11:14 174 -> /dev/ptmx Jan 06 19:21:38 it's an awfully small timeout Jan 06 19:21:41 write does the same, but presumably idle cpu isn't sending any commands :) Jan 06 19:22:09 dwc-: bumping it to 100usec drops cpu to 15% for example Jan 06 19:22:48 haven't looked at the rest of the code ... but there's got to be a better way... what's the masterLock for? Jan 06 19:23:14 ideally it would be entirely blocking (move select out of the lock) but idk the locking rules Jan 06 19:23:17 heh, what you said :) Jan 06 19:23:50 * dwc- doesn't even have a checkout of this project yet Jan 06 19:23:55 s/checkout/clone/ Jan 06 19:24:13 bumping it to 1000usec drops cpu usage to 3% Jan 06 19:24:26 ideally wouldn't sleep with the lock, but at least that says this for sure is the culprit Jan 06 19:24:53 any degradation in responsiveness? Jan 06 19:24:57 (noticeable) Jan 06 19:25:01 not afaict no Jan 06 19:25:05 but that's still 1/1000th of a second Jan 06 19:25:05 lol Jan 06 19:27:03 lemme get a bt keyboard, i'm not convinced general responsiveness isn't somewhat effected by enyo/plugin etc Jan 06 19:29:34 nopers, but does seem same as before. Jan 06 19:29:50 will poke a bit to see if cleaner fix but still idles much nicer now Jan 06 19:31:23 make sure you touch the terminal area to give it focus for your bt keyboard to work Jan 06 19:32:13 Brybry: oh, ty. i had done that mostly by accident and was gonna look into what was going on later xD Jan 06 19:32:18 ty for the tip :) Jan 06 19:34:24 probably what I'll do as a quick thing for that is a focus set on keyboard minimize Jan 06 19:35:44 I can catch when an HP bluetooth keyboard is attach on the plugin side but I dunno how to notify the enyo side from the plugin side (short of running an actual lunaservice/palmservice server which is not really acceptable) Jan 06 19:45:02 UI side timer loop to ping the plugin? (just not every 1ns) Jan 06 20:33:37 dtzWill: thats 30% at 384 hz Jan 06 20:33:50 which isnt that much really Jan 06 20:35:08 PuffTheMagic_: keep reading Jan 06 20:35:13 it's at 1.5ghz Jan 06 20:36:33 and the read stuff definitely needs work Jan 06 20:36:39 should have that cleaned up nicely shortly Jan 06 20:36:45 nice Jan 06 20:36:53 do we know who wrote this code originally? Jan 06 20:37:19 i'm having a hard time not coming to the conclusion that whoever wrote the read/write code was in a bit over their head Jan 06 20:37:37 shrug, or just being extra careful with intention to revisit Jan 06 20:38:09 based on the copyrights in the top of the files, my guess is some Chinese CS student Jan 06 20:38:36 well overall, seems that sdlterminal was very incomplete Jan 06 20:39:03 sooo, probably the orig author was going to revisit things Jan 06 20:39:05 but idk Jan 06 20:39:10 its out of his hands now Jan 06 20:39:29 hopefully my changes won't be thought silly by somoene else down the road ;) Jan 06 20:40:45 lol Jan 06 20:40:53 something we all can hope for O:) Jan 06 20:42:39 PuffTheMagic_: can you do a 'time dmesg' for me? Jan 06 20:42:48 it's a hack of a benchmark, but offhand i don't have anything better Jan 06 20:43:07 sure Jan 06 20:43:41 wonderful, ty Jan 06 20:43:41 real 3.075 Jan 06 20:43:45 o__O Jan 06 20:44:03 but i should prob not be using ondemand gov for this Jan 06 20:44:05 (is your device clocked down? maybe run a few times and report lowest?) Jan 06 20:44:07 haha yeah probably not Jan 06 20:45:12 fwiw i'm seeing between 1.01 and 1.12s, and it idles perfectly now (zero cpu usage when nothing's happening) Jan 06 20:45:37 at what speed Jan 06 20:45:42 1.5ghz, sorry Jan 06 20:45:42 cpu speed i mean Jan 06 20:46:04 im locking mine at 384 ;) Jan 06 20:46:28 lol Jan 06 20:46:42 slower should exaggerate issues more Jan 06 20:46:59 hmm, i'd think that even with on-demand running 'time dmesg' a bunch of times (since it pegs the cpu) would be the same sa using the performance governor at 1.5 Jan 06 20:47:09 but getting significantly higher times Jan 06 20:47:09 shurg Jan 06 20:48:02 ok well i will lock to 1.5 then Jan 06 20:48:20 oh i cant do 1.5 Jan 06 20:48:23 i have stock kernel Jan 06 20:48:35 oh i can do 1.4 then Jan 06 20:48:39 do u your tests on 1.188 Jan 06 20:48:43 sure thing Jan 06 20:48:45 thats the highest i have Jan 06 20:48:47 oh is that what they ship at? Jan 06 20:48:48 haha Jan 06 20:48:48 XD Jan 06 20:49:05 <3 webos-internals for making it so i forgot the default clock rate Jan 06 20:49:58 4 runs, 1.30 to 1.48 Jan 06 20:51:43 damn Jan 06 20:51:49 thats like a second faster than im getting Jan 06 20:51:53 hooray Jan 06 20:51:58 well this also idles wonderfully Jan 06 20:52:01 which i'm rather fond of Jan 06 20:52:15 playing with buffer sizes might help, but i'm not doing that yet Jan 06 20:52:19 i get 2.2-2.7 Jan 06 20:52:38 skewed closer to 2.2 Jan 06 20:52:58 dtzWill: thanks for putting some time into this Jan 06 20:53:12 sure thing, it's fun :) Jan 06 20:53:19 i want a great usable terminal too Jan 06 20:59:45 u commit anything yet? Jan 06 20:59:54 not pushed, no Jan 06 20:59:59 1 sec, quality control :) Jan 06 21:01:21 dtzWill: https://fbcdn-sphotos-a.akamaihd.net/hphotos-ak-ash4/385463_10100466302582823_14206794_50456706_724651065_n.jpg Jan 06 21:01:57 hahaha :) Jan 06 21:02:20 im just glad i beat oil to it Jan 06 21:02:33 he has a special hot key to dump memes Jan 06 21:02:37 heh Jan 06 21:09:20 * PuffTheMagic_ keeps pressing F5 on dtzWill github Jan 06 21:09:28 i'll ping you! haha Jan 06 21:09:39 also just got feedback from a conference i submitted to, so a tad distracted :) Jan 06 21:10:03 what conference and was it good news? Jan 06 21:11:22 ICSE (http://www.ifi.uzh.ch/icse2012/) and so far seems like good news Jan 06 21:11:31 well-liked, hell better-liked than I expected :P Jan 06 21:11:48 unfortunately it's not a decision, they send comments and we provide feedback and don't find out until end of january Jan 06 21:12:07 but icse is a good conference, international top-tier. more than i had hoped for :) *crosses fingers* Jan 06 21:12:19 ah Jan 06 21:20:30 :D Jan 06 21:20:46 i just added a little code to vttest that sets the default rows and cols to the terms actual size Jan 06 21:20:56 oh hooray Jan 06 21:21:02 instead of defaulting to 24x80.32 Jan 06 21:21:05 instead of defaulting to 24x80.132 Jan 06 21:22:31 and im gonna change it so that it sends the reset command on exit Jan 06 21:22:39 instead of arbitrarily setting params Jan 06 21:39:52 PuffTheMagic_, HEH Jan 06 21:40:23 ? Jan 06 21:43:12 twitter post Jan 06 21:43:41 ya that image is too good, had to share Jan 06 21:58:13 * PuffTheMagic_ kids dtzWill Jan 06 21:58:19 hopefully he falls on the commit button **** ENDING LOGGING AT Fri Jan 06 22:06:39 2012 **** BEGIN LOGGING AT Fri Jan 06 22:07:27 2012 Jan 06 22:07:39 rofl said that while the logger was down :P **** ENDING LOGGING AT Fri Jan 06 22:08:09 2012 **** BEGIN LOGGING AT Fri Jan 06 22:08:41 2012 Jan 06 22:41:22 PuffTheMagic_, do you know how to set focus on the terminal for keyboard input? If I manually tap the area it works fine, but trying focus() and even creating mouse click events and dispatching them on the plugin fail me Jan 06 22:44:51 or Jan 06 22:44:57 guh, figured it out Jan 06 22:45:07 don't use click events, use mousedown events :D Jan 06 22:53:48 Brybry: what are u doing? Jan 06 22:55:30 seeing if I can make things behave slightly better for real keyboard input Jan 06 23:03:26 Brybry, what app? Jan 06 23:03:37 wterm Jan 06 23:56:49 PuffTheMagic_: pingaling Jan 06 23:56:55 sorry for talking it up and then going MIA xD Jan 07 00:18:29 PuffTheMagic_: the performance boost is wrong, although i think the code has better behavior now regardless. idk why it didn't occur to me that our demsg's could/would be of very very different sizes Jan 07 00:18:37 and as such taht was a terrible cross-device comparison Jan 07 00:26:04 im sure the boost wasnt accurate Jan 07 00:26:17 ya i was thinking about the different sizes Jan 07 00:45:21 i'm sad the code didn't get simpler--you can just do a simple looped read/write Jan 07 00:45:35 but then the thread couldn't be reaped *neatly* without involving signals or something else Jan 07 01:48:36 well i dont notice a performance hit Jan 07 01:48:49 and it def idles with less cpu Jan 07 01:49:42 touch mine idles more around 4% Jan 07 01:50:16 and when i say idle i mean with top/htop running ;) Jan 07 01:50:53 or 10 Jan 07 01:50:57 this is weird Jan 07 01:50:57 idk Jan 07 01:51:00 it def less Jan 07 01:51:25 prob because im not overclocked Jan 07 01:52:04 oh Jan 07 01:52:06 no Jan 07 01:52:19 errr are you really not seeing it idle around 0? Jan 07 01:52:33 ya absolutely not Jan 07 01:52:37 that is very very wrong, the patch i submitted has them only waking up 1x second Jan 07 01:52:45 no i mean cpu time as a percentage should be zero Jan 07 01:52:45 lol Jan 07 01:52:45 i've seen it go down to about 1% once Jan 07 01:52:58 this is while running your monitoring app from within wterm? Jan 07 01:53:08 i have top going now and its goes between 5 and 10 basically Jan 07 01:53:17 ya Jan 07 01:53:21 from within Jan 07 01:53:29 wel Jan 07 01:53:30 lol Jan 07 01:53:33 /okay/ Jan 07 01:53:35 that's not idling xD Jan 07 01:53:48 that's just 'less usage'. now if you actually idle, so does wterm Jan 07 01:54:01 but yes it does mean lower cpu usage overall, including more static updates for things like top/etc Jan 07 01:55:09 ya i guess it is idling at 0 Jan 07 02:02:38 PuffTheMagic_: more goodness pull req'd :D Jan 07 02:50:55 dtzWill: LOL Jan 07 02:51:01 u just added back shit i removed Jan 07 02:51:50 i know exactly what i did :) Jan 07 02:51:58 and i didn't 'just' add it back Jan 07 02:52:02 else it'd be a revert or similar Jan 07 02:52:24 the most important differences are that we still do a SDL_WaitEvent to have nicer blocking behavior Jan 07 02:52:52 which i believe was the motivation behind your change Jan 07 02:54:20 only 'real' difference relative to before the related commit is that this consumes the event queue before trying to render, and if we're rendering too fast (probably won't happen) it blocks since no one needs a 40+ fps terminal Jan 07 02:54:43 but i care less about that change, so suit yourself :) Jan 07 02:54:51 but yes lulz at code churn Jan 07 02:55:05 actually Jan 07 02:55:27 in one of my posts on the forums i said that sdl_wait plus something to limit fps was probably the best route Jan 07 02:55:32 so glad u did that Jan 07 02:55:49 yeah, that works wonderfully in *most cases Jan 07 02:55:57 but remember we have a terminal running that changes the terminal state in wterm Jan 07 02:56:04 which often fires off VIDEOEXPOSE events Jan 07 02:57:27 but hooray, and the sdl_wait change is all yours Jan 07 02:57:32 i just combined forces ;) :D Jan 07 02:58:09 i dont fully appreciate your other commit though Jan 07 02:58:17 im sure if i study it more it will make sense Jan 07 02:58:25 idk what the difference between blend and shade is Jan 07 02:58:40 http://sdl.beuc.net/sdl.wiki/SDL_ttf_Functions_Render Jan 07 02:58:48 also, try it and see ;) :P **** ENDING LOGGING AT Sat Jan 07 02:59:57 2012