| *** svalx has joined #maemo | 00:08 | |
| *** sunshavi has joined #maemo | 00:18 | |
| *** dafox has quit IRC | 00:25 | |
| *** trumee_ has joined #maemo | 00:32 | |
| *** trumee has quit IRC | 00:34 | |
| *** Kilroo has joined #maemo | 00:54 | |
| *** Pali has quit IRC | 00:56 | |
| *** Oksana has quit IRC | 00:59 | |
| *** Oksana has joined #maemo | 01:01 | |
| *** r00t^home has quit IRC | 01:14 | |
| *** esaym153 has quit IRC | 01:25 | |
| *** esaym153 has joined #maemo | 01:26 | |
| *** ChanServ has quit IRC | 01:49 | |
| *** esaym153 has quit IRC | 01:56 | |
| *** esaym153 has joined #maemo | 01:57 | |
| *** ChanServ has joined #maemo | 02:03 | |
| *** sinisalo.freenode.net sets mode: +o ChanServ | 02:03 | |
| *** esaym153 has quit IRC | 02:10 | |
| *** esaym153 has joined #maemo | 02:11 | |
| *** esaym153 has quit IRC | 02:14 | |
| *** esaym153 has joined #maemo | 02:15 | |
| *** Kabouik- has quit IRC | 02:25 | |
| *** Kabouik- has joined #maemo | 02:25 | |
| *** Kabouik_ has joined #maemo | 02:27 | |
| *** Kabouik_ has quit IRC | 02:29 | |
| *** Kabouik has joined #maemo | 02:31 | |
| *** Kabouik- has quit IRC | 02:31 | |
| *** Kabouik has quit IRC | 02:36 | |
| *** Kabouik has joined #maemo | 02:36 | |
| *** sunshavi has quit IRC | 02:47 | |
| *** florian has quit IRC | 03:03 | |
| *** freemangordon has quit IRC | 03:08 | |
| *** tm has quit IRC | 03:21 | |
| *** infobot has quit IRC | 03:24 | |
| *** sparre has quit IRC | 03:24 | |
| *** sparre has joined #maemo | 03:24 | |
| *** tm_ has joined #maemo | 03:25 | |
| *** infobot has joined #maemo | 03:26 | |
| *** ChanServ sets mode: +v infobot | 03:26 | |
| *** sunshavi has joined #maemo | 04:38 | |
| *** Kabouik has quit IRC | 05:05 | |
| *** r00t^home has joined #maemo | 05:15 | |
| *** infobot has quit IRC | 05:19 | |
| *** infobot has joined #maemo | 05:20 | |
| *** ChanServ sets mode: +v infobot | 05:20 | |
| *** Kabouik has joined #maemo | 05:20 | |
| *** FalconSpy_ has joined #maemo | 05:21 | |
| *** guerby_ has joined #maemo | 05:22 | |
| *** geaaru has quit IRC | 05:29 | |
| *** guerby has quit IRC | 05:29 | |
| *** FalconSpy has quit IRC | 05:29 | |
| *** amospalla has quit IRC | 05:29 | |
| *** mickname has quit IRC | 05:29 | |
| *** useretail has quit IRC | 05:29 | |
| *** mickname has joined #maemo | 05:31 | |
| *** useretail has joined #maemo | 05:34 | |
| *** amospalla has joined #maemo | 05:36 | |
| *** geaaru has joined #maemo | 05:37 | |
| 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. | 05:54 |
|---|---|---|
| *** d10n25 has joined #maemo | 06:01 | |
| *** d10n25 has quit IRC | 06:05 | |
| *** DarthVader has joined #maemo | 06:11 | |
| *** DarthVad` has joined #maemo | 06:12 | |
| *** DarthVader has quit IRC | 06:16 | |
| *** FalconSpy_ has quit IRC | 06:21 | |
| *** FalconSpy has joined #maemo | 06:21 | |
| *** FalconSpy has joined #maemo | 06:21 | |
| *** FalconSpy has quit IRC | 06:50 | |
| *** pagurus` has joined #maemo | 06:59 | |
| *** pagurus has quit IRC | 07:01 | |
| *** FalconSpy has joined #maemo | 07:08 | |
| *** Ambroisie has joined #maemo | 07:20 | |
| *** Ambroisie has quit IRC | 07:24 | |
| *** spiiroin has quit IRC | 08:01 | |
| *** pathfinder has joined #maemo | 08:06 | |
| *** pathfinder has quit IRC | 08:09 | |
| *** Kilroo has quit IRC | 08:10 | |
| *** freemangordon has joined #maemo | 08:31 | |
| *** spiiroin has joined #maemo | 08:37 | |
| *** geaaru has quit IRC | 08:39 | |
| *** guerby_ has quit IRC | 08:58 | |
| *** guerby has joined #maemo | 08:59 | |
| *** dafox has joined #maemo | 09:24 | |
| *** ecloud_wfh is now known as ecloud | 09:48 | |
| *** geaaru has joined #maemo | 10:01 | |
| *** dafox has quit IRC | 10:05 | |
| *** mva_ is now known as mva | 10:06 | |
| *** Thanks has joined #maemo | 10:41 | |
| *** Thanks has quit IRC | 10:43 | |
| *** xorly has joined #maemo | 10:44 | |
| DocScrutinizer05 | hail strict typing | 10:59 |
| DocScrutinizer05 | this implicit typing is a mess | 10:59 |
| DocScrutinizer05 | there shouldn't even be a thing like "integer division", only cast while assigning results to variables | 11:01 |
| KotCzarny | say that to fpu less cpus | 11:02 |
| 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 | 11:03 |
| DocScrutinizer05 | int i = int( a / b ) | 11:04 |
| DocScrutinizer05 | int i = a / b BZZZZZZZ JACKASS! | 11:04 |
| bencoh | actually the current behavior is both sane and accurate | 11:05 |
| DocScrutinizer05 | it is, but not obvious | 11:05 |
| DocScrutinizer05 | as the description implies: it's implicit | 11:05 |
| bencoh | you just should not expect a float result when dividing integers | 11:05 |
| KotCzarny | that's a compiler's nuance, or language? | 11:06 |
| DocScrutinizer05 | you always should expect a float result when dividing | 11:06 |
| bencoh | it might be implicit, but nothing indicates it should not be the case | 11:06 |
| bencoh | absolutely not | 11:06 |
| KotCzarny | if language, it's ok, if compiler, it's black magic | 11:06 |
| KotCzarny | (for new users) | 11:06 |
| DocScrutinizer05 | it's langiage, for c | 11:06 |
| bencoh | KotCzarny: C standard | 11:06 |
| KotCzarny | then it's up to the user to learn properly | 11:07 |
| bencoh | most probably K&R or c89, at least | 11:07 |
| DocScrutinizer05 | it's prolly B already ;-D | 11:07 |
| bencoh | haha, could be | 11:07 |
| DocScrutinizer05 | aka: the most eloquent assembler ever made | 11:07 |
| Maxdamantus | Just to be clear: the issue is implicit conversion, not implicit typing. | 11:12 |
| bencoh | (or the lack thereof) | 11:13 |
| bencoh | (which is a good thing in my opinion) | 11:13 |
| Maxdamantus | The issue is its precense. | 11:13 |
| Maxdamantus | presence* | 11:13 |
| bencoh | ? | 11:13 |
| DocScrutinizer05 | of course it's a matter of personal preferences | 11:13 |
| DocScrutinizer05 | I lack half of the convo, sorry | 11:14 |
| Maxdamantus | imo 5/4 == 2 is acceptable, 5/4.0 == 2.5 should be a type error. | 11:14 |
| bencoh | Maxdamantus: ah | 11:14 |
| bencoh | (5/2.0 I guess) | 11:14 |
| Maxdamantus | er, yeah | 11:14 |
| KotCzarny | imo current behavior of c is ok | 11:15 |
| bencoh | KotCzarny: I think so as well, but ... :) | 11:15 |
| Maxdamantus | I would probably also lean on the side of having separate operators for floating and integral division. | 11:15 |
| DocScrutinizer05 | how do you add a ".0" to int i; ? | 11:15 |
| bencoh | DocScrutinizer05: you cannot; you have to cast it | 11:15 |
| KotCzarny | similarly to whole pointer thingy, tracking and remembering variable types and expected return types is up to the dev | 11:15 |
| DocScrutinizer05 | :-P | 11:15 |
| KotCzarny | in c++ otoh yeah, compiler should nag the poor user to death with warnings/errors | 11:16 |
| KotCzarny | bencoh, i think i+=.0 will work ;) | 11:16 |
| Maxdamantus | C has a bunch of other issues around implicit conversions, eg: int x = 4; unsigned y = -4; x < y; | 11:17 |
| KotCzarny | unless you want to change type | 11:17 |
| 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 | 11:17 |
| Maxdamantus | eh, should've been the other way round | 11:17 |
| KotCzarny | maxd: in that case you get a nice, juicy warning | 11:17 |
| Maxdamantus | int x = -4; unsigned y = 4; y < x; | 11:17 |
| *** florian has joined #maemo | 11:17 | |
| bencoh | KotCzarny: i+=0. won't change anything to i | 11:18 |
| bencoh | you cannot change the type of a variable | 11:18 |
| DocScrutinizer05 | ORLY? :-D | 11:18 |
| bencoh | DocScrutinizer05: I dunno why, but he seemed to imply that it would | 11:19 |
| DocScrutinizer05 | hehehehe | 11:19 |
| bencoh | (or was that sarcasm? :]) | 11:19 |
| KotCzarny | bencoh, question was not clear (i've went with how to add .0 in value to i ;) | 11:19 |
| bencoh | huhu | 11:19 |
| Maxdamantus | 20:17:33 < KotCzarny> maxd: in that case you get a nice, juicy warning | 11:20 |
| Maxdamantus | I don't seem to get any warning with `gcc -Wall -pedantic` | 11:20 |
| KotCzarny | hmm, let me check | 11:20 |
| Maxdamantus | That's using 4.9.3 though, a bit old. | 11:20 |
| Maxdamantus | Still no warning with 6.4.0 | 11:21 |
| bencoh | well, it's valid behavior, although I would expect a compiler warning as well | 11:21 |
| bencoh | they do warn about unused variables, so ... | 11:21 |
| bencoh | not warning about that is silly | 11:22 |
| KotCzarny | oh right. it's in -Wextra | 11:23 |
| KotCzarny | (in 4.9.2 at least) | 11:23 |
| Maxdamantus | Heh, don't think I've ever used -Wextra | 11:23 |
| KotCzarny | it's nice to catch some more obvious brainfarts ;) | 11:23 |
| Maxdamantus | more obvious, or less obvious? Presumably less. | 11:24 |
| Maxdamantus | Anyway, in a sensible language, that's just a type error. | 11:24 |
| KotCzarny | more as in numerical number of them | 11:24 |
| Maxdamantus | because you should have something like `(>) :: a -> a -> boolean`, where `a` is any given number type. | 11:25 |
| KotCzarny | c assumes dev knows what he/she is doing | 11:25 |
| Maxdamantus | So `(>) :: unsigned -> signed -> boolean` is not valid. | 11:25 |
| KotCzarny | and if you know that int x wont get into negatives or y more than half of the type, it will work | 11:26 |
| KotCzarny | many bugs prove it wrong though ;) | 11:26 |
| KotCzarny | but that's C, love it, learn it or go into some sandbox | 11:26 |
| KotCzarny | it's like trying to apply political correctness to the programming language | 11:27 |
| Maxdamantus | Those are exclusive, right? | 11:28 |
| bencoh | Maxdamantus: both learn and love C, you mean? | 11:28 |
| Maxdamantus | bencoh: yes. | 11:28 |
| bencoh | I somehow fell in love with it :) | 11:28 |
| Maxdamantus | I mostly just got amused by figuring out weird things based on reading the standards over and over again. | 11:29 |
| Maxdamantus | eg, like how you can pass arrays to functions in C90 but not C99. | 11:29 |
| Maxdamantus | but in either case, you can't do anything with those passed arrays. | 11:29 |
| bencoh | their are some standard oddities, yeah | 11:29 |
| bencoh | there* | 11:29 |
| Maxdamantus | though gnu89 lets you use the array in those cases where you can pass it (but that's non-standard) | 11:30 |
| KotCzarny | isnt string an array? | 11:30 |
| KotCzarny | ;) | 11:30 |
| Maxdamantus | Not exactly. | 11:31 |
| 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); } | 11:35 |
| 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. | 11:36 |
| Maxdamantus | and in gnu89, I think you can actually write `int a[10] = va_arg(ap, int [10]);` to get it again. | 11:38 |
| 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. | 11:41 |
| Maxdamantus | another variadic function* | 11:42 |
| bencoh | Maxdamantus: what do you mean by "array" in that case? | 11:45 |
| Maxdamantus | bencoh: in which case? | 11:45 |
| bencoh | is the whole array stored in the stack? | 11:45 |
| bencoh | c90 | 11:45 |
| Maxdamantus | bencoh: if you think about it as a stack and of all arguments being on the stack, yes. | 11:45 |
| bencoh | that sounds odd tbh, but ... :) | 11:46 |
| Maxdamantus | Usually you don't get to handle arrays as values. | 11:46 |
| bencoh | (I mean, such a definition sounds odd) | 11:46 |
| Maxdamantus | because array expressions end up just being pointers in all sensible contexts other than when they appear as the operand of &. | 11:47 |
| 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. | 11:47 |
| bencoh | yeah | 11:47 |
| bencoh | ah | 11:47 |
| bencoh | I see | 11:47 |
| 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. | 11:48 |
| Maxdamantus | (in C90, `foo().a[0]` is invalid when `foo().a` is an array) | 11:48 |
| bencoh | sounds like a standard "bug" :) | 11:48 |
| KotCzarny | is there any gain of passing it as array instead of just pointer? | 11:48 |
| bencoh | (bug-by-design I mean) | 11:48 |
| *** jskarvad has joined #maemo | 11:49 | |
| Maxdamantus | KotCzarny: it would be logically sensible to be able to pass array values around. | 11:49 |
| bencoh | KotCzarny: well, the pointer is eventually invalid, while copied data would remain valid | 11:49 |
| 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. | 11:49 |
| KotCzarny | so it might even be slower because it has to copy the function argument? | 11:50 |
| Maxdamantus | KotCzarny: possibly. It depends how you're using it and what sort of optimisations the compiler is able to make. | 11:51 |
| 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. | 11:52 |
| 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. | 11:53 |
| 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. | 11:54 |
| Maxdamantus | (particularly, Go and Rust) | 11:54 |
| Maxdamantus | in Go, an `int[3]` value itself is equivalent to three ints, instead of being a pointer to an object containing 3 ints. | 11:55 |
| 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. | 11:56 |
| *** m4lvin has quit IRC | 11:56 | |
| 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 &) | 11:57 |
| *** m4lvin has joined #maemo | 11:58 | |
| bencoh | actually, passing objects (others than standard int/float and pointers) as arguments always sounded odd to me | 12:00 |
| Maxdamantus | objects are not things you pass, unless you mean reference/pointer. | 12:01 |
| Maxdamantus | in languages like Java, "object" and "reference" are often conflated. | 12:01 |
| bencoh | I mean passing a struct, for instance | 12:02 |
| Maxdamantus | Ah. | 12:02 |
| bencoh | it always looks wrong to me, although I know you can | 12:02 |
| KotCzarny | i always think of struct as an array with multiple types inside | 12:03 |
| Maxdamantus | Well, if you have something like a 2D vector, you'd normally want to pass a single value containing both components. | 12:03 |
| Maxdamantus | Passing a pointer in that case would be a bit like passing a pointer every time you wanted to pass a single number. | 12:03 |
| KotCzarny | but for a compiler it's just memory area | 12:03 |
| Maxdamantus | also, it's often a lot cleaner being able to return structs than having to take in a "return pointer". | 12:04 |
| Maxdamantus | `struct player player = new_player(4, 5);` rather than `struct player player; new_player(&player, 4, 5);` | 12:05 |
| Maxdamantus | imo the former is nicer .. some might disagree. | 12:05 |
| 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);` | 12:09 |
| KotCzarny | latter has a bonus of not needed for additional variable | 12:09 |
| KotCzarny | *no need | 12:10 |
| Maxdamantus | Indeed. | 12:10 |
| Maxdamantus | (former, rather) | 12:10 |
| KotCzarny | the one that takes &result as a func param | 12:10 |
| Maxdamantus | It's the other one that has fewer variables. | 12:11 |
| Maxdamantus | The latter has to declare variables to store the "results" of `dot_prod` | 12:11 |
| KotCzarny | i meant that compiler doesnt have to copy the result | 12:11 |
| Maxdamantus | (`ab`, `cd`) | 12:11 |
| KotCzarny | and just operate on result itself | 12:11 |
| Maxdamantus | If either is faster, I'd expect it to be the former. | 12:12 |
| KotCzarny | you can't overload operators in c, so it's not that useful there (but has its uses) | 12:13 |
| Maxdamantus | since it would probably end up just splitting the struct values across different registers. | 12:13 |
| Maxdamantus | so `dot_prod(a, b)` would essentially be compiled down to `dot_prod(a.x, a.y, b.x, b.y)` | 12:13 |
| *** Kabouik_ has joined #maemo | 12:13 | |
| KotCzarny | aren't you passing pointer? | 12:13 |
| KotCzarny | well, mem address to a struct | 12:14 |
| Maxdamantus | No. `point` is meant to be a plain struct in both cases. | 12:14 |
| Maxdamantus | typedef struct { double x, y; } point; | 12:14 |
| KotCzarny | tbh i dont know if you use only one field of the struct in function to cause compiler to unpack it wholly | 12:14 |
| KotCzarny | i would assume it just acts as if that was a pointer | 12:15 |
| Maxdamantus | There shouldn't really be anything to "unpack". | 12:16 |
| Maxdamantus | aside from potential padding, wrapping things inside a struct in C should normally be a zero-cost abstraction. | 12:16 |
| Maxdamantus | `struct { int a; }` should be passed around pretty much the same way that an `int` is passed around. | 12:16 |
| Maxdamantus | in memory, they should look the same. | 12:16 |
| Maxdamantus | That's contrary to an object in Java .. if you write `class Wrapped { int a; }`, that's not a zero-cost abstraction. | 12:17 |
| Maxdamantus | since any `Wrapped` value is a pointer. | 12:17 |
| Maxdamantus | They're specifically working on fixing that issue by creating a new concept called "value classes" | 12:18 |
| Maxdamantus | http://openjdk.java.net/jeps/169 | 12:18 |
| bencoh | "working" on that kind of stuff, in 2018, sounds kinda funny, for a 20yo language :) | 12:19 |
| Maxdamantus | Well, most languages in the last 20 years haven't provided such a thing. | 12:19 |
| Maxdamantus | in most languages all you've had is objects. | 12:19 |
| Maxdamantus | and maybe a finite number of non-reference primitive types. | 12:20 |
| Maxdamantus | (because of that, "primitive" is often taken to mean "non-reference" nowadays) | 12:20 |
| 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. | 12:21 |
| Maxdamantus | (made in the last 20 or 30 years) | 12:21 |
| bencoh | C structs can be non-reference | 12:23 |
| Maxdamantus | Yes, and C was made almost 50 years ago | 12:24 |
| 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. | 12:24 |
| bencoh | ah, I see your point :) | 12:24 |
| 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. | 12:25 |
| 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) | 12:29 |
| KotCzarny | whoops | 12:30 |
| KotCzarny | wrong chan | 12:30 |
| *** m4lvin has quit IRC | 12:32 | |
| *** m4lvin has joined #maemo | 12:32 | |
| *** eMHa_ has quit IRC | 12:45 | |
| *** eMHa_ has joined #maemo | 13:25 | |
| *** FireFly8 has joined #maemo | 13:46 | |
| *** FireFly8 has quit IRC | 13:51 | |
| *** spiiroin has quit IRC | 14:13 | |
| *** Kabouik_ has quit IRC | 14:14 | |
| *** Kabouik_ has joined #maemo | 14:15 | |
| *** l_bratch has quit IRC | 14:31 | |
| *** spiiroin has joined #maemo | 14:50 | |
| *** jurop has joined #maemo | 15:21 | |
| *** guerby has quit IRC | 16:31 | |
| *** jskarvad_ has joined #maemo | 16:36 | |
| *** jskarvad has quit IRC | 16:37 | |
| *** trx has quit IRC | 16:40 | |
| *** florian_kc has joined #maemo | 16:43 | |
| *** florian has quit IRC | 16:44 | |
| *** trx has joined #maemo | 16:46 | |
| *** trx has quit IRC | 16:46 | |
| *** trx has joined #maemo | 16:46 | |
| *** florian_kc is now known as florian | 16:52 | |
| *** drrty has quit IRC | 17:14 | |
| *** drrty has joined #maemo | 17:17 | |
| *** CompanionCube16 has joined #maemo | 17:17 | |
| *** CompanionCube16 has quit IRC | 17:18 | |
| *** guerby has joined #maemo | 17:19 | |
| *** guerby has quit IRC | 17:20 | |
| *** guerby has joined #maemo | 17:22 | |
| *** fuz_ has quit IRC | 17:27 | |
| *** segnior has quit IRC | 17:27 | |
| *** segnior has joined #maemo | 17:28 | |
| *** segnior has quit IRC | 17:41 | |
| *** jhutchins5 has joined #maemo | 17:44 | |
| *** jhutchins5 has quit IRC | 17:46 | |
| *** segnior has joined #maemo | 17:47 | |
| *** fuz_ has joined #maemo | 18:04 | |
| *** Pali has joined #maemo | 18:13 | |
| *** pathfinder has joined #maemo | 18:46 | |
| *** pathfinder has quit IRC | 18:49 | |
| *** DarthVad` has quit IRC | 19:10 | |
| *** Kabouik_ has quit IRC | 19:16 | |
| *** Kabouik_ has joined #maemo | 19:17 | |
| *** jskarvad_ has quit IRC | 19:38 | |
| *** ZLSA2 has joined #maemo | 19:46 | |
| *** sunshavi has quit IRC | 19:49 | |
| *** sunshavi has joined #maemo | 19:50 | |
| *** ZLSA2 has quit IRC | 19:51 | |
| *** svalx has quit IRC | 19:52 | |
| *** svalx has joined #maemo | 19:52 | |
| *** sunshavi has quit IRC | 19:56 | |
| *** Wizzup has quit IRC | 20:35 | |
| *** Wizzup has joined #maemo | 20:42 | |
| *** geaaru has quit IRC | 21:05 | |
| *** eMHa_ has quit IRC | 21:12 | |
| *** florian_kc has joined #maemo | 21:37 | |
| *** eMHa_ has joined #maemo | 21:39 | |
| *** Trashlord9 has joined #maemo | 21:58 | |
| *** sunshavi has joined #maemo | 22:00 | |
| *** Trashlord9 has quit IRC | 22:00 | |
| *** florian has quit IRC | 22:07 | |
| *** florian_kc is now known as florian | 22:07 | |
| *** florian_kc has joined #maemo | 22:07 | |
| *** Kabouik_ has quit IRC | 22:31 | |
| *** sunshavi has quit IRC | 22:32 | |
| *** sunshavi has joined #maemo | 22:35 | |
| *** sunshavi has quit IRC | 22:58 | |
| *** Vlad24 has joined #maemo | 23:52 | |
| *** trumee has joined #maemo | 23:53 | |
| *** trumee_ has quit IRC | 23:55 | |
| *** Vlad24 has quit IRC | 23:55 | |
| *** trumee_ has joined #maemo | 23:57 | |
| *** trumee has quit IRC | 23:58 | |
Generated by irclog2html.py 2.15.1 by Marius Gedminas - find it at mg.pov.lt!