| 00:26.29 | *** join/#maemo infobot (~infobot@208.53.50.136) |
| 00:26.29 | *** topic/#maemo is Welcome to #maemo http://maemo.org/intro/ | N9/harmattan related questions please in #harmattan ! | "firmware" see ~lf (or ~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 |
| 00:26.29 | *** mode/#maemo [+v infobot] by ChanServ |
| 01:38.53 | *** join/#maemo sunshavi (~user@181.65.22.21) |
| 02:15.46 | *** join/#maemo r00t^home (~r00t@port-92-202-163-191.dynamic.qsc.de) |
| 02:20.19 | *** join/#maemo infobot (ibot@208.53.50.136) |
| 02:20.19 | *** topic/#maemo is Welcome to #maemo http://maemo.org/intro/ | N9/harmattan related questions please in #harmattan ! | "firmware" see ~lf (or ~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 |
| 02:20.19 | *** mode/#maemo [+v infobot] by ChanServ |
| 02:20.43 | *** join/#maemo Kabouik (~kabouik@236.34.200.37.customer.cdi.no) |
| 02:21.39 | *** join/#maemo FalconSpy_ (falconspy@ip70-190-163-75.ph.ph.cox.net) |
| 02:22.57 | *** join/#maemo guerby_ (~guerby@ip165.tetaneutral.net) |
| 02:31.54 | *** join/#maemo mickname (~mickname@2001:708:30:1300:468a:5bff:fe24:e59e) |
| 02:34.02 | *** join/#maemo useretail (useretail@gateway/shell/elitebnc/x-yxsyaymojdnxgrcv) |
| 02:36.40 | *** join/#maemo amospalla (~amospalla@unaffiliated/amospalla) |
| 02:37.01 | *** join/#maemo geaaru (~geaaru@151.60.41.47) |
| 02:54.44 | brolin_empey | KotCzarny: Yes, with â1.0/3â or â1/3.0â the result is correct. I forgot that integer division is different than decimal/float division. |
| 03:01.06 | *** join/#maemo d10n25 (~d10n@static-190-181-45-108.acelerate.net) |
| 03:11.01 | *** join/#maemo DarthVader (~user@2a02:a446:8185:1:4446:a223:e322:b200) |
| 03:12.34 | *** join/#maemo DarthVad` (~user@ip5652d1e2.speed.planet.nl) |
| 03:21.36 | *** join/#maemo FalconSpy (falconspy@ip70-190-163-75.ph.ph.cox.net) |
| 03:21.36 | *** join/#maemo FalconSpy (falconspy@unaffiliated/falconspy) |
| 03:59.58 | *** join/#maemo pagurus` (~user@i59F7764F.versanet.de) |
| 04:08.12 | *** join/#maemo FalconSpy (falconspy@unaffiliated/falconspy) |
| 04:20.48 | *** join/#maemo Ambroisie (~Ambroisie@203.234.245.5) |
| 05:06.01 | *** join/#maemo pathfinder (~pathfinde@190-78-228-86.dyn.dsl.cantv.net) |
| 05:31.37 | *** join/#maemo freemangordon (~ivo@46.249.74.23) |
| 05:37.18 | *** join/#maemo spiiroin (~spiiroin@2001:998:2a:dead:6d7a:2144:ebd4:1b4d) |
| 05:59.06 | *** join/#maemo guerby (~guerby@april/board/guerby) |
| 06:24.34 | *** join/#maemo dafox (~dafox@31.161.136.69) |
| 07:01.19 | *** join/#maemo geaaru (~geaaru@host170-152-static.43-88-b.business.telecomitalia.it) |
| 07:41.10 | *** join/#maemo Thanks (~Thanks@KD027094138034.ppp-bb.dion.ne.jp) |
| 07:44.02 | *** join/#maemo xorly (~xorly@ip-86-49-24-93.net.upcbroadband.cz) |
| 07:59.27 | DocScrutinizer05 | hail strict typing |
| 07:59.46 | DocScrutinizer05 | this implicit typing is a mess |
| 08:01.27 | DocScrutinizer05 | there shouldn't even be a thing like "integer division", only cast while assigning results to variables |
| 08:02.11 | KotCzarny | say that to fpu less cpus |
| 08:03.07 | DocScrutinizer05 | and it's the implicit hidden cast that makes me throw up. A decent compiler would throw an error or at least a bold fat warning when assigning a (possibly) non-integer result to an integer variable |
| 08:04.20 | DocScrutinizer05 | int i = int( a / b ) |
| 08:04.55 | DocScrutinizer05 | int i = a / b BZZZZZZZ JACKASS! |
| 08:05.10 | bencoh | actually the current behavior is both sane and accurate |
| 08:05.30 | DocScrutinizer05 | it is, but not obvious |
| 08:05.52 | DocScrutinizer05 | as the description implies: it's implicit |
| 08:05.58 | bencoh | you just should not expect a float result when dividing integers |
| 08:06.20 | KotCzarny | that's a compiler's nuance, or language? |
| 08:06.22 | DocScrutinizer05 | you always should expect a float result when dividing |
| 08:06.25 | bencoh | it might be implicit, but nothing indicates it should not be the case |
| 08:06.31 | bencoh | absolutely not |
| 08:06.42 | KotCzarny | if language, it's ok, if compiler, it's black magic |
| 08:06.47 | KotCzarny | (for new users) |
| 08:06.55 | DocScrutinizer05 | it's langiage, for c |
| 08:06.56 | bencoh | KotCzarny: C standard |
| 08:07.12 | KotCzarny | then it's up to the user to learn properly |
| 08:07.12 | bencoh | most probably K&R or c89, at least |
| 08:07.31 | DocScrutinizer05 | it's prolly B already ;-D |
| 08:07.48 | bencoh | haha, could be |
| 08:07.55 | DocScrutinizer05 | aka: the most eloquent assembler ever made |
| 08:12.10 | Maxdamantus | Just to be clear: the issue is implicit conversion, not implicit typing. |
| 08:13.11 | bencoh | (or the lack thereof) |
| 08:13.23 | bencoh | (which is a good thing in my opinion) |
| 08:13.29 | Maxdamantus | The issue is its precense. |
| 08:13.38 | Maxdamantus | presence* |
| 08:13.49 | bencoh | ? |
| 08:13.57 | DocScrutinizer05 | of course it's a matter of personal preferences |
| 08:14.16 | DocScrutinizer05 | I lack half of the convo, sorry |
| 08:14.28 | Maxdamantus | imo 5/4 == 2 is acceptable, 5/4.0 == 2.5 should be a type error. |
| 08:14.39 | bencoh | Maxdamantus: ah |
| 08:14.48 | bencoh | (5/2.0 I guess) |
| 08:14.57 | Maxdamantus | er, yeah |
| 08:15.17 | KotCzarny | imo current behavior of c is ok |
| 08:15.26 | bencoh | KotCzarny: I think so as well, but ... :) |
| 08:15.31 | Maxdamantus | I would probably also lean on the side of having separate operators for floating and integral division. |
| 08:15.34 | DocScrutinizer05 | how do you add a ".0" to int i; ? |
| 08:15.53 | bencoh | DocScrutinizer05: you cannot; you have to cast it |
| 08:15.58 | KotCzarny | similarly to whole pointer thingy, tracking and remembering variable types and expected return types is up to the dev |
| 08:15.59 | DocScrutinizer05 | :-P |
| 08:16.20 | KotCzarny | in c++ otoh yeah, compiler should nag the poor user to death with warnings/errors |
| 08:16.52 | KotCzarny | bencoh, i think i+=.0 will work ;) |
| 08:17.00 | Maxdamantus | C has a bunch of other issues around implicit conversions, eg: int x = 4; unsigned y = -4; x < y; |
| 08:17.08 | KotCzarny | unless you want to change type |
| 08:17.29 | DocScrutinizer05 | in my book a operation (divide) that could yield a float WILL yield a float, always. If you want "integer divide" you got operators and cast for that |
| 08:17.30 | Maxdamantus | eh, should've been the other way round |
| 08:17.33 | KotCzarny | maxd: in that case you get a nice, juicy warning |
| 08:17.44 | Maxdamantus | int x = -4; unsigned y = 4; y < x; |
| 08:17.47 | *** join/#maemo florian (~florian_k@Maemo/community/contributor/florian) |
| 08:18.34 | bencoh | KotCzarny: i+=0. won't change anything to i |
| 08:18.49 | bencoh | you cannot change the type of a variable |
| 08:18.51 | DocScrutinizer05 | ORLY? :-D |
| 08:19.10 | bencoh | DocScrutinizer05: I dunno why, but he seemed to imply that it would |
| 08:19.17 | DocScrutinizer05 | hehehehe |
| 08:19.21 | bencoh | (or was that sarcasm? :]) |
| 08:19.25 | KotCzarny | bencoh, question was not clear (i've went with how to add .0 in value to i ;) |
| 08:19.35 | bencoh | huhu |
| 08:20.05 | Maxdamantus | 20:17:33 < KotCzarny> maxd: in that case you get a nice, juicy warning |
| 08:20.23 | Maxdamantus | I don't seem to get any warning with `gcc -Wall -pedantic` |
| 08:20.30 | KotCzarny | hmm, let me check |
| 08:20.43 | Maxdamantus | That's using 4.9.3 though, a bit old. |
| 08:21.00 | Maxdamantus | Still no warning with 6.4.0 |
| 08:21.40 | bencoh | well, it's valid behavior, although I would expect a compiler warning as well |
| 08:21.49 | bencoh | they do warn about unused variables, so ... |
| 08:22.11 | bencoh | not warning about that is silly |
| 08:23.08 | KotCzarny | oh right. it's in -Wextra |
| 08:23.19 | KotCzarny | (in 4.9.2 at least) |
| 08:23.39 | Maxdamantus | Heh, don't think I've ever used -Wextra |
| 08:23.56 | KotCzarny | it's nice to catch some more obvious brainfarts ;) |
| 08:24.11 | Maxdamantus | more obvious, or less obvious? Presumably less. |
| 08:24.43 | Maxdamantus | Anyway, in a sensible language, that's just a type error. |
| 08:24.57 | KotCzarny | more as in numerical number of them |
| 08:25.10 | Maxdamantus | because you should have something like `(>) :: a -> a -> boolean`, where `a` is any given number type. |
| 08:25.24 | KotCzarny | c assumes dev knows what he/she is doing |
| 08:25.25 | Maxdamantus | So `(>) :: unsigned -> signed -> boolean` is not valid. |
| 08:26.06 | KotCzarny | and if you know that int x wont get into negatives or y more than half of the type, it will work |
| 08:26.29 | KotCzarny | many bugs prove it wrong though ;) |
| 08:26.59 | KotCzarny | but that's C, love it, learn it or go into some sandbox |
| 08:27.48 | KotCzarny | it's like trying to apply political correctness to the programming language |
| 08:28.00 | Maxdamantus | Those are exclusive, right? |
| 08:28.19 | bencoh | Maxdamantus: both learn and love C, you mean? |
| 08:28.25 | Maxdamantus | bencoh: yes. |
| 08:28.28 | bencoh | I somehow fell in love with it :) |
| 08:29.14 | Maxdamantus | I mostly just got amused by figuring out weird things based on reading the standards over and over again. |
| 08:29.25 | Maxdamantus | eg, like how you can pass arrays to functions in C90 but not C99. |
| 08:29.46 | Maxdamantus | but in either case, you can't do anything with those passed arrays. |
| 08:29.51 | bencoh | their are some standard oddities, yeah |
| 08:29.55 | bencoh | there* |
| 08:30.17 | Maxdamantus | though gnu89 lets you use the array in those cases where you can pass it (but that's non-standard) |
| 08:30.38 | KotCzarny | isnt string an array? |
| 08:30.48 | KotCzarny | ;) |
| 08:31.16 | Maxdamantus | Not exactly. |
| 08:35.37 | Maxdamantus | in case anyone's interested with the array passing thing: struct a { int a[10]; }; struct a foo(void){ struct a r = {0}; return r; } void bar(int a, ...){} int main(void){ bar(42, foo().a); } |
| 08:36.38 | Maxdamantus | In C90, that passes an array to `bar`. In C99 and C11 it passes a pointer that is invalid once control actually reaches the function. |
| 08:38.52 | Maxdamantus | and in gnu89, I think you can actually write `int a[10] = va_arg(ap, int [10]);` to get it again. |
| 08:41.27 | Maxdamantus | in C89 itself, you can at least write `va_arg(ap, a10);` given `typedef int a10[10];` (but not necessarily `va_arg(ap, int [10])`, since `va_arg` is only specified as taking an identifier as the type), but you can't do anything with it except pass it to another variadic since it's a non-lvalue of array type. |
| 08:42.02 | Maxdamantus | another variadic function* |
| 08:45.04 | bencoh | Maxdamantus: what do you mean by "array" in that case? |
| 08:45.19 | Maxdamantus | bencoh: in which case? |
| 08:45.24 | bencoh | is the whole array stored in the stack? |
| 08:45.28 | bencoh | c90 |
| 08:45.43 | Maxdamantus | bencoh: if you think about it as a stack and of all arguments being on the stack, yes. |
| 08:46.18 | bencoh | that sounds odd tbh, but ... :) |
| 08:46.19 | Maxdamantus | Usually you don't get to handle arrays as values. |
| 08:46.41 | bencoh | (I mean, such a definition sounds odd) |
| 08:47.00 | Maxdamantus | because array expressions end up just being pointers in all sensible contexts other than when they appear as the operand of &. |
| 08:47.38 | Maxdamantus | but `foo().a` is a weird case, since `foo().a` is not an lvalue, so the array â pointer rule doesn't apply to it in C90. |
| 08:47.38 | bencoh | yeah |
| 08:47.50 | bencoh | ah |
| 08:47.53 | bencoh | I see |
| 08:48.14 | Maxdamantus | C99 added the extra case of non-lvalue array expressions though, so in C99 it does turn into a pointer, which means you can then access one of its members. |
| 08:48.33 | Maxdamantus | (in C90, `foo().a[0]` is invalid when `foo().a` is an array) |
| 08:48.41 | bencoh | sounds like a standard "bug" :) |
| 08:48.45 | KotCzarny | is there any gain of passing it as array instead of just pointer? |
| 08:48.46 | bencoh | (bug-by-design I mean) |
| 08:49.14 | *** join/#maemo jskarvad (jskarvad@redhat/jskarvad) |
| 08:49.25 | Maxdamantus | KotCzarny: it would be logically sensible to be able to pass array values around. |
| 08:49.27 | bencoh | KotCzarny: well, the pointer is eventually invalid, while copied data would remain valid |
| 08:49.59 | Maxdamantus | KotCzarny: C doesn't let you do that (except in this weird case), so when that's useful you pretty much just have to put the array inside a struct. struct values can be passed around. |
| 08:50.09 | KotCzarny | so it might even be slower because it has to copy the function argument? |
| 08:51.40 | Maxdamantus | KotCzarny: possibly. It depends how you're using it and what sort of optimisations the compiler is able to make. |
| 08:52.08 | Maxdamantus | KotCzarny: you should compare it to something like structs .. sometimes it's useful to pass a struct value, sometimes it's useful to pass a pointer to a struct object. |
| 08:53.02 | Maxdamantus | Logically, you should be given the same choice with arrays. It's probably just for historical reasons that you're not given that choice. |
| 08:54.03 | Maxdamantus | in other modern languages that provide a C-style distinction between pointers/references and non-pointer/reference product types, they offer that choice properly. |
| 08:54.10 | Maxdamantus | (particularly, Go and Rust) |
| 08:55.35 | Maxdamantus | in Go, an `int[3]` value itself is equivalent to three ints, instead of being a pointer to an object containing 3 ints. |
| 08:56.12 | Maxdamantus | So when you pass an `int[3]`, you're passing a copy of those three ints, just as when you pass an `int` or a `struct { a int }`, you're passing a copy of that int. |
| 08:57.25 | Maxdamantus | You can make a slice (basically a pointer) out of it using something like `a[:]`, which is pretty much what C does implicitly whenever you write an array expression (other than when it's the operand of &) |
| 08:58.27 | *** join/#maemo m4lvin (~m4lvin@w4eg.de) |
| 09:00.33 | bencoh | actually, passing objects (others than standard int/float and pointers) as arguments always sounded odd to me |
| 09:01.07 | Maxdamantus | objects are not things you pass, unless you mean reference/pointer. |
| 09:01.34 | Maxdamantus | in languages like Java, "object" and "reference" are often conflated. |
| 09:02.05 | bencoh | I mean passing a struct, for instance |
| 09:02.15 | Maxdamantus | Ah. |
| 09:02.16 | bencoh | it always looks wrong to me, although I know you can |
| 09:03.01 | KotCzarny | i always think of struct as an array with multiple types inside |
| 09:03.04 | Maxdamantus | Well, if you have something like a 2D vector, you'd normally want to pass a single value containing both components. |
| 09:03.26 | Maxdamantus | Passing a pointer in that case would be a bit like passing a pointer every time you wanted to pass a single number. |
| 09:03.26 | KotCzarny | but for a compiler it's just memory area |
| 09:04.37 | Maxdamantus | also, it's often a lot cleaner being able to return structs than having to take in a "return pointer". |
| 09:05.42 | Maxdamantus | `struct player player = new_player(4, 5);` rather than `struct player player; new_player(&player, 4, 5);` |
| 09:05.57 | Maxdamantus | imo the former is nicer .. some might disagree. |
| 09:09.04 | Maxdamantus | and obviously with the 2D vector example .. `point x = plus(dot_prod(a, b), dot_prod(c, d))` rather than `point x, ab, cd; dot_prod(&ab, &a, &b); dot_prod(&cd, &c, &d); plus(&x, &ab, &cd);` |
| 09:09.48 | KotCzarny | latter has a bonus of not needed for additional variable |
| 09:10.06 | KotCzarny | *no need |
| 09:10.11 | Maxdamantus | Indeed. |
| 09:10.27 | Maxdamantus | (former, rather) |
| 09:10.42 | KotCzarny | the one that takes &result as a func param |
| 09:11.14 | Maxdamantus | It's the other one that has fewer variables. |
| 09:11.28 | Maxdamantus | The latter has to declare variables to store the "results" of `dot_prod` |
| 09:11.35 | KotCzarny | i meant that compiler doesnt have to copy the result |
| 09:11.36 | Maxdamantus | (`ab`, `cd`) |
| 09:11.53 | KotCzarny | and just operate on result itself |
| 09:12.58 | Maxdamantus | If either is faster, I'd expect it to be the former. |
| 09:13.03 | KotCzarny | you can't overload operators in c, so it's not that useful there (but has its uses) |
| 09:13.17 | Maxdamantus | since it would probably end up just splitting the struct values across different registers. |
| 09:13.41 | Maxdamantus | so `dot_prod(a, b)` would essentially be compiled down to `dot_prod(a.x, a.y, b.x, b.y)` |
| 09:13.43 | *** join/#maemo Kabouik_ (~kabouik@158.38.1.70) |
| 09:13.47 | KotCzarny | aren't you passing pointer? |
| 09:14.01 | KotCzarny | well, mem address to a struct |
| 09:14.05 | Maxdamantus | No. `point` is meant to be a plain struct in both cases. |
| 09:14.22 | Maxdamantus | typedef struct { double x, y; } point; |
| 09:14.52 | KotCzarny | tbh i dont know if you use only one field of the struct in function to cause compiler to unpack it wholly |
| 09:15.31 | KotCzarny | i would assume it just acts as if that was a pointer |
| 09:16.01 | Maxdamantus | There shouldn't really be anything to "unpack". |
| 09:16.24 | Maxdamantus | aside from potential padding, wrapping things inside a struct in C should normally be a zero-cost abstraction. |
| 09:16.44 | Maxdamantus | `struct { int a; }` should be passed around pretty much the same way that an `int` is passed around. |
| 09:16.51 | Maxdamantus | in memory, they should look the same. |
| 09:17.43 | Maxdamantus | That's contrary to an object in Java .. if you write `class Wrapped { int a; }`, that's not a zero-cost abstraction. |
| 09:17.52 | Maxdamantus | since any `Wrapped` value is a pointer. |
| 09:18.12 | Maxdamantus | They're specifically working on fixing that issue by creating a new concept called "value classes" |
| 09:18.39 | Maxdamantus | http://openjdk.java.net/jeps/169 |
| 09:19.08 | bencoh | "working" on that kind of stuff, in 2018, sounds kinda funny, for a 20yo language :) |
| 09:19.48 | Maxdamantus | Well, most languages in the last 20 years haven't provided such a thing. |
| 09:19.55 | Maxdamantus | in most languages all you've had is objects. |
| 09:20.11 | Maxdamantus | and maybe a finite number of non-reference primitive types. |
| 09:20.26 | Maxdamantus | (because of that, "primitive" is often taken to mean "non-reference" nowadays) |
| 09:21.27 | Maxdamantus | I suspect Go and Rust are pretty much the only relatively known-about languages that allow you to specify your own non-reference types. |
| 09:21.44 | Maxdamantus | (made in the last 20 or 30 years) |
| 09:23.57 | bencoh | C structs can be non-reference |
| 09:24.23 | Maxdamantus | Yes, and C was made almost 50 years ago |
| 09:24.50 | Maxdamantus | I'm saying that practically every well-known language made in the last 20 or 30 years has been unlike C in this regard. |
| 09:24.50 | bencoh | ah, I see your point :) |
| 09:25.13 | Maxdamantus | but they're now trying to fix it, since the concept already exists in Go and Rust, and they're trying to introduce it finally to Java. |
| 09:29.56 | KotCzarny | since i'm fixing up sysarm product i would prefer to wait until one is available (if you can arrange similar value, ie. ~55months of 4TB in /ca) |
| 09:30.01 | KotCzarny | whoops |
| 09:30.02 | KotCzarny | wrong chan |
| 09:32.29 | *** join/#maemo m4lvin (~m4lvin@w4eg.de) |
| 10:25.15 | *** join/#maemo eMHa_ (~mh@81.26.162.98) |
| 10:46.19 | *** join/#maemo FireFly8 (~FireFly@ai126167028176.37.access-internet.ne.jp) |
| 11:15.12 | *** join/#maemo Kabouik_ (~kabouik@158.38.1.70) |
| 11:50.42 | *** join/#maemo spiiroin (~spiiroin@82-203-144-8.bb.dnainternet.fi) |
| 12:21.02 | *** join/#maemo jurop (~Jurop@91.252.47.56) |
| 13:36.14 | *** join/#maemo jskarvad_ (jskarvad@redhat/jskarvad) |
| 13:43.05 | *** join/#maemo florian_kc (~florian_k@Maemo/community/contributor/florian) |
| 13:46.07 | *** join/#maemo trx (~ns-team@cable-188-2-25-100.dynamic.sbb.rs) |
| 13:46.07 | *** join/#maemo trx (~ns-team@devbin/founder/trx) |
| 14:17.15 | *** join/#maemo drrty (~drrty@71-221-6-221.klln.qwest.net) |
| 14:17.38 | *** join/#maemo CompanionCube16 (~Companion@220.78.235.254) |
| 14:19.23 | *** join/#maemo guerby (~guerby@april/board/guerby) |
| 14:22.43 | *** join/#maemo guerby (~guerby@april/board/guerby) |
| 14:28.49 | *** join/#maemo segnior (segnior@gateway/shell/xshellz/x-ixemrcuihnjcvpmm) |
| 14:44.22 | *** join/#maemo jhutchins5 (~jhutchins@188.214.190.70) |
| 14:47.59 | *** join/#maemo segnior (segnior@gateway/shell/xshellz/x-yofstipufdfcbxko) |
| 15:04.28 | *** join/#maemo fuz_ (~eric@ks.cpbm.eu) |
| 15:13.23 | *** join/#maemo Pali (~pali@Maemo/community/contributor/Pali) |
| 15:46.49 | *** join/#maemo pathfinder (~pathfinde@122.254.150.116) |
| 16:17.20 | *** join/#maemo Kabouik_ (~kabouik@158.38.1.70) |
| 16:46.30 | *** join/#maemo ZLSA2 (~ZLSA@14.51.87.182) |
| 16:50.01 | *** join/#maemo sunshavi (~user@181.65.22.21) |
| 16:52.42 | *** join/#maemo svalx (~Thunderbi@212.119.216.50) |
| 17:42.41 | *** join/#maemo Wizzup (~Wizzup@82.161.36.93) |
| 18:37.40 | *** join/#maemo florian_kc (~florian_k@Maemo/community/contributor/florian) |
| 18:39.32 | *** join/#maemo eMHa_ (~mh@p5089DF5B.dip0.t-ipconnect.de) |
| 18:58.53 | *** join/#maemo Trashlord9 (~Trashlord@240.red-88-12-240.dynamicip.rima-tde.net) |
| 19:00.10 | *** join/#maemo sunshavi (~user@181.65.22.21) |
| 19:07.37 | *** join/#maemo florian_kc (~florian_k@Maemo/community/contributor/florian) |
| 19:35.14 | *** join/#maemo sunshavi (~user@181.65.22.21) |
| 20:52.24 | *** join/#maemo Vlad24 (~Vlad@86.121.225.12) |
| 20:53.49 | *** join/#maemo trumee (~trumee@c-98-194-48-184.hsd1.tx.comcast.net) |
| 20:57.07 | *** join/#maemo trumee_ (~trumee@c-98-194-48-184.hsd1.tx.comcast.net) |
| 21:06.35 | *** join/#maemo olspookishmagus1 (~olspookis@190-38-77-17.dyn.dsl.cantv.net) |
| 21:42.26 | *** join/#maemo Kilroo (~Kilroo@071-071-098-125.res.spectrum.com) |
| 22:02.35 | *** join/#maemo Kabouik (~kabouik@236.34.200.37.customer.cdi.no) |
| 22:03.18 | *** join/#maemo trumee (~trumee@c-98-194-48-184.hsd1.tx.comcast.net) |
| 22:36.06 | *** join/#maemo lukedashjr (~luke-jr@unaffiliated/luke-jr) |
| 23:16.41 | *** join/#maemo l_bratch (~l_bratch@2001:4db0:100:12:3f74:c6dc:da08:9b00) |
| 23:57.44 | *** join/#maemo Vajb (~Vajb@85-76-44-134-nat.elisa-mobile.fi) |