IRC log of #maemo for Thursday, 2018-08-23

*** svalx has joined #maemo00:08
*** sunshavi has joined #maemo00:18
*** dafox has quit IRC00:25
*** trumee_ has joined #maemo00:32
*** trumee has quit IRC00:34
*** Kilroo has joined #maemo00:54
*** Pali has quit IRC00:56
*** Oksana has quit IRC00:59
*** Oksana has joined #maemo01:01
*** r00t^home has quit IRC01:14
*** esaym153 has quit IRC01:25
*** esaym153 has joined #maemo01:26
*** ChanServ has quit IRC01:49
*** esaym153 has quit IRC01:56
*** esaym153 has joined #maemo01:57
*** ChanServ has joined #maemo02:03
*** sets mode: +o ChanServ02:03
*** esaym153 has quit IRC02:10
*** esaym153 has joined #maemo02:11
*** esaym153 has quit IRC02:14
*** esaym153 has joined #maemo02:15
*** Kabouik- has quit IRC02:25
*** Kabouik- has joined #maemo02:25
*** Kabouik_ has joined #maemo02:27
*** Kabouik_ has quit IRC02:29
*** Kabouik has joined #maemo02:31
*** Kabouik- has quit IRC02:31
*** Kabouik has quit IRC02:36
*** Kabouik has joined #maemo02:36
*** sunshavi has quit IRC02:47
*** florian has quit IRC03:03
*** freemangordon has quit IRC03:08
*** tm has quit IRC03:21
*** infobot has quit IRC03:24
*** sparre has quit IRC03:24
*** sparre has joined #maemo03:24
*** tm_ has joined #maemo03:25
*** infobot has joined #maemo03:26
*** ChanServ sets mode: +v infobot03:26
*** sunshavi has joined #maemo04:38
*** Kabouik has quit IRC05:05
*** r00t^home has joined #maemo05:15
*** infobot has quit IRC05:19
*** infobot has joined #maemo05:20
*** ChanServ sets mode: +v infobot05:20
*** Kabouik has joined #maemo05:20
*** FalconSpy_ has joined #maemo05:21
*** guerby_ has joined #maemo05:22
*** geaaru has quit IRC05:29
*** guerby has quit IRC05:29
*** FalconSpy has quit IRC05:29
*** amospalla has quit IRC05:29
*** mickname has quit IRC05:29
*** useretail has quit IRC05:29
*** mickname has joined #maemo05:31
*** useretail has joined #maemo05:34
*** amospalla has joined #maemo05:36
*** geaaru has joined #maemo05:37
brolin_empeyKotCzarny: 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 #maemo06:01
*** d10n25 has quit IRC06:05
*** DarthVader has joined #maemo06:11
*** DarthVad` has joined #maemo06:12
*** DarthVader has quit IRC06:16
*** FalconSpy_ has quit IRC06:21
*** FalconSpy has joined #maemo06:21
*** FalconSpy has joined #maemo06:21
*** FalconSpy has quit IRC06:50
*** pagurus` has joined #maemo06:59
*** pagurus has quit IRC07:01
*** FalconSpy has joined #maemo07:08
*** Ambroisie has joined #maemo07:20
*** Ambroisie has quit IRC07:24
*** spiiroin has quit IRC08:01
*** pathfinder has joined #maemo08:06
*** pathfinder has quit IRC08:09
*** Kilroo has quit IRC08:10
*** freemangordon has joined #maemo08:31
*** spiiroin has joined #maemo08:37
*** geaaru has quit IRC08:39
*** guerby_ has quit IRC08:58
*** guerby has joined #maemo08:59
*** dafox has joined #maemo09:24
*** ecloud_wfh is now known as ecloud09:48
*** geaaru has joined #maemo10:01
*** dafox has quit IRC10:05
*** mva_ is now known as mva10:06
*** Thanks has joined #maemo10:41
*** Thanks has quit IRC10:43
*** xorly has joined #maemo10:44
DocScrutinizer05hail strict typing10:59
DocScrutinizer05this implicit typing is a mess10:59
DocScrutinizer05there shouldn't even be a thing like "integer division", only cast while assigning results to variables11:01
KotCzarnysay that to fpu less cpus11:02
DocScrutinizer05and 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 variable11:03
DocScrutinizer05int i = int( a / b )11:04
DocScrutinizer05int i = a / b   BZZZZZZZ JACKASS!11:04
bencohactually the current behavior is both sane and accurate11:05
DocScrutinizer05it is, but not obvious11:05
DocScrutinizer05as the description implies: it's implicit11:05
bencohyou just should not expect a float result when dividing integers11:05
KotCzarnythat's a compiler's nuance, or language?11:06
DocScrutinizer05you always should expect a float result when dividing11:06
bencohit might be implicit, but nothing indicates it should not be the case11:06
bencohabsolutely not11:06
KotCzarnyif language, it's ok, if compiler, it's black magic11:06
KotCzarny(for new users)11:06
DocScrutinizer05it's langiage, for c11:06
bencohKotCzarny: C standard11:06
KotCzarnythen it's up to the user to learn properly11:07
bencohmost probably K&R or c89, at least11:07
DocScrutinizer05it's prolly B already ;-D11:07
bencohhaha, could be11:07
DocScrutinizer05aka: the most eloquent assembler ever made11:07
MaxdamantusJust 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
MaxdamantusThe issue is its precense.11:13
DocScrutinizer05of course it's a matter of personal preferences11:13
DocScrutinizer05I lack half of the convo, sorry11:14
Maxdamantusimo 5/4 == 2 is acceptable, 5/4.0 == 2.5 should be a type error.11:14
bencohMaxdamantus: ah11:14
bencoh(5/2.0 I guess)11:14
Maxdamantuser, yeah11:14
KotCzarnyimo current behavior of c is ok11:15
bencohKotCzarny: I think so as well, but ... :)11:15
MaxdamantusI would probably also lean on the side of having separate operators for floating and integral division.11:15
DocScrutinizer05how do you add a ".0" to int i; ?11:15
bencohDocScrutinizer05: you cannot; you have to cast it11:15
KotCzarnysimilarly to whole pointer thingy, tracking and remembering variable types and expected return types is up to the dev11:15
KotCzarnyin c++ otoh yeah, compiler should nag the poor user to death with warnings/errors11:16
KotCzarnybencoh, i think i+=.0 will work ;)11:16
MaxdamantusC has a bunch of other issues around implicit conversions, eg: int x = 4; unsigned y = -4; x < y;11:17
KotCzarnyunless you want to change type11:17
DocScrutinizer05in 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 that11:17
Maxdamantuseh, should've been the other way round11:17
KotCzarnymaxd: in that case you get a nice, juicy warning11:17
Maxdamantusint x = -4; unsigned y = 4; y < x;11:17
*** florian has joined #maemo11:17
bencohKotCzarny: i+=0. won't change anything to i11:18
bencohyou cannot change the type of a variable11:18
DocScrutinizer05ORLY? :-D11:18
bencohDocScrutinizer05: I dunno why, but he seemed to imply that it would11:19
bencoh(or was that sarcasm? :])11:19
KotCzarnybencoh, question was not clear (i've went with how to add .0 in value to i ;)11:19
Maxdamantus20:17:33 < KotCzarny> maxd: in that case you get a nice, juicy warning11:20
MaxdamantusI don't seem to get any warning with `gcc -Wall -pedantic`11:20
KotCzarnyhmm, let me check11:20
MaxdamantusThat's using 4.9.3 though, a bit old.11:20
MaxdamantusStill no warning with 6.4.011:21
bencohwell, it's valid behavior, although I would expect a compiler warning as well11:21
bencohthey do warn about unused variables, so ...11:21
bencohnot warning about that is silly11:22
KotCzarnyoh right. it's in -Wextra11:23
KotCzarny(in 4.9.2 at least)11:23
MaxdamantusHeh, don't think I've ever used -Wextra11:23
KotCzarnyit's nice to catch some more obvious brainfarts ;)11:23
Maxdamantusmore obvious, or less obvious? Presumably less.11:24
MaxdamantusAnyway, in a sensible language, that's just a type error.11:24
KotCzarnymore as in numerical number of them11:24
Maxdamantusbecause you should have something like `(>) :: a -> a -> boolean`, where `a` is any given number type.11:25
KotCzarnyc assumes dev knows what he/she is doing11:25
MaxdamantusSo `(>) :: unsigned -> signed -> boolean` is not valid.11:25
KotCzarnyand if you know that int x wont get into negatives or y more than half of the type, it will work11:26
KotCzarnymany bugs prove it wrong though ;)11:26
KotCzarnybut that's C, love it, learn it or go into some sandbox11:26
KotCzarnyit's like trying to apply political correctness to the programming language11:27
MaxdamantusThose are exclusive, right?11:28
bencohMaxdamantus: both learn and love C, you mean?11:28
Maxdamantusbencoh: yes.11:28
bencohI somehow fell in love with it :)11:28
MaxdamantusI mostly just got amused by figuring out weird things based on reading the standards over and over again.11:29
Maxdamantuseg, like how you can pass arrays to functions in C90 but not C99.11:29
Maxdamantusbut in either case, you can't do anything with those passed arrays.11:29
bencohtheir are some standard oddities, yeah11:29
Maxdamantusthough gnu89 lets you use the array in those cases where you can pass it (but that's non-standard)11:30
KotCzarnyisnt string an array?11:30
MaxdamantusNot exactly.11:31
Maxdamantusin 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
MaxdamantusIn 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
Maxdamantusand in gnu89, I think you can actually write `int a[10] = va_arg(ap, int [10]);` to get it again.11:38
Maxdamantusin 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
Maxdamantusanother variadic function*11:42
bencohMaxdamantus: what do you mean by "array" in that case?11:45
Maxdamantusbencoh: in which case?11:45
bencohis the whole array stored in the stack?11:45
Maxdamantusbencoh: if you think about it as a stack and of all arguments being on the stack, yes.11:45
bencohthat sounds odd tbh, but ... :)11:46
MaxdamantusUsually you don't get to handle arrays as values.11:46
bencoh(I mean, such a definition sounds odd)11:46
Maxdamantusbecause array expressions end up just being pointers in all sensible contexts other than when they appear as the operand of &.11:47
Maxdamantusbut `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
bencohI see11:47
MaxdamantusC99 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
bencohsounds like a standard "bug" :)11:48
KotCzarnyis 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 #maemo11:49
MaxdamantusKotCzarny: it would be logically sensible to be able to pass array values around.11:49
bencohKotCzarny: well, the pointer is eventually invalid, while copied data would remain valid11:49
MaxdamantusKotCzarny: 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
KotCzarnyso it might even be slower because it has to copy the function argument?11:50
MaxdamantusKotCzarny: possibly. It depends how you're using it and what sort of optimisations the compiler is able to make.11:51
MaxdamantusKotCzarny: 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
MaxdamantusLogically, 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
Maxdamantusin 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
Maxdamantusin Go, an `int[3]` value itself is equivalent to three ints, instead of being a pointer to an object containing 3 ints.11:55
MaxdamantusSo 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 IRC11:56
MaxdamantusYou 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 #maemo11:58
bencohactually, passing objects (others than standard int/float and pointers) as arguments always sounded odd to me12:00
Maxdamantusobjects are not things you pass, unless you mean reference/pointer.12:01
Maxdamantusin languages like Java, "object" and "reference" are often conflated.12:01
bencohI mean passing a struct, for instance12:02
bencohit always looks wrong to me, although I know you can12:02
KotCzarnyi always think of struct as an array with multiple types inside12:03
MaxdamantusWell, if you have something like a 2D vector, you'd normally want to pass a single value containing both components.12:03
MaxdamantusPassing a pointer in that case would be a bit like passing a pointer every time you wanted to pass a single number.12:03
KotCzarnybut for a compiler it's just memory area12:03
Maxdamantusalso, 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
Maxdamantusimo the former is nicer .. some might disagree.12:05
Maxdamantusand 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
KotCzarnylatter has a bonus of not needed for additional variable12:09
KotCzarny*no need12:10
Maxdamantus(former, rather)12:10
KotCzarnythe one that takes &result as a func param12:10
MaxdamantusIt's the other one that has fewer variables.12:11
MaxdamantusThe latter has to declare variables to store the "results" of `dot_prod`12:11
KotCzarnyi meant that compiler doesnt have to copy the result12:11
Maxdamantus(`ab`, `cd`)12:11
KotCzarnyand just operate on result itself12:11
MaxdamantusIf either is faster, I'd expect it to be the former.12:12
KotCzarnyyou can't overload operators in c, so it's not that useful there (but has its uses)12:13
Maxdamantussince it would probably end up just splitting the struct values across different registers.12:13
Maxdamantusso `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 #maemo12:13
KotCzarnyaren't you passing pointer?12:13
KotCzarnywell, mem address to a struct12:14
MaxdamantusNo. `point` is meant to be a plain struct in both cases.12:14
Maxdamantustypedef struct { double x, y; } point;12:14
KotCzarnytbh i dont know if you use only one field of the struct in function to cause compiler to unpack it wholly12:14
KotCzarnyi would assume it just acts as if that was a pointer12:15
MaxdamantusThere shouldn't really be anything to "unpack".12:16
Maxdamantusaside 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
Maxdamantusin memory, they should look the same.12:16
MaxdamantusThat's contrary to an object in Java .. if you write `class Wrapped { int a; }`, that's not a zero-cost abstraction.12:17
Maxdamantussince any `Wrapped` value is a pointer.12:17
MaxdamantusThey're specifically working on fixing that issue by creating a new concept called "value classes"12:18
bencoh"working" on that kind of stuff, in 2018, sounds kinda funny, for a 20yo language :)12:19
MaxdamantusWell, most languages in the last 20 years haven't provided such a thing.12:19
Maxdamantusin most languages all you've had is objects.12:19
Maxdamantusand 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
MaxdamantusI 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
bencohC structs can be non-reference12:23
MaxdamantusYes, and C was made almost 50 years ago12:24
MaxdamantusI'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
bencohah, I see your point :)12:24
Maxdamantusbut 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
KotCzarnysince 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
KotCzarnywrong chan12:30
*** m4lvin has quit IRC12:32
*** m4lvin has joined #maemo12:32
*** eMHa_ has quit IRC12:45
*** eMHa_ has joined #maemo13:25
*** FireFly8 has joined #maemo13:46
*** FireFly8 has quit IRC13:51
*** spiiroin has quit IRC14:13
*** Kabouik_ has quit IRC14:14
*** Kabouik_ has joined #maemo14:15
*** l_bratch has quit IRC14:31
*** spiiroin has joined #maemo14:50
*** jurop has joined #maemo15:21
*** guerby has quit IRC16:31
*** jskarvad_ has joined #maemo16:36
*** jskarvad has quit IRC16:37
*** trx has quit IRC16:40
*** florian_kc has joined #maemo16:43
*** florian has quit IRC16:44
*** trx has joined #maemo16:46
*** trx has quit IRC16:46
*** trx has joined #maemo16:46
*** florian_kc is now known as florian16:52
*** drrty has quit IRC17:14
*** drrty has joined #maemo17:17
*** CompanionCube16 has joined #maemo17:17
*** CompanionCube16 has quit IRC17:18
*** guerby has joined #maemo17:19
*** guerby has quit IRC17:20
*** guerby has joined #maemo17:22
*** fuz_ has quit IRC17:27
*** segnior has quit IRC17:27
*** segnior has joined #maemo17:28
*** segnior has quit IRC17:41
*** jhutchins5 has joined #maemo17:44
*** jhutchins5 has quit IRC17:46
*** segnior has joined #maemo17:47
*** fuz_ has joined #maemo18:04
*** Pali has joined #maemo18:13
*** pathfinder has joined #maemo18:46
*** pathfinder has quit IRC18:49
*** DarthVad` has quit IRC19:10
*** Kabouik_ has quit IRC19:16
*** Kabouik_ has joined #maemo19:17
*** jskarvad_ has quit IRC19:38
*** ZLSA2 has joined #maemo19:46
*** sunshavi has quit IRC19:49
*** sunshavi has joined #maemo19:50
*** ZLSA2 has quit IRC19:51
*** svalx has quit IRC19:52
*** svalx has joined #maemo19:52
*** sunshavi has quit IRC19:56
*** Wizzup has quit IRC20:35
*** Wizzup has joined #maemo20:42
*** geaaru has quit IRC21:05
*** eMHa_ has quit IRC21:12
*** florian_kc has joined #maemo21:37
*** eMHa_ has joined #maemo21:39
*** Trashlord9 has joined #maemo21:58
*** sunshavi has joined #maemo22:00
*** Trashlord9 has quit IRC22:00
*** florian has quit IRC22:07
*** florian_kc is now known as florian22:07
*** florian_kc has joined #maemo22:07
*** Kabouik_ has quit IRC22:31
*** sunshavi has quit IRC22:32
*** sunshavi has joined #maemo22:35
*** sunshavi has quit IRC22:58
*** Vlad24 has joined #maemo23:52
*** trumee has joined #maemo23:53
*** trumee_ has quit IRC23:55
*** Vlad24 has quit IRC23:55
*** trumee_ has joined #maemo23:57
*** trumee has quit IRC23:58

Generated by 2.15.1 by Marius Gedminas - find it at!