00:57:28 | reactormonk | type TTime* {.final, importc.} = object |
00:57:30 | reactormonk | getSeconds: proc (): int |
00:57:41 | reactormonk | and t.getSeconds fails with lib/pure/times.nim(448, 22) Error: undeclared field: 'getSeconds' |
01:05:08 | reactormonk | ... that's because the symbol 'windows' is defined when running JS. WTF? |
01:05:49 | reactormonk | oh, wait |
01:06:02 | reactormonk | posix is defined. |
01:29:36 | * | zahary1 quit (Quit: Leaving.) |
01:39:48 | * | Trixar_za is now known as Trix[a]r_za |
01:51:58 | reactormonk | wtf. |
02:04:07 | * | XAMPP_ quit (Quit: My code has no bug's, just random features) |
02:04:38 | * | XAMPP joined #nimrod |
02:04:38 | * | XAMPP quit (Changing host) |
02:04:38 | * | XAMPP joined #nimrod |
02:59:55 | reactormonk | Araq, I think I kind of jumped out of a loop with functional ;-) |
03:00:05 | reactormonk | or used a next, that is |
03:18:35 | * | zahary is now known as zahary_ |
03:35:17 | * | fowl quit (Quit: Leaving) |
08:28:45 | * | q66 joined #nimrod |
08:31:52 | * | XAMPP quit (Quit: My code has no bug's, just random features) |
09:01:14 | * | XAMPP joined #nimrod |
10:50:10 | NimBot | Araq/Nimrod 7a319d9 Araq [+0 ±1 -0]: bugfix: new(TTable[string, int]) compiles |
11:23:41 | * | Boscop joined #nimrod |
13:06:29 | * | Trix[a]r_za is now known as Trixar_za |
14:35:45 | dom96 | hello |
14:36:09 | Araq | hi dom96 |
14:36:22 | dom96 | sup? |
14:38:49 | reactormonk | Araq, any way to find out where a compilation symbol is defined? |
14:39:22 | Araq | reactormonk: use 'nimrod dump' to see what's defined |
14:39:38 | Araq | in general only --define/d defines a symbol |
14:39:48 | Araq | apart from the builtin defines, of course |
14:40:11 | reactormonk | Araq, posix seems to defined when compiling to JS |
14:40:24 | reactormonk | ... that's why times.nim breaks in JS |
14:40:47 | Araq | that's likely a compiler bug |
15:32:03 | * | Trixar_za is now known as Trix[a]r_za |
17:32:07 | Araq | reactormonk: but the workaround it easy: when defined(posix) and not defined(js) ... |
17:41:33 | * | zahary joined #nimrod |
18:00:11 | reactormonk | Araq, ok |
18:10:52 | reactormonk | lib/pure/times.nim(242, 35) Error: conversion from TTime to float is invalid |
18:10:53 | reactormonk | let's see |
18:11:23 | reactormonk | I think you make some assumptions based on C |
18:12:45 | Araq | 'you' is likely dom96 here ... :P |
18:13:56 | reactormonk | yep. |
18:14:04 | * | dom96 hides |
18:14:46 | reactormonk | dom96, get it working. |
18:15:05 | reactormonk | http://sprunge.us/QWPh |
18:15:26 | reactormonk | Araq, I think we should split the times stuff into js and c |
18:16:10 | Araq | meh, that means 2 more include files ... |
18:16:20 | reactormonk | so what? |
18:17:51 | * | Araq dislikes a proliferation of files |
18:18:13 | reactormonk | why? |
18:20:33 | Araq | because inevitably it means to have more files open at once in the editor and more switching between them |
18:20:57 | reactormonk | othweise you have damn long files and you need to open two views |
18:21:01 | Araq | and times.nim is pretty small anyway |
18:21:22 | reactormonk | but it's got a shitload of defined in there, you always need to be aware where you are |
18:26:11 | Araq | come on, I just skimmed it again, it's still perfectly fine |
18:27:36 | dom96 | There are many much bigger modules in the stdlib. |
18:27:40 | reactormonk | oke... |
18:29:14 | reactormonk | lib/pure/times.nim(481, 21) Error: can have an unlisted effect: TEffect |
18:29:15 | reactormonk | hmm |
18:30:01 | reactormonk | what's the difference between TTime and TTimeInfo? |
18:30:29 | Araq | TTime seconds since UNIX's birth or something |
18:30:45 | Araq | TTimeInfo = time in days, hours, seconds etc. |
18:31:00 | reactormonk | basically our time |
18:32:06 | reactormonk | are you sure we don't want to use an external lib for that part? Because result = getGMTime(TTime(float(t) + secs)) is not always right, fucking corner cases. |
18:32:36 | dom96 | I think i've already mentioned this: there should be a epochTime overload to convert a TTime into a epoch time float. |
18:33:01 | reactormonk | dom96, issue? |
18:33:16 | dom96 | reactormonk: pull request :P |
18:33:30 | reactormonk | dom96, is there an issue about that? |
18:33:51 | dom96 | Dunno |
18:33:58 | dom96 | Don't think so |
18:34:00 | reactormonk | and why reinvent the wheel about that :-/ |
18:34:46 | dom96 | A times module? Well, I myself dislike dependencies. |
18:35:04 | reactormonk | NIH? |
18:35:47 | reactormonk | ah, broken-down time. should do fine. |
18:47:57 | * | zahary quit (Quit: Leaving.) |
18:54:23 | reactormonk | any way to define prefix operators? |
18:56:31 | Araq | reactormonk: no need to define them explicitly |
18:56:37 | reactormonk | Araq, ok |
18:56:47 | Araq | proc `?`(x: Int): int = x-3 |
18:56:54 | Araq | ?234 # works |
18:57:37 | reactormonk | nice |
18:57:49 | reactormonk | can I somehow iterate over the fields of an object? |
18:58:05 | Araq | use the 'fields' iterator ;-) |
18:58:22 | reactormonk | :-/ |
18:59:43 | reactormonk | and how do I access the fields? obj[field] ? |
19:00:23 | Araq | for f in obj.fields: # 'f' is the obj.field |
19:01:01 | reactormonk | oh, I need the name of the field, or a lens, if you wanna call it that |
19:01:17 | reactormonk | http://sprunge.us/gUaO |
19:01:22 | Araq | for name, field in fieldPairs(obj): |
19:01:52 | Araq | you can also use it to iterate over 2 objects at once iirc: |
19:02:07 | Araq | for a, b in fields(result, interval) |
19:02:21 | Araq | a = -b |
19:05:32 | reactormonk | fancy |
19:41:40 | reactormonk | http://sprunge.us/HEfG huh. |
19:50:13 | reactormonk | working on it. |
19:55:11 | dom96 | you're passing an argument to a function which does not require one? |
20:37:50 | * | gradha joined #nimrod |
20:58:48 | reactormonk | maybe |
20:59:15 | reactormonk | just bought 3 BTC for 107$ each because I had a buy lying around O.o |
21:03:10 | * | Trix[a]r_za is now known as Trixar_za |
21:48:38 | gradha | let's say I want "nimrod doc2" to specify the documentation for a module is at version x.y.z |
21:49:06 | gradha | let's say this module itself contains a const VERSION = "x.y.z" |
21:49:20 | gradha | any way to make the generated doc contain a version marker with the value of this const? |
21:49:36 | Araq | sure, kind of |
21:49:41 | gradha | I guess I could write myself a nimrod proc which imported the module to read its version, the run nimrod doc on it |
21:49:56 | gradha | but maybe nimrod doc already has this functionality |
21:50:11 | Araq | nimrod doc *almost* has it ;-) let me look it up |
21:50:33 | gradha | looking at sources like lib.txt I see ":Version: |nimrodversion|" but that requires parameter passing |
21:50:51 | Araq | well that's how to do it |
21:50:57 | Araq | :Version: |myversion| |
21:51:15 | Araq | and then pass in the command line: --putenv:myversion=0.9.2 |
21:51:19 | gradha | ok, so 1) extract string from module 2) run nimrod doc with extracted string |
21:51:26 | Araq | yeah |
21:51:28 | * | fowl joined #nimrod |
21:52:00 | Araq | doc2 could easily do it your way though I guess |
21:52:13 | Araq | but ugh |
21:52:37 | Araq | that would require some forwarding logic as I bet the comment comes before the version's defintion |
21:53:14 | gradha | what's replaced when the putenv: is not passed? empty string? |
21:53:32 | Araq | it's kept as |myversion| in the output iirc |
21:53:46 | Araq | the compiler warns about it though |
21:56:57 | fowl | are there plans to allow macros in typedef pragmas |
21:57:43 | Araq | fowl: hrm, I thought that's already supported :-) |
21:58:01 | Araq | you mean type TFoo = object {.mymacro.} right? |
21:59:05 | fowl | yea |
21:59:56 | fowl | i get invalid pragma |
22:03:49 | Araq | ok, adding to my todo |
22:18:20 | gradha | is it possible to define a proc which accepts an adhoc input tuple? I mean, without declaring the type previously |
22:18:46 | gradha | I'm trying proc test(something: (xmajor: int, xminor: int, xmaintenance: int)) = echo repr(something) |
22:18:47 | Araq | sure, tuples are structural types |
22:19:02 | gradha | ah, that's the constructor |
22:19:21 | Araq | proc test(something: tuple[xmajor, xminor, xmaintainance: int]) |
22:19:32 | fowl | gradha: tuple[fields] |
22:19:53 | gradha | good, i was forgetting the tuple before the brackets |
22:20:46 | gradha | awww... procs won't accept tuples with different field names |
22:21:36 | Araq | if you feel adventurous, you could try: |
22:21:57 | Araq | proc test(something: type((1,1,1)) |
22:22:26 | Araq | this way 'something' gets an "unnamed" tuple without field names |
22:22:40 | Araq | which currently can't be accessed directly |
22:24:39 | gradha | maybe it would be nice if the tuples for the procs could "rename" the tuple being passed, in a way it's like the proc using a parameter name different from the caller's variable |
22:29:07 | Araq | this feature has been requested before, I don't like it |
22:29:35 | gradha | I don't like it either |
22:29:40 | Araq | tuple[key, val: int] is pretty different from tuple[x, y: int] for me |
22:30:10 | Araq | you can pass either (1, 2) or (x: 1, y: 2) though and I think that's fair enough already |
22:30:30 | * | XAMPP quit (Ping timeout: 252 seconds) |
22:32:13 | gradha | a marked proc with * is an exported proc |
22:32:25 | gradha | a marked const/variable with a * is an exported const/variable |
22:32:33 | gradha | is it correct to say both are exported symbols? |
22:32:42 | Araq | sure |
22:34:54 | fowl | whats the difference in putting the pragma after the type name or after the actual type |
22:35:09 | fowl | ie type TVector{.final, pure.} = object .. vs type TVector = object{.final, pure.} |
22:35:32 | Araq | there is no difference |
22:35:52 | Araq | however, it's wrong to put it after the name for 'ref object' |
22:36:08 | Araq | as the pragma refers to the object, not to the 'ref object' |
22:36:31 | Araq | however, it's pretty much an artifact of the implementation |
22:37:27 | fowl | ah ok |
22:40:11 | dom96 | Araq: Maybe we should have some syntax to specify unnamed tuples? |
22:40:22 | * | XAMPP joined #nimrod |
22:56:11 | * | gradha quit (Quit: bbl, have youtube videos to watch) |
23:02:21 | Araq | dom96: already on my todo |
23:03:18 | Araq | planned syntax is tuple(int, int) |
23:07:41 | dom96 | why not just tuple[int, int]? |
23:08:34 | Araq | because that's ambiguous I think |
23:08:49 | Araq | meh ... maybe it's not |
23:16:54 | Araq | good night |
23:17:02 | dom96 | same here |
23:19:54 | * | q66 quit (Read error: Connection reset by peer) |