**** BEGIN LOGGING AT Thu Apr 02 02:59:58 2015 Apr 02 03:05:18 antrik: is Vala a proper high-level language? iow, What is the common alternative to c++? Apr 02 03:06:44 D? Apr 02 07:29:00 [02mdbus] 07mickeyl pushed 031 commit to 03master [+0/-0/±2] 13http://git.io/jjud Apr 02 07:29:06 [02mdbus] 07mickeyl 037d9a02c - TODO++ and slight additions to the README.md Apr 02 08:14:16 you'd think after 50 years the computer scientists should finally have found a common idea of what's the proper high level language. But no.... :-/ Apr 02 08:17:10 meanwhile I think you should focus on the problem at hand, not at the language you're using to solve it Apr 02 08:31:23 true, but it's somewhat irritating that there are so many of 'em. And this inevitably leads to dozens of duplicated work on tools, like FOO is the same as BAR, but written in BAZ instead of DINGS *sigh* Apr 02 08:34:00 [02mdbus] 07mickeyl pushed 031 commit to 03master [+0/-0/±2] 13http://git.io/jj9Z Apr 02 08:34:06 [02mdbus] 07mickeyl 034691cfb - manpage: improve wording as pointed out by DocScrutinizer Apr 02 08:44:16 mickeyl: indeed, and it's a self sustaining effect Apr 02 08:46:42 I've seen often enough a "well, all that languages out there annoyed me, so I made invented my own one, the ultimate best language ever" -- "But... that looks like 99% of FOO (invented 1968) and 1% of BAR (invented 2004)" -- "Ohh!" Apr 02 08:48:15 I guess whole master thesises(?? thesi, tesa?) failed for that Apr 02 08:53:11 [02vala-dbus-binding-tool] 07mickeyl pushed 031 commit to 03master [+3/-0/±3] 13http://git.io/jjda Apr 02 08:53:17 [02vala-dbus-binding-tool] 07mickeyl 03ba9458e - add a manpage Apr 02 09:15:04 Not-311d: quite chatty, arent you ? :p Apr 02 09:15:18 at least we've got life here :-) Apr 02 09:23:14 Not-311d: help Apr 02 09:23:47 meh Apr 02 09:24:04 mickeyl: you added Not-311d ? Apr 02 09:26:14 mickeyl: if yes, please do /msg chanserv flags Not-311d +V Apr 02 09:26:35 opps Apr 02 09:26:53 mickeyl: if yes, please do /msg chanserv flags #openmoko-cdevel Not-311d +V Apr 02 09:27:58 even /msg chanserv flags #openmoko-cdevel Not-311d!*@*.* +V Apr 02 09:28:35 I'd really prefer that bot had a proper registration, but... guess that's hard to talk the owner into Apr 02 09:53:41 dang bots Apr 02 10:07:44 [02cornucopia] 07jake42 opened issue 03#1: fsotdld crashes on changing networkinterface - 13http://git.io/veenj Apr 02 10:11:02 DocScrutinizer05: yep, i added it. i issues the chancery commands, but i didn't get any result back from chancery Apr 02 10:11:46 chanserv? Apr 02 10:12:12 [2015-04-02 Thu 12:12:03] <-> chanserv> flags #openmoko-cdevel Not-311d!*@*.* +V Apr 02 10:12:13 [2015-04-02 Thu 12:12:03] [Notice] -ChanServ- Flags +V were set on Not-311d!*@*.* in #openmoko-cdevel. Apr 02 10:12:15 [2015-04-02 Thu 12:12:03] *** ChanServ gives Not-311d permission to talk. Apr 02 10:12:28 [2015-04-02 Thu 12:12:17] [Notice] -ChanServ- 10 Not-311d!*@*.* +V [modified 14s ago] Apr 02 10:12:41 alas it has no note on who added it, so nm Apr 02 10:14:20 thought the ACL has a note on who set the flags Apr 02 10:14:32 so we could know who added the bot Apr 02 10:16:01 anyway you got +f on ACL, so chanserv should accept your command Apr 02 10:19:17 [2015-04-02 Thu 12:19:08] [Whois] mickeyl is logged in as mickey|zzZZzz. Apr 02 10:19:27 hmm, yeah. It *should* Apr 02 10:20:15 [02cornucopia] 07jake42 opened issue 03#2: fsotdld does not trigger alarm at right time after suspend - 13http://git.io/vee8i Apr 02 10:20:24 excellent. bugs coming in :) Apr 02 10:20:26 typo on "chancery" ? Apr 02 10:20:29 ya Apr 02 10:20:35 autocompletion Apr 02 10:20:38 ooh Apr 02 10:20:40 need to disable that Apr 02 10:20:45 err Apr 02 10:20:46 indeed :-) Apr 02 10:20:47 autocorrection, actually Apr 02 10:20:52 stupid OS Apr 02 10:21:42 stupid autocorrections, not context aware Apr 02 10:22:01 try shell with autocorrection ;-) Apr 02 10:22:06 heh, yah Apr 02 10:22:19 those two would really make shr alot better when fixed Apr 02 10:22:50 jake42: great spotting Apr 02 10:22:52 I could wake up to the sound of my freerunner again :p Apr 02 10:23:18 well, it's still over my head to fix those but I tried my best Apr 02 10:23:24 time and suspend/resume is a nightmare in SHR Apr 02 10:23:30 or more generally debian Apr 02 10:24:15 internal timers are using jiffies or whatever, and those get readjusted to a random new origina after resume Apr 02 10:24:19 I don't know how monotonic time advances in n900 Apr 02 10:25:08 something is completey odd with time and suspend/resume in this system Apr 02 10:25:24 though an alarm set for wallclocktime should really depend on that not monotonic time Apr 02 10:25:45 but actually RTC alarms should work on "everyday" time Apr 02 10:25:55 well RTC works Apr 02 10:26:00 device wakes up Apr 02 10:26:10 at right time Apr 02 10:26:13 usual MM-dd hh:mm:ss format Apr 02 10:26:21 ooh Apr 02 10:26:42 and then the local systemtime is completely off and thus the wake reason gets lost Apr 02 10:26:52 right? Apr 02 10:27:12 I don't know exactly Apr 02 10:27:34 I recall I've seen weird stuff happening during resume Apr 02 10:27:38 fsotdld sets a timeout in glib Apr 02 10:28:15 but time to the timeout only advances when system is not suspended Apr 02 10:28:37 so system wakes up, fsotdld doesn Apr 02 10:28:49 system time gets restored to value before suspend, but then some weird mechanism *adds* an offset calculated from time of suspend to RTC time of resume Apr 02 10:28:53 't get a signal? Apr 02 10:28:55 pretty fuggly Apr 02 10:29:10 the thing is is worked sometime ago Apr 02 10:29:23 race condition maybe Apr 02 10:29:24 back then "uptime" also showed corret uptime Apr 02 10:29:29 correct* Apr 02 10:29:39 this offset correction only happens some time +after* resume Apr 02 10:29:43 inklusive being in suspend Apr 02 10:30:16 * jake42 is off to lunch Apr 02 10:31:41 but back when I looked into it, the issue been that the offset been calculated between SUS1 to RES2, but the actual systime scew was SUS2 (later than SUS1) to RES1 (earlier than RES2) Apr 02 10:32:11 the only correct thing would be to set systime anew from RTC, just like during boot Apr 02 10:32:22 when resuming Apr 02 10:32:46 I don't see why we need to add an offset to a systime that's massively incorrect anyway Apr 02 10:33:00 rather than set it all new right waway Apr 02 10:34:17 ((offset been calculated)) this introduced an error up to 30s into systime iirc Apr 02 10:34:54 which might already be too much and too late for fsotdld to recognize the alarm being due Apr 02 11:17:54 ooh, well, it seems the ticket already has a pretty good hint who's culprit (gnome) and how to fix it (don't use monotonic time) Apr 02 12:09:30 of course! as soon as there's an opportunity, our German ministry of internal affairs tries to establish further controls for even national air travel. As if that would help *anything* for safety. Damn Orwell state Apr 02 12:10:13 what's next? German no-fly lists Apr 02 13:24:22 PaulFertser: there is no "common" alternative. some like D, some like Vala (or C#), some like Go, some like Rust, some like more exotic languages such as OCaml... and of course, for most things that are not very low-level or very performance-critical, there are loads of higher-level languages Apr 02 13:48:44 >>If you can't do it in FORTRAN, do it in assembly language. If you can't do it in assembly language, it isn't worth doing.<< Apr 02 13:49:01 ;-) Apr 02 18:23:11 [02cornucopia] 07mickeyl labeled issue 03#1: fsotdld crashes on changing networkinterface - 13http://git.io/veenj Apr 02 18:28:09 [02cornucopia] 07mickeyl commented on issue 03#1: fsotdld crashes on changing networkinterface - 13http://git.io/veJpm Apr 02 18:29:05 [02cornucopia] 07mickeyl assigned issue 03#1: fsotdld crashes on changing networkinterface - 13http://git.io/veenj **** ENDING LOGGING AT Fri Apr 03 02:59:59 2015