| 00:02.02 | dos1 | there is no "server it can coordinate with" aside of trackers, but that's per torrent file (but DHT can be used instead anyway) |
| 00:03.22 | dos1 | generally you just create a .torrent file with a hash and some open tracker specified, then point your local client to it in a way so it treats your file as already downloaded, and then send .torrent file to someone else (or to some public index) |
| 00:05.30 | dos1 | (or magnet link can be used instead of .torrent file) |
| 00:06.10 | DocScrutinizer05 | no connection to any trackers here |
| 00:06.29 | dos1 | http://www.mepis.org/docs/en/index.php?title=Creating_a_torrent |
| 00:07.06 | *** join/#maemo RiD (~RiD@2.83.62.95) |
| 00:07.18 | dos1 | trackers are per-file, so if you don't have any torrents down/uploading then that's expected :P |
| 00:07.45 | DocScrutinizer05 | HAHAHA!!! >>You must add at least one tracker: type or paste in the URL: http://linuxtracker.org:2710/announce and click the add button.<< |
| 00:08.13 | DocScrutinizer05 | suuure, I know this by heart, and thus the shitty ktorrent doesn't even suggest it |
| 00:09.02 | DocScrutinizer05 | and the magnet seems to linger there like it does nothing at all |
| 00:09.11 | dos1 | dunno what you want to seed - if it's not some 100% legal linux iso, then something like http://openbittorrent.com/ will probably be a better choice :P |
| 00:09.39 | DocScrutinizer05 | probably best choice is to forget about that torrent shit |
| 00:10.17 | nox- | torrents are faster for some people |
| 00:10.48 | DocScrutinizer05 | meh, I don't care |
| 00:10.54 | nox- | :) |
| 00:11.07 | TheOnlyJoey|desk | i normally download torrent with the speed of my internet connection, 50mbit as we speak |
| 00:11.14 | DocScrutinizer05 | it's not like it gives me headache to NOT share some of the stuff I have here |
| 00:11.32 | dos1 | it all depends |
| 00:11.34 | DocScrutinizer05 | this ktorrent client however for sure gives me headache |
| 00:11.59 | TheOnlyJoey|desk | DocScrutinizer05, try Transmission, has served me well for years :) |
| 00:12.41 | dos1 | ktorrent is a pretty good client imo - you would probably have similar problems with any client |
| 00:13.00 | dos1 | unless it has some "friendly" trackers etc. so it autoprefills this stuff for you ;) |
| 00:13.58 | DocScrutinizer05 | ok, so much for wasted time with torrents |
| 00:15.09 | dos1 | anyway, that mepis wiki page has it described pretty well |
| 00:18.41 | nox- | magnet:?xt=urn:btih:49f11696a576b26adc8254216728484b268554e3&dn=firmwares |
| 00:18.48 | nox- | doesnt seem to work at least in rtorrent |
| 00:19.03 | *** join/#maemo janemba (~101@unaffiliated/janemba) |
| 00:19.08 | nox- | (from xes' link) |
| 00:23.41 | DocScrutinizer05 | exactly |
| 00:24.16 | *** join/#maemo eMHa_ (~mh@2a02:8071:2e81:c500:d6be:d9ff:fe2b:f21b) |
| 00:24.25 | DocScrutinizer05 | and http://openbittorrent.com/ reports "Error: invalid data from tracker" |
| 00:32.22 | nox- | theres a thunder:// link too which seems to belong to https://en.wikipedia.org/wiki/Thunder_Download |
| 00:32.37 | nox- | "Although not widely reported, Xunlei client has been discovered spreading the malware Win32/KanKan to thousands of Chinese Windows PCs and Android devices.[5] In 2013 the company admitted its employees bundled malware into Xunlei client.[6]" |
| 00:32.38 | nox- | uh |
| 00:32.47 | hurrian_ | such a surprise |
| 00:35.31 | jon_y | isn't xunlei also one of those exploiting torrent clients? |
| 00:35.45 | jon_y | uh, selfish client |
| 00:35.46 | nox- | wouldnt know |
| 00:36.09 | jon_y | last I read, it was banned from private trackers |
| 00:36.51 | nox- | well if it spreads malware who wants to use it anyway... |
| 00:37.37 | *** join/#maemo jonwil (~jonwil@27-33-80-219.tpgi.com.au) |
| 00:37.51 | jon_y | lusers want to, for faster speeeeed |
| 00:39.09 | nox- | any idea whats wrong with that magnet link? or is it just the tracker being down? |
| 00:40.11 | jon_y | I think its just the tracker since you got the torrent already |
| 00:44.10 | nox- | there doesnt even seem to be a .torrent to download |
| 00:44.14 | hurrian_ | man, and people wonder why nobody outside of china wants to use that crap |
| 00:46.21 | *** part/#maemo dima5` (~user@cpe-23-243-199-75.socal.res.rr.com) |
| 00:49.53 | *** join/#maemo robbiethe1st (~robbiethe@192.183.178.155) |
| 01:15.49 | *** join/#maemo Humpelstilzchen (erik@e177220033.adsl.alicedsl.de) |
| 01:27.22 | *** join/#maemo janemba (~101@unaffiliated/janemba) |
| 01:29.04 | *** join/#maemo erlehmann (~erlehmann@g226046190.adsl.alicedsl.de) |
| 01:39.55 | *** join/#maemo RiD (~RiD@2.83.62.95) |
| 01:48.01 | DocScrutinizer05 | I gave up on torrent, that's silly. When you need sth, just ask me |
| 01:48.37 | DocScrutinizer05 | I got an amazingly huge backup folder here |
| 02:05.09 | *** join/#maemo janemba (~101@unaffiliated/janemba) |
| 02:39.35 | *** join/#maemo maybeWTF (~cl@p5B163708.dip0.t-ipconnect.de) |
| 03:01.41 | *** join/#maemo lxp1 (~lxp@188-22-116-169.adsl.highway.telekom.at) |
| 03:05.45 | *** join/#maemo dima5` (~user@cpe-23-243-199-75.socal.res.rr.com) |
| 03:12.28 | *** join/#maemo janemba (~101@unaffiliated/janemba) |
| 03:40.07 | *** join/#maemo janemba (~101@unaffiliated/janemba) |
| 04:09.53 | *** join/#maemo Psi (~Psi@49-50-247-217.a.hd.net.nz) |
| 04:11.46 | *** join/#maemo LauRoman (~LauRoman@79.116.47.218) |
| 04:52.24 | *** join/#maemo dhbiker (~dhbiker@APN-122-133-250-gprs.simobil.net) |
| 05:09.29 | *** join/#maemo maybeHere (~cl@p5B163708.dip0.t-ipconnect.de) |
| 05:09.35 | *** join/#maemo maybeArgh (~cl@p5B163708.dip0.t-ipconnect.de) |
| 05:25.30 | *** join/#maemo jormungandr (~henry@213.23.120.114) |
| 05:54.54 | *** join/#maemo kolp (~quassel@55d4555a.access.ecotel.net) |
| 06:02.23 | *** join/#maemo fuz_ (nobody@vau75-10-88-164-23-88.fbx.proxad.net) |
| 06:14.08 | *** join/#maemo DocScrutinizer05 (~saturn@openmoko/engineers/joerg) |
| 06:17.29 | *** join/#maemo Gadgetoid (~Gadgetoid@210.73.2.81.in-addr.arpa) |
| 06:22.28 | *** join/#maemo mavhc (~mavhc@cpc65310-basf8-2-0-cust204.12-3.cable.virginm.net) |
| 06:32.28 | *** join/#maemo mavhc (~mavhc@cpc65310-basf8-2-0-cust204.12-3.cable.virginm.net) |
| 06:56.08 | *** join/#maemo Pilke (~Pilke@85-76-138-197-nat.elisa-mobile.fi) |
| 06:59.41 | *** join/#maemo AD-N770 (~jep@195.10.10.182) |
| 07:02.55 | *** join/#maemo norayr (~noch@212.73.74.28) |
| 07:22.17 | *** join/#maemo LaoLang_cool (~LaoLang_c@219.130.218.204) |
| 07:43.13 | *** join/#maemo rcg (~rcg@fhffm1223.nat.fh-frankfurt.de) |
| 07:48.49 | *** join/#maemo goldkatze (~nobody@unaffiliated/goldkatze) |
| 07:57.32 | *** join/#maemo janemba (~101@unaffiliated/janemba) |
| 07:59.45 | *** join/#maemo shamus (~shmaus@ip-206-192-193-180.marylandheights.ip.cablemo.net) |
| 08:07.45 | *** join/#maemo geaaru (~geaaru@host170-152-static.43-88-b.business.telecomitalia.it) |
| 08:14.13 | *** join/#maemo dhbiker (~dhbiker@APN-122-22-111-gprs.simobil.net) |
| 08:29.39 | *** join/#maemo Kup (d4589884@gateway/web/freenode/ip.212.88.152.132) |
| 08:48.25 | *** join/#maemo tanty_off (~agomez@fanzine.igalia.com) |
| 09:05.44 | *** join/#maemo robink (~quassel@unaffilated/robink) |
| 09:06.01 | *** join/#maemo geaaru (~geaaru@host170-152-static.43-88-b.business.telecomitalia.it) |
| 09:13.31 | *** join/#maemo Kabouik (~quassel@147.99.218.243) |
| 09:21.55 | *** join/#maemo Aspi (~Carry@119.81-167-9.customer.lyse.net) |
| 09:23.15 | Aspi | there are lots of entries of phones world wide promoting "UNLOCKED". what is this "unlocked" really, can a vendor lock a device, especially a N900 that will be flashed? |
| 09:25.02 | kerio | Aspi: rapuyama don't care, rapuyama don't give a fuck |
| 09:25.21 | kerio | you can flash as hard as you want, the n900 will stay oplocked/simlocked |
| 09:26.00 | Aspi | so it's done in some ROM? |
| 09:29.57 | hurrian_ | there are locked N900s? |
| 09:30.37 | *** join/#maemo mkaindl (~mkaindl@ama-dablam.markus-kaindl.de) |
| 09:31.08 | Aspi | that's what I don't know. I dunno if "unlocked" is Chinese marketing scam. |
| 09:31.48 | hurrian_ | the Hong Kong refurbished N900s are unlocked, but are probably reballed with cigarette lighters |
| 09:33.19 | Aspi | so, I have the dilemma that if I buy second hand, previous owner might in turn have bought a HK :) |
| 09:34.07 | hurrian_ | do you already have a N900? |
| 09:34.17 | Aspi | no |
| 09:34.21 | hurrian_ | reusing HK N900s isn't too bad if you just want spare parts |
| 09:34.35 | hurrian_ | welp, that's pretty risky then |
| 09:34.38 | fizzie | There's an "Enter code to remove operator lock" option in the title-bar-menu of the "Settings" application, which kind of sounds like they sold operator-locked N900s somewhere. Unless it's there just in case. |
| 09:35.36 | Aspi | ah, okay. I'm just gonna ask seller if I buy. |
| 09:36.06 | Aspi | are y'all excited about the Neo900? or will you live with the N900 to your death? :) |
| 09:37.11 | hurrian_ | my N900 was swiped, and all the N900s on the local equivalent of eBay are dead/sold as-is. |
| 09:37.13 | *** join/#maemo ALo (~alogeno@110.pool85-59-50.dynamic.orange.es) |
| 09:37.43 | Aspi | ditto, so I look international |
| 09:38.32 | hurrian_ | unfortunately, I won't be happy with just an OMAP3730, having been totally spoiled by how powerful octa-core balls out Android phones are. |
| 09:38.39 | Aspi | I might take a chance on a HK refurb if I can't get something else, as they are not extremely expensive, and I might get lucky and get a reasonably working item (?) |
| 09:39.47 | hurrian_ | I'll probably just run NeoFremantle on my N9, when it materializes. |
| 09:40.51 | dos1 | [02:24:25] <DocScrutinizer05> and http://openbittorrent.com/ reports "Error: invalid data from tracker" |
| 09:41.07 | dos1 | this url is for the browser, tracker url is on the page :) |
| 09:58.22 | *** join/#maemo eMHa_ (~mh@nat.de.netviewer.com) |
| 09:58.54 | *** join/#maemo arcean (~arcean@aacz229.neoplus.adsl.tpnet.pl) |
| 10:08.54 | Aspi | kerio: after reading the logs about rapuyama O_o maybe I'll need a second thinkthrough about N900 |
| 10:10.06 | *** part/#maemo Aspi (~Carry@119.81-167-9.customer.lyse.net) |
| 10:16.39 | DocScrutinizer05 | hurrian_: good luck! I doubt anybody will backport the N9-BB5 cmt stack to fremantle |
| 10:18.16 | DocScrutinizer05 | other than that, you're right that N9 has basically exactly same SoC and Storage/Memory chip like Neo900 |
| 10:18.46 | hurrian_ | isn't the BB5 comm rather similar? |
| 10:22.06 | *** join/#maemo janemba (~101@unaffiliated/janemba) |
| 10:22.49 | DocScrutinizer05 | I don't think so. N9 BB5 is responsible for handling aegis certs/tokens and actually this is what forbids downgrading of HARM "firmware" |
| 10:24.08 | hurrian_ | that's something interesting to test, unlzo'ing PR1.2 and running it on N9. |
| 10:24.48 | hurrian_ | as far as I've read in the kernel hooks for aegis, I haven't seen any calls to BB5, but it might be in userland |
| 10:26.03 | hurrian_ | besides, if BB5 doesn't get it's aegis fix, what's it gonna do, shut down the device? Nemo clearly works without it* (ofono as the RIL instead of Nokia's stuff, but hey, it works) |
| 10:31.16 | *** join/#maemo norayr (~noch@212.73.74.28) |
| 10:46.59 | *** join/#maemo goldkatze (~nobody@unaffiliated/goldkatze) |
| 10:47.41 | *** join/#maemo janemba (~101@unaffiliated/janemba) |
| 10:52.42 | *** join/#maemo janemba (~101@unaffiliated/janemba) |
| 11:06.15 | *** join/#maemo merlin1991 (~merlin@Maemo/community/cssu/merlin1991) |
| 11:07.07 | *** join/#maemo janemba (~101@unaffiliated/janemba) |
| 11:13.46 | *** join/#maemo dhbiker (~dhbiker@APN-122-203-188-gprs.simobil.net) |
| 11:36.59 | *** part/#maemo Kup (d4589884@gateway/web/freenode/ip.212.88.152.132) |
| 11:44.55 | *** join/#maemo janemba (~101@unaffiliated/janemba) |
| 12:04.25 | *** join/#maemo janemba (~101@unaffiliated/janemba) |
| 12:13.57 | *** join/#maemo Wulfe (~ninja@107.188.192.252) |
| 12:13.59 | *** join/#maemo Wulfe (~ninja@unaffiliated/wulfe) |
| 12:25.34 | *** join/#maemo erlehmann (~erlehmann@89.204.130.3) |
| 12:34.06 | *** join/#maemo janemba (~101@unaffiliated/janemba) |
| 13:00.05 | *** join/#maemo b1101 (~b@209.222.5.228) |
| 13:00.05 | *** join/#maemo b1101 (~b@fsf/member/b1101) |
| 13:04.33 | *** join/#maemo flynx_ (~flynx@70-139-50-84.lightspeed.hstntx.sbcglobal.net) |
| 13:27.08 | *** join/#maemo janemba (~101@unaffiliated/janemba) |
| 13:37.31 | *** join/#maemo jas4711 (~jas@2001:16d8:ff9c:0:f2de:f1ff:fe16:509b) |
| 13:38.31 | *** join/#maemo janemba (~101@unaffiliated/janemba) |
| 13:41.39 | *** join/#maemo SAiF1 (~SAiF@117.196.141.55) |
| 13:43.00 | *** join/#maemo RiD (~RiD@bl22-62-95.dsl.telepac.pt) |
| 13:56.04 | *** join/#maemo RedM (~redw@89-73-179-171.dynamic.chello.pl) |
| 14:03.21 | *** join/#maemo DrCode (~DrCode@gateway/tor-sasl/drcode) |
| 14:32.12 | *** join/#maemo konelix__ (~konelix@190.148.56.177) |
| 14:34.23 | *** join/#maemo konelix__ (~konelix@190.148.56.177) |
| 15:01.55 | *** join/#maemo bluelupo (~quassel@2a02:810d:1600:7f0:e2cb:4eff:fe8b:b2f1) |
| 15:07.17 | *** join/#maemo bluelupo_ (~quassel@2a02:810d:1600:7f0:e2cb:4eff:fe8b:b2f1) |
| 15:22.13 | *** join/#maemo bluelupo_ (~quassel@2a02:810d:1600:7f0:e2cb:4eff:fe8b:b2f1) |
| 15:24.23 | *** join/#maemo SAiF (~SAiF@117.248.190.222) |
| 15:49.57 | *** join/#maemo bluelupo (~quassel@2a02:810d:1600:7f0:e2cb:4eff:fe8b:b2f1) |
| 15:51.15 | *** join/#maemo ced117 (~ced117@opensuse/member/ced117) |
| 15:54.51 | *** join/#maemo kerio (kerio@acehack.de) |
| 16:00.47 | bencoh | hm, looking at scim_panel_gtk code ... no wonder scim eats battery ... |
| 16:00.52 | bencoh | <PROTECTED> |
| 16:01.24 | bencoh | couldnt get uglier |
| 16:03.17 | bencoh | (checks every 500ms whether it should exit or not) |
| 16:07.34 | *** join/#maemo N-Mi (~nicolas@calvix/staff/N-Mi) |
| 16:11.56 | *** join/#maemo heroux (~heroux@50708355.static.ziggozakelijk.nl) |
| 16:15.50 | *** join/#maemo LjL (~ljl@unaffiliated/ljl) |
| 16:49.16 | *** join/#maemo fuz_ (nobody@vau75-10-88-164-23-88.fbx.proxad.net) |
| 16:57.00 | *** join/#maemo Kabouik (~quassel@110.109.138.88.rev.sfr.net) |
| 17:00.10 | *** join/#maemo LauRoman (~LauRoman@79.116.47.218) |
| 17:17.01 | *** join/#maemo infobot (ibot@rikers.org) |
| 17:17.01 | *** topic/#maemo is Welcome to #maemo http://maemo.org/intro/ | N9/harmattan related questions please in #harmattan ! | "firmware" see ~tabletsdev ~combined ~emmc ~flasher sdk: ~sb | http://wiki.maemo.org/Community_Council | Source: http://wiki.maemo.org/Sources | Chanlog: http://mg.pov.lt/maemo-irclog | #maemo-ssu is where the (few) devels and maintainers of the maemo-future meet |
| 17:17.02 | *** mode/#maemo [+v infobot] by ChanServ |
| 17:47.15 | DocScrutinizer05 | bencoh: every 500ms is almost OKish |
| 17:50.36 | DocScrutinizer05 | also aiui it passes a callback to some gtk_timeout_add () function, which - depending on the way this function works - could cancel the previous callback registered. When it does, then this is an absolutely correct way to implement a 500ms timeout |
| 17:51.38 | DocScrutinizer05 | however when it doesn't cancel the previous check_exit_timeout_cb registration then that's terribly broken indeed |
| 17:53.25 | DocScrutinizer05 | I guess the real problem happens somewhere else, prolly in some busy loop that polls for input |
| 18:01.47 | *** join/#maemo mbs1337 (~mbs1337@188-181-201-83-dynamic.dk.customer.tdc.net) |
| 18:04.55 | *** join/#maemo mbs1337 (~mbs1337@188-181-201-83-dynamic.dk.customer.tdc.net) |
| 18:05.53 | bencoh | DocScrutinizer05: well according to powertop it does fix the issue |
| 18:06.14 | DocScrutinizer05 | what does fix which issue? |
| 18:07.01 | bencoh | removing this timer let the cpu go to c4 |
| 18:07.09 | bencoh | lets* |
| 18:07.17 | kerio | isn't it c0 |
| 18:07.25 | kerio | no wait, it goes the other way right |
| 18:07.42 | bencoh | yeah the other way |
| 18:08.58 | DocScrutinizer05 | well, randomly removing timers for sure fixes some timer-caused issues eventually, but it prolly will introduce some severe other breakage |
| 18:10.28 | bencoh | it doesnt break a functionality as such (and newer versions of scim have this line commented as well) .... but it wont die on sigterm anymore |
| 18:11.05 | bencoh | sigs are processed in another thread which updates a global var (ugly) |
| 18:11.28 | DocScrutinizer05 | I cannot tell for sure what's the root problem from a single line of code (in this case), but I can *guess* that the code registers 100 timer callbacks per second and never cancels a single one of them. And when push comes to pull it will register a new timer callback event when the callback function of a previous timer event gets called |
| 18:14.34 | bencoh | this line gets executed once and the _cb doesnt seem to register a timer .... but meh :) |
| 18:14.56 | DocScrutinizer05 | the line >> _check_exit_timeout = gtk_timeout_add (500, check_exit_timeout_cb, NULL); << doesn't look like it could cancel a previously registered timer, since for that it would need the _check_exit_timeout handle to that previous instance as a parameter handed to the function |
| 18:15.28 | *** join/#maemo sLumPia (~sLumPia@114.124.34.15) |
| 18:16.34 | bencoh | http://scim-for-maemo.googlecode.com/svn-history/r162/trunk/scim-1.4.7-maemo/extras/panel/scim_panel_gtk.cpp :) |
| 18:16.56 | *** join/#maemo jas4711 (~jas@2001:16d8:cca1:0:dda4:8805:c606:9390) |
| 18:19.03 | DocScrutinizer05 | >> gtk_timeout_add has been deprecated since version 2.4 and should not be used in newly-written code. Use g_timeout_add() instead.<< |
| 18:19.23 | bencoh | it's a 5yo code ;) |
| 18:19.56 | bencoh | but yeah, looks like others patched it to use g_timeout_add() as well |
| 18:20.15 | DocScrutinizer05 | http://www.gtk.org/tutorial1.2/gtk_tut-17.html#ss17.1 mhm |
| 18:20.40 | DocScrutinizer05 | >>...can create a timeout function that will be called every "interval" milliseconds.<< |
| 18:21.01 | bencoh | hmm actually they also removed this callback as well |
| 18:21.06 | DocScrutinizer05 | so it's a recurring timer |
| 18:21.10 | bencoh | yeah it is |
| 18:21.25 | DocScrutinizer05 | that's pretty odd |
| 18:21.26 | bencoh | (that's actually what I was implying, sorry) |
| 18:21.35 | *** join/#maemo florian (~fuchs@Maemo/community/contributor/florian) |
| 18:22.07 | bencoh | it's an ugly recurring timer to check "should I die now ?" |
| 18:22.11 | DocScrutinizer05 | The return value is an integer "tag" which may be used to stop the timeout by calling: |
| 18:22.12 | DocScrutinizer05 | <PROTECTED> |
| 18:22.30 | DocScrutinizer05 | braindamaged code |
| 18:22.33 | bencoh | yup |
| 18:22.58 | DocScrutinizer05 | HAHA >>You may also stop the timeout function by returning zero or FALSE from your callback function.<< |
| 18:23.18 | bencoh | I might try to update scim to 1.4.14 (part of it has been rewritten and it should behave better) |
| 18:23.32 | bencoh | but I cant even build 1.4.7 in sb |
| 18:23.45 | bencoh | I half-baked the tool from binary lib |
| 18:24.03 | bencoh | I wonder how it got built at first |
| 18:24.36 | *** join/#maemo at1as (~at1as@c-68-61-134-228.hsd1.mi.comcast.net) |
| 18:24.50 | DocScrutinizer05 | I'd not be surprised to find gtk do a busy loop for every instance of timer event registered via gtk_timeout_add() |
| 18:25.59 | *** part/#maemo mkaindl (~mkaindl@ama-dablam.markus-kaindl.de) |
| 18:34.45 | DocScrutinizer05 | I honestly wonder why this code needs such nonsense instead of doing it right in signalhandler(int sig) |
| 18:37.39 | bencoh | they eventually had it write |
| 18:37.55 | bencoh | the author was probably on heavy drug .... or just sleep deprived ;) |
| 18:38.27 | bencoh | s/write/right/ : https://bugzilla.redhat.com/show_bug.cgi?id=444150 |
| 18:39.25 | bencoh | funny thing is we got a borked version for maemo, and people started writing a kludgy menu applet "switcher" instead of patching/looking for a patch |
| 18:39.35 | bencoh | (this bug ticket predates n900) |
| 18:39.37 | DocScrutinizer05 | <PROTECTED> |
| 18:39.39 | DocScrutinizer05 | <PROTECTED> |
| 18:39.40 | DocScrutinizer05 | <PROTECTED> |
| 18:39.42 | DocScrutinizer05 | <PROTECTED> |
| 18:39.43 | DocScrutinizer05 | WTF? |
| 18:39.47 | bencoh | exactly |
| 18:40.22 | bencoh | told you it was ugly |
| 18:40.29 | DocScrutinizer05 | this whole code has more cruft and commented-out lines of code than actually meaningful ones |
| 18:41.49 | DocScrutinizer05 | and this coude looks to me pretty similar to a chinese PCB |
| 18:41.55 | DocScrutinizer05 | code* |
| 18:42.11 | bencoh | :)) |
| 18:42.30 | bencoh | considering scim is mostly used for cjk input .... it probably is |
| 18:42.39 | bencoh | (or japanese code, maybe) |
| 18:42.49 | DocScrutinizer05 | apply random changes until it starts to work. then cut out components until it stops working. Revert last component removal. Produce |
| 18:43.08 | bencoh | hm no, definitely chinese, from the names |
| 18:47.04 | DocScrutinizer05 | God, I hate such uninspired code |
| 18:47.25 | DocScrutinizer05 | reading it feels like drinking sour milk |
| 18:48.03 | *** join/#maemo sq-one (~sq-one@p549AAC96.dip0.t-ipconnect.de) |
| 18:48.18 | DocScrutinizer05 | and thinking of that code maybe running on my machine gives me a feeling like in a restaurant where I know they cook with rotten milk |
| 18:49.32 | DocScrutinizer05 | ugh, meeting today |
| 18:55.15 | *** join/#maemo ciroip (~ciro@cpe-071-068-052-063.carolina.res.rr.com) |
| 18:58.28 | bencoh | I'm pretty sure half (most ?) of desktop software looks or looked like that at some point |
| 18:58.37 | bencoh | and maemo prolly isnt an exception |
| 19:03.24 | DocScrutinizer05 | I'm quite sude most of KDE looks similar, yes |
| 19:03.29 | DocScrutinizer05 | sure* |
| 19:04.21 | DocScrutinizer05 | most (core) maemo code I've seen isn't all that bad |
| 19:04.45 | bencoh | look at hildon-desktop then :> |
| 19:05.02 | DocScrutinizer05 | some stuff (hildon for example) could use some more love for parameter checking etc |
| 19:05.09 | bencoh | or just the fact that you cant have desktop widgets without waking cpu |
| 19:05.24 | DocScrutinizer05 | err wut? |
| 19:05.33 | bencoh | (I mean, waking cpu more than is needed) |
| 19:06.09 | bencoh | I spotted a few loops/condition inversion in hildon-home |
| 19:06.27 | bencoh | (or hildon-desktop, I dont remember where this part of the code sits) |
| 19:07.19 | bencoh | basically it loops through widgets and checks whether display is *inside* the loop for each widget |
| 19:07.27 | bencoh | and I suspect there is more |
| 19:08.36 | DocScrutinizer05 | you mean hildon executing all widget code frequently to do display updates as long as desktop is visible? well, that's not exactly nice but sort of tolerable |
| 19:09.49 | DocScrutinizer05 | the fact that a single segfaulting or freezing widget makes whole desktop go south is more severe |
| 19:09.50 | bencoh | depending on the widget it can get pretty heavy |
| 19:10.18 | bencoh | true, that's quite bad as well, but this is more of a design thing |
| 19:10.44 | DocScrutinizer05 | display update for all widgets is as well |
| 19:11.26 | bencoh | on a different level/of a different nature |
| 19:11.28 | DocScrutinizer05 | since the widgets are executed in hildon context, as simple function calls, there's no reasonable way for them to announce they don't need to update their display |
| 19:12.15 | DocScrutinizer05 | a widget simply returning as fast as possuble when nothing to do is the most lightweight way to handle this in this architecture |
| 19:13.21 | *** join/#maemo totalizator (~totalizat@89-69-49-198.dynamic.chello.pl) |
| 19:13.48 | DocScrutinizer05 | and anyway since the homescreen and thus the widgets are visible, there's a certain system load anyway, and particularly a certain energy consumption by backlight and mere display data bus. So a 10 wakeups per second for CPU don't really hurt |
| 19:13.49 | bencoh | anyway ... now to build http://tomoe.sourceforge.jp against scim in sb |
| 19:14.12 | bencoh | DocScrutinizer05: actually I was talking of display status check |
| 19:14.22 | bencoh | s/of/about/ |
| 19:14.26 | DocScrutinizer05 | display status check? |
| 19:14.40 | bencoh | "is display on" "is desktop visible" "is device unlocked" |
| 19:14.43 | bencoh | that kind of things |
| 19:14.58 | DocScrutinizer05 | that's supposed to get done in hildon |
| 19:15.21 | DocScrutinizer05 | makes absolutely no sense to do it in every widget |
| 19:15.41 | bencoh | that's done in hildon but in reverse order/in a peculiar way |
| 19:15.47 | bencoh | lemme find the source |
| 19:16.11 | DocScrutinizer05 | when display of homescreen isn't visible, not a single widget is visible, so why should hildon run any wiget code in that sitation? |
| 19:17.15 | DocScrutinizer05 | as soon as display status changes from invisible to visible, all widgets need to update their display content, and then every 50ms or whatever |
| 19:18.05 | DocScrutinizer05 | as soon as status changes from visible to not visible (aka background, or locked), hildon should stop executing +any* widget code |
| 19:18.36 | bencoh | hd_comp_mgr_update_applets_on_current_desktop_property |
| 19:19.17 | DocScrutinizer05 | every widget in turn is supposed to check early if there's actually sth to update and return when e.g. last (seconds) digit of the clock didn't change |
| 19:19.21 | bencoh | it goes through widgets twice and make Xlib calls whether display is on or not |
| 19:20.00 | bencoh | which roughly means going through X11 crazy codepath |
| 19:20.17 | DocScrutinizer05 | I never checked that hildon code. I'm talking from mere best practice which I'd expect to see in hildon |
| 19:21.26 | bencoh | well ... I'd definitely love to see more best practice everywhere :) |
| 19:21.29 | DocScrutinizer05 | and I'm pretty sure hildon does NOT do what you say it does, when screen is locked. Otherwise my battery wouldn't stay a 5h even |
| 19:22.30 | bencoh | I didnt say it would really update widgets when locked, but it would do some X calls |
| 19:22.56 | DocScrutinizer05 | X calls are as worse as display updates |
| 19:23.14 | jaska | i guess i need to look up the dual bl-5j hack, my mugen is getting shorter |
| 19:26.03 | bencoh | DocScrutinizer05: well some widgets (hello qwb !) can do much worse ... but yeah, X calls arent free, that's my point ;) |
| 19:29.42 | DocScrutinizer05 | my point is that I honestly doubt they happen while screen locked |
| 19:30.15 | DocScrutinizer05 | if they actually do, then that's prolly a bug |
| 19:30.23 | bencoh | I think it does at least for XDeleteProperty |
| 19:30.51 | bencoh | though I didnt rebuild hildon/mb to trace that |
| 19:31.43 | bencoh | but then again, powertop has different output with and without widgets (be it one simple widget) |
| 19:32.00 | DocScrutinizer05 | that's bad |
| 19:32.29 | DocScrutinizer05 | at least when you talk about locked screen |
| 19:32.36 | bencoh | yup |
| 19:33.14 | DocScrutinizer05 | actually with a locked screen hildon itself shouldn't run anymore |
| 19:33.59 | DocScrutinizer05 | unless some idiotic widget scheduled a timer |
| 19:34.58 | DocScrutinizer05 | you know, one of the kind that sends a signal to wake up the process on expiry |
| 19:35.20 | *** join/#maemo ult (~root@188.198.32.95.dsl-dynamic.vsi.ru) |
| 19:35.44 | DocScrutinizer05 | "the process" is hildon here, and of course it needs to run *all* widgets so the idiotic one has a chance to service the timer expiry |
| 19:36.18 | bencoh | I think I tested with DCE widget at that time |
| 19:36.32 | bencoh | (which behaved better than qwb, but still) |
| 19:36.33 | DocScrutinizer05 | whatever that is |
| 19:36.46 | bencoh | desktop cmd exec |
| 19:36.46 | *** join/#maemo xes (~xes@unaffiliated/xes) |
| 19:36.55 | bencoh | and I checked the source as well |
| 19:37.09 | DocScrutinizer05 | umm well |
| 19:37.16 | *** part/#maemo ult (~root@188.198.32.95.dsl-dynamic.vsi.ru) |
| 19:38.08 | bencoh | I stopped using widgets at that point |
| 19:38.09 | DocScrutinizer05 | I dunno what QBW does, but it prolly shouldn't run any timers. it has nothing that needs a timed execution |
| 19:38.24 | bencoh | qwb has timed functionality (as well as dce) |
| 19:38.39 | bencoh | but qwb is heavier in everything |
| 19:39.26 | DocScrutinizer05 | ~qbw |
| 19:39.51 | DocScrutinizer05 | ~qwb |
| 19:40.07 | *** join/#maemo ult (~root@188.198.32.95.dsl-dynamic.vsi.ru) |
| 19:41.03 | DocScrutinizer05 | it's probably an absolutely idiotic idea to implement something like a daemon that get executed 10 times per second in a widget |
| 19:41.37 | DocScrutinizer05 | I can't think of any such function that would need that |
| 19:41.50 | bencoh | it is, but ... looks like some people found it neat |
| 19:41.57 | bencoh | I dont understand either :) |
| 19:46.20 | *** join/#maemo javispedro (~javier@Maemo/community/contributor/javispedro) |
| 19:53.34 | DocScrutinizer05 | I mean, sure I could integrate the fan control of my PC into xeyes.... BUT... |
| 19:54.37 | DocScrutinizer05 | shouldn't a widget do *only* stuff that's actually visible on display? And particularly shouldn't it STOP doing this as soon as the display isn't visible? |
| 19:56.35 | DocScrutinizer05 | a maemo widget isn't just an arbitrary X-app with a funny shaped window |
| 20:01.42 | kerio | DocScrutinizer05: X has a way to figure out whether or not you're drawn |
| 20:03.38 | DocScrutinizer05 | kerio: so what? |
| 20:03.54 | DocScrutinizer05 | you're aware that all widgets run as "hildon" ? |
| 20:04.00 | kerio | so even if it was an arbitrary X program, it doesn't really have an excuse to waste cpu |
| 20:04.23 | bencoh | :) |
| 20:05.00 | DocScrutinizer05 | kerio: that's completely off the point we discussed, which is timer ALARM |
| 20:05.13 | kerio | "shouldn't a widget do *only* stuff that's actually visible on display? And particularly shouldn't it STOP doing this as soon as the display isn't visible?" |
| 20:05.32 | kerio | i expect every fucking program to do that, not only widgets |
| 20:05.42 | DocScrutinizer05 | aha |
| 20:05.59 | DocScrutinizer05 | kerio: that's completely off the point we discussed, which been daemons |
| 20:06.34 | DocScrutinizer05 | and those for sure don't give an F that they are not visible usually |
| 20:08.04 | DocScrutinizer05 | lemme put it simple: you MUST NOT make an X program out of crond |
| 20:12.10 | *** join/#maemo xes_ (~xes@unaffiliated/xes) |
| 20:14.39 | *** join/#maemo jas4711 (~jas@2001:16d8:cca1:0:c44f:bedb:5930:c5c1) |
| 20:22.58 | *** join/#maemo DrCode (~DrCode@gateway/tor-sasl/drcode) |
| 20:24.35 | *** join/#maemo alexript (~ircchatte@95-24-89-126.broadband.corbina.ru) |
| 20:38.07 | *** join/#maemo YnG (~YnG@213.158.216.156.pat.umts.dynamic.t-mobile.pl) |
| 20:49.33 | *** join/#maemo louisdk (~louis@static-5-103-130-65.seas-nve.net) |
| 20:52.38 | *** join/#maemo at1as (~at1as@c-68-41-93-27.hsd1.mi.comcast.net) |
| 21:05.03 | *** join/#maemo nox- (noident@freebsd/developer/nox) |
| 21:16.44 | bencoh | is there a place to set envvars for programs started from X (I'd use .xinitrc, but I'm not sure it's honoured on maemo) ? |
| 21:23.03 | *** join/#maemo kraft (kraft@gateway/shell/blinkenshell.org/x-lhodzkkjqswkafsn) |
| 21:29.06 | *** join/#maemo eMHa_ (~mh@HSI-KBW-46-223-128-122.hsi.kabel-badenwuerttemberg.de) |
| 21:42.37 | *** join/#maemo janemba (~101@unaffiliated/janemba) |
| 21:44.02 | *** join/#maemo goldkatze (~nobody@unaffiliated/goldkatze) |
| 22:18.13 | *** join/#maemo Marigabi (~canaima@190.206.16.124) |
| 23:02.33 | *** join/#maemo RiD (~RiD@2.83.62.95) |
| 23:09.17 | *** join/#maemo at1as (~at1as@kurios.r4780y.com) |
| 23:23.58 | *** join/#maemo dima5` (~user@cpe-23-243-199-75.socal.res.rr.com) |
| 23:46.19 | *** join/#maemo pcfe (~pcfe@37-5-66-76-dynip.superkabel.de) |
| 23:46.20 | *** join/#maemo pcfe (~pcfe@redhat/pcfe) |
| 23:47.52 | DocScrutinizer05 | hmmmm, some apps get started by the original binary acme (which in fact is a symlink to maemo-invoker(?) ) sending a dbus cmd to maemo-launcher(?) which then invokes the real binary acme.launch |
| 23:48.25 | DocScrutinizer05 | or some similar names and scenario. Hard to believe in any env vars getting set for the final binary in this |
| 23:48.53 | DocScrutinizer05 | I guess global envs can get set though, somewhere in the initscripts |
| 23:52.26 | *** join/#maemo nox- (noident@freebsd/developer/nox) |
| 23:58.57 | bencoh | nothing per-user then |