00:54:39 | * | XAMPP quit (Read error: Connection reset by peer) |
00:55:07 | * | XAMPP joined #nimrod |
05:14:43 | Araq | reactormonk: use a 'ref EFloat' |
05:14:46 | Araq | and |
05:14:52 | Araq | new(err) |
05:15:05 | Araq | err.reason = status |
05:15:09 | Araq | raise err |
05:15:14 | Araq | have to go, bye |
09:05:40 | * | armin__ joined #nimrod |
09:06:16 | * | armin__ is now known as apriori_work |
09:42:23 | * | Araq_ joined #nimrod |
09:43:03 | Araq_ | apriori_work: I like your tuple idea |
09:43:25 | Araq_ | and in fact it's almost already implemented in the current compiler |
09:55:04 | apriori_work | Araq, good ;) |
09:56:19 | apriori_work | overload resolution should of course prefer the precise tuple description over an anonymous match |
10:02:11 | * | Araq_ quit (Read error: Connection timed out) |
10:03:38 | * | Araq_ joined #nimrod |
10:07:56 | Araq_ | arg, really? |
10:08:09 | Araq_ | we'll see about that :P |
10:21:38 | * | Araq_ quit (Quit: ChatZilla 0.9.88.2 [Firefox 14.0.1/20120713134347]) |
10:35:51 | * | zahary1 quit (Ping timeout: 245 seconds) |
13:42:17 | * | Boscop quit (Disconnected by services) |
13:42:20 | * | Boscop joined #nimrod |
14:37:29 | * | Trix[a]r_za is now known as Trixar_za |
14:40:01 | * | Boscop quit (Ping timeout: 246 seconds) |
14:42:36 | * | Boscop joined #nimrod |
14:49:15 | Trixar_za | Ha, the mental state I have for the word Nimrod is overloaded since I think of three distinct things when I hear or see the word. |
15:30:15 | * | zahary joined #nimrod |
15:37:05 | fowl | hey Trixar_za whats going on |
15:38:09 | Trixar_za | Not much. Went a little gambling last night. I normally don't gamble because I'm like a money sink. It all just disappears |
15:38:29 | Trixar_za | But last night I was milking machines. I walked in with 200 and walked out with 1500 |
15:38:53 | Trixar_za | Playing on a 2c machine too |
15:41:46 | fowl | cool |
15:42:39 | fowl | ive only gambled a few times, afterwards i wished i had spent the money on weed instead |
15:43:24 | Trixar_za | I have more sense than my dad though. Every time I just won big, I worked down to a round number and cashed out. Left 50 on the card and started again. |
15:43:52 | Trixar_za | My dad keeps gambling even when he has won big :/ |
15:43:57 | * | apriori_work quit (Remote host closed the connection) |
16:08:03 | * | apriori_ joined #nimrod |
16:13:43 | * | Boscop quit (Disconnected by services) |
16:13:46 | * | Boscop joined #nimrod |
16:15:43 | reactormonk | gambling is a tax for people who don't know math? |
16:16:06 | fowl | ha i like that |
16:17:10 | * | Boscop quit (Disconnected by services) |
16:17:13 | * | Boscop joined #nimrod |
16:38:13 | * | shevy quit (Ping timeout: 260 seconds) |
16:48:57 | apriori_ | Araq: http://pastebin.com/yfjKX1YQ is that a compiler bug? |
16:49:21 | apriori_ | I mean, you said, values are not allowed but proposed to use an IDX type instead.. not quite sure how that should work |
16:50:55 | * | shevy joined #nimrod |
16:51:16 | Araq | apriori_: yeah, bug ... but '..' is also a proc these days |
16:51:27 | Araq | hm |
16:51:36 | reactormonk | Araq: so I can only pass a ref object to raise? |
16:51:43 | Araq | reactormonk: yes |
16:51:58 | Araq | error message is misleading, I know |
16:52:43 | reactormonk | change it |
16:52:50 | Araq | apriori_: try to use TVector[range[0..2], T] |
16:53:09 | apriori_ | Araq: working |
16:53:36 | Araq | '..' is ambiguous ... |
16:53:56 | Araq | it has special meaning in 'array' and 'range' |
16:54:03 | apriori_ | ok |
16:54:07 | Araq | dunno what to do about it |
16:54:27 | Araq | I will think about it |
16:54:31 | apriori_ | np |
16:55:11 | apriori_ | currently, I wonder whether it'd be a good idea to manage matrices only as flat arrays |
17:00:44 | apriori_ | Araq: also I wonder about the following.. in e.g. D I could build a template struct, which uses the dimension to build the respective array and also provide accessors (array wise and componenet name wise) |
17:01:28 | apriori_ | is there a way to "automatically" create such stuff, if a type "pattern" like TVector3[T] = array[0..2, T] is declared? |
17:01:59 | apriori_ | say.. a user will write in his type section: type TVector3F = TVector3[float].. |
17:02:15 | apriori_ | well, in that special cases it makes no real sense to be able to do that, because generics will just suffice |
17:03:13 | apriori_ | a more useful example: we got TVectorN*[A, T] = array[A, T] |
17:03:57 | apriori_ | and on instanciation of TVector3F = TVectorN[range[0..2], float] I would also like to autogenerate accessors like x, y, z |
17:04:30 | apriori_ | actually, even those can become generics.. but I see no way to properly generalize depending on the length of the vector |
17:04:38 | apriori_ | e.g. 2 D or 4D |
17:05:23 | apriori_ | do you understand what I mean? |
17:07:06 | reactormonk | Araq: http://sprunge.us/MHNh but it doesn't compile - http://sprunge.us/SGJg |
17:09:41 | reactormonk | hm, no !! in nimrod to convert any value to bool? nil => false, everything else true |
17:10:42 | Araq | sorry brb |
17:21:28 | Araq | reactormonk: your code is fine, but you mustn't import artihm.nim |
17:21:41 | Araq | as it's part of system.nim |
17:22:13 | Araq | how would !! work in nimrod? |
17:22:56 | Araq | apriori_: accessors can be put into a template I guess and then you can instantiate that if you want them |
17:23:10 | apriori_ | hm |
17:23:22 | apriori_ | some "onInstantiate" pragma would be awesome.. |
17:23:26 | fowl | proc `!`(a: pointer): bool = return not isNil(a) ? |
17:23:33 | apriori_ | that would then call template/macro |
17:25:34 | Araq | are accessors really useful for vectors? |
17:26:07 | Araq | I think they are stupid, you can't abstract the access anyway for performance reasons |
17:26:43 | Araq | and you can easily do: const x = 1 |
17:26:48 | Araq | v[x] |
17:26:49 | apriori_ | they might.. but they really increase readability |
17:27:12 | Araq | or proc x(v ...) |
17:27:15 | Araq | v.x |
17:27:26 | apriori_ | that proc would be the way |
17:28:25 | reactormonk | Araq: as I mentioned, convert everything but nil to true |
17:30:06 | Araq | in C, !x means x == NULL |
17:30:24 | Araq | so it could be confusing |
17:31:54 | Araq | zahary wants "proxies" for v.x |
17:32:13 | Araq | basic idea is to mark 'TVector' with a macro |
17:32:30 | Araq | which is queried if v.UKNOWN is found |
17:32:36 | Araq | *UNKNOWN |
17:33:11 | Araq | I think this would solve your problem, apriori_ |
17:33:19 | apriori_ | yup |
17:33:34 | apriori_ | another "problem" would be .. accessing matrix entries |
17:33:43 | apriori_ | I think the following would work, but look awful: |
17:33:51 | apriori_ | matrix[(i, j)] |
17:34:04 | Araq | nah, you can easily overload [] |
17:34:12 | apriori_ | that would be an overload |
17:34:14 | apriori_ | taking a tuple |
17:34:24 | Araq | proc `[]` (m: TMatrix, a, b: int) |
17:34:40 | Araq | and then invoke it with: m[i, j] |
17:34:42 | apriori_ | would that be: matrix[a, b] ? |
17:34:53 | apriori_ | very nice ;) |
17:34:59 | Araq | yeah, overloading of [] is special cased :-) |
17:35:08 | Araq | btw there is also {} for column access |
17:35:08 | apriori_ | awesome |
17:35:36 | apriori_ | yeah, so we'd have: |
17:35:46 | apriori_ | [a, b].. specific entry or even range |
17:35:52 | apriori_ | (a submatrix) |
17:36:03 | apriori_ | [a] for a row or range of rangs |
17:36:07 | apriori_ | *rows |
17:36:16 | apriori_ | and same with {} for columns |
17:45:09 | reactormonk | Araq: http://sprunge.us/WXBb <- code in question |
17:46:15 | Araq | well what is the question? |
17:47:00 | reactormonk | Araq: floatCheck returns nil (aka no result = called) when the test fails |
17:47:30 | Araq | what is its return type? |
17:47:42 | reactormonk | of floatCheck? FPStatus |
17:47:53 | reactormonk | of the shortcuts? bool |
17:48:06 | Araq | how can FPStatus ever be nil? |
17:48:21 | reactormonk | http://sprunge.us/KLCS |
17:48:41 | reactormonk | aka 'no match' |
17:48:50 | Araq | that's not nil |
17:48:59 | reactormonk | but? |
17:49:11 | Araq | result == FPStatus(0) if not re-assigned |
17:49:32 | reactormonk | and what if not assigned? |
17:49:36 | reactormonk | ah |
17:49:39 | reactormonk | ups |
17:50:05 | Araq | actually we could have: |
17:50:26 | Araq | proc `!!`[T](x: T): bool = |
17:50:44 | Araq | var y: T |
17:50:51 | Araq | result = x == y |
17:51:20 | Araq | that would check against T's default initialization value |
17:52:16 | reactormonk | seems like my idea of an API doesn not fit nimrod |
17:52:45 | Araq | seems you're in dynamic typing land in your mind |
17:53:32 | Araq | but your API looks nice, there is no problem |
17:53:45 | Araq | you don't need 'nil' at all here |
17:54:14 | reactormonk | ehm, FPStatus(0) is NotANumber |
17:54:24 | Araq | yeah that's the problem |
17:54:26 | reactormonk | and I can't change that because that's what fpclassify gives me |
17:55:18 | Araq | true, you either need a mapping fpclassify's resulttype -> FPStatus |
17:55:34 | Araq | or you simply do: |
17:55:41 | Araq | result = Normal |
17:56:07 | Araq | in floatCheck |
17:57:03 | reactormonk | I'm not sure I like that |
17:58:24 | Araq | but you need some mapping anyway I think |
17:58:46 | Araq | as you can't use {NotANumber, Infinite, Subnormal} in the C code gen ... |
18:03:35 | Araq | but proc floatCheck*(x: float, checks: set[FPStatus]): FPStatus is unnecessary; just do the check in floatGuard |
18:04:09 | Araq | think about it, why would one ever call it? |
18:04:29 | Araq | it doesn't raise an exception ... |
18:04:51 | reactormonk | because you don't want an exception, just a return type? |
18:05:01 | Araq | but why? |
18:05:07 | apriori_ | Araq: I'd still vote for nimrod becoming case sensitive ;) |
18:05:38 | Araq | I can use the other floatCheck for that, reactormonk |
18:06:31 | Araq | apriori_: use case? |
18:06:36 | reactormonk | hmm, right |
18:07:20 | apriori_ | Araq: well, I just say that.. because e.g. in math you have tons of use cases of e.g. using n/N |
18:08:09 | Araq | in fact, I want case sensitivity for single letters |
18:08:51 | apriori_ | actually.. why not become case sensitive throughout? |
18:09:11 | apriori_ | I find case insensitivty more confusing than helpful |
18:09:16 | apriori_ | *insensitivity |
18:09:30 | Araq | no idea how much code would break and I want to be protected from idiots |
18:09:42 | Araq | who think identifiers_like_this_are_readable |
18:09:51 | Araq | because they are not |
18:10:05 | Araq | I want to tokenize in my head |
18:10:14 | Araq | and the _ are almost in the next line |
18:10:17 | apriori_ | so you prefer camel case? |
18:10:29 | Araq | yeah |
18:10:37 | Araq | except for abbrevs, GC_disable |
18:10:52 | apriori_ | your rules of the tokenizer would even allow to transform the above example into identifiersLike... |
18:11:11 | Araq | yeah |
18:11:15 | Araq | that was the idea |
18:11:26 | apriori_ | question is... is mixing cases and style that "brutally" any better |
18:11:57 | apriori_ | well.. definetly some religious topic |
18:13:09 | reactormonk | Araq: I do. |
18:13:50 | Araq | I also heavily dislike ALL_CAPS for constants btw |
18:14:05 | Araq | because they emphasize constants |
18:14:14 | Araq | they deserve no emphasize IMHO |
18:14:23 | apriori_ | well, sometimes |
18:14:26 | apriori_ | but usually not.. |
18:14:31 | Araq | and they are in flux often |
18:14:40 | Araq | often they end up becoming a variable |
18:14:46 | Araq | to be set via some config file |
18:15:09 | apriori_ | well, I prefer prefixing |
18:15:14 | apriori_ | like "C" or something |
18:15:43 | fowl | I get this error: sg_assets.nim(212, 2) Error: invalid expression: ' followed by the stmt list |
18:15:49 | apriori_ | currently.. in nimrod I stick to P, R, T for pointer, ref, "normal type".. guess C will be used for constants or so |
18:16:07 | Araq | fowl: I broke macros |
18:16:10 | reactormonk | Araq: parameter <-> global variable |
18:16:34 | Araq | I often use a 'g' prefix for globals |
18:16:37 | reactormonk | err parameter <-> constant |
18:16:46 | fowl | i picked a bad time to update then eh |
18:17:00 | reactormonk | in ruby, basically every scope type looks different |
18:17:03 | apriori_ | fowl: git bisect :P |
18:18:19 | Araq | except that ruby has like 3 scopes and that just doesn't work |
18:18:58 | Araq | I prefer prefix operators over sigils anyway |
18:19:08 | Araq | and they don't like each other |
18:19:10 | fowl | ruby has local, global, instance and class |
18:19:18 | fowl | and one is never used, so yeah 3 |
18:19:30 | Araq | yeah and 'local' doesn't suffice for closures |
18:19:56 | fowl | ? |
18:20:16 | fowl | why not |
18:20:31 | Araq | I dunno how ruby does it, but python requires 'nonlocal' I think |
18:20:45 | apriori_ | Araq: in generic constraints.. what is "distinct" and "primary"? |
18:21:18 | Araq | "distinct" -- some distinct type |
18:21:34 | Araq | "primary" -- some type (grammar term) |
18:21:43 | apriori_ | k |
18:26:41 | Araq | I also love to use all lowercase when debugging or in a REPL |
18:26:59 | apriori_ | yeah.. that are the advantages.. |
18:27:03 | apriori_ | being able to rapidly type in just lowercase |
18:27:34 | fowl | or if your mad OMG(WTF(..)) |
18:27:41 | Araq | in visual studio I have no autocompletion in breakpoint conditions |
18:27:47 | Araq | that sounds like nitpicking |
18:27:53 | Araq | but it's really a problem for me :D |
18:28:51 | * | Trixar_za is now known as Trix[a]r_za |
18:29:03 | Araq | and my bash does not autocomplete when a filename happens to start with a capital letter |
18:29:15 | Araq | I know there is some flag to turn that on |
18:29:19 | apriori_ | yup |
18:29:40 | Araq | but the bash on my mac didn't support it :P |
18:29:48 | apriori_ | tzz.. mac :P |
18:31:23 | Araq | in fact, CS only works in Java |
18:31:45 | Araq | in C# the rules are broken: |
18:31:56 | Araq | private PageType PageType; // WTF? |
18:32:14 | Araq | python's stdlib is inconsistent |
18:32:42 | apriori_ | yup.. pythons stdlib is hell |
18:32:54 | apriori_ | sometimes with _, sometimes without, sometimes camel case, sometimes not |
18:32:54 | Araq | and C/C++ are full of different styles |
18:33:44 | Araq | C often uses alllowercpswithoutvwls |
18:33:56 | Araq | asithasnonamespaces |
18:34:29 | apriori_ | yeah, totally readable |
18:37:14 | Araq | in C# interfaces start with capital I |
18:38:37 | Araq | that's not bad, but if you have more entities than styles you start using prefixes |
18:39:12 | Araq | Nimrod has: const, var, let, proc, template, macro, converter, iterator and type |
18:39:29 | Araq | that's 9 entities |
18:39:38 | * | zahary quit (Ping timeout: 244 seconds) |
18:39:40 | Araq | how many styles do we get with CS? |
18:40:25 | Araq | mixed_style, ALL_CAPS, camelCase, ... |
18:41:11 | Araq | I have a hard time to map the styles to the entities in a way that would make sense |
18:41:58 | apriori_ | yeah, usually |
18:42:04 | Araq | and as I said, if Nimrod becomes CS, the compiler should enforce the naming scheme :P |
18:43:10 | apriori_ | I wouldn't have a problem with that |
18:43:54 | Araq | well make a suggestion |
18:44:17 | apriori_ | well, I can't, yet.. |
18:45:01 | Araq | well proc, template, converter, iterator, macro should use the same convention I guess |
18:45:14 | Araq | and so do let and var |
18:45:54 | Araq | so it's: type, var, proc and const |
18:47:04 | Araq | type: starts with a capital letter |
18:47:15 | Araq | except for 'int' and 'string' etc. ... |
18:47:35 | apriori_ | O_o |
18:47:39 | apriori_ | why does that compile? : |
18:47:50 | apriori_ | http://pastebin.com/LbKY1jLL |
18:47:56 | apriori_ | notice the last row |
18:48:36 | Araq | generics are really permissive :P |
18:48:50 | apriori_ | I meant more 1[i] |
18:48:55 | apriori_ | which makes no sense |
18:48:55 | Araq | you have no chance but to instantiate them to get some checking |
18:49:01 | apriori_ | ok |
18:49:06 | Araq | "abc"[i] does make sense :P |
18:49:17 | apriori_ | yeah, but not number literatal 1 |
18:49:32 | Araq | but it's the same syntactically |
18:49:35 | apriori_ | unless... it would be some bit operator |
18:49:46 | apriori_ | yeah |
18:49:47 | Araq | you could overload [] for int |
18:50:06 | Araq | but anyway the "indices" will fail soon |
18:50:21 | apriori_ | apropos.. |
18:50:26 | Araq | as the compiler will require the symbols to be defined in the current scope |
18:50:29 | apriori_ | something like this should go into stdlib: |
18:50:34 | apriori_ | iterator indices*[A, T](v: array[A, T]) : A = |
18:50:35 | apriori_ | for i in countUp(low(v), high(v)): |
18:50:37 | apriori_ | yield i |
18:50:47 | apriori_ | if that is even right |
18:50:59 | apriori_ | because actually A should not be a range, if A is a range, but an element of it |
18:51:18 | apriori_ | well, I meant the return should not be a range, if A is a range |
18:51:32 | Araq | but the return *type* is A |
18:51:55 | Araq | the *value* is not a range of course |
18:52:05 | apriori_ | hrm, yes |
18:52:57 | Araq | you don't need indices btw |
18:52:59 | Araq | use: |
18:53:08 | Araq | for i, x in v1: |
18:53:15 | Araq | v2[i] -= x |
18:53:32 | Araq | ok, you need it if you're not interested in a[i] at all I guess |
18:53:38 | apriori_ | since I'm often a performance maniac.. I hope that doesn't really copy x |
18:54:00 | Araq | it doesn't |
18:54:14 | apriori_ | good |
18:54:26 | Araq | though it's hard to say for objects ;-) |
18:54:40 | Araq | as it then depends on the C optimizer |
18:54:47 | apriori_ | hm |
18:55:03 | Araq | I wouldn't worry about it though |
18:55:28 | Araq | C++ does that very often and compilers have caught on |
18:55:36 | apriori_ | ok |
18:57:06 | apriori_ | oh.. I really gonna need some unit tests for this stuff... later |
18:58:51 | fowl | Araq: how can i store a ref type as a normal pointer for interfacing with c? should i just store addr theref[] ? |
18:59:26 | Araq | that's not any better than 'cast' |
18:59:40 | apriori_ | hm.. how about addr + gc ref mark? |
18:59:47 | apriori_ | to make sure it wont get lost |
18:59:55 | fowl | Araq: i have to cast it anyways to use it |
19:00:17 | Araq | depends onto what the C proc does with the pointer |
19:00:36 | Araq | if it escapes, you're in trouble and need GC_ref(), GC_unref() |
19:00:58 | Araq | if it doesn't escape, 'cast' should do |
19:02:54 | apriori_ | sry for bugging you all day, Araq.. but shouldnt this actually work? :) : http://pastebin.com/Jd5Sufku |
19:03:26 | apriori_ | oh fuck |
19:03:29 | apriori_ | not exported... |
19:03:31 | apriori_ | aaahhh |
19:03:56 | apriori_ | yup, that was it |
19:04:07 | Araq | apriori_: don't worry, I expect you to break the compiler with this stuff |
19:04:18 | apriori_ | ;) |
19:05:09 | Araq | btw, it's possible to implement: |
19:05:13 | reactormonk | Araq: http://sprunge.us/JTfh |
19:05:14 | Araq | for i in A: |
19:05:23 | Araq | have a look at the iterator for enums |
19:05:33 | Araq | the same should be possible for range[A..B] |
19:06:03 | apriori_ | ah, yeah, I remember |
19:07:00 | Araq | reactormonk: google it |
19:07:09 | apriori_ | Araq: not working for A = range[0..2] |
19:07:19 | apriori_ | missing overload for items, it seems |
19:07:32 | Araq | ? |
19:07:32 | apriori_ | hrm |
19:07:42 | Araq | "it's possible to implement" I said |
19:07:42 | apriori_ | vector.nim(36, 12) Error: type mismatch: got (typedesc[range 0..2]) |
19:07:44 | apriori_ | but expected one of: |
19:07:45 | apriori_ | system.items(a: string): char |
19:07:47 | apriori_ | system.items(E: typedesc[enum]): typedesc[enum] |
19:07:48 | apriori_ | system.items(a: openarray[T]): T |
19:07:50 | apriori_ | system.items(a: array[IX, T]): T |
19:07:51 | apriori_ | system.items(a: set[T]): T |
19:07:53 | apriori_ | system.items(a: seq[T]): T |
19:07:54 | apriori_ | system.items(a: cstring): char |
19:08:04 | Araq | well yes |
19:08:13 | Araq | you need to add it to system.nim |
19:08:18 | Araq | and implement it |
19:08:28 | reactormonk | aye |
19:08:48 | apriori_ | yeah, ok.. sry.. didnt read properly ;) |
19:11:33 | fowl | Araq: i'll be fine using gc_ref/unref because i know when they are created/destroyed |
19:11:49 | fowl | i should prboably just use raw pointers though in that case |
19:15:44 | Araq | reactormonk: you can now use type FPStatus {.pure.} = enum |
19:15:56 | Araq | so that FPStatus.Infinity is required |
19:16:09 | Araq | and the global namespace is not polluted |
19:16:31 | Araq | I don't like it ... ;-) |
19:16:52 | Araq | but most other people like the "cleaner" enums I guess |
19:18:26 | Araq | I prefer prefixes: fpInf, fpNan, fpSub, fpNormal |
19:18:45 | reactormonk | prefixes are for languages that fail in scope |
19:19:10 | Araq | yeah lets sigil them |
19:19:18 | Araq | if only that would work ... :P |
19:19:59 | Araq | prefixes always sneak in |
19:20:19 | Araq | even C# has 'I' for interfaces and 'T' for generic types |
19:20:37 | reactormonk | ruby doesn't :-) |
19:21:21 | reactormonk | btw: -lm fixes the problem |
19:21:32 | reactormonk | because we need to link libm |
19:21:52 | Araq | the config should already contain -lm |
19:22:12 | reactormonk | I compiled an empty test.nim, and it does not |
19:22:31 | apriori_ | Araq: apropos breaking the compiler ;) |
19:22:48 | Araq | http://blog.mikiobraun.de/2009/10/whats-wrong-with-ruby-module-functions.html |
19:23:02 | apriori_ | Araq: the prior posted code for some reason allows e.g. addition of a vector2d to a vector3d |
19:23:15 | Araq | reactormonk: this guy disagrees with you |
19:24:07 | reactormonk | Araq: that's only marginally interessting |
19:24:51 | Araq | http://www.joshstaiger.org/archives/2006/12/of_closures_met_1.html |
19:25:20 | fowl | thats a dumb example |
19:26:10 | Araq | how so? |
19:26:15 | fowl | instead of making a Fcts module to hold bessel() he could have just called MoreMath.bessel() since that is what a module function is.. |
19:26:24 | reactormonk | Araq: just a lame pun. |
19:26:40 | Araq | my second link is better |
19:26:56 | reactormonk | Araq: fail scoping as in no namespaces |
19:27:15 | Araq | "Matz clearly recognizes that there are issues with Ruby's current scoping implementation, so maybe this is one of them." |
19:27:39 | reactormonk | ruby does have namespaces. I associate prefixes with lisp, where you have almost no namespaces |
19:28:20 | fowl | Araq: that article is just silly |
19:28:44 | Araq | ok, what about the second one? |
19:28:47 | fowl | in ruby, methods aren't closures, why write an article complaining about it? blocks, procs, lambdas specifically are closures |
19:28:52 | apriori_ | hrm.. |
19:29:11 | apriori_ | why does nimrod not detect in that case, that A is not the exact some for those both types :/ |
19:30:42 | apriori_ | http://pastebin.com/79fJWDc5 |
19:31:12 | fowl | It kinda sucks that every time I want to create a closure I'm forced to use the less succinct ".call" syntax. if you're that anal about succinctness there is #[] for calling procs or #.() |
19:31:52 | reactormonk | fowl: go javascript if you want closures :-) |
19:32:04 | apriori_ | yuk, javashit... |
19:32:18 | reactormonk | apriori_: coffeescript makes it a bit better |
19:32:25 | Araq | *shrug* scope rules are hard and you can't please everybody |
19:32:26 | reactormonk | but don't use their object system |
19:33:13 | fowl | reactormonk: that's exactly what it is, "i dont like ruby because in ruby methods aren't closures" -- if methods being closures is a requirement to be your language of choice go do lua or javascript |
19:33:32 | apriori_ | reactormonk: helping a workmate to develop a webgl renderer was a mere nightmare.. |
19:33:51 | reactormonk | apriori_: I guess so :-) |
19:33:52 | apriori_ | reactormonk: debugging javascript is a nightmare.. that "define anywhere, see everywhere" thing is also a nightmare |
19:34:14 | reactormonk | :D |
19:34:44 | Araq | *shrug* Lua's design seems better on paper |
19:35:04 | Araq | having used Lua and not Ruby, I think I'd prefer Ruby |
19:35:45 | Araq | Lua's scoping rules are better I'm quite sure, but this 'nil' hunting is annoying |
19:36:10 | Araq | and 'function' is too long as a keyword ;-) |
19:36:35 | fowl | oh at the end of this it comes down to "look at some functions in javascript, these are closures! im happy again!" |
19:36:44 | Araq | plus it lacks a case statement and lots of other useful things |
19:36:55 | Araq | apriori_: bug report |
19:37:46 | fowl | also, class and module blocks open a new scope, they just do, sorry |
19:38:07 | Araq | or even better collect these things and make a single bug report for all you encounter :-) |
19:38:16 | Araq | as it's getting overwhelming |
19:39:38 | apriori_ | hehe, okay |
19:39:58 | apriori_ | actually.. if I'm not wrong, this might indicate general issues with generics |
19:40:05 | apriori_ | running other series of tests |
19:41:33 | * | zahary joined #nimrod |
19:50:10 | apriori_ | how can I print the actual type that was picked for a generic instantiation? |
19:54:20 | Araq | dunno, there is some magic for it |
19:54:37 | Araq | forgot its name |
19:57:31 | Araq | apriori_: tests/run/ttypetraits |
19:57:42 | apriori_ | k, reading |
19:57:44 | reactormonk | Araq: so, basically, nimrod c doesn't include -lm |
19:58:02 | reactormonk | at least not for the basics without any include |
19:58:47 | Araq | reactormonk: indeed it's in math.nim: |
19:58:50 | Araq | when defined(Posix): |
19:58:52 | Araq | {.passl: "-lm".} |
19:58:57 | Araq | damn |
19:59:00 | apriori_ | Error: internal error: (filename: compiler/evals.nim, line: 867) :/ |
20:00:13 | Araq | and that's what the compiler's code says: |
20:00:17 | Araq | ## XXX: This should be pretty much guaranteed to be true |
20:00:18 | Araq | # by the type traits procs' signatures, but until the |
20:00:20 | Araq | # code is more mature it doesn't hurt to be extra safe |
20:00:22 | Araq | :D |
20:00:41 | apriori_ | ouch |
20:00:46 | Araq | so much for the "guaranteed to be true" |
20:01:33 | apriori_ | hehe |
20:02:38 | reactormonk | Araq: ... which is not in system.nim - now what? |
20:03:17 | Araq | move it to system.nim |
20:03:28 | Araq | or even better remove it from math.nim |
20:03:35 | Araq | and add it to the default config file |
20:03:55 | Araq | config/nimrod.cfg |
20:04:41 | reactormonk | Araq: just include math.nim into system.nim? |
20:04:56 | Araq | do not do that |
20:05:06 | Araq | system.nim is special :P |
20:05:17 | reactormonk | or, rather, system/ |
20:05:22 | Araq | anyway -ldl is handled in the config file too |
20:05:38 | Araq | so it's consistent to handle -lm there |
20:06:55 | reactormonk | basically add -lm to everyone of the four? |
20:07:20 | Araq | add it if posix |
20:08:05 | reactormonk | how do I add options? |
20:08:08 | reactormonk | += = |
20:08:21 | Araq | read the config file |
20:08:43 | Araq | check how it's done for -ldl |
20:08:53 | reactormonk | gcc.options.linker = "-ldl" |
20:09:31 | Araq | well do it this way then: |
20:09:41 | Araq | --passl:"-lm" |
20:09:54 | Araq | that will add to the options |
20:10:27 | reactormonk | yep, works |
20:10:33 | reactormonk | now for some tests |
20:14:24 | Araq | math.h should really add -lm if it needs it |
20:15:04 | Araq | leaking abstraction ;-) |
20:15:24 | Araq | stdio.h manages to do without -lio ... |
20:16:43 | reactormonk | there are no tests for arithm.nim ? |
20:17:04 | Araq | there are but I forgot where |
20:17:19 | Araq | just use tmath |
20:18:21 | apriori_ | Araq: https://github.com/Araq/Nimrod/issues/202 |
20:18:21 | reactormonk | how do I get an inf/NaN/subnormal float? |
20:18:41 | Araq | system.Inf exists |
20:18:42 | reactormonk | apriori_: split them up |
20:18:58 | apriori_ | reactormonk: he didnt want them to be splitted |
20:19:40 | reactormonk | hum |
20:20:03 | Araq | to get a NaN, use Inf / Inf I think |
20:20:13 | Araq | no idea how to get a subnormal |
20:27:23 | reactormonk | DBL_MIN/10 apparently |
20:30:33 | reactormonk | how do I get DBL_MIN in code? :-/ |
20:30:42 | reactormonk | low(float) ? |
20:31:15 | Araq | var DBL_MIN {.importc, header: "<math.h>".}: float |
20:45:37 | reactormonk | is there a macro for 'when target is C...'? |
20:56:08 | Araq | when not defined(NimrodVM) and not defined(ECMAScript): |
20:56:18 | Araq | (sucks, I know) |
20:57:19 | reactormonk | can't you introduce a when defined(C)? |
20:57:31 | reactormonk | or even when target(C) |
20:59:37 | apriori_ | got go |
20:59:38 | apriori_ | bye all |
21:00:18 | * | apriori_ quit (Quit: Konversation terminated!) |
21:37:13 | Araq | ah hi zahary |
21:37:42 | Araq | what do you think about range[a..b] vs. a..b in generics? |
21:45:56 | zahary | well, you had an idea about it many months ago - we can make array[int, T] equivalent to array[range[0..int], T] |
21:46:46 | zahary | that will improve things a little bit - otherwise, I guess it's a bug that 0..2 is not detected as range in this situation |
21:50:22 | Araq | well ... we can't detect types easily: p[0..2](x, y) is ambiguous |
21:50:51 | Araq | and if expressions can be passed to generics, it will be ambiguous |
21:51:08 | Araq | even in semcheck |
21:52:44 | zahary | 0..2 is not a regular expression right now? |
21:52:58 | zahary | it's intercepted by the parser/sem somewhere with special meaning? |
21:53:29 | Araq | yeah it's turned into a nkRange sometimes |
21:54:04 | Araq | it is a regular expression except in some cases where it isn't ;-) |
21:54:43 | zahary | ideally, it will just produce a range value, which is something that's valid as a type argument |
21:55:12 | zahary | var x = 0..2 seems perfectly fine in regular code |
21:56:32 | Araq | TSlice needs to become a magic for that to work |
21:56:48 | Araq | but yeah, seems a good way to do it |
22:03:57 | reactormonk | just got overrun on AC :-/ |
22:05:06 | zahary | about 1): typeRel will report range[0..1] and range[0..2] as compatible types and this triggers implicit conversion between array[0..2] and array[0..1] |
22:05:57 | Araq | yeah I thought it was something like that |
22:06:27 | Araq | fix: special casing that in the branch for tyArray? |
22:09:18 | reactormonk | huh? http://sprunge.us/ZaGK |
22:09:57 | Araq | reactormonk: fixed it already |
22:10:17 | Araq | but may break it again tonight |
22:10:54 | reactormonk | hum |
22:11:16 | reactormonk | lib/pure/unittest.nim(92, 16) Error: undeclared identifier: 'TestStatusIMPL' |
22:13:58 | reactormonk | \o/ |
22:14:36 | reactormonk | err wtf |
22:14:45 | reactormonk | oh, my fail |
22:15:00 | reactormonk | zahary: why have a suite and a test keyword? not just one? |
22:16:04 | zahary | the suite allows you to have a common setup and teardown code for all tests |
22:16:14 | reactormonk | why can't test do that? |
22:17:12 | reactormonk | Araq: var DBL_MIN {.importc, header: "<math.h>".}: float fails |
22:17:18 | zahary | at this time in the evening I can only come up with a stupid example, but imagine you are testing various sorting procs |
22:17:20 | reactormonk | it sets it to '0' |
22:17:38 | reactormonk | zahary: I just wonder why the functionality of 'suite' couldn't be merged into test |
22:17:49 | zahary | you'll want all tests to have access to local variable with unsorted sequence - the common setup part will prepare just that |
22:18:12 | Araq | reactormonk: the 'var' needs to be a global |
22:18:23 | zahary | no, it can be local too |
22:18:27 | Araq | or try it with {.noinit.} |
22:18:42 | zahary | the setup code will just be inserted at the begging of each test proc |
22:19:11 | reactormonk | zahary: so why can't test have this functionality as well? |
22:19:38 | reactormonk | where do I make feature requests for unittest btw? |
22:19:54 | zahary | reactormonk, tell me how the suite functionality can be merged into test? I'm not sure yet what's confusing you |
22:20:30 | reactormonk | zahary: nah, I got the idea. I just wonder wherever it would be possible to reduce it to a single keyword 'test' |
22:20:46 | zahary | you can always use test without a suite |
22:21:05 | zahary | the suite only allows you to have shared setup/teardown |
22:21:17 | reactormonk | ... got something else in mind as well. a 'check_proc' that takes 'proc', 'arguments', 'result' |
22:21:39 | reactormonk | ... or improve the inspect functionality of check :-) |
22:21:50 | reactormonk | oke |
22:21:52 | zahary | can you elaborate? check proc(arguments) == result ? |
22:22:07 | zahary | aha, I see what you mean |
22:22:07 | reactormonk | http://sprunge.us/hNCS <- how to improve that? |
22:22:22 | zahary | indeed - the inspecting functionality is not finished |
22:22:23 | reactormonk | I'm like "ok, it failed. now what?" |
22:23:06 | zahary | you can try to get your hands dirty - it would be a good exercise in using macros |
22:23:18 | reactormonk | ugh |
22:23:33 | reactormonk | I'd just add a condition and a repl ;-) |
22:23:56 | zahary | https://github.com/Araq/Nimrod/blob/master/lib/pure/unittest.nim |
22:24:03 | zahary | notice how I left TODO there :) |
22:24:20 | zahary | it won't be much different from what I'm doing in the nkInfix case |
22:25:09 | reactormonk | ah |
22:26:24 | reactormonk | can't you check for literals? |
22:27:40 | zahary | I'm checking for literals in the infix case - I can try to implement the print outs for calls tomorrow if you don't feel like trying yourself |
22:28:51 | reactormonk | nah, gotta read some papers |
22:30:10 | reactormonk | Araq: DBL_MAX is 2.1599848462962204e-317 |
22:30:19 | reactormonk | something is very, very wierd |
22:34:52 | reactormonk | zahary: already something nice around for table-testing? |
22:36:33 | Araq | so zahary I'm about to merge semExpr and semStmt |
22:36:50 | Araq | any ideas what could break? |
22:39:04 | zahary | I guess nothing since semStmt is calling semExpr internally and there isn't any node kinds which are handled by both? |
22:39:13 | zahary | effectively, they are merged right now |
22:40:22 | dom96 | Araq: Were you brave enough to enable the compile tests yet? |
22:40:34 | Araq | dom96: indeed and I fixed most of them |
22:40:48 | Araq | and I broke only few in all these months :-) |
22:40:57 | dom96 | Araq: That's good :) |
22:41:14 | Araq | but we really need branches for nimbuild |
22:41:33 | Araq | it's really easy to decide whether a bugfix breaks some code or not |
22:42:00 | Araq | so maintaining 2 branches should be easy |
22:42:11 | dom96 | Yes, I know. I will add that ASAP. |
22:42:16 | Araq | good |
22:44:08 | zahary | I wanted to merge semType and semExpr btw |
22:46:52 | Araq | how would that work? by some flag? |
22:47:14 | Araq | semType interprets nkBracketExpr very differently for instance |
22:48:15 | zahary | since we have typedesc params now, such things can work with the standard magic system (or sometimes even with templates) |
22:51:13 | Araq | yeah well, I'll merge semStmt and semExpr first and gather some experience :-) |
22:51:49 | Araq | semType has some other problems in addition but I'm not opposed to merging it |
22:51:58 | zahary | … or with special cases in semBracket like the rest of built-in types . it's unfortunate that type cannot appear as values anywhere within the program |
22:53:25 | zahary | and I'm not fair, because it mostly works now, but semExpr and semType end up calling each other and repeating the same switch statements with the same code for idents, macros, etc |
22:53:48 | Araq | true |
22:57:11 | zahary | https://github.com/Araq/Nimrod/blob/master/compiler/sigmatch.nim#L388 |
22:57:11 | zahary | btw what does it mean that the ArrayConstructor have a generic type at sons[0] (this is where the tyRange goes usually)? |
22:58:25 | Araq | well it means exactly that |
22:58:38 | Araq | its index type is a generic type |
22:59:38 | zahary | can you give me an example for such array? |
23:00:31 | Araq | type TX[Idx] = array[Idx, int] |
23:01:04 | Araq | the built-in containers have no tyGenericBody/Inst stuff |
23:01:31 | Araq | the reason is historical |
23:01:38 | Araq | ;-) |
23:02:09 | Araq | I always fight with the generic types implementation ;-) |
23:02:26 | zahary | aha, it's my bad actually - didn't see that GenericParam is in GenericTypes too (I was assuming it's GenericBody) |
23:15:05 | Araq | good night |