| 00:17:11 | * | gf3 joined #nimrod |
| 00:17:39 | * | gf3 left #nimrod (#nimrod) |
| 02:46:31 | * | JStoker quit (Excess Flood) |
| 02:58:14 | * | JStoker joined #nimrod |
| 07:06:21 | * | fowl quit (*.net *.split) |
| 07:13:23 | * | zahary joined #nimrod |
| 07:20:29 | * | fowl joined #nimrod |
| 07:20:29 | * | fowl quit (Changing host) |
| 07:20:29 | * | fowl joined #nimrod |
| 10:16:58 | * | zahary quit (Read error: No route to host) |
| 10:18:25 | * | zahary joined #nimrod |
| 15:46:03 | * | shevy quit (Ping timeout: 252 seconds) |
| 15:58:51 | * | shevy joined #nimrod |
| 16:12:03 | * | zahary quit (Read error: Connection reset by peer) |
| 17:01:28 | * | zahary joined #nimrod |
| 18:24:37 | * | Bosc0p joined #nimrod |
| 18:25:51 | * | zahary left #nimrod (#nimrod) |
| 18:25:53 | * | zahary joined #nimrod |
| 18:27:44 | * | Bosc0p is now known as Boscop |
| 18:27:44 | * | Boscop quit (Changing host) |
| 18:27:44 | * | Boscop joined #nimrod |
| 18:41:25 | zahary | Araq, some interesting trivia - I tested bootstrapping speed on windows with gcc 4.5.2, msvc 10 and intel 12. |
| 18:41:25 | zahary | msvc : 2.7s |
| 18:41:25 | zahary | gcc : 3.2s |
| 18:41:25 | zahary | intel: 3.4s |
| 18:43:21 | Araq | zahary: interesting :-) |
| 18:43:31 | Araq | I implemented the type system I had in mind for integers |
| 18:43:37 | Araq | but it kind of sucks |
| 18:43:53 | Araq | I introduced tyInt + nkIntLit(42) for integer literals |
| 18:44:10 | Araq | and only if the integer literal in in range, it is convertible to uint8 etc. |
| 18:44:10 | zahary | sucks for the user or for the compiler? |
| 18:44:21 | Araq | both :-) |
| 18:44:51 | Araq | for the user it's very confusing to get "got (int, int, int)" |
| 18:45:00 | Araq | "but expected (cint, int, cint)" |
| 18:45:03 | zahary | I understood your idea the first time you described it, but it seemed a little overkill (to have a separate type instance for each literal) |
| 18:45:39 | Araq | and some ints fit cint and some do not so the error message is confusing as hell :-) |
| 18:46:06 | Araq | I implemented a type cache, so no separate type instance per literal |
| 18:46:08 | zahary | hmm, you could print it as |
| 18:46:08 | zahary | got (43, int) |
| 18:46:25 | Araq | yeah but the real problem is: |
| 18:46:35 | Araq | (4+5) should be an int literal too |
| 18:46:45 | zahary | aha |
| 18:46:56 | Araq | and while not hard to implement |
| 18:47:16 | Araq | it then makes the type dependent of the const capabilities of the compiler |
| 18:47:42 | zahary | you mean the const folding capabilities? |
| 18:47:46 | Araq | yes |
| 18:49:03 | Araq | formally tyInt + literal introduces a tyIntLit in the language |
| 18:49:30 | Araq | and then we need to specify that it's converted to tyInt in cases like this: |
| 18:49:32 | Araq | var x = 0 |
| 18:50:10 | Araq | and we have type inference for + et al |
| 18:50:44 | Araq | proc `+` (x, y: intlit): intlit |
| 18:50:56 | zahary | btw, there is an interesting idea that didn't make into C++ 11 on time |
| 18:50:56 | zahary | the expression template guys noticed that type inference breaks their libraries |
| 18:50:56 | zahary | auto product = M1 * M2; // oops, product is the expression template object |
| 18:51:38 | zahary | the proposed solution is to add an "operator auto" to the language - it allows to plug yourself in the type inference process |
| 18:52:46 | Araq | omg ... :-) |
| 18:53:16 | Araq | term rewriting macros ftw |
| 18:56:26 | zahary | :) yep, but it's nice to remember this example. also, if IntLit + IntLit just produces another IntLit, the "special type inference" solution solves the problem |
| 18:58:55 | Araq | well my new solution is to make tyInt less expensive to convert to any other integer type |
| 18:59:10 | Araq | so that i16 and 7 produces i16 |
| 18:59:28 | zahary | the C conversion rules? |
| 18:59:34 | Araq | that's not C |
| 18:59:55 | Araq | C does i16 & int -> int |
| 19:00:06 | Araq | C promotes smaller types to 'int' |
| 19:00:14 | zahary | hmm, but is this only for literals then? |
| 19:00:15 | Araq | and else to the larger type |
| 19:00:57 | Araq | no |
| 19:01:19 | Araq | C's hex literals are unsigned int, C's literals are int, afaik |
| 19:01:42 | Araq | and literals which don't fit int, are long, long long etc. |
| 19:02:00 | zahary | I've never given this any thought, but doing the opposite of C sounds scary :) |
| 19:02:34 | Araq | but it also solves the "I wanna use int32 everywhere for cache efficiency" problem :-) |
| 19:02:57 | Araq | and the compiler emits a downcast check anyway |
| 19:03:21 | Araq | and if it can be proven to fail at compiler time, the compiler errors out |
| 19:03:47 | Araq | so i18 + 4564 would be a compile-time error |
| 19:03:55 | Araq | *i8 |
| 19:04:08 | Araq | but after type checking |
| 19:04:19 | Araq | it would match the int8 + operator |
| 19:04:37 | Araq | so basically we have the rules: |
| 19:05:01 | Araq | implicit conversion is allowed if no information is lost (int8 -> int16) (like before) |
| 19:05:35 | Araq | 2) 'int' is special and can be downcasted implicitely |
| 19:05:43 | Araq | *narrowed |
| 19:06:15 | Araq | which is quite easy and doesn't break any code as far as I tested it |
| 19:06:37 | Araq | plus it makes nimrod more useful on 8 bit cpus than C ... :D |
| 19:09:28 | zahary | I see. I'm interested in digging up the history on how all the rules in C got established. otherwise, I guess I haven't formed an opinion on the usefulness/dangers of implicit casts |
| 19:11:52 | zahary | the codegen is quite often casting to NI64 btw, which is something I was always curious about, but never got to the point to chase it down. what kind of code is producing these casts? |
| 19:16:58 | zahary | damn, gotta go, see you later |
| 19:17:02 | Araq | ha |
| 19:17:05 | Araq | same here |
| 19:17:08 | Araq | see you later |
| 21:18:05 | Araq | fowl: I don't understand your problem |
| 21:18:32 | Araq | the compiler passes -lm to gcc anyway via the configuration file I think |
| 21:32:59 | fowl | it seems to work without it now >_> |
| 21:33:01 | fowl | https://gist.github.com/3005966 |
| 21:39:05 | Araq | should I add them to math? |
| 21:40:29 | fowl | sure |
| 21:43:06 | Araq | alright |
| 21:43:48 | Araq | why does `mod` not use 'fmod'? |
| 21:44:16 | Araq | and should division by 0 really return 'x'? |
| 21:49:39 | fowl | fmod acts differently than i expected it to, it will return a negative number if you give it a negative number |
| 21:51:59 | Araq | that may be the case for 'mod' for ints too ... :-) |
| 21:54:49 | fowl | o |
| 21:57:10 | fowl | How can I create a TRect with x/y/w/h wihtout setting each one? something like var r = TRect(x, y, w, h) would be perfect |
| 21:58:24 | Araq | make TRect a tuple and you can use (x, y, w, h) |
| 21:58:38 | Araq | or make a constructor proc |
| 21:58:51 | Araq | you can also play syntax games |
| 21:59:47 | Araq | proc `\`(x, y, w, h: int): TRect = ... |
| 22:05:40 | * | apriori_ joined #nimrod |
| 22:05:45 | fowl | how weird can the proc names get? :) |
| 22:07:43 | Araq | @~??/||| |
| 22:07:56 | Araq | very weird ;-) |